3 ms·

> “The line of code that the developer could write the fastest… maintain the cheapest… that never breaks for the user, is the line of code the developer never h

by valine 11y ago

> “The line of code that the developer could write the fastest… maintain the cheapest… that never breaks for the user, is the line of code the developer never had to write.” I don't think graphical programming has ever really solved this problem. The only time interface builder is useful is with really small applications. Once you have any amount of complexity you're much better off creating your interface programmatically. Interface builder is just another thing I have to learn, and relearn when Apple decides to change it 2 years from now. If Apple partners with Adobe and creates an interface builder / photoshop hybrid, maybe we could talk. If I could connect my designers psd file directly to a core data backend, that might provide some legitimate time savings.

Joeri 11y ago
Graphical programming cannot make the activity of programming easier. Programming is encoding a system of rules. It doesn't matter whether you do it by point-and-click or by written language, the rules remain the same. The "ease" of point-and-click is discoverability of possible rules and intuitive representation of said rules, but that's nothing that a good IDE can't do at the code level just as well.
- 21 11y ago
  Yes it can. Dragging and dropping to create a data processing pipeline is much faster and less error prone than writing the equivalent code. An easy to see example are audio pipeline building software, where you hook together various components - http://factmag-images.s3.amazonaws.com/wp-content/uploads/2015/10/reaktor-6-screen-b.jpg http://factmag-images.s3.amazonaws.com/wp-content/uploads/20... Google also has something like this - https://i.imgur.com/bGTSDf5.png https://i.imgur.com/bGTSDf5.png
  - theoh 11y ago
    Has anyone tried to write functional programs (not necessarily of the reactive FRP variety) this way? I'm trying to imagine how it would play with algebraic data types and pattern matching. (I feel Haskell syntax is dreadful once you start trying to achieve anything beyond "functional pearl"-type material.)
  - TheOtherHobbes 11y ago
    Only if the code is trivial. Max/MSP and PD are the goto products here. https://cycling74.com/max7/ https://cycling74.com/max7/ They're incredibly horrible for anything complicated. Even a simple for loop requires multiple clicks to select the modules you need, multiple lines of typing to set their parameters, and multiple mouse movements to define the connections. It literally takes about around ten times longer than typing. Neither handles encapsulation elegantly and transparently. (Max 7 is the best effort yet, but it's still not pain free.) They have some nice DSP features for building DSP chains, and as long as you stick with those they're useful. But they're an instant nightmare if you try to do anything with logic that would be trivial in written code. Reaktor doesn't compare because it just does the DSP thing. It's a very simple pipeline. The takeaway is that simple module composition is easy, but non-trivial logic flows with many data types can be very challenging indeed.
- digi_owl 11y ago
  http://drakon-editor.sourceforge.net/ http://drakon-editor.sourceforge.net/
21 11y ago
Interestingly, Adobe used (not sure now) for PS interface a programmatic interface builder, where you describe with text the general layout of the dialog and the various fields/interactions. This library is open-sourced - http://stlab.adobe.com/group__asl__overview.html#asl_overview_adam_and_eve_adam http://stlab.adobe.com/group__asl__overview.html#asl_overvie... sheet clipping_path { output: result <== { path: path, flatness: flatness }; interface: unlink flatness : 0.0 <== (path == empty) ? 0.0 : flatness; path : 1; }
- seanmcdirmid 11y ago
  Isn't that Adam and Eve? I remember reading about this awhile ago.
- throwaway_xx9 11y ago
  I went to a talk by the author of their auto-layout engine. He would always tell his manager, "You can give me two weeks to enhance the tool, or two weeks to do it manually. Your choice."
vitd 11y ago
I work on a product that has millions of lines of code and has been in existence for over 15 years. It uses Interface Builder and has a very complex interface. IB works just fine. It has quirks like any other tool you'll use, but dealing with it is no worse than dealing with the changes to compilers, graphics drivers, OSes, etc.

by valine 11y ago

Joeri 11y ago

Graphical programming cannot make the activity of programming easier. Programming is encoding a system of rules. It doesn't matter whether you do it by point-and-click or by written language, the rules remain the same. The "ease" of point-and-click is discoverability of possible rules and intuitive representation of said rules, but that's nothing that a good IDE can't do at the code level just as well.

21 11y ago
Yes it can. Dragging and dropping to create a data processing pipeline is much faster and less error prone than writing the equivalent code. An easy to see example are audio pipeline building software, where you hook together various components - http://factmag-images.s3.amazonaws.com/wp-content/uploads/2015/10/reaktor-6-screen-b.jpg http://factmag-images.s3.amazonaws.com/wp-content/uploads/20... Google also has something like this - https://i.imgur.com/bGTSDf5.png https://i.imgur.com/bGTSDf5.png
- theoh 11y ago
  Has anyone tried to write functional programs (not necessarily of the reactive FRP variety) this way? I'm trying to imagine how it would play with algebraic data types and pattern matching. (I feel Haskell syntax is dreadful once you start trying to achieve anything beyond "functional pearl"-type material.)
- TheOtherHobbes 11y ago
  Only if the code is trivial. Max/MSP and PD are the goto products here. https://cycling74.com/max7/ https://cycling74.com/max7/ They're incredibly horrible for anything complicated. Even a simple for loop requires multiple clicks to select the modules you need, multiple lines of typing to set their parameters, and multiple mouse movements to define the connections. It literally takes about around ten times longer than typing. Neither handles encapsulation elegantly and transparently. (Max 7 is the best effort yet, but it's still not pain free.) They have some nice DSP features for building DSP chains, and as long as you stick with those they're useful. But they're an instant nightmare if you try to do anything with logic that would be trivial in written code. Reaktor doesn't compare because it just does the DSP thing. It's a very simple pipeline. The takeaway is that simple module composition is easy, but non-trivial logic flows with many data types can be very challenging indeed.
digi_owl 11y ago
http://drakon-editor.sourceforge.net/ http://drakon-editor.sourceforge.net/

21 11y ago

Interestingly, Adobe used (not sure now) for PS interface a programmatic interface builder, where you describe with text the general layout of the dialog and the various fields/interactions. This library is open-sourced - http://stlab.adobe.com/group__asl__overview.html#asl_overview_adam_and_eve_adam http://stlab.adobe.com/group__asl__overview.html#asl_overvie... sheet clipping_path { output: result <== { path: path, flatness: flatness }; interface: unlink flatness : 0.0 <== (path == empty) ? 0.0 : flatness; path : 1; }

seanmcdirmid 11y ago
Isn't that Adam and Eve? I remember reading about this awhile ago.
throwaway_xx9 11y ago
I went to a talk by the author of their auto-layout engine. He would always tell his manager, "You can give me two weeks to enhance the tool, or two weeks to do it manually. Your choice."

vitd 11y ago

I work on a product that has millions of lines of code and has been in existence for over 15 years. It uses Interface Builder and has a very complex interface. IB works just fine. It has quirks like any other tool you'll use, but dealing with it is no worse than dealing with the changes to compilers, graphics drivers, OSes, etc.