4 ms·

Developers need to start taking Flowcharts, UML more seriously - I think most people don't see it's full power.

by suyash 10y ago

nerdponx 10y ago
I commented on this recently: https://news.ycombinator.com/item?id=13822441 https://news.ycombinator.com/item?id=13822441 It seems the only "visual programming" environments are either domain-specific, esoteric, intended for children, or some combination of the above. And I think that's a damn shame. I'm a data scientist, not a computer scientist: give me a suitable abstraction layer on top of code, and I will use it. I think flowchart-based programming is one way, maybe the only way, to make this possible.
- deleted 10y ago
  [deleted]
- flor1s 10y ago
  I used to be in the camp thinking that we should be using way more visual programming tools. I even worked at a startup company building a "software factory" (essentially a tool for generating a DB and an accompanying front-end which can load a metamodel for that DB and builds an interface for it). Nowadays I do think that visual programming is better for domain-specific purposes. I also think that for many purposes code is a suitable abstraction layer on top of machine instructions. Meanwhile abstraction means removing nonessential detail, however for a general purpose programming language one cannot predict which features are essential in a specific application. That's why visual programming is working in domain-specific areas, because in that case you can often decide which details are nonessential.
- patrickg_zill 10y ago
  There is the Russian DRAKON programming language, might be worth having a look at it.
- Analemma_ 10y ago
  I don't know about this. At my last job, one of the very first problems dropped in my lap was to fix a debugging tool that had been mostly written in Workflow Foundation, a flowchart-based programming environment for .NET that isn't domain-specific, esoteric, or intended for children. It was the tenth circle of Hell and almost drove me to a nervous breakdown in my first month on the job. Despite how often I quote Joel Spolsky's "never rewrite the project from scratch" essay, I threw the whole thing out and wrote it again, and was much better off for doing so. Now, certainly the specific failings of WF, and the bast^H^H^H^H person who wrote the tool were partially to blame here, but even with all that in mind, the experience has permanently soured me on visual programming. It has all kinds of flaws-- it's harder to reason about, harder to debug, harder to comment, and harder to quickly modify that plain old source code. If there was some trade-off, an upside for all that trouble, maybe it would be worth it, but I can't see one.
- michaelchisari 10y ago
  Until someone can come up with a way to draw faster than we can type, programming will always tend towards text.
  - nerdponx 10y ago
    I'd love to get an MVP for this kind of product up and running and actually do user speed testing. My money would be on comparable speed in first-time users, and higher productivity in practiced users. Of course, a GUI's performance would highly depend on its user experience. I wonder how an existing graph manipulation program like Gephi might fare, versus something specifically optimized for this task.
- lacampbell 10y ago
  I am not sure I see much advantage in visual programming on the small scale, ie little boxes for control flow. But I badly want it for bigger, architectural concerns. Why do our IDEs just display lists of files in a pane? I've often day dreamed about an IDE where the system is visually modeled as a network of modules/objects, with edges representing dependencies, and you'd double click on a module/object to edit its source code. Somewhat relevant: http://prog21.dadgum.com/69.html http://prog21.dadgum.com/69.html
- jacquesm 10y ago
  In a way APL is 'flowchart based programming', the flow is so simple it can be used to express what otherwise would be a program with multiple constructs on a single line. Each APL character then becomes a 'box' in your flowchart. Sort of a minimalist graphical representation of what the program does. A unix command line gives me a similar feeling with processes feeding their output into other processes each doing some kind of transformation on their input with the | character functioning as the lines in a flowchart. Now obviously that has some differences with an actual flowchart (such as 'if' statements) but the effect is close enough that there are some parallels.
- jeffwass 10y ago
  Have you taken a look at LabVIEW? I used it pretty heavily back in grad school. It's a graphical programming language, you connect wires between modules and operators. Its weird to get used to at first, especially if youre proficient in text-based programming languages, but when you get a feel for letting the program flow drive the logic, you can do some pretty powerful things. The general idea is that you have a "front panel" that controls user input, and then the back-end programming. Eg, Boolean inputs can be a variety of switches, outputs can be lights and LED's. Floating inputs can be knobs and sliders, outputs can be displays, meters, bar graphs. Very easy to add plots that update in real time. It's popular with lab research and data acquisition users, since you can easily whip up nice UI's, and many producers of laboratory hardware provide LabVIEW drivers. You can also easily create advanced techniques or data structures too. Eg, wrap a state machine inside a queue widget, for a "Queued State Machine". Some drawbacks are that it's proprietary commercial software, and the 'code' can easily become a tangled mess of wires. http://www.ni.com/labview/ http://www.ni.com/labview/ Example implementation of a state machine : http://www.ni.com/tutorial/7595/en/ http://www.ni.com/tutorial/7595/en/
- simonh 10y ago
  Visual or graphical programming environments have useful applications, but I think they're always going to be niche. My kids had a lot of fun with Scratch for example, it's a lovely way to learn programming. The big problem I see with visual programming tools though is that they prescribe the tools you can use to work on the system. I can work on the same Python scripts on Windows, Unix and iOS, in a windowing environment or a console. I can use Submlime Text, Vi, EMACS, Notepad++, whatever I want and configure them however I like. Syntax highlighting even visually distinguishes different aspects of the code in useful ways that even parallels some of the features of graphical coding environments. I can even generate code from other code, or use refactoring tools. If your graphical tool generates text or something like XML then ok, you can do processing on that, but which is authoritative? The graphical representation or the underlying document? Now all you have is a fancy editor for what's really a text format anyway. So I think in a lot of ways visual tools complicate things in some ways as much or more than they simplify them in others. I suspect that the domains in which these trade offs prove to be worthwhile are fairly limited.
willtim 10y ago
I use the odd simple flowchart for documentation, but it's not a concise notation. It has no agreed method for abstraction and composition, and generally does not scale.

Developers need to start taking Flowcharts, UML more seriously - I think most people don't see it's full power.

by suyash 10y ago

Developers need to start taking Flowcharts, UML more seriously - I think most people don't see it's full power.

I commented on this recently: https://news.ycombinator.com/item?id=13822441 https://news.ycombinator.com/item?id=13822441 It seems the only "visual programming" environments are either domain-specific, esoteric, intended for children, or some combination of the above. And I think that's a damn shame. I'm a data scientist, not a computer scientist: give me a suitable abstraction layer on top of code, and I will use it. I think flowchart-based programming is one way, maybe the only way, to make this possible.

deleted 10y ago
[deleted]
flor1s 10y ago
I used to be in the camp thinking that we should be using way more visual programming tools. I even worked at a startup company building a "software factory" (essentially a tool for generating a DB and an accompanying front-end which can load a metamodel for that DB and builds an interface for it). Nowadays I do think that visual programming is better for domain-specific purposes. I also think that for many purposes code is a suitable abstraction layer on top of machine instructions. Meanwhile abstraction means removing nonessential detail, however for a general purpose programming language one cannot predict which features are essential in a specific application. That's why visual programming is working in domain-specific areas, because in that case you can often decide which details are nonessential.
patrickg_zill 10y ago
There is the Russian DRAKON programming language, might be worth having a look at it.
Analemma_ 10y ago
I don't know about this. At my last job, one of the very first problems dropped in my lap was to fix a debugging tool that had been mostly written in Workflow Foundation, a flowchart-based programming environment for .NET that isn't domain-specific, esoteric, or intended for children. It was the tenth circle of Hell and almost drove me to a nervous breakdown in my first month on the job. Despite how often I quote Joel Spolsky's "never rewrite the project from scratch" essay, I threw the whole thing out and wrote it again, and was much better off for doing so. Now, certainly the specific failings of WF, and the bast^H^H^H^H person who wrote the tool were partially to blame here, but even with all that in mind, the experience has permanently soured me on visual programming. It has all kinds of flaws-- it's harder to reason about, harder to debug, harder to comment, and harder to quickly modify that plain old source code. If there was some trade-off, an upside for all that trouble, maybe it would be worth it, but I can't see one.
michaelchisari 10y ago
Until someone can come up with a way to draw faster than we can type, programming will always tend towards text.
- nerdponx 10y ago
  I'd love to get an MVP for this kind of product up and running and actually do user speed testing. My money would be on comparable speed in first-time users, and higher productivity in practiced users. Of course, a GUI's performance would highly depend on its user experience. I wonder how an existing graph manipulation program like Gephi might fare, versus something specifically optimized for this task.
lacampbell 10y ago
I am not sure I see much advantage in visual programming on the small scale, ie little boxes for control flow. But I badly want it for bigger, architectural concerns. Why do our IDEs just display lists of files in a pane? I've often day dreamed about an IDE where the system is visually modeled as a network of modules/objects, with edges representing dependencies, and you'd double click on a module/object to edit its source code. Somewhat relevant: http://prog21.dadgum.com/69.html http://prog21.dadgum.com/69.html
jacquesm 10y ago
In a way APL is 'flowchart based programming', the flow is so simple it can be used to express what otherwise would be a program with multiple constructs on a single line. Each APL character then becomes a 'box' in your flowchart. Sort of a minimalist graphical representation of what the program does. A unix command line gives me a similar feeling with processes feeding their output into other processes each doing some kind of transformation on their input with the | character functioning as the lines in a flowchart. Now obviously that has some differences with an actual flowchart (such as 'if' statements) but the effect is close enough that there are some parallels.
jeffwass 10y ago
Have you taken a look at LabVIEW? I used it pretty heavily back in grad school. It's a graphical programming language, you connect wires between modules and operators. Its weird to get used to at first, especially if youre proficient in text-based programming languages, but when you get a feel for letting the program flow drive the logic, you can do some pretty powerful things. The general idea is that you have a "front panel" that controls user input, and then the back-end programming. Eg, Boolean inputs can be a variety of switches, outputs can be lights and LED's. Floating inputs can be knobs and sliders, outputs can be displays, meters, bar graphs. Very easy to add plots that update in real time. It's popular with lab research and data acquisition users, since you can easily whip up nice UI's, and many producers of laboratory hardware provide LabVIEW drivers. You can also easily create advanced techniques or data structures too. Eg, wrap a state machine inside a queue widget, for a "Queued State Machine". Some drawbacks are that it's proprietary commercial software, and the 'code' can easily become a tangled mess of wires. http://www.ni.com/labview/ http://www.ni.com/labview/ Example implementation of a state machine : http://www.ni.com/tutorial/7595/en/ http://www.ni.com/tutorial/7595/en/
simonh 10y ago
Visual or graphical programming environments have useful applications, but I think they're always going to be niche. My kids had a lot of fun with Scratch for example, it's a lovely way to learn programming. The big problem I see with visual programming tools though is that they prescribe the tools you can use to work on the system. I can work on the same Python scripts on Windows, Unix and iOS, in a windowing environment or a console. I can use Submlime Text, Vi, EMACS, Notepad++, whatever I want and configure them however I like. Syntax highlighting even visually distinguishes different aspects of the code in useful ways that even parallels some of the features of graphical coding environments. I can even generate code from other code, or use refactoring tools. If your graphical tool generates text or something like XML then ok, you can do processing on that, but which is authoritative? The graphical representation or the underlying document? Now all you have is a fancy editor for what's really a text format anyway. So I think in a lot of ways visual tools complicate things in some ways as much or more than they simplify them in others. I suspect that the domains in which these trade offs prove to be worthwhile are fairly limited.

willtim 10y ago

I use the odd simple flowchart for documentation, but it's not a concise notation. It has no agreed method for abstraction and composition, and generally does not scale.