Why I Hate All Computer Programming Languages
rebelscience.blogspot.com
rebelscience.blogspot.com
Programming is not the only discipline that has adopted specialized languages. Disciplines like music and mathematics also use their own unique descriptive notations. Programming is not hard because of programming languages; on the contrary, learning a programming language is by far the easiest step in learning to program. Becoming a good musician, or a good mathematician, takes years of practise and study. Programming is no different.
That's not to say you can't simplify programming, in the same way that Guitar Hero and Wii Music simplify music. But you can only do this by hiding complexity, by restricting the user to a small subset of a very broad subject. This can be very useful; but you can't replace programming altogether using this technique, any more than Guitar Hero has made the electric guitar obsolete.
These things too can become arbitrarily complex within their specific domains (Csound being a prime example), but most of the innovation is devoted to making it easier for the mediocre player to obtain interesting musical results, at the expense of some flexibility or authenticity. This can aid learning to some degree, and substantially democratizes toolsets - for example, although I have neither the space nor the cash to buy a piano, I have access to such good emulations that it doesn't matter. Of greater importance than either of these are the innovative possibilities for creating new kinds of music that are not achievable by conventional means - even if you dislike electronic music, you probably enjoy the contributions from of audio technology to film soundtracks.
You are quite right that electronic emulations will not and should not displace real instruments like guitars, trumpets, drums etc., no matter what their level of sophistication. The same is true is of domain-specific modeling tools and pure programming. However, I submit that within their limitations, such tools have the potential to vastly increase overall productivity. And as I've observed before, patch-based 'analog computers' have a trick or two up their sleeve yet: now that cheap digital von Neumann computers are a commodity, people are doing interesting and usual things with the emulated versions that would have been prohibitively expensive in the past.
Actually the latest version of Guitar Hero ('World Tour') does include the ability to record, edit & share. It's very limited of course.
http://www.rebelscience.org/Seven/bible.html http://www.rebelscience.org/Crackpots/notorious.htm
He has a good sense of humor about it though and even links to this Google search:
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.
[1]: http://www.mathworks.com/products/simulink/
[2]: http://www.mathworks.com/cmsimages/sl_fig1_wl_15362.gif
But I haven't used Simulink, so I may be wrong.
And by "cumbersome," I mean it gets to the point that just using a programming language would be both simpler and clearer.
For the last couple of weeks I've been trying the best I can to read everything under the sun that has to do with alternative computer architectures. I know that just like in 'regular' science there is a fringe to computing, but what if there are viable alternatives to the von Neumann architecture and we just stopped looking for them ?
Even a really good alternative way to program existing computers would already be quite a step.
I don't have enough low level programming experience to say one is better than the other or that the Harvard architecture is as flexible as the Von Neumann architecture has proved to be in practice. I am just not that good of a computer scientist.
I can say, though, that I found Harvard an awful lot easier to get to grips with conceptually and fun to program - perhaps because I could map me+tool+task onto instruction memory + DSP + data.
If you are seriously interested in this I recommend getting hold of a DSP evaluation board for about $100. Analog Devices make the Sharc (and many others) which some people like because of their floating point capability; Motorola's 56k DSP series are fixed point which makes for a steeper learning curve, but many people say they're a better architecture. I learned 56k DSP. You could also look into PIC uControllers.
Please summarize and share your findings when you reach some sort of milestone.
The original poster of the article has some very interesting things to say about the way computers are being programmed today. I'm not sure if that means we will depart with von Neumann, a radically different approach to programming would already give us some new insights.
I'm going to get shot down for this for sure, but since LISP there really has been no new original idea in how to write software. Java, python, PHP, C, C# and so on all look the same to me.
Languages that are different directions such as Forth, LISP and handfull of others have my interest because I think they will show us a path out of the swamp we are currently in.
Some of the people here on HN have side projects on the go that are extremely interesting from this point of view.
Dijkstra, EWD 1041: The programmers were horrified too: they derived their intellectual excitement from not quite understanding what they were doing and their professional satisfaction from finding weird bugs they had first introduced in their daring irresponsibility.
I'll add, people (users) tend to like it when their professionals know what they are doing. Surgeons shouldn't use chainsaws, even though it'd be more fun to do so.
Also, you haven't known pain until you've tried to actually accomplish something by stringing together pretty boxes in a data-flow language like Max/MSP or Pure Data. Imagine operating an early AT&T switchboard with a pool cue, then crank up the suck.
People have been experimenting with object models and component models for 30 years. Despite considerable progress, no one has found anything that really knocks your socks off. Old news.
The "programming environments as toys" argument seems to be at odds with fixed syntactic and semantic interpretation for programming languages, which is a bit like arguing against steering wheels for cars - sure, having the car drive itself would be nice, but throwing away the steering wheel is really not going to have the desired effect.
It is less hardcore than a "real" programmer, but we are now at the point that you a person can create great value by assembling pre-existing components and create genuinely new things. The components amount to an abstraction, and the key questions are whether you can make an abstraction layer that is simple, and yet also powerful enough to accomplish worthwhile tasks without needing to break the abstraction. As examples, consider components in fields of engineering: nuts, screws, nails, resistors, capacitors, chips etc
The difficult part seems that putting these components together itself becomes a complex and difficult task. However, if we are prepared to limit the power, it is possible to make it simpler: consider audio components that plug together; or bicycle and car components. Maybe this is limited to "customization", but for some purposes, that's all you need to do. And with components that are sufficiently powerful, perhaps you really can build really useful new things.
Glue languages, like Python, already facilitate this to some extent, although the process of assembly is more complex than the blogger wishes, and of course people can and do real programming in Python.