Two straw men walk into the Foo Bar...

by Chris Adamson


Two straw men walk into the Foo Bar...




"Howdy, pardner. My name's Java, but my friends call me "The COBOL of the 21st Century". People know me for bein' verbose. 'N fact, it takes 200 lines of code and three XML descriptor files just to say 'Hello world'."




"Yo dude, 'sup. I'm a dynamic-slash-scripting language. I'm all about cutting to the chase. You can whip up web apps with me in five minutes. Of course, if you put me in production, I'll go down faster than a porn star on coke."




OK, everyone, now that we've worked through the outrageous generalizations, we won't need any such ridiculous exaggerations in the comments... right, guys?



I do find the Java vs. Ruby/Python/etc. sniping interesting not as a technology choice, but as an expression of values, a means of teasing out what matters to developers. This is important because it should totally tell us where Java needs to go in the future, in a more useful (if less direct) way than assembling committees of experts to write JCP specs of sometimes dubious practicality.



So obviously, it was of great interest the other day to see of James Gosling speak of his affinity for scripting languages in his blog entry RADlab, scripting and scale, even going so far as to say:



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."



What kind of forces? Gosling cites scaling. He describes some curious misuses of various languages (a BASIC compiler done with emacs macros, an Adobe Illustrator clone in PostScript), and concludes "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." Kind of a straw man argument, but we'll come back to that in a sec.



Representing the sane side of the scripting language argument (i.e., not the idiots who pollute talkbacks with "Java is teh suck" and actually aren't being ironic) is Bruce Tate and his manifesto Beyond Java. This is easily the most interesting computer book I've read this year. It's not perfect -- Bruce Eckel dings him for some weak research, and his understanding of desktop Java is summed up by embarrassing and pithy cheapshots like "friends don't let friends use Swing" -- but the bulk of his argument is strong. Tate says that Java has become less productive than the alternatives for the key tasks most developers use it for: connecting some kind of web interface to a database, possibly with some business logic.



Not to overpersonalize the two sides, but let's represent these two vital assertions by the speakers: Gosling says scripting languages won't scale, and Tate says Java has gotten too complicated.



It is critically important to understand and appreciate that Gosling doesn't have to be wrong for Tate to be right, and vice versa. Indeed, the most interesting case, and the most likely one, is that they're both right: Java scales better, but it's more of a pain to write.



That leads directly to an important question: is Java's complexity worth it? And that may be an issue of context.



After all, these are arguably gray-area assertions: At some point, Java scales significantly better than the scripting languages... but when? For some developers and some projects, Java's complexity is unduly burdensome... but for whom? There may be projects so small that the scaling question doesn't figure. There may be projects so complex that the simplicity of the scripting languages are irrelevant.



It would be easy enough to fall back to the usual conclusion that "there's no one perfect language," and that would be fine, but there really is more weight to this argument than that. It wouldn't still be attracting so much attention if it really were entirely subjective, like a preferred style for indenting curly braces, or the perfect font for coding.



So now here's the context that I spoke of above, and why I think Tate's arguments really need to drive some change within the Java community: who is the Java programming experience really tailored for? Tate argues that Java is increasingly concerned only with a very high-end, enterprise developer. That worries me because... and this is a hunch and a feeling that I can't back up with numbers so don't ask... that there might only be a few hundred developers who genuinely have to deal with a million simultaneous users, while there's probably at least a million developers who'll never have to handle more than a hundred simultaneous users.



The more Gosling is right about Java scaling, the better suited it is for the first group. The more Tate is right about Java complexity, the worse suited it is for the latter group. And look which group is larger.



That's what interests me about Beyond Java. Not that Java is intrinsically wrong, but that it may have become wrong for a lot of the people using it.



Ten years ago, the young Java programmer could ask the C++/CORBA types whether it really made sense for them to have to worry about memory management instead of business logic. Today, the scripting language advocates are asking us why we have to be responsible for so many add-on frameworks and configuration files. It's not hard to see this as an analogy that Java desperately needs to avoid falling into.



We now return you to your regularly-scheduled language bashing...


12 Comments

aristotle
2005-12-21 16:59:40
Re:
You may want to read Steve Yegge’s Is Weak Typing Strong Enough? article. Excerpt:


    In any case, for several years I got to watch Perl and Java folks working side by side doing pretty much the same tasks. In some cases, they even had to implement the same logic in both languages. Yes, there were inefficiencies with our Perl-and-Java approach. However, it was the right decision at the time, and as a result, I was personally able to witness a more or less apples-to-apples, multi-year comparison of the strong-typing and weak-typing camps at work in the same production environment.


Read here:
http://www.cabochon.com/~stevey/blog-rants/strong-weak-typing.html

chromatic
2005-12-21 23:11:06
"Scales"?
What does it mean that something scales?


Does it mean that you get a linear or better increase in productivity as you add more programmers? Do you get a linear or better increase in performance as you add more resources to the deployed application?


I'm being serious here. I want to understand exactly how Java scales better than something else so I can evaluate if it's true. It seems important.

TimWarwick
2005-12-22 00:44:59
Best of Both...?
Doesn't Mustang have the Rhino Javascript engine built in?


I quite like the idea of quickly prototyping in Javascript.


Or scripting my Java business objects in a lightweight way.


JavaOnRails: javascript to access java libraries?


Sun are trying to loosen the shackles.

vprise
2005-12-22 01:58:42
"Scales"?
It means all of the above. But mostly it means the ability to scale.
The thing is that you can write terrible code that won't scale in any language including Java and you can write a very scaleable application in C++, where is the difference then? Java has several features and standards that make writing a scalable application very easy. Some of these features exist in other languages compiled/JITed etc... but no platform/language has all of the features listed and they are not as mature in any competing platform/language combination:


1. In the language level Java is designed to be VERY simple (this design was damaged a bit in Java 5) this allows us to make many assumptions about the code and allows us to grep large code bases very easily. Coupled with garbage collection and a very simple approach to memory management Java in terms of the language allows large teams to collaborate more eaily.
Java has grown more complex over the years but mostly in the API which fits with the approach of "if you don't need it you don't need to know about it" unlike language complexity where you might run into code that uses a language feature that you never used before.


2. Raw computing power today is actually on Java's side. Performance on low end machines is very good and can already compete with C++, but it gets better. When you place an application on a large scale 64 bit machine with more than 8gb of RAM a garbage collection run can take minutes. However, modern Java VM's scale up well by offering paralel GC's (that don't stop the VM) and generation based approaches that are very efficient.
Better yet, because of the optimizing JIT's the bigger your code base the better your relative performance will be. Add to that the fact that security is simpler (no need for array boundry checks and fewer attacks on most cases) and you get a picture of very easy deployment.


3. Scalability also means moving up to any type of hardware (throw hardware at the problem), this is very easy with Java! We developed huge applications on PC's that moved without a hitch to mainframes and huge Unix servers. Some people complain that WORA is not a reality, those people never worked with platforms that existed before Java!


4. Java EE is designed for high end servers. That is one of the main complaints against it and one of its best features. JTA (the Java Transaction API) is designed around XA transactions that allow network transparent two phase commit, most applications written in Java EE don't really need 2PC however in the future they could scale to make use of this functionality very easily. Also most application don't necessarily make use of network transparency provided by Java EE but they can easily use these services in the future.
Java ofers a very rich standard API for server development that allows you to move to the "best of bread" application server that matches your needs, by using a standard you are not locked in to an implementation that may stagnate.
Java EE allows clustering very easily further simplifying the process of throwing hardware at the problem.


So essentially I listed several things:
a. Speed
b. Support for large memory and codec.
c. Development simplicity (maintaining large code)
d. Portability to high class machines
e. Standard - Java EE, pick the best of breed
f. Designed for high end needs (JTA/EJB)


All of these are the basics of Java scalability that no other platform has to the same extent as Java.

libsys
2005-12-22 06:35:30
"Scales"?
The simple definition:


Something that performs at the same level as load increases.

pjstadig
2005-12-22 06:36:18
What's wrong with Java appealing to enterprise?
Chris,
If I understand you correctly, you are saying that Java appeals to the 100 developers whose systems deal with 1,000,000 concurrent users instead of appealing to the 1,000,000 concurrent users whose systems deal with 100 concurrent users, and you are saying that Java should try to appeal to the latter group more. Why?


I think it makes sense for Java to be good at enterprise, because though the group of developers that really need that functionality may be small, they still need that functionality. There are languages that are good at making systems with 100 concurrent users.


Why does appealing to developers making smaller systems have to be the future direction of Java?


Why not just leave it at "there is no perfect language?"


I agree that people should stop beating up straw men and realize that different languages work for different purposes. Don't try to make Java into Ruby, and don't try to make Ruby into Java.

pjstadig
2005-12-22 06:37:18
What's wrong with Java appealing to enterprise?
Sorry, should say "1,000,000 developers whose systems deal with 100 concurrent users"
invalidname
2005-12-22 06:53:45
Re: What's wrong with Java appealing to enterprise?
Well, Java is designed to be a general-purpose language, as opposed to something domain-specific (PHP for web apps, Prolog for logic, etc). Consider what Gosling says in that same blog:


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?


Java seems like it's changing from a general purpose language to one heavily optimized for advanced enterprise development. As a developer focused primarily on desktop Java development, I've felt the language moving away from my needs for a long time: putting stuff like JMX in the core language does nothing for me, especially when problems like desktop deployment (bundling, library versioning, etc.) have laid unresolved for years.


--Chris

kebernet
2005-12-22 07:45:13
Falling into your own trap
So now here's the context that I spoke of above, and why I think Tate's arguments really need to drive some change within the Java community: who is the Java programming experience really tailored for? Tate argues that Java is increasingly concerned only with a very high-end, enterprise developer. That worries me because... and this is a hunch and a feeling that I can't back up with numbers so don't ask... that there might only be a few hundred developers who genuinely have to deal with a million simultaneous users, while there's probably at least a million developers who'll never have to handle more than a hundred simultaneous users.


"Dealing with a million simultaneous users" doesn't really go to the issue of complexity at the core level. The problem Java has is that it has built frameworks and lanugage structures around supporting the "enterprise" edge cases at the expense of the common tasks. It is entirely possible that you might only need to support 50 users in a complex EAI project that needs 3 of those edge cases, or 5 gigausers on something doesn't need any of them. The thing is, the 3 or 4 usecases for each framework or API that *everyone* needs should be fast and blazingly easy. Let everything else be a little harder and on average, it helps everyone.

Scoregasm
2005-12-22 08:02:48
"Scales"?
In my view it's only two things; the ability to handle the stress of "high load" and ease at which the developer can maintain the code base. I'll trade some of the former for more of the latter... I can always place more iron to handle preformance, but it will take a lot more developers to support 2 mil. lines of code.


I think the assumption that a light syntax language like python cannot scale is unproven and false; just like the idea that automatic garbage collection was though of as a bad design flaw.

alexvollmer
2005-12-22 08:45:20
dynamic vs. static
For the most part Java has lost a lot of its "soul" in the last few years. What was once an expressive and readable language has become over-burdened with annotations and XML. However, you can still write a lot of interesting software in Java without all of that.


With the heavy framework-orientation that Java has taken on in the last five years (in an effort to carve out the enterprise niche), it's been really easy to get lost in XML and configuration. But Java is a great language for expressing domain models--something people just don't talk enough about.


I don't buy the argument that Java is hard to write. Have you tried Eclipse? The code writes itself--and please, don't give me the argument about being on a desert island with no Eclipse. It's free and it's the best IDE out there.


When I'm writing Python I'm transported back to eight years ago when my only editor was emacs with tons of hand-crafted macros to get through the boilerplate. Yes, there are some better tools out there for these languages, but I find I spend an awful lot of time just writing prototypes with the various objects in the language to see what they do rather than having first-class docs or an interactive IDE with which to explore them.


Time will tell whether or not the Perl/PHP/Ruby/Python crowd does a better job at domain-modeling. Frameworks are interesting, but they are only a means to an end. Let's not forget what Java was really good for to begin with.

Xapp
2005-12-29 05:35:44
"Scales"?
In this context, I think it is a little more complex than that. In addition to vprise' response, when determining scaleability, it is important to make sure that the language can:
- do all you need it to do now
- do all you need it to do in the future
- do all you need it to do well


Java, c++ etc are designed to 'do everything' (i.e. you can write code to make it do what you want). The scalability of a language is going to be a function of size (LOC), complexity and performance. Ideally, these three elements should be loosely coupled. That is, one should not drasticly affect any other. Size and complexity should be low and performance high.


For most languages, it is possible to 'do everything' but in doing so, size/complexity/performance may be detrementally affected. You'll eventually hit a ceiling.


Choosing a language requires careful thought and experience. Always has, always will.


--Russ