…or at least talk. I’m appearing at the Epicenter conference in Dublin next week. I’ve got two sessions lined up:
Ending the Era of Patronizing Language Design
I linked, indirectly, to this article the other day and, after reading it again, I agree completely. Well, I agree completely with the notion that we should stop accepting “we didn’t put that feature into the language because you’re too stupid to use it” from language designers.
You really should read the comments accompanying the article, some are wise, many are interesting, unsurprisingly many seem to be commenting on a totally different article.
Now, what this doesn’t mean is that every language should have every feature, it just means that presumed incompetence isn’t an acceptable reason for not having it. Languages need to be designed with taste, discrimination and a desire to facilitate developer productivity.
For too long we have been told by programming language designers that we should eat our steak with a spoon because knives are too dangerous.
What sort of features am I thinking of here? Well, Java is a major culprit of the “you’re too stupid” mindset.
Automatic memory management : This isn’t the sort of feature I’m talking about. This is an enabling feature, something added to the language to help developers. Does it have drawbacks? Sure it does, there are times when direct-to-the-metal can be useful. But a decision was made here to facilitate in one area and compromise in another.
Operator overloading : Can it be used for evil? Sure. So can talcum-powder.. that doesn’t mean we should ban it and force our babies to suffer from trench-nappy-region. There are many cases where operator overloading makes sense and its absence in Java is painful. Exhibit 1 ‘BigDecimal’.
Immutable Strings : Another case of “not what I’m talking about”. Mutable Strings can be useful and powerful, but not having them brings advantages too. This was a conscious decision.
No meta-model : Without a meta model programmers dive into byte code manipulation and magical “doesn’t work like anything else in the language” constructs like DynamicProxy. Can meta-programming be hard and weird? Sure, so is physics. Shall we ban that? It isn’t the same, I hear you cry. You’re damn right it isn’t. Those guys created the atom bomb, and we still let/encourage/train/pay people do it. Heck we teach physics to CHILDREN. There are times in this world, when nuclear fission is just plain useful.
The list goes on.
Sharp vs. Blunt Instruments: “If you want your team to produce great work and take responsibility for their decisions, give them powerful tools.”
(Via Glenn Vanderburg: Blog.)
Hallelujah brother Glen. Everyone say, “praise the power”. C’mon now, say it with me, “praise the power”.
Jack Cough on Software: Scala over Ruby - My Debate Ends: This article struck a chord with me today.
I spent most of today flipping back and forward between Ruby and Scala. I’m working on a project where I’m writing some Ruby talking over sockets and streams and files and I needed something JVM flavoured on the other end.
The JVM end was just some driver code that was going in the bin. I had IDEA open because I was using it to write the Ruby side ( at which it is fantastic ) and a simple Scala script seemed easiest - that’s where my head has been recently so it seemed most natural.
Things did not go so well - the embedded Ruby that I was using was badly mangled and had chunks of the standard libraries missing. I ended up spending the day bashing away at various ways of solving the problem. With each change of direction I had to rework both the Ruby and the Scala side of the solution. I noticed something odd.
Version 1.0 was a bit faster to write on the Ruby side. I’m a better Ruby programmer than I am a Scala programmer, but that aside I feel that it was slightly easier to express the problem than in Scala. But as the day went on the Scala code became easier to work with whilst the Ruby code had good and bad patches. Significant refactorings or changes of approach often led to runtime errors in the Ruby code. This wasn’t a problem in the Scala code. The IDE, compiler and type system caught most of the problems well before I got the application running.
Have I abandoned Ruby forever? No, it is near and dear to my heart and it is still better for bashing out scripts for which there will be no version 2. The benefits of Scala didn’t become apparent until 4 to 6 hours into the piece.
Some questions come to mind:
How well would the Scala fare long term? I don’t know. It is possible that I won’t understand it tomorrow and that every day will have a 4 to 6 hour ramp up time. But I don’t think so. I think I’d reap more benefits tomorrow than I did today.
How would Java have fared? I worked on a similar problem the day before and I used Java. It was a pain in the patooty in many ways, but I’m not sure if it comes above or below the Ruby version though. Many of the same characteristics that Scala has were apparent in that session too. I am sure that I found the Scala experiment more productive - despite the fact that I’m a much, much better Java programmer than I am a Scala or Ruby programmer.
I’ve written here, in the past, about my belief that, by starting an Open Source project, you’re making a commitment to the world. It seems that Rod Johnson of Spring fame and owner of successful Open Source company Springsource agrees with me.
Whilst being interviewed during episode 238 of The Java Posse Rod commented that he felt “Open Source projects, like puppies, are for life not just Christmas”.
This trickle down from Reuters looks and sounds legit.
I’m not sure how I feel about this. Mostly positive I think. Sun has been chasing the client-side dream for the last couple of years ( well forever really, but with renewed vigour of late ) with twaddle such as JavaFX. Personally, I’ve written mostly server side Java. That’s what I expect to continue to do. If I was going to write client side code, I wouldn’t use JavaFX. I can’t think of a single reason why I would choose JavaFX over Flash or Swing or GWT or SWT or … anything.
Sun, who’ve been financially constrained for a long time, have been focussing resources on client side development and that has led to stagnation and lack of drive on the core Java language. Take the complete failure to deliver on closures for example - Sun had other priorities, so nothing happened. IBM sells hardware, lots of back end hardware. They make money out of said hardware and want people to write as many apps as possible for them. I have hope that they can deliver on the sort of roadmap that will make me happy.
I had a conversation with the head of Sun’s R&D department about three years ago. We talked about their hardware platform and the fact that they were producing hardware with massive numbers of processors and cores, and that each of the cores were comparatively slow. This sort of architecture seems ideal for hosting PHP/RoR/CGI/share-nothing apps and kind of poor for hosting Java apps. I asked him if he felt that was true, and what they were planning to do about it. He said, yes their hardware and software sweet-spots had diverged and that they had some ideas about how to realign their offerings. As far as I can tell, things are still the same today.
Don’t get me wrong. I like Sun. They’ve given me lots of free stuff, for a long time, and in return I’ve given them … nothing. That’s not quite true, I’ve had Solaris boxes ripped out and replaced with IBM Blades running Linux. So, I’ve given them less than nothing. Sheesh, no wonder their stock price has gone down the drain.
Recent Comments