Hacker News Reader

Comment by valine | Hacker News Reader

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

View on HN

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.

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.

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

Google also has something like this - https://i.imgur.com/bGTSDf5.png

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

Only if the code is trivial.

Max/MSP and PD are the goto products here.

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.

http://drakon-editor.sourceforge.net/

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

    sheet clipping_path
    {
    output:
        result          <== { path: path, flatness: flatness };

    interface:
        unlink flatness : 0.0 <== (path == empty) ? 0.0 : flatness;
        path            : 1;
    }

Isn't that Adam and Eve? I remember reading about this awhile 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."

Reply on news.ycombinator.com