
 Why I Hate All Computer Programming Languages - Anon84
http://rebelscience.blogspot.com/2009/08/why-i-hate-all-computer-programming.html
======
weavejester
Ah, another silver bullet.

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.

~~~
anigbrowl
Not to disagree with your substantive point, but I think Guitar Hero is a very
poor comparison. As far as I'm aware, there's no way to take one of these toys
and create any kind of original music with it, other than by smashing it into
something and recording the resulting noise. A better comparison would be
instruments for making (mostly) electronic music, such as synthesizers,
samplers, and sequencers.

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.

~~~
zhyder
"Guitar Hero is a very poor comparison. As far as I'm aware, there's no way to
take one of these toys and create any kind of original music with it"

Actually the latest version of Guitar Hero ('World Tour') does include the
ability to record, edit & share. It's very limited of course.

~~~
anigbrowl
Egad. I wonder how much music they expect one to make with 4 buttons...but
I'll look into it. Thanks for the correction.

------
basugasubaku
Wow, if you start reading the rest of this guy's writings the crackpot
indicators start lighting up.

<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:

[http://www.google.com/search?hl=en&q=%22louis+savain%22+...](http://www.google.com/search?hl=en&q=%22louis+savain%22+crackpot&btnG=Search)

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

~~~
dmnd
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>

~~~
olavk
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.

------
jacquesm
I can't help but have the strong feeling that you're on to something.

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.

~~~
anigbrowl
I'm sure you've already come across it, but the best-known alternative is the
Harvard Architecture, which is commonly used on DSPs:
<http://en.wikipedia.org/wiki/Harvard_architecture>

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.

~~~
jacquesm
I've used DSPs with this architecture and I don't think it is a major
contender to von Neumann, it has its applications though (DSP, embedded
systems).

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.

------
keefe
This article describes model driven application development, the focus of my
current company, where an application is considered to have a model that
describes the application state and a domain specific model and the model that
describes application state may be varied dynamically. This is completely
distinct from programming. Programming is about manipulating data and how a
computer actually operates on data (threads & ram etc). Somebody will always
have to do programming in some language in order to enable "interesting"
business users with such point of views to do things easily. The other side of
the model-driven coin (distinct from UI code) is using rules to describe data
transformations. This is not exactly a shameless plug because I am leaving
this company but you can see model driven development in action by downloading
TopBraid Composer Maestro Edition
<http://www.topquadrant.com/products/TB_Composer.html> and navigating to
<http://localhost:8083/tbl> You will see several applications which you can
select and then select a data model to work with.... at that point your
application is in a particular state (such and such widget configuration) that
application state may then be saved off as another application and so forth.
Going back to TBC you can see that actual data models that represent this
application state and you can look into SparqlMotion and SPIN for how
inferencing can be used to add support for rules in a model driven manner. The
advantage of TQ's approach is that it is based on open standards most notably
RDF, which is a sufficiently generic data model that it may be considered
universal. I still believe that actually implementing components and complex
algorithms should still be done in code. To me the memory state of an
operating system represents a very particular closed world that can then be
mapped to the general, open world expressed in RDF (or however you like to
express the universe of data, I believe RDF is best atm)

------
scj
FTA: We like the element of discovery that comes from not knowing exactly how
things will behave if they are joined together or taken apart. We like to say
things like, “oh”, “aah”, or “that’s cool” when we half-intentionally fumble
our way into a surprising design that does exactly what we want it to do and
more.

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.

------
bct
Take a look around the site, the guy's a crank. He's been talking about how
great COSA is for years, but he's never actually _implemented_ it, or even
shown examples of how it's supposed to look beyond a few trivialities.

------
thunk
There are words for proper "bigger Lego bricks": HLLs and libraries. There's
also a word for the kind he wants: Duplo.

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.

------
henning
Programming is hard, let's go shopping.

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.

------
gdp
This article appears to argue against basic facts about formal languages and
the limits of machines. The argument seems to go something like "I don't like
programming languages because they force me to work in a certain way! Now,
here's another way to do programming!"

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.

------
10ren
My PhD supervisor and I talked about this, as the creation of a new category
of IT worker: a component _assembler_ .

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.

------
BigZaphod
It sounds like he wants something like Automator
(<http://www.macosxautomation.com/automator/>) where you can just create
sequences from very high level blocks of functionality. That has it's uses, of
course, but it's not even on the same level as "real" programming, IMO.

------
pjvandehaar
I think he just described much of LISP (from my limited knowledge of it)

------
calcnerd256
I guess he wants to combine DSLs with Gnome-Do, then?

------
greyfade
This guy is a loon.

