Hacker News Reader

Comment by _mhr_ | Hacker News Reader

How would you prefer to see computers programmed, besides code?

Personally I like diagrammatic programming, most often seen for signal processing workflows in VFX or audio synthesis. My favorite platform from a design pov is a robotics IDE now called Flowstone. It's based around ruby iirc; in an earlier version you could also write modules in C or assembler. http://www.dsprobotics.com/flowstone.html

There are upsides an downsides to this paradigm of course; one downside is that it's not obvious how to read control flows at first. On the upside, having all your functions available in modular form makes if far easier to explore and program using high-level concepts. What I hate about conventional programming is all the typing and having to remember all the function parameters, calling conventions etc., I want the computer to do that for me. Writing code in an IDE is about as enticing as making my own Lego bricks from scratch.

I agree with you, but to play devil's advocate: isn't the purpose of an IDE to keep you from having to remember parameters and stuff like that? Autocomplete?

IDEs turn textual languages into quasi graphical languages. E.g. a porthole showing a symbol's references across the project, where you can seamlessly edit the code in some distant file somewhere. Or when a bulky Java object is collapsed down to look like a lambda. Autocomplete, too, is getting graphical with icons and tabs.

Unfortunately they're still constrained by the language itself being designed around text. A lot more could be done with a language+IDE developed in tandem, with the IDE's needs always taking precedence in decisions.

Modularity and dynamic typing are not unique to the visual editors like you describe (my limited experience was with labview).

Yeah,

I would agree that diagrammatic programming is a process that inherently seems like it would solve the opaqueness of programming.

But I'd say this paradigm is just as much inherently limited and not useful for "serious" work. This is because the multitude of "parts" that a computer program has exist in too large a space to be visually represented and because the details don't really follow our intuits for two or three dimensional objects.

I wouldn't know if URI diagrams are (still?) used heavily in industry, but they are taught. Those work architectural, or generative but limited.

There have been a few attempts at visual programming languages. None that have really panned out to the mainstream but I don't think that's a failure of the idea entirely. Some things like complex spreadsheets or MS Access applications have clear analogies to programming but are more visual in nature. And there are things like Mac's Automater that have a lot of theoretical potential. Some things like bash pipelines could be really amenable to a more visual style as well

Writing code as text is fine. But I'd love to see the idea of a "call graph" become a first-class citizen as a programming tool. What's the point of building modular abstractions if you still need to glue them together with text?

Can you elaborate on what you mean by that? What would it mean to be able to manipulate the call graph? In which situations would that be useful?

Basically, a compiler that translates UML (e.g. in GraphViz DOT format [0], or Mermaid format [1]) to actual code.

If I have a bunch of libraries that more or less do what I want and all my program has to do is glue them together (this is common in scripting scenarios), then I could just draw it up in a GUI like Gephi and cross-compile it to a script, instead of writing the script by hand. Complete separation of data flow from the implementation of that flow.

I imagine you could do this pretty easily in a language like Haskell (since everything is a function call) or Lisp (where everything is "data") so you don't have to implement special logic to figure out how particular nodes should behave. You could also do this for "explicit" DAG engines like Make, Airflow, and Luigi.

[0]: http://www.graphviz.org/content/dot-language [1]: https://knsv.github.io/mermaid/

EDIT: this ([2]) turned up in my Googling. I suppose there's a good reason nobody uses it?

[2]: https://en.wikipedia.org/wiki/Executable_UML

Many UML modeling tools like Visual Paradigm allow you to generate code based on your models. One big problem in this approach is that it is hard to make changes beyond that. Some people want to customize the generated code, but that means that if you want to make changes to the diagram you somehow have to merge back the changes which were manually made.

If you are interested in this you should check out a company called Mendix, which is building a SaaS platform for building applications using graphical tools, and the Eclipse Modelling Framework, which is a huge project aiming to add modelling and code generation capabilities to Eclipse (in my experience it is slightly academic, in the sense that you often encounter bugs or cryptic errors in practical use).

(I, personally, am just fine with textual code. I'd be open to new stuff but for now I like typing my code in)

There's a bunch of 'block based' programming languages that some educators are using to teach programming. Searching for 'Blockly' turned up https://developers.google.com/blockly/, but they're definitely not the only game in town.

Way back when Charles Simonyi created this thing he called "Intentional Programming" (https://en.wikipedia.org/wiki/Intentional_programming). As near as I can tell the big idea is that instead of encoding the program in textual source code you'd instead store the program in a parse tree/etc (I'm not super-familiar with compiler details - it's some sort of tree that represents the program, semantically). Your IDE would then enable you to interact with it however you wanted (as text, as blocks, etc, etc).

So yeah - text is king, but there's a lot of other really interesting options out there, too

Reply on news.ycombinator.com