9 ms·

Well, I've been programming for 20+ years across dozens of languages, and I can't understand what a single one of those diagrams is actually doing. But I can g

Well, I've been programming for 20+ years across dozens of languages, and I can't understand what a single one of those diagrams is actually doing. But I can grok the "textual code" example almost instantly, so fast that the difference in effort is almost laughable. I find the mental overhead in understanding the diagrams vs. "textual code" (that phrase makes me mentally chuckle each time I read it) is orders of magnitude higher. Sorry, but I simply don't buy what they're selling (and I say this as someone who lives and dies by the whiteboard). About the only thing out of this that looks actually useful for real-world software engineering is the visual profiling piece. If I were them, I'd probably throw out everything else they are working on and focus on that single piece alone, because that could be pretty useful.

wantreprenr007 11y ago
Etoys and many others have tried, maybe a good language and good IDE could have sufficient benefit, but I'm unsure how a UI would ever map to complex algorithms better than textual-interface paradigms. They can try and see, even if the likelihood of failure is unfortunately very high (until it's not). VPL seems currently like an utopia, apart from dashboards, configuration of control systems which naturally map to the real world and interface builders. One interesting VPL I ran into is a free fractal editor on iOS which lets one build up visual LOGO execution pipeline(s) of operations.
hodwik 11y ago
Work for a company that sells visual programming tools. Our customers absolutely love the functionality. A number of very large organizations are using it: from the military, to Netflix, HP, NASA, Pharmaceutical companies, and so on. The major benefit is that it lets process owners/managers, who aren't programmers, see and understand the code/architecture behind their processes, and suggest, or even make, important changes to those processes.
- wantreprenr007 11y ago
  LabVIEW?
- noobermin 11y ago
  How about a parser that creates a high level flow chart out of normal code?
  - wdanilo 11y ago
    Hi! I'm one of the guys behind Luna. The problem with such parser is that in vast majority of cases such graph is not readable by non-technical people, it is not interactive, does not visualise results and doesnt allow you to fast reconnecting components, switching and testing ideas. Moreover, it would be very hard to provide a tool that would draw graphs with the same layout of unchanged elements between iterations, so the layout would completely change after changing the text. In fact the problem originates from the source language - if you want to create a data flow graph out of imperative language, you'll hit a wall really fast, because the output would be messy and completely not understandable. Luna is purelly functional and designed in such way, the graphical representation matches the textual one in nice, seamless way.
    - noobermin 11y ago
      Right, the so-called "level of abstraction" is just an abstraction for textual hackers, one that other hackers get but a visualizer like a "c to dot" parser wouldn't. You're basically making the abstract higher order domain of discourse the programming "language".
smilekzs 11y ago
MatLab/Simulink feels natural for control system / DSP design.
xg15 11y ago
As you said, you have been programming for 20 years, therefore you likely have built a lot of experience and innate skills for dealing with text and considerably less for dealing with diagrams. I don't think this tells anything whether someone with the same amount of experience in diagrams might be able to make more of it than you with the equivalent text representation.
- jules 11y ago
  For what it's worth, mathematicians work on paper so they aren't constrained by anything, but they still use textual nested syntax instead of visual dataflow graphs.
  - yorwba 11y ago
    Ironically one of the first languages of formal logic used a visual syntax [1] but only parts of it remain in use: as ordinary textual operators (like the turnstile ⊢ or negation ¬). [1] https://en.wikipedia.org/wiki/Begriffsschrift https://en.wikipedia.org/wiki/Begriffsschrift
  - logicrook 11y ago
    That's a completely false analogy. We rely on text to represent what's best written as text. When you want to speak of a specific automaton or graph, you'll give a figure, unless the mathematical structure is really big (infinite maybe) and thus best described intentionally. Frege's notation is another example, although it was a bit idiosyncratic, but its legacy very much lives in proof theory. And then there are string diagrams, proof nets, ... Do you know anybody doing maths who could say "well I've never felt the need to use a figure in my life"?
    - paulhodge 11y ago
      > We rely on text to represent what's best written as text. Yes exactly. And if you look at the common methods for how knowledge is represented, in mathematics or any field really, it's very roughly around 80% knowledge as text and 20% graphs/diagrams/figures. An image can be extremely helpful and illustrative if appropriate. But almost nowhere do you see people communicate primarily with images. Text is king. I think if the programming environment doesn't embrace text as the primary input method, then it's not really good as a general-purpose environment; it'll only be successful in niches.
zby 11y ago
How much of that 20+ years of experience was in visual languages and how much it was in textual languages?
- JoeAltmaier 11y ago
  Like everyone, all of it. Doesn't bode well for this product idea.
- king_magic 11y ago
  How long did we try to get UML to work? There's a reason that visual representations haven't taken off, it's not like they haven't been tried before. And don't get me wrong - there are absolutely use cases for these types of tools, but at the end of the day, I think there are just too many challenges in visual representation for this to to work for "any application" (as Luna claims).
  - coldtea 11y ago
    UML solved a non problem, tied to a bureacratic software design method. And it wasn't even executable.
    - king_magic 11y ago
      And this feels like solving a non-problem as well, IMHO.
  - zby 11y ago
    Yeah - this is a hard problem and the chances are small. Nevertheless if you had 20+ years of experience in programming textual languages than it is no surprise that you understand them better than visual languages. That part of your argument does not seem valid.
coldtea 11y ago
>Well, I've been programming for 20+ years across dozens of languages, and I can't understand what a single one of those diagrams is actually doing. What exactly looks difficult to parse about the visual example going: read -> grade -> transform -> grade -> final touches -> write To me it's a very obvious image processing pipeline, reading the image, grading (in image processing terms this means color work, e.g. adding a hue to the highlights), doing a transformation (e.g. some rotation, or similar), grading again, and finally writing the result to disk. If you wonder what "exactly" they are doing, then unless you open each box (like the 2nd "grade" box is open), they're not meant to tell you. Closed, they're meant to give a high level overview of how your functions etc are connected. Think of it as seeing your code in your programming editor with the functions folded. The second example is also obvious. There's a selectable (by dropdown) input source, currently set to read posts from Twitter. Posts read are then fed into a (switchable on/off) filter, that either passes them all, or only keeps the one from Europe. Of course you need to spend a few minutes (or days) to familiarize yourself with the visual language (like you would for new terms if you met a new programming language), e.g. how the toggle icon means a "switchable" option.
- king_magic 11y ago
  Ok, so maybe I'm being a little over the top when I say "I can't understand what a single one of those diagrams is actually doing". I'm not stupid, and sure, I can grok 'em if I spent enough time digging into them. My point is - I could either waste time piecing together a visual diagram like that (which is going to be fairly different visually from use case to use case - e.g., image processing vs. text processing, resulting in more mental overhead) - or I could look at code, which is (for me, at least) simply much quicker and easier to understand (in many cases). Furthermore, these are idealized examples. Start throwing in error handling. Concurrent processes. I predict that diagrams that can fully capture complex systems will lean far more towards "visual overload" than not, and really, how useful is a tool like this at that point? Maybe something like this could be fine if it's just high-level processes, but it just falls apart the more detailed things get.
  - wdanilo 11y ago
bloaf 11y ago
I think the big application of visual programming is in domains where the concrete "unit operations" map neatly to programming functions. For example, things like this: https://www.aspentech.com/uploadedImages/Community/Blogs/Engineering/Ethanol_Process_Aspen_Plus.jpg?n=4458 https://www.aspentech.com/uploadedImages/Community/Blogs/Eng... That chemical process simulator lets engineers who are bad "text programmers" make complex chemical process simulations by giving them a library of functions that correspond neatly with the set of tools the engineer is used to thinking about. Indeed, other engineers can discern the intent of a flowsheet made in this tool faster than they could if they were looking at the text-code.

wantreprenr007 11y ago

Etoys and many others have tried, maybe a good language and good IDE could have sufficient benefit, but I'm unsure how a UI would ever map to complex algorithms better than textual-interface paradigms. They can try and see, even if the likelihood of failure is unfortunately very high (until it's not). VPL seems currently like an utopia, apart from dashboards, configuration of control systems which naturally map to the real world and interface builders. One interesting VPL I ran into is a free fractal editor on iOS which lets one build up visual LOGO execution pipeline(s) of operations.

hodwik 11y ago

Work for a company that sells visual programming tools. Our customers absolutely love the functionality. A number of very large organizations are using it: from the military, to Netflix, HP, NASA, Pharmaceutical companies, and so on. The major benefit is that it lets process owners/managers, who aren't programmers, see and understand the code/architecture behind their processes, and suggest, or even make, important changes to those processes.

wantreprenr007 11y ago
LabVIEW?
noobermin 11y ago
How about a parser that creates a high level flow chart out of normal code?
- wdanilo 11y ago
  Hi! I'm one of the guys behind Luna. The problem with such parser is that in vast majority of cases such graph is not readable by non-technical people, it is not interactive, does not visualise results and doesnt allow you to fast reconnecting components, switching and testing ideas. Moreover, it would be very hard to provide a tool that would draw graphs with the same layout of unchanged elements between iterations, so the layout would completely change after changing the text. In fact the problem originates from the source language - if you want to create a data flow graph out of imperative language, you'll hit a wall really fast, because the output would be messy and completely not understandable. Luna is purelly functional and designed in such way, the graphical representation matches the textual one in nice, seamless way.
  - noobermin 11y ago
    Right, the so-called "level of abstraction" is just an abstraction for textual hackers, one that other hackers get but a visualizer like a "c to dot" parser wouldn't. You're basically making the abstract higher order domain of discourse the programming "language".

smilekzs 11y ago

MatLab/Simulink feels natural for control system / DSP design.

xg15 11y ago

As you said, you have been programming for 20 years, therefore you likely have built a lot of experience and innate skills for dealing with text and considerably less for dealing with diagrams. I don't think this tells anything whether someone with the same amount of experience in diagrams might be able to make more of it than you with the equivalent text representation.

jules 11y ago
For what it's worth, mathematicians work on paper so they aren't constrained by anything, but they still use textual nested syntax instead of visual dataflow graphs.
- yorwba 11y ago
  Ironically one of the first languages of formal logic used a visual syntax [1] but only parts of it remain in use: as ordinary textual operators (like the turnstile ⊢ or negation ¬). [1] https://en.wikipedia.org/wiki/Begriffsschrift https://en.wikipedia.org/wiki/Begriffsschrift
- logicrook 11y ago
  That's a completely false analogy. We rely on text to represent what's best written as text. When you want to speak of a specific automaton or graph, you'll give a figure, unless the mathematical structure is really big (infinite maybe) and thus best described intentionally. Frege's notation is another example, although it was a bit idiosyncratic, but its legacy very much lives in proof theory. And then there are string diagrams, proof nets, ... Do you know anybody doing maths who could say "well I've never felt the need to use a figure in my life"?
  - paulhodge 11y ago
    > We rely on text to represent what's best written as text. Yes exactly. And if you look at the common methods for how knowledge is represented, in mathematics or any field really, it's very roughly around 80% knowledge as text and 20% graphs/diagrams/figures. An image can be extremely helpful and illustrative if appropriate. But almost nowhere do you see people communicate primarily with images. Text is king. I think if the programming environment doesn't embrace text as the primary input method, then it's not really good as a general-purpose environment; it'll only be successful in niches.

zby 11y ago

How much of that 20+ years of experience was in visual languages and how much it was in textual languages?

JoeAltmaier 11y ago
Like everyone, all of it. Doesn't bode well for this product idea.
king_magic 11y ago
How long did we try to get UML to work? There's a reason that visual representations haven't taken off, it's not like they haven't been tried before. And don't get me wrong - there are absolutely use cases for these types of tools, but at the end of the day, I think there are just too many challenges in visual representation for this to to work for "any application" (as Luna claims).
- coldtea 11y ago
  UML solved a non problem, tied to a bureacratic software design method. And it wasn't even executable.
  - king_magic 11y ago
    And this feels like solving a non-problem as well, IMHO.
- zby 11y ago
  Yeah - this is a hard problem and the chances are small. Nevertheless if you had 20+ years of experience in programming textual languages than it is no surprise that you understand them better than visual languages. That part of your argument does not seem valid.

coldtea 11y ago

>Well, I've been programming for 20+ years across dozens of languages, and I can't understand what a single one of those diagrams is actually doing. What exactly looks difficult to parse about the visual example going: read -> grade -> transform -> grade -> final touches -> write To me it's a very obvious image processing pipeline, reading the image, grading (in image processing terms this means color work, e.g. adding a hue to the highlights), doing a transformation (e.g. some rotation, or similar), grading again, and finally writing the result to disk. If you wonder what "exactly" they are doing, then unless you open each box (like the 2nd "grade" box is open), they're not meant to tell you. Closed, they're meant to give a high level overview of how your functions etc are connected. Think of it as seeing your code in your programming editor with the functions folded. The second example is also obvious. There's a selectable (by dropdown) input source, currently set to read posts from Twitter. Posts read are then fed into a (switchable on/off) filter, that either passes them all, or only keeps the one from Europe. Of course you need to spend a few minutes (or days) to familiarize yourself with the visual language (like you would for new terms if you met a new programming language), e.g. how the toggle icon means a "switchable" option.

king_magic 11y ago
Ok, so maybe I'm being a little over the top when I say "I can't understand what a single one of those diagrams is actually doing". I'm not stupid, and sure, I can grok 'em if I spent enough time digging into them. My point is - I could either waste time piecing together a visual diagram like that (which is going to be fairly different visually from use case to use case - e.g., image processing vs. text processing, resulting in more mental overhead) - or I could look at code, which is (for me, at least) simply much quicker and easier to understand (in many cases). Furthermore, these are idealized examples. Start throwing in error handling. Concurrent processes. I predict that diagrams that can fully capture complex systems will lean far more towards "visual overload" than not, and really, how useful is a tool like this at that point? Maybe something like this could be fine if it's just high-level processes, but it just falls apart the more detailed things get.
- wdanilo 11y ago

bloaf 11y ago

I think the big application of visual programming is in domains where the concrete "unit operations" map neatly to programming functions. For example, things like this: https://www.aspentech.com/uploadedImages/Community/Blogs/Engineering/Ethanol_Process_Aspen_Plus.jpg?n=4458 https://www.aspentech.com/uploadedImages/Community/Blogs/Eng... That chemical process simulator lets engineers who are bad "text programmers" make complex chemical process simulations by giving them a library of functions that correspond neatly with the set of tools the engineer is used to thinking about. Indeed, other engineers can discern the intent of a flowsheet made in this tool faster than they could if they were looking at the text-code.