Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

He is arguing against "linguistic programming" and apparently proposes a graphical form of component-based programming.

This has been proposed before, and here is why it will not work: Core to programming is creating abstractions and naming them. No other tool (that I know of) beside language can do that. Sure, a graphic environment might let you connect a bunch of pre-defined components on the same abstraction level to solve a task. However, what will you do if you want to reuse this construct as part of a larger program?

Graphical tools/programming can be used for very specific pre-defined tasks on a single abstraction level, but it will never be useful for general programming.



MATLAB's Simulink[1] is a graphical programming environment that allows you to create, name and reuse abstractions. Look at the picture[2] on their site for a simple example.

[1]: http://www.mathworks.com/products/simulink/

[2]: http://www.mathworks.com/cmsimages/sl_fig1_wl_15362.gif


That is cool, but I am arguing that when you work primarily with named abstractions you are back to linguistic programming. And general purpose programming is about building abstractions on top of abstractions.

But I haven't used Simulink, so I may be wrong.


What if the "components" are closed under the method of composition? You could probably get quite a bit of abstraction that way, not that it would be more powerful than what we already have which at least has this tool for creating abstraction...


But how would you represent your new composed component in the larger picture? Only solution I see is to give it a name that indicates the function. And pretty soon you are just moving boxes with names on around the canvas.


I agree. All of the graphical programming environments I've seen start to get cumbersome when you use them in unexpected or non-trivial ways.

And by "cumbersome," I mean it gets to the point that just using a programming language would be both simpler and clearer.


Then maybe we need a nice bijection between a nice language (a Lisp, perhaps?) and a nice graphical language (maybe a Lispier version of LabView or this COSA nonsense).




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: