Why Aren't Computer Programming Languages Designed Better? | Hacker News Reader

Why Aren't Computer Programming Languages Designed Better?

fastcodesign.com

5 pointsandrewdumont6 comments

Around 1981, in the early days of Personal Computer World, one of the very early UK personal computer magazines, there was an article which it seems I will never forget. The journalist excitedly expounded on a new application that was being written, called "The Last One", or TLO. The idea was that the application understood a business requirement expressed in English, thereby making all other application development languages/systems redundant.

Safe to say, we're still not there yet.

P.S. also in PCW, a great magazine in its day, was another article about a program that could keep compressing files repeatedly to make them really small. I haven't see that yet, either.

And we will likely never get there. A good place to start reasoning about programming languages is the philosophy of language. Frege, Hume, Wittgenstein, Searle are some interesting figures in this space. Many language philosophers believe there are some basics of language that everyone grasps, and the particulars of a language evolve from necessity. Fortunately there is little agreement on what these basic elements are. This is what makes it interesting.

"Evidence-based programming languages" won't solve anything by finding natural-language equivalents for difficult syntax. What natural language will these equivalents be created in? English, Japanese, Arabic? All languages? Will Japanese programmers share their code with English programmers by means of a Babel fish?

The idea of a poorly designed language is nonsense. All languages that exist or have existed were designed precisely for what and when they were needed.

At its core programming is about appropriate abstraction. To be widely useful the programming language's wheels should tread lightly, just touching the road. If there's too much abstraction, there's no friction and you go nowhere. With too little abstraction you're pegged to the ground and expend enormous amounts of energy to go anywhere.

This is an interesting article about how non-programmers see it.

What the author fails to understand is the difference between having a steeper learning curve versus less verbosity. When you read and write code all day long, you don't really pay much attention to syntax, it's just there to shape the logic.

In order to learn, it's okay to have a more familiar pseudo-code to get a feel of what programming is like. But I wouldn't want to write that code all the time.

An english-like syntax has already been introduced: http://en.wikipedia.org/wiki/COBOL#Verbose_syntax

The article is talking about Perl anyway, which is notorious for its seemingly random syntax, so I don't think its really a good example for how intelligible and random programming language syntax is. When you're a beginner, the languages syntax really does matter and thats one reason why, eg, Python is a better beginner language than Perl. Perl is often jokingly referred to as "line noise" while Python is often referred to as "executable pseudocode".

Having said that, I completely agree with what you say. When spending a lot of time writing code, you really don't care about how intuitive the language is for beginners - much more important is that you can accurately and quickly express your programs. The closer to english a language gets, the more verbose the language gets and if I spend a lot of time programming, I want the language to be succint and straight to the point. (Nevermind that English contains a lot of ambiguous constructs, so an "english" programming language would still be horribly artificial for beginners anyway)

> if I spend a lot of time programming, I want the language to be succint and straight to the point.

When I was a beginner, I -also- wanted that. For some people, verbose == readable, but for many, it's just not so.

I've been recently somewhat surprised at how much syntax means even to experienced developers. Just look at the very positive responses CoffeeScript has received, especially when compared to the criticism Dart gathered with regards to its syntax (Yeah, those weren't the only complaints, but they did make up a large percentage).

Personally, the whole thing made me realize syntax is more or less meaningless to me. I was never really spending that much time making, or correcting, syntax related problems when writing JavaScript in the first place. Though when using CoffeeScript, I was spending a substantially larger amount of time trying to find ways of doing things that I knew were possible in regular JS, but generally avoided in CoffeeScript -- things like mixins, using closures for restricting access to internal members, having members named 'on', etc.

In the end I was spending too much time looking at the JavaScript output to see what was going on continue with CS. Its idioms make the popular subset of JS really great, at the cost of making things outside of it less 'natural' than they are in plain JS.

Reply on news.ycombinator.com