And so for 20 years now these folks —
*the* shining lights, in many ways, of “practical” programming
language, operating systems, and general systems research — have
continued to fail to “get” the fundamental practical needs of everyday
programmers working in The Real World. “Go” is just another language
written first for the compiler and only secondarily for the programmer
— and stuck in a 70s mindset* about the relationship of that
programmer to the (digital) world within which they live and work!
(But hey, it compiles fast! Which is, of course, THE problem that
really needs addressing.)
He then goes on to talk about some aspects of languages that frustrate him.
J.H.C, folks, it’s nearly 2010. Let’s get a few things straight:
– most programming involves schlepping a few but complex data types
between different string representations
– programmers have become plumbers and documentation-archaeologists
mostly, which is sad and uninteresting
– programming languages are for *programmers* — not compilers and
– until you make the everyday, “simple” things simple, it will
continue to be a dark art practiced by fewer and fewer
– any language that makes you explicitly import an IO module to
read a file or stdin is fucked
– declarations are a pointless anachronism (same for explicit
– if I have to understand category theory to write a program that
does IO, IT IS A NON STARTER!
– less stupid line-noise syntax and punctuation, people
I don’t understand why the need to compile fast is such a big deal. If your programming language makes you write so much code that it takes more than a few seconds to compile, you should probably look at using a different language. Here are some things that I’d like to see in a programming language that is designed for programmers rather than compilers or computers.
1) No typing – That’s not to say that I can’t declare my own types, classes, objects, etc… But that calls to objects should be type independent. (e.g. messaging and dynamic dispatch)
2) Built in unit testing – I should be able to declare contracts on the methods and pass/fail criteria. The tests should be run as part of the compile step or interpretation (if the language is compiled or interpreted)
4) Automatic inclusion of libraries based on path and usage. – I don’t mind having to pull in a library to do file I/O or consume some other kind of data like ATOM or JSON. But at compile time, if I have referenced any of the objects contained in the library, all of the references to the library should be handled for me automatically. Any name collisions should be compiler warnings so I can specify which library to use by in my code or make the reference explicit in some other way. I like Pythons path based module convention, the language should just search the child directories for a library if the library isn’t already included in the base language pack.
5) Anytime a design pattern emerges, it should be re-factored into the language itself.
I’m sure there’s more that I would add. What kinds of features would you like to see in a language oriented towards programmers rather than compilers?