6 ms·

I agree. Program execution is rarely linear too in a codebase of any real size, so viewing the source of a program as a linear page of text doesn't make much se

I agree. Program execution is rarely linear too in a codebase of any real size, so viewing the source of a program as a linear page of text doesn't make much sense. I think there's an opportunity for a big player in the dev tools space to create a mainstream visual programming language and associated tooling. Many are trying, like Luna (https://github.com/luna/luna-studio https://github.com/luna/luna-studio) and Dark (https://darklang.com/ https://darklang.com/) but I'm worried they're not established enough to gain traction. Unfortunately programming with a text editor has become so mainstream that investing time in learning potentially better tools nets a lot of friction and not to much gain.

pjmlp 7y ago
IDEs, shader editors, game design languages like Blueprint, LabVIEW are examples of mainstream tooling that aren't purely text based.
- disposedtrolley 7y ago
  True, but I don’t think there’s a general purpose programming language whose tooling expresses source code as visual flows of data, that people would use in place of Go, Python etc.
  - lonelappde 7y ago
    You mean like Scratch? Everybody thinks they want that until they try it on a real non-toy problem. https://en.m.wikipedia.org/wiki/Intentional_programming https://en.m.wikipedia.org/wiki/Intentional_programming
    - pjmlp 7y ago
      As someone that also has a background in digital circuits tooling, I think that the problem is the spaghetti codding that usually leads to monoliths. While on text based languages, lack of modularity is kind of hidden and only jumps at you when you try to actually change anything, on visual languages it jumps right at you when you open a project. Ideally, anything that requires panning or zooming, should be packed into their own little reusable building block, instead many try to package as much as they can into a single screen.
      - disposedtrolley 7y ago
        > While on text based languages, lack of modularity is kind of hidden and only jumps at you when you try to actually change anything, on visual languages it jumps right at you when you open a project. I've worked on some projects using Node RED (https://nodered.org/ https://nodered.org/) and have found this to be very true. It's painfully obvious that you're in for a fun ride when the code is literally spaghetti.
    - disposedtrolley 7y ago
      No, not Scratch :P I think programmers should be trusted to write code as text, but the IDE should in some way help visualise how data flows through the system. Intentional programming seems interesting. Reminds me a little of BDD frameworks like Cucumber (https://cucumber.io/docs https://cucumber.io/docs)
  - pjmlp 7y ago
    That is exactly how LabVIEW and Blueprint are used.
    - disposedtrolley 7y ago
      But they're still specialised tools which work well in their respective domains. You wouldn't build a web API with LabVIEW.
      - pjmlp 7y ago
        No you would build it with Biztalk or OutSystems.
      - Reelin 7y ago
        I promise I'm not trying to pick on you here, but LabVIEW actually offers a module specifically for building web-based interfaces for your equipment (http://www.ni.com/en-us/shop/select/labview-nxg-web-module http://www.ni.com/en-us/shop/select/labview-nxg-web-module). I'll agree that graphical languages don't seem to have caught on for general purpose programming, but some reasonably powerful ones certainly exist at this point. Speculating as to why, I admit I have no intention of picking up a graphical language for my next project. Partly it's familiarity (I don't know what I'm missing), partly it's learning curve (expending effort when my current tools already work), and there's definitely concern about the ecosystem (manually writing bindings is never fun). There are also existing tools whose functionality overlaps to some extent - I've seen (and briefly played with) tools for some languages that will create flow diagrams from your source code. It seems like graphic-centric languages exist, but only gain widespread adoption for specific tasks that are frustrating or tedious to address without them.
        LukeShu 7y ago
        When I had to suffer through LabVIEW (2009ish) my notion was that it LabVIEW-the-language might have potential to be a decent language, and that it was a shame that the only possible IDE for it (LabVIEW-the-program) was so horrible. The expensive license can't be helping mindshare, either. (Now, that was long enough ago that I forget most of my specific opinions, and many of them are probably now outdated.)
  - Reelin 7y ago
    It's not purely graphical, but MATLAB with Simulink definitely qualifies as both mainstream and general purpose from my perspective. A feature equivalent FOSS alternative would be nice though...
    - disposedtrolley 7y ago
      I've never dabbled with MATLAB or Simulink before (and I don't think I have the background to do so, at least for Simulink!) but I did just skim some of the tutorial videos. What stood out to me was the instant feedback that's provided when the pipeline was modified; you can immediately see the ramifications of your actions.
notduncansmith 7y ago
> viewing the source of a program as a linear page of text doesn't make much sense. I don’t think we really view a file of source code as a linear page of text though, right? It’s a tree. Sibling nodes are often laid out either horizontally or vertically, and children are often wrapped in some type of brace and/or indented, maybe delimited. I think the fact that editors usually a) align the textual boundaries of tree nodes, and b) allow syntactically/semantically-invalid states, sometimes gets people thinking about editing a character stream instead of a semantic tree.
boomlinde 7y ago
As far as I'm concerned, that the source code is divided into files of linear streams of characters is a technical detail. My navigation isn't linear and my editing often isn't, and the editor I use goes through great lengths to enable just that. Having used node-based programming environments extensively (Max, Reaktor) I am not convinced that that there is a ergonomically sound alternative to just writing the code in linear text files, but admit that there are probably domains where it is more suitable. I found it tedious and straining, particularly when you have to use both mouse and keyboard.

pjmlp 7y ago

IDEs, shader editors, game design languages like Blueprint, LabVIEW are examples of mainstream tooling that aren't purely text based.

disposedtrolley 7y ago
True, but I don’t think there’s a general purpose programming language whose tooling expresses source code as visual flows of data, that people would use in place of Go, Python etc.
- lonelappde 7y ago
  You mean like Scratch? Everybody thinks they want that until they try it on a real non-toy problem. https://en.m.wikipedia.org/wiki/Intentional_programming https://en.m.wikipedia.org/wiki/Intentional_programming
  - pjmlp 7y ago
    As someone that also has a background in digital circuits tooling, I think that the problem is the spaghetti codding that usually leads to monoliths. While on text based languages, lack of modularity is kind of hidden and only jumps at you when you try to actually change anything, on visual languages it jumps right at you when you open a project. Ideally, anything that requires panning or zooming, should be packed into their own little reusable building block, instead many try to package as much as they can into a single screen.
    - disposedtrolley 7y ago
      > While on text based languages, lack of modularity is kind of hidden and only jumps at you when you try to actually change anything, on visual languages it jumps right at you when you open a project. I've worked on some projects using Node RED (https://nodered.org/ https://nodered.org/) and have found this to be very true. It's painfully obvious that you're in for a fun ride when the code is literally spaghetti.
  - disposedtrolley 7y ago
    No, not Scratch :P I think programmers should be trusted to write code as text, but the IDE should in some way help visualise how data flows through the system. Intentional programming seems interesting. Reminds me a little of BDD frameworks like Cucumber (https://cucumber.io/docs https://cucumber.io/docs)
- pjmlp 7y ago
  That is exactly how LabVIEW and Blueprint are used.
  - disposedtrolley 7y ago
    But they're still specialised tools which work well in their respective domains. You wouldn't build a web API with LabVIEW.
    - pjmlp 7y ago
      No you would build it with Biztalk or OutSystems.
    - Reelin 7y ago
      I promise I'm not trying to pick on you here, but LabVIEW actually offers a module specifically for building web-based interfaces for your equipment (http://www.ni.com/en-us/shop/select/labview-nxg-web-module http://www.ni.com/en-us/shop/select/labview-nxg-web-module). I'll agree that graphical languages don't seem to have caught on for general purpose programming, but some reasonably powerful ones certainly exist at this point. Speculating as to why, I admit I have no intention of picking up a graphical language for my next project. Partly it's familiarity (I don't know what I'm missing), partly it's learning curve (expending effort when my current tools already work), and there's definitely concern about the ecosystem (manually writing bindings is never fun). There are also existing tools whose functionality overlaps to some extent - I've seen (and briefly played with) tools for some languages that will create flow diagrams from your source code. It seems like graphic-centric languages exist, but only gain widespread adoption for specific tasks that are frustrating or tedious to address without them.
      - LukeShu 7y ago
        When I had to suffer through LabVIEW (2009ish) my notion was that it LabVIEW-the-language might have potential to be a decent language, and that it was a shame that the only possible IDE for it (LabVIEW-the-program) was so horrible. The expensive license can't be helping mindshare, either. (Now, that was long enough ago that I forget most of my specific opinions, and many of them are probably now outdated.)
- Reelin 7y ago
  It's not purely graphical, but MATLAB with Simulink definitely qualifies as both mainstream and general purpose from my perspective. A feature equivalent FOSS alternative would be nice though...
  - disposedtrolley 7y ago
    I've never dabbled with MATLAB or Simulink before (and I don't think I have the background to do so, at least for Simulink!) but I did just skim some of the tutorial videos. What stood out to me was the instant feedback that's provided when the pipeline was modified; you can immediately see the ramifications of your actions.

notduncansmith 7y ago

> viewing the source of a program as a linear page of text doesn't make much sense. I don’t think we really view a file of source code as a linear page of text though, right? It’s a tree. Sibling nodes are often laid out either horizontally or vertically, and children are often wrapped in some type of brace and/or indented, maybe delimited. I think the fact that editors usually a) align the textual boundaries of tree nodes, and b) allow syntactically/semantically-invalid states, sometimes gets people thinking about editing a character stream instead of a semantic tree.

boomlinde 7y ago

As far as I'm concerned, that the source code is divided into files of linear streams of characters is a technical detail. My navigation isn't linear and my editing often isn't, and the editor I use goes through great lengths to enable just that. Having used node-based programming environments extensively (Max, Reaktor) I am not convinced that that there is a ergonomically sound alternative to just writing the code in linear text files, but admit that there are probably domains where it is more suitable. I found it tedious and straining, particularly when you have to use both mouse and keyboard.