James Gosling: on the Java Road

« Adventures in intern... | Main | Safety is Freedom »

20051215 Thursday December 15, 2005


RADlab, scripting and scale

Get the e-newsletter: Sign up now for the On Demand Business e-newsletter. On Demand Business is helping smaller companies like yours win big. Learn how. I had a long and fascinating Wednesday with a couple of folks from Berkeley's new RAD Lab (press, home). While their public decoding of the acronym RAD is "Reliable Adaptive Distributed", they also care deeply about the more common decoding: "Rapid Application Development". The conversation was all over the map, but a major thread was about the design tension between scripting languages and strongly typed general purpose languages.

Over the years I've used and created a wide variety of scripting languages, and in general, I'm a big fan of them. When the project that Java came out of first started, I was originally planning to do a scripting language. But a number of forces pushed me away from that.

The biggest was concerns about performance and the inevitability of scale. I can't remember how often I've had experiences where someone has proudly shown me some system they've put together using the scripting-language-du-jour: things like an Adobe Illustrator clone written entirely in PostScript; a satellite groundstation diagnostic system written as TECO macros; a BASIC compiler written as Emacs macros; fourier transform algorithms in PostScript... This list is endless. They always ended with "this is so cool, but I'd like it to be as fast as {C,Assembler,whatever}". People get into scripting to quickly build small quick things, but they often grow far beyond where the initial concept started.

Another was about testing, reliability and maintainability. One of the common properties of scripting languages is brevity. This tends to lead to omitting declarations, weak typing and ignoring errors. Generally a great thing if you're quickly putting something together; not so great if you want checks and balances that crosscheck correctness.

Another is generality. Many scripting languages get a good part of their coolness from being specialized - by having key functionality wired into their hearts. A good example is perl, with it's great regular expressions and hash tables. But this drags in a number of issues, chief among them being: what if you want to do something outside the language's area of specialization? Many modern apps need to do exactly that, so one of two things happen: languages get used for wildly inappropriate things (fourier transforms in PostScript), or a collection of languages get used together (which can make it very hard for any one person to understand them, and interconnections can be a nightmare).

The list of interesting questions is really long, this blog entry could easily be a book (that I'll never have time to write). This hardly scratches the surface. The number of potential PhD thesis topics is huge.

(Thu Dec 15 09:49:31 PST 2005)
Permalink Comments [19]

Comments:

C'mon, you should be able to come up with much better FUD than that.

Posted by Obie on December 16, 2005 at 12:44 PM PST #

I think there will always be tension between the old folks and those of us who've used the new crop of dynamic languages to build large-scale, sophisticated applications. The old folks think scripting languages are quaint little boxes, awkward but useful, essentially bash writ large. The old folks would do well to take a Ruby programming course, and to really understand the power of the test-first methodology that's taken hold in the Ruby community (and the Objective-C developers within Apple Computer). But then they'd no longer be old folks. Also, what's fundamentally problematic with writing a BASIC compiler in Emacs, aside from the pointlessness of the endeavour? Are you not aware that 'Emacs macros' are written in Lisp?

Posted by Gollum on December 16, 2005 at 02:27 PM PST #

Wow. All that, and you never even mentioned Ruby by name ;-)
Before you start talking about scripting languages not being performant or not scaling well, you'd better spend a little time doing some research into the topic.
And, of course, you'd better get that spell checker of yours to understand that Perl is not a misspelling of pearl.

Posted by Lori M Olson on December 16, 2005 at 02:39 PM PST #

This is the standard old-line argument in the static vs. dynamic debate. But I really think that it misses the point entirely. I think that Kevin Barnes got it right in his "Freedom Languages" essay where he reframes the debate as freedom vs. safety. I highly recommened reading ithere : www.journalhome.com/codecraft/9003/ Curt

Posted by Curtis Hibbs on December 16, 2005 at 02:57 PM PST #

Interesting post James - I really loved your examples of the ways people have tried to stretch particular languages to fit problems that are the wrong shape! I actually wrote something along similar lines (although rather less eloquently) the other day; anyone interested, please see my blog entry called Business Week Thinks Java Is So 90s.

I was also minded to reply to Obie's comment, but it turned into something a bit long, so I've put that as a post on my blog too - Java, Scripting, Credentials, Authority, Reputation and Influence...

Posted by Simon Brocklehurst on December 16, 2005 at 04:07 PM PST #

Now I'm sure that Ruby has legs.

Posted by Anthony Martin on December 16, 2005 at 04:58 PM PST #

Did any of you read the article with your brains turned on? Why the hell would he mention Ruby at all and yet you all bring it up like he said something against Ruby. Oh I see, any opportunity to squeeze the work Ruby into it.

Posted by Bob on December 16, 2005 at 07:13 PM PST #

I think the argument isn't against statically typed languages or dynamic typing. I think the argument is that languages (maybe by design) that so happen to have weak typing are getting a lot of focus and Java which is 10 years old is losing some its foothold. Maybe, after those 10 years of development; developers wanted to revist things like Lisp, smalltalk. Come up with simpler syntax; Ruby, Python. Also, will anyone else acknowledge that all these XML config web-applications/standalones scripts are needed because we need something dynamic. And oh how fun it is to debug a JSF application and its plethora of config files and jsf pages.

Posted by Berlin Brown on December 16, 2005 at 09:15 PM PST #

I have several years of experience with Java and Perl, and only about six months with Ruby. Still, I have found that dynamic typing, mix-ins, and lambda functions have led to simpler designs, much less code, and more reliability than doing the same thing in Java or C#.

Performance was much more of an issue in the past than it is now. Java, Perl and Ruby are all fast enough in most situations.

Scalability is important, but I don't believe scripting languages have any particular problems just because they are scripting languages. The factors that contribute most to scalability are probably object orientation and testing frameworks, and all three languages have that.

Both Ruby and Perl comes with unit test frameworks as standard, which is very important when building complex applications. With Ruby and Perl, testing is part of the culture.

With Java, despite the popularity of JUnit, and lots of very capable Java programmers that use it, testing is not part of the culture in the same way. Not to forget, EJB has actively discouraged Java programmers from both testing and using loosely coupled designs. I've had to introduce programmers to unit testing, and teach the basics, in most Java projects I've worked on for the past three years.

Another thing that affects scalability is how complex code you have to write to implement a piece of functionality. Recently, I wrote what was supposed to be a simple parser in Java. To get the flexibility I wanted, with pluggable tokenizers and serializers and whatnots, I ended up with no less than 15 interfaces and classes. With Ruby, I can get the same result with one class and two mix-ins. (I can probably do the same thing with Java and Spring, but then the application has to lug Spring and an XML configuration file around.)

If Ruby allows me to reduce the number of artifacts by 80% compared to Java, then odds are that applications written in Ruby scale better. Simpler design, and fewer lines of code, translate into fewer bugs and cheaper maintenance. (I don't expect the difference to be quite as spectacular in all my projects, but I do expect Ruby programs to have simpler designs in the vast majority of cases.)

I have found that most (though not all) of the things I want to do as a programmer are easier with Ruby than with Java. This includes writing some fairly large applications.

Posted by Henrik Mårtensson on December 17, 2005 at 03:26 PM PST #

Hi James, I too prefer Java because it is very carefully structured. The exception catching mechanism is very helpful. I agree that languages that hide this aspect may seem simpler but in many ways feel like they are papering over something important. I also really enjoy the type mechanism, the fact that it is dead solid now, and that programs written in it can run on any OS. I would like to do other things in my life, and learning variations of near similar programming languages is not my idea of a life well spent. For those who want to look at something completely different I suggest looking at RDF.

At the same time I think we can diffuse most of the current attacks by helping other languages be compiled into java byte code. There allread are a lot of languages that do this, such as Jython, Jruby, Groovy, etc. The people involved in those efforts believe that some byte code changes could help them. Perhaps that is all that is needed to make them happy. And if they write to the jvm then in the long term they are more likely to pick up on java, or perhaps we can increase the likelyhood of the next programming revolution happening on our soil.

Somone mentioned how a lot of java server side frameworks use XML files to intialise, which I think open a whole in the strict semantics of java. After all the only thing one knows about these xml files is that there are strings and tags in there. Perhaps if one started writing property files in a more strongly typed language there would be a better fit with java. I'd like to explore what that would look like with RDF/OWL. Since RDF using OWL ontologies is a type system, perhaps we can close the gap again. in these initialisation files one finds in so many frameworks. Compilers or IDE"s could confirm that the intialisation files are consistent with the type system, and so one could have static type checking there too.

Posted by Henry Story on December 19, 2005 at 12:51 AM PST #

The thing that startles me the most in reading the comments is how they all misinterpret weak and strong into dynamically and statically... they have nothing to do with eachother. C is a statically weakly typed language. Java is a statically strongly typed language. Python is a dynamically strongly typed language. I dont know abouyt ruby, but i guess it's the same as python, a dynamically strongly typed language. Strongly means that you are not able to read an Integer as a Float, for example. This is perfectly legal in languages as C and C++ (non-managed languages or languages that have no VM, CLR or whatever it's called in your favorite language/platform) Dynamically means that when you put an Integer in a variable/label one moment, it is perfectly legal to put a Float io it the next. However you will not be able to put an Integer it it and read it as a Float. just my 2cts. PS. when I read the blogpost again it amazes me that it looks like even the great Gossling himself is not clear on this as he opposses scripting languages against strongly typed general purpose languages (the link for scripting mentions Python, so that is also strong). Could it be that even James does not know the difference between strong and static? Anyway, in my view Python also is an GP and strong language, allbeit dynamically typed.

Posted by Willem Voogd on December 19, 2005 at 07:17 AM PST #

I seem to remember that Mac OS X (NEXT) was written in Objective-C, a dynamically typed language and that seems to have worked out well. Dynamic languages have their place just as static languages have theirs. Flaming one or the other is pointless. I would pick Ruby for a webapp due to Rails, Java for enterprise projects that require messaging etc and Objective-C for Mac Apps.

Posted by Amor on December 19, 2005 at 08:13 AM PST #

Those who wish to instruct Mr. Gosling in the virtues of dynamic languages, and in particular those who think it necessary to inform him about the extension language of Emacs or the virtues of Postscript, should read just a tiny bit of history. Try "Gosling Emacs" and "Network extensible Window System".

Posted by Roger Hayes on December 19, 2005 at 08:48 AM PST #

Guilty as charged Willem! That was sloppy of me. I suspect that part of the reason for this was the context in which we've talking about typing - specifically catching bugs due to misassignment of variables. The point being that both weakly typed and dynamically typed languages can lead to variable-related bugs that would be caught in strongly typed and dynamically typed languages, without the need for writing tests.

Posted by Simon Brocklehurst on December 19, 2005 at 08:54 AM PST #

Hehe, Tim Bray just pointed out an article that mentions that php running on a jvm is 6 times faster than on apache. Perhaps in the end it's not the syntax that's important just the semantics, and that is captured in the jvm.

Posted by Henry Story on December 19, 2005 at 10:33 AM PST #

Try coding a distributed transaction that spans 4-5 different pieces(remote processes & Legacy Adaptors) with ruby. Could you easily roll them all back? JEE is designed for huge enterprise applications. So why are we comparing apples and oranges???? As far as JSE 5, yes it has it problems, but it also has it merits. I think desktop Java is making a come back. Look for more cross platform games and rich clients via Java Web Start and Applets. Long Live Java!!!

Posted by J Doe on December 19, 2005 at 01:20 PM PST #

J Doe, I would venture to ask "why would you want to distribute a transaction over 4-5 different pieces"? I like Java and Ruby both, but it's comments like that which make me question wether Java encourages complexity by its very nature or it's the implementation choices of others. Just because you can doesn't necessarily mean that you should. Just my 2 cents.

Posted by Berin Loritsch on December 20, 2005 at 11:30 AM PST #

It's honestly a question of syntax, or rather how much syntax is required. This idea that scripting languages are different from "normal" languages is outdated. How is python (source -> byte code -> interpeter) really different from java (source -> byte code -> jvm) when your a developer? Coming from python to java the amount of syntax needed is insane. Struts makes me cry in a fetal position (a file for each button?), spring MVC is not much better, but I can suppress the emotion for a few years. The less lines I type, the less bugs I type, the easier it is to qa, the easier it is to reuse. The simplicity of python is also seen when using it at the command line - it's so easy to test new idea and play with modules live. Last, it really encourages test-driven (which encourages mvc) design as part of the language and not an addon. I think there is some understanding now in the java world that java has suffered from over designing of the language - at least it seems that way as a new guy to this scene. Java focused on the big scale and ignored the small scale to the point where using java in the small scale isn't very pretty. I've come to the belief that the ability of a language/framework/etc to scale down to the simple tasks gives it the ability to scale up to the large ones. No-one ever liked the semicolon anyay =)

Posted by Michael Neel on December 20, 2005 at 12:53 PM PST #

What is really need is an unbiased empirical evaluation of the different languages used to program the same real-world task. The only such comparison I know of dates from 2000 and all the languages have moved on since then, but I think the overall conclusion is still sound. This is what the summary says: <pre\> 80 implementations of the same set of requirements are compared for several properties, such as run time, memory consumption, source text length, comment density, program structure, reliability, and the amount of effort required for writing them. The results indicate that, for the given programming problem, which regards string manipulation and search in a dictionary, “scripting languages” (Perl, Python, Rexx, Tcl) are more productive than “conventional languages” (C, C++, Java). In terms of run time and memory consumption, they often turn out better than Java and not much worse than C or C++. In general, the differences between languages tend to be smaller than the typical differences due to different programmers within the same language. The full paper can be found at http://page.mi.fu-berlin.de/~prechelt/Biblio/jccpprt_computer2000.pdf.
It is often claimed that the benefits of "scripting" languages do not scale, however I am working as part of a team on an enterprise python application with several hundred thousand lines of code and that is not our experience. The number of bugs we have encountered that would have been prevented by a strictly typed language have been miniscule.

Posted by Dave Kirby on December 21, 2005 at 11:49 AM PST #

Post a Comment:

Comments are closed for this entry.