Thoughts on
tagged with
- event handling
- correctness
- dependencies
- focus
- intentionality
- practise
- responsiveness
- Software engineering
- speaking
One of the highlights for me at JAOO Sydney 2009 was Dave Thomas’ talk on Cloud computing. Among other things, he talked about the vast dinosaur swamp of OO middleware that Java developers will be having fun maintaining for the next thirty years.
As somebody whose programming time is mostly either UI related in JavaScript or hobby coding in whatever takes my fancy in a given week (this week it’s factor) I was in a good position to laugh in a “it’s funny because it’s not happening to me” way at the humorous insights from Dave, the self confessed former Pied Piper of Objects. Actually, I found it especially amusing because my recollection of computer science at university in the late 90’s was that almost every student at the time was begging, demanding, wailing and gnashing their teeth… to be trained as a member of this army of average Java middleware programmers.
Of course, opting to code UI in JavaScript long ago revoked my membership to the fraternity of real programmers so my hyperbole on these things can freely be dismissed as nonsense by that part of the world shepherding business objects for a living.
I was raised on objects. I like objects. I do not like what we did with them.
In particular, I don’t like that I can sit in a meeting of non-programmers who once walked past a Computer Science 101 lecture and hear somebody saying that “we should take an object-oriented approach” to the problem.
I don’t like that anybody doing architecture ever talked in terms of UML class diagrams where all the business objects were drawn and detailed and then all the messages, you know the actual stuff going on was reduced to zero. It’s all interface, all objects and nothing happening. That’s not designing a living system for code, it’s designing a pyramid to bury people in.
All objects with no messages, no configurability, no data. Everything else got moved or obliterated until finally, finally when somebody turned around and realised “Hey, we need ways to do a bunch of this other stuff” the answer that came forth was XML. So now there’s this whole universe of people programming all the important parts of their software in XML. I don’t care to take a guess at how that is going to work out.
Of course, that was all too hard for many people and instead of following the musical pipe they went off to use PHP, broke every single principle of good, bad and ugly software design - including some that weren’t invented yet, and still managed to get things done. That said, I’ve done enough work with things such as the Wordpress template system to be reasonably confident that something has gone horribly awry and that there’s a good chance that a whole community of programmers will also be keeping themselves in jobs maintaining the mess they’ve created in PHP.
Back to JAOO though, it was good to see a strong representation for dynamic languages, DSL’s, functional programming and on top of all that, it was good to hear all types of people with a good sense of history and architects talking about service oriented architectures and composition.
Now, at this point I would assume that any lispers still paying attention to current trends can only be wondering why it took so many dances around the prickly-pear tree before more people started to “get it.” The lispers may have questions such as “Did it really take fifty years for lambda to even start entering mainstream consciousness?” and “Is XML really what you made of s-expressions?” and those would be just warm up questions… what happened?
The shift to DSL’s is encouraging… I can only hope that this time we can actually get them right as almost everything that has come before has been an abomination. That goes double for most of the 4GL’s around, I’m looking at you CSS. The problem with most 4GL’s is that they were designed to suit the problem, not the people who had to solve the problem. I think one of the big challenges going forward will be how to design languages, or design the space around which languages can develop, that work better for users… while still maintaining conceptual purity and elegance.
There is a short text written by Poul Anderson entitled Uncleftish Beholding which shows, to some extent, what English would have looked like in the absence of loanwords. It’s interesting to see the number of phrasings that somebody speaking English now would find awkward. English is something of a mixed-breed.
If we multiply the number of language speakers by the number of documents on the web in that language then English is far-and-away the winner in those popularity rankings. I don’t know how important that is but I don’t think English is emerging as the single human language of the web.
How about programming languages? Peter Van Roy thinks that there is evidence that one true programming language is emerging. Some disagree. Esperanto anyone?
Programming languages have something resembling native speakers at least from a “how many users do we have” aspect because, as Yegge points out, most programmers only know one language. In other words, secondary languages are rare… at least for a substantial proportion of the community.
There are plenty of programmers who know how to do the same thing in several languages and try to impose that where they can. JavaScript consistently fell victim to that where people were constantly conceiving ways of doing things that didn’t suit the language. Many people did that when they moved from a training in Java to JavaScript, jumping through hoops to get JavaScript to work like Java because, you know, it looks like it can.
There’s a difference between trying to impose unsuitable syntactic sugar on a language (classes in JavaScript) and liberating the language by demonstrating how patterns from other languages might translate more naturally (Crockford’s module pattern.) It’s good to bring ideas and techniques to a language, not so good to try hammering in conventions.
Of course, programming languages are not like-for-like comparable with human languages. Still, in the way that it has taken influence from other languages - for better or worse - JavaScript is kinda like English.
Guy Steele talks about growing a language (video, pdf) indicating a desire to make a language flexible enough so that the people using it can build on the language provided. The programming language provides the rules - and hence limitations - around which programs can be created. The things people do in a programming language creates the dialogue.
Java has been successful on that level at least partly because it makes it easy for those one language people to create a dialogue or use an existing dialogue.
The thing is, a programming language can be restrictive in a way that a human language typically can not.
Programming languages are used by world builders and the type of language determines the effectiveness with which people can construct universes. Programming languages have philosophical ramifications because the construction of the programming language impacts on the types of dialogue that can happen. A human working in the regular world can invent new rules of discourse and moreover may actually invent a new language (with words or symbols) with which to describe or talk about the world.
The can be achieved in a programming language but the restrictiveness of a programming language can make constructing a new domain-specific language difficult enough that it’s almost never attempted in that language. On the JVM the rigidness of Java and an understandable resilience to change looks like it will lead to increased popularity of new languages running on the JVM at the expense of the Java programming language. As the language of discourse, Java looks like it will soon fade instead of grow.
Languages need to evolve, JavaScript managed to do that mostly by accident and in a different sense to that in which Java grew. The point though is that if JavaScript had not been able to grow at all then despite any luck it would probably now be dead.
Still, as Eich and Crockford both say, popularity doesn’t usually have much to do with the design of the language except perhaps where the design seems familiar… though familiarity itself is a double-edged sword.
In the end though JavaScript like all languages needs to evolve or die… with care.
An infinitely flexible programming language would be infinitely extensible and, most likely, infinitely useless. On the other hand, a language too heavy on restrictions will be useful… but for a sufficiently small problem set that it too would ultimately be useless.
The growth of a language really happens in the community.
Just like HTML, many of the programming languages already in existence today are trying to evolve inside the constraints of standards committees… occasionally this may prove midly successful but I think the best you can hope for when doing that is a Bonsai.
