“We now have our answer why BGGA is a rotten piece of idiocy that ruins java as a language, and, being the mothership of the JVM, the whole java as a framework stack.”
And the best thing is, he’s right. Nothing to add, really. Someone even suggested Gilad Bracha left Sun because he has lost the feeling for Java and would rather do a different language.
Java is an excellent example of how you start out with a design that is rather “impure”, and has to be, in order to survive the initial competetive struggle; and then later, when there would be enough resources to realize some of the Real Cool ideas, you realize you can’t because you’re stuck with what and how you started.
One such example is the handling of primitive types. Auto-boxing is just a hack, trying to introduce “Everything Is An Object” through the back door. But the special cases introduced in the beginning stay in place.
A more recent example is the closures for Java / CICE discussion, where everyone agrees it’s going to be an addition to the Java language; no way you could replace some old feature made redundant by the new stuff. You cannot even extend the existing interfaces, because that would break implementations of those interfaces that exist out there in the wild.
There are fundamental decisions that cannot be changed easily once people have started building upon them. Operating Systems, Programming Languages, Platform APIs, Off-The-Shelf Software, they all have more than just a little legacy compatibility problem. The current anti-intellectual “agile” trend is good enough for applying those flexible, mature and well-thought-out processes and tools, but trying to develop and maintain a programming language in such a light-footed way means asking for desaster (or at least, bad quality).
A platform won’t stay competetive for long if you bolt on new things where they get in your way. If Saint-Exupéry is right, you need to remove things to increase consistency, making the language and platform more understandable and more usable.
The way to save your investment is to modularize, parallelize, interoperate, and deprecate. You can’t take things away from the Java platform, but you can provide increasingly consistent alternatives for parts of it (“nio”), interoperate with the old stuff for the time being, and hope for the old stuff to fade away. Note that this is not an agile approach – it does not involve a closed world assumption, it aims to keep long-term promises, and it ties significant resources (for maintaining several alternatives plus interoperability between them). Agile projects do not have a history; platforms do.
Most parts of Java will be with us for years to come. So please, don’t spoil the Java language and syntax with a mix of redundant, overlapping, complex features; don’t add something you may want to remove later. If it’s not proven yet, it doesn’t have to be part of the platform; just provide the hooks for others to provide it and experiment with it. I’d rather have a mix of language environments that Play Well With Others, with a JVM that acts as a “Common Language Runtime”, than a monolithic superplatform that assimilates every feature under the sun.
“And so the median language, meaning whatever language the median programmer uses, moves as slow as an iceberg. […] Obviously, the median language has enormous momentum. I’m not proposing that you can fight this powerful force. What I’m proposing is exactly the opposite: that, like a practitioner of Aikido, you can use it against your opponents.”
“[…] when our hypothetical Blub programmer looks in the other direction, up the power continuum, he doesn’t realize he’s looking up. What he sees are merely weird languages.”
Paul Graham (April 2001, but current as ever)
“Rails has this wonderful caching system that compensates for Ruby’s slow execution speed called “page caching” and “fragment caching”. Rails uses this to transfer the actual web traffic from Rails to the web server itself. […] Because of this a Rails application many times can outperform similar applications in Java or PHP.”
Zed on Ruby, Rails, Mongrel, and More – O’Reilly Ruby
funny… Mr.Zed describes exactly the reason why some eight years ago, the CoreMedia Generator ™ was designed the way it is. The only difference being that the immature and slow language at the time was Java.
Just like Apple kept arguing “we don’t need fast CPUs because what you want works fast enough”, until they finally solved their performance problem.
Allen Holub sagt: Just Say No to XML. XML sei klobig, und wer XML für Konfiguration etc. nutzt, ist nur zu faul, Compilerbau zu lernen.
Dazu meine ich: No.
Nein, es hat keinen Sinn, dass sich jeder seinen eigenen Scanner, Parser, syntax-bewussten Editor, Debugger, Pretty Printer etc. baut. Das ist es, was man im traditionellen Compiler-Bau lernt. Vermutlich auch in dem Buch, das Allen Holub in dem Artikel plugt (“By the way, my own…”). Insbesondere hat es wenig Wert, einen eigenen Scanner mit eigenen Regeln für Tokens und Kommentare entwerfen zu müssen, wenn man eigentlich nur eine Datenstruktur wzB einen struts-Kontrollfluss-Graphen ausdrücken möchte.
Oder auch: Yes.
XML ist viel zu klobig. Eine kompakte erweiterbare Syntax, wie sie Prolog, Lisp und Smalltalk von Anfang an geboten haben, und wie sie heutzutage Ruby bietet, macht da deutlich weniger Schmerzen. Man muss nur ein wenig aufpassen, nicht zu viel Semantik der Turing-mächtigen Wirtssprache in die domänenspezifische Sprache zu übernehmen, sonst ist sie nachher nicht mehr analysierbar, optimierbar, verstehbar, automatisch umschreibbar etc.
Aber warum überhaupt ASCII ? Warum nicht interaktiv im GUI die Datenstrukturen manipulieren, so wie wir es vom Quelltext in IDEA gewohnt sind (achte mal auf Deine Sequenz von Tastendrücken während einer Programmier-Session – mit Programmtext hat das wenig zu tun).
Links zum Thema:
Synthesizer Generator
Jetbrains’ Meta Programming System
Intentional Programming
Subtext