Have modern programming languages failed? From the point of view of learnability and maintainability, yes! What would a truly maintainable and learnable programming language look like? This is the conclusion of a six-part series exploring the future of programming languages (read The World’s Most Maintainable Programming Language: Part 1, The World’s Most Maintainable Programming Language: Part 2, The World’s Most Maintainable Programming Language: Part 3, The World’s Most Maintainable Programming Language: Part 4, and The World’s Most Maintainable Programming Language: Part 5).
Final Thoughts
Designing a programming language is far more difficult than the thousands of languages in the world today (dozens in common use) might lead you to believe. No language is perfect. Certainly no language in popular use gets everything right.
Why not try to learn from the failures of all of the existing languages and build a new language from a few simple, vital, and often overlooked principles? Our programs might become more robust and powerful, our users might be happier, and finally computer programming might be open to everyone again, not just those willing to put up with incredible unnecessary frustrations and bizarre incantations justified by the dubious weight of decades of historical baggage.
I don’t suggest that all of my thoughts here are perfect, and I hope I have acknowledged the two places where there is room for improvement. However, I do believe that this approach represents a dramatic difference from previous languages, due in no small part to the relentless pursuit of the correct goals.
Aside from a formal specification, which I hope to produce in the near future, the language needs a name. Here is where many modern languages have done well. Perl, named after Pearl Biggar (Larry Wall’s fiancée), Ruby (named after Ruby Kusanagi Matsumoto, Yukihiro Matsumoto’s youngest daughter), Ada (named after Charles Babbage’s first programming student, Ada Lovelace), and COBOL (named after Colleen Bolero, the heroine of a Ravel operetta) have set a high standard for naming techniques. With that in mind, I propose to call this world’s most maintainable programming language Avril, named less provocatively after my long-suffering girlfriend, who graciously allowed me many evenings and weekends by myself while I wrestled with these ideas.
Thanks to Adam Turoff, Allison Randal, Curtis Poe, and Damian Conway for feedback and suggestions.
Nice finish, what I gather from the opinions in the series is this:
Amazon and Reddit used to use LISP extensively on their web sites, but they've moved away from their LISP code, not because the code wasn't good, but because its maintainers had moved on, and finding new LISP programmers is difficult and expensive.
This is like trading in a Japanese or German car, not because there is anything wrong with the car, but because you are sick of paying $1200 for a replacement belt.
The imagined language seeks to solve that "new maintainer" issue.
(In an email, I believe I forgot that the stress of the articles is maintenance, not ease of programming.)
Colleen Bolero? LOL
The idea of maintainabilty of programming language as intruduced here is nice, but it's really pain to code in such a simple language, which would novice understand so easy, but experienced programmer must code every simple feature he needs. I really appreciate map, grep, firt .. variants of "for" in Perl. Because they not only shorten my code, but express what is this chunk of code about (not iterating over array, but finding some values (grep), searching for some value (first) or transforming the array (map) .. This reminds me also "vi" editor, which has really sharp learning curve, but after some experience the work with this editor is _fast_, _effective_ and fun :).
A programming language named Avril (April in french)... Some allusions to fish in the text... Opinions that don't seems to come from the chromatic I read until now... A conclusion that comes out on April 1...
Even though some ideas in there appear interestings, I don't think I would ever use such a language, I prefer the freedom and the real power Perl, or Perl6, bring me, though they don't meet many of your requirements. :)
Brilliant april fool's ! :D
Hehe, oh, duh ... har har, April fools day. I thought we were going someplace with this!! :) Someone give this man a pony! An Avril fool's day joke isn't really a success unless the jokester pushes the bounds of credulity and still gets away with it. So I guess I was fooled this time.
Reading the articles, I see a lot of non-functional and functional requirements that by themselves mostly sound pretty good. It's getting them all together in one place that's the challenge. If I were to pick a couple that would get priority (and let the rest slide), I would pick:
* Consistency - to reduce ambiguity
* Comprehensiveness - to provide a standard API for most things
* Power - to foster creativity (credulity in question!)
* No Compiler or Platform-Specific Code - a.k.a. Virtual Machine?
* A Powerful type system
* Provability - hrmmm ... pushing bounds of credulity!
* A Single Development Environment - Nice goal to have...
I dunno, it's fun to dream even if you push the envelope a little. Perhaps one nice way to deal with a lot of the cross-cutting issues in language design is to have lots of little languages (with little language compilers) all working together to produce code.
I imagine having a scientific math formula language, a spreadsheet language, a procedural/structured code language, and a interface/resources/media control language, and event scheduler language that could all co-mingle in one set of sources. Each little language could have escapes to bridge to code executing in other little languages. And each of the languages would compile to a bytecode or storage format that makes the most sense for that language. The executor (VM) could provide a runtime framework that would understand and be optimized for each of the languages as well as choreograph their interactions.
Probably the most interesting piece would actually be the editor in my little dream scenario. It'd be so nice to sprinkle rich media directly in with my code and have it "just work".
Why are there dozens of programming languages in common use? Because no one language can do it all. For instance, there aren't many languages better at writing reports than old RPG, but don't try to do anything else with it - it is a one-trick pony. There are more general purpose languages than that, but all of them have strengths and weaknesses. I wouldn't write a new language, but try to make an old one better - maybe with a pre-compiler.
Hmm...this series didn't go where I guessed it was going to. I thought the entire thing was a diabolically inventive way of drumming up interest in Perl 6. "We need a language that has features 1, 2, 3...lo and behold, Perl 6!" Of course, my hypothesis got less and less plausible the more that I read.
Absolutely hilarious, albeit a few days late. There are some great ideas in here mixed with some truly great jokes. (Some are so subtle that it's hard to detect the dividing line....)
I had hopes coming into this article, but there were unfortunatly quickly dashed.
Personally, I'd hate using a language that forced me to make variable names a certain length based on their lifetime ( assuming the compiler even got lifetime right for them) or only let my bools end in -ing. I can see the is_123456789_sorted_ing variables already :|
And some things are just incompatable. Simplicity wants only 8 to 10 primatives, but the library also has to be comprehensive, and even the best-designed libraries I've ever seen are not immediatly understandable. Libraries need to be written by humans at some point, and I don't have great hope for elegant libraries written by programmers that can't even be trusted to name variables or to make functions do what their names say.
I also challenge the statement that operator overloading is to be avoided. I fail to see how needing to use .get ( or whatever it's called -- I can never remember ) in Java is better than operator[] on C++'s std::vector. It certainly goes against the principles of consistancy and simplicity. Not to mention having to look up whether a Complex's .add method is the equivalent of + or +=, which I've already needed to learn for ints. ( Of course, a functional language with write-once variables doesn't have this problem, but that's something the author doesn't seem to have even considered. )
Also, Consistancy wants multipule implementations, but "A Single Development Environment" wants no more than one of anything. Which isn't logical anyways. Would this discussion even be taking place if there was only one programming language? Did FireFox not force Microsoft to develop IE7?
In general, the language described would be a limiting, frustrating one in which to work. Not to mention nigh impossible to implement, as it apparently is supposed to be able to check correctness.
For an alternative view--and imho a better one--about what good programming languages need, try the following:
http://www.paulgraham.com/hundred.html
http://www.paulgraham.com/popular.html
Not a php guy in the bunch? Much rather use php than perl.
You seem to have described a programming language lovingly named:
J.
J, but with the option to fill space with homilies and canon-consistent long descriptors for the things along the ordered but many lines of a) Fields of Mathematics (not quaternions and Hamiltonians plus steam and egg; the whole postdoc reel of what you ought to really mean as an aesthete or disciplinarian, and thenceforth b) variables named after engaging issues of _Film Threat._
It is like a C with a strong backhand.
For the programmer with skills at the rudimentary level,
you can return the felt with an entire slab of beef behind it and gently spin the rubber inside it off your strings so that the receiving player will be in a new 12-dimensional universe when they return.
This is already well documented in the _Prince of Tennis_ series in clear simple language I can't write; it's too informal. But the variable names are all there for easy communication.
J It is APL* but much will be much easier to understand because:
- The APL operators, which are 7 or so special characters plus the box character we know from when Acrobat printed unsubstituted fonts as M and N-boxes instead of 7 kinds of overprinted nonnatural nonCaesarian mess-u-up, are replaced with either typable letters or ordinalized mnemonic operator.
- We're going to open that up in honor of this article to allow obvious film-reference operators. This should mud-lubricated-wookie-dum-dum the ankles of the clarity problem and make it trivial, nay Arnie-backing-between-split-roots-of-sway-suspended-groundpounder-bonus-with-counterweighted-hitch-trigger-in-way-of-bladey-rasta-foe simple for the unblushed sub-sevens new vinter.
-For the truly engramless, (drug companies: are you running out of target audiences for your NSAIDs? Monetize this space!) who are being read to in a PreClassic(R) Womb or LeapFrog Krypton Escape Wodget(LP) an interpreting VM which makes the simple pleasures of softly oversampled _King Emperor Tomato Ketchup_ and simple shapes such as characters in _9 Lives_, _Crash_ and _Capote_ to them. Not only that, but while their experience of functional formation, from a clot of V8 in connective tissue, and of kicking mom or the cryostat or whoever comes into fashion; moves its ancient animal survival hand into and over them, you'll know that a well-generalized series of contrasting mathematical paradigms and algebraic types are being patterned just out of reach of the uninitialized motor cortex strip. With this, when they start to discover their voice and that they have separate metatarsals, you can reach for their pudgy little palms. If you can make contact before they teleport for the '44 Saturn Conference on Bertrand Russell and Shaolin Soccer, you'll know parenthood proper.
More advanced programmers will appreciate the improved color picker.
I only have one word and the word is Scheme.
You may need a moment to compose yourselves. Scheme will bring about a "Golden age" of programming, that is
much more golden the the other golden ages.
Scheme is powerful, Tony. I wonder if a language that sticks so closely to the lambda calculus is comprehensible to non-math geeks however.
oookaaaaayyyyyyyy, this is propably the most longwinded april fool's joke that i have come across in a very long time. ;-) not that there weren't any hints...
but nonetheless beware of people who might take this serious and try to _implement_ it literally as presented. the result should propably not be christened 'avril' but 'adolf'. >;->
@chromatic: imho there is a difference between having to deal with lambda calculus (or anything similar) within mathematics or the theory of computation on one hand and _in practice_ on the other. lambda calculus in scheme or any other language that employs it is not a matter of theory. on the third hand you might not get around learning at least a little bit about computability, formal languages, automata and other basic topics, at least _by practice_, if you want to write good, working programs. as long as the current basic paradigms of programming and computing prevail, i think it is actually quite helpful to have a fundamental concept implemented in the language as a consistent and transparent formalism. even and _especially_ when non-math geeks (like me <g>) are concerned. better take a few(!) more days to understand that one formalism than having to remember and take care of many different kinds and cases of syntactic sugar and grammatical atrocities (hello, dear descendants of the algol family!). it is just a matter of communicating it the right way. which in that case would be a non-mathematical and more informal one.