As much as I like pg's essays generally I don't particularly like his essays on hardcore programming topics like language design. Maybe it is because I am inexperienced in most of the topics he discusses in his essays but I am quite experienced in programming.
Some reactions to the essay:
"I predict a similar fate for Java"
It is ridiculous that pg once said he does not know Java at all. Yet he expresses his opinions about it. How can I take his opinion seriously as someone who knows almost the whole language specification of Java by head and had been programming in Java for at least 9 years? It is not only knowing the language which is important. But knowing all those problem patterns that have to be solved at typical enterprise projects. These projects are inherently complicated and has a lot to do with databases (and less with expressing nice and elegant algorithms). Java is not a particularly good language, but without developing a lot for in enterprise projects you really don't know what is needed by those projects. That said my favourite language is Scala. It ihas all the advantages of Java and the Java platform but it is a much better language than Java. It is not a 'pure' language. Pure languages never really do well for widespread practical use.
"I think it's important not just that the axioms be well chosen, but that there be few of them. Mathematicians have always felt this way about axioms-- the fewer, the better-- and I think they're onto something."
First the core language in mathematics (the language of first order logic) is orthogonal to axioms. You can have a language with simple syntax (some math books define such a minimalistic language for first order logic), but it will not be good for practical use and will not be concise. So for practical use and for conciseness mathematicians have introduced plently of notations. (e.g. typographical conventions for differentiation, integration, infix syntax for addition, multiplication, etc...), etc. The real-world language that mathematicians use day-to-day is more like let's say Scala than a very pure language.
Axioms (and theorems derived from them) are more like libraries. There are plenty of axiom systems: (separate for numbers, geomerty, etc...) The whole mathematics is something like the Java ecosystem: lots of libraries.
What pg speaks about is some kind of utopia. A world where all programmers have to do is to express elegant algorithms. But programmers have to solve complex problems which mostly don't have an elegant solution at all. 100 years later we will still not have incredibly elegant solutions for our then hard problems. Even mathematicians don't always have elegant minimalistic solutions for their problems. Andrew Wiles worked for 10 years to prove his theorem. The proof is the result of lots of work and knowledge, and is incredibly complex. It does not fit on the margin at all.
Just look at natural languages: they are incredibly useful and concise in some sense, but they are incredibly complex. Programming languages will never be so complex, but they will not necessarily be extremely simple either.
Edit: I love minimalism, and I hate convoluted overcomplicated libraries and code bases, and I hate very leaky abstractions. The smaller the code base is the better: this is my main philosophy. But I still think that pg goes too far with his utopia for simplicity. I think that simplicity and conciseness of application code requires some complexity and intricacy on the core language and libraries side.
I am not against language research. For example there is one interesting research language, called 'Joy' which is the most concise of all languages I know and its simplicity inspires me. It is really fun. I just have no clue how I would write a 'usual' big business system in it because I did not develop my system development cognitive patterns on such an exotic language.
One more thing, he discusses some details about strings, lists, hashtables, and representing numbers as lists.
These are in fact not deep language design topics. Most of what he discusses are not core features of 'serious' languages in 2010: they are already mostly library stuff.
For example let's take Scala. Treating strings as lists? Create a Seq descendant string class, and create implicit conversion from the normal String to it (and vica versa): and you can use it in scala.
Arrays as Hashtables? The syntax is already the same in Scala, they even have common traits (kind of interfaces).
Numbers as lists? Also library implementation detail. Create a Seq based number class and define implicit conversion for it, and you are done. Defining operator behaviour for these 'numbers' is possible in Scala.
The deeper questions are in my opinion: static vs. dynamic. typing. In case of static typing the question is what kind of type system we have?(Scala's is complex but powerful.) What kind of type inference we have? How felxible/convenient the syntax is? Does object orientation makes sense, what kind of (multiple) inheritence we support? Purely functional or enable imperative programming style? (Imperative programming is not just how the computer 'thinks', it is a 'natural' description of some concepts. (Like an instruction manual.))
Also, note that static and dynamic typing are not mutually exclusive (dynamic typing with optional static annotations is one very practical point in the continuum; inferred (i.e., few to no annotations) static typing is another), and static/dynamic typing are distinct from strong & weak typing. C is semi-weakly typed, because you can fake out the type system easily with casts.
Basically, static vs dynamic is about how early types can be decided, strong vs. weak is about how strictly they're enforced. People have been mixing the terms up for a while though, even in type system papers, which adds lots of confusion.
I prefer a utopia where we don't need to write horrible complicated enterprise applications. They're not fun anyway.
The enterprises don't have a clue what they need anyway, I bet python can replace Java in all enterprise applications and do a better job, but the managers are too thick headed to accept anything unless it's mainstream and backed by a mega corporation.
Python is a better language than Java overall, but Java has some advantages over Python: because of static typing it is faster and has a very good IDE support. (autocomplete, code navigation, refactoring, etc...) In my eyes the most superior languages have static typing with a clever type inference, so that the code remains concise despite static typing. I like Scala because it really has the best of all worlds. (Although really mastering it is a bit more work than mastering Java or Python.)
Comments
As much as I like pg's essays generally I don't particularly like his essays on hardcore programming topics like language design. Maybe it is because I am inexperienced in most of the topics he discusses in his essays but I am quite experienced in programming.
Some reactions to the essay:
"I predict a similar fate for Java"
It is ridiculous that pg once said he does not know Java at all. Yet he expresses his opinions about it. How can I take his opinion seriously as someone who knows almost the whole language specification of Java by head and had been programming in Java for at least 9 years? It is not only knowing the language which is important. But knowing all those problem patterns that have to be solved at typical enterprise projects. These projects are inherently complicated and has a lot to do with databases (and less with expressing nice and elegant algorithms). Java is not a particularly good language, but without developing a lot for in enterprise projects you really don't know what is needed by those projects. That said my favourite language is Scala. It ihas all the advantages of Java and the Java platform but it is a much better language than Java. It is not a 'pure' language. Pure languages never really do well for widespread practical use.
"I think it's important not just that the axioms be well chosen, but that there be few of them. Mathematicians have always felt this way about axioms-- the fewer, the better-- and I think they're onto something."
First the core language in mathematics (the language of first order logic) is orthogonal to axioms. You can have a language with simple syntax (some math books define such a minimalistic language for first order logic), but it will not be good for practical use and will not be concise. So for practical use and for conciseness mathematicians have introduced plently of notations. (e.g. typographical conventions for differentiation, integration, infix syntax for addition, multiplication, etc...), etc. The real-world language that mathematicians use day-to-day is more like let's say Scala than a very pure language.
Axioms (and theorems derived from them) are more like libraries. There are plenty of axiom systems: (separate for numbers, geomerty, etc...) The whole mathematics is something like the Java ecosystem: lots of libraries.
What pg speaks about is some kind of utopia. A world where all programmers have to do is to express elegant algorithms. But programmers have to solve complex problems which mostly don't have an elegant solution at all. 100 years later we will still not have incredibly elegant solutions for our then hard problems. Even mathematicians don't always have elegant minimalistic solutions for their problems. Andrew Wiles worked for 10 years to prove his theorem. The proof is the result of lots of work and knowledge, and is incredibly complex. It does not fit on the margin at all.
Just look at natural languages: they are incredibly useful and concise in some sense, but they are incredibly complex. Programming languages will never be so complex, but they will not necessarily be extremely simple either.
Edit: I love minimalism, and I hate convoluted overcomplicated libraries and code bases, and I hate very leaky abstractions. The smaller the code base is the better: this is my main philosophy. But I still think that pg goes too far with his utopia for simplicity. I think that simplicity and conciseness of application code requires some complexity and intricacy on the core language and libraries side.
"What pg speaks about is some kind of utopia."
More of a limit. By historical standards you're approaching it fairly rapidly. A couple decades ago you might have been using Cobol.
Someone has to work on the stuff at the limit, in order to generate the ideas that the "real world" stuff copies.
I am not against language research. For example there is one interesting research language, called 'Joy' which is the most concise of all languages I know and its simplicity inspires me. It is really fun. I just have no clue how I would write a 'usual' big business system in it because I did not develop my system development cognitive patterns on such an exotic language.
http://en.wikipedia.org/wiki/Joy_(programming_language)
One more thing, he discusses some details about strings, lists, hashtables, and representing numbers as lists.
These are in fact not deep language design topics. Most of what he discusses are not core features of 'serious' languages in 2010: they are already mostly library stuff.
For example let's take Scala. Treating strings as lists? Create a Seq descendant string class, and create implicit conversion from the normal String to it (and vica versa): and you can use it in scala.
Arrays as Hashtables? The syntax is already the same in Scala, they even have common traits (kind of interfaces).
Numbers as lists? Also library implementation detail. Create a Seq based number class and define implicit conversion for it, and you are done. Defining operator behaviour for these 'numbers' is possible in Scala.
The deeper questions are in my opinion: static vs. dynamic. typing. In case of static typing the question is what kind of type system we have?(Scala's is complex but powerful.) What kind of type inference we have? How felxible/convenient the syntax is? Does object orientation makes sense, what kind of (multiple) inheritence we support? Purely functional or enable imperative programming style? (Imperative programming is not just how the computer 'thinks', it is a 'natural' description of some concepts. (Like an instruction manual.))
Also, note that static and dynamic typing are not mutually exclusive (dynamic typing with optional static annotations is one very practical point in the continuum; inferred (i.e., few to no annotations) static typing is another), and static/dynamic typing are distinct from strong & weak typing. C is semi-weakly typed, because you can fake out the type system easily with casts.
Basically, static vs dynamic is about how early types can be decided, strong vs. weak is about how strictly they're enforced. People have been mixing the terms up for a while though, even in type system papers, which adds lots of confusion.
For a really good tour of language design issues, check out CTM (http://www.info.ucl.ac.be/~pvr/book.html) or EoPL (http://www.cs.indiana.edu/eip/eopl.htm). I've also heard good things about PLP (http://www.cs.rochester.edu/~scott/pragmatics/), but haven't read it yet.
But, Java does suck!
I prefer a utopia where we don't need to write horrible complicated enterprise applications. They're not fun anyway.
The enterprises don't have a clue what they need anyway, I bet python can replace Java in all enterprise applications and do a better job, but the managers are too thick headed to accept anything unless it's mainstream and backed by a mega corporation.
Python is a better language than Java overall, but Java has some advantages over Python: because of static typing it is faster and has a very good IDE support. (autocomplete, code navigation, refactoring, etc...) In my eyes the most superior languages have static typing with a clever type inference, so that the code remains concise despite static typing. I like Scala because it really has the best of all worlds. (Although really mastering it is a bit more work than mastering Java or Python.)
It's the other way around. Java has good IDE support because it's too annoying to write Java applications without an IDE. Java needs IDE support.
On the other hand, python is so pleasant you can develop big applications without any IDE support, just good old vim with ctrl-p word completion.