4 ms·

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

by _mhr_ 10y ago

MikeTheGreat 10y ago
(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/ 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 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
ketralnis 10y ago
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
nerdponx 10y ago
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?
- _mhr_ 10y ago
  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?
  - nerdponx 10y ago
    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 http://www.graphviz.org/content/dot-language [1]: https://knsv.github.io/mermaid/ 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 https://en.wikipedia.org/wiki/Executable_UML
    - flor1s 10y ago
      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).
anigbrowl 10y ago
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 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.
- _mhr_ 10y ago
  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?
  - mcbits 10y ago
    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.
- posterboy 10y ago
  Modularity and dynamic typing are not unique to the visual editors like you describe (my limited experience was with labview).
- joe_the_user 10y ago
  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.

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

by _mhr_ 10y ago

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

(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/ 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 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

ketralnis 10y ago

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

nerdponx 10y ago

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?

_mhr_ 10y ago
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?
- nerdponx 10y ago
  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 http://www.graphviz.org/content/dot-language [1]: https://knsv.github.io/mermaid/ 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 https://en.wikipedia.org/wiki/Executable_UML
  - flor1s 10y ago
    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).

anigbrowl 10y ago

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 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.

_mhr_ 10y ago
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?
- mcbits 10y ago
  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.
posterboy 10y ago
Modularity and dynamic typing are not unique to the visual editors like you describe (my limited experience was with labview).
joe_the_user 10y ago
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.