Skip to main content

Chapter 1: Owls and Ostriches

30 replies [Last post]
invalidname
Offline
Joined: 2003-06-09

Chapter 1 establishes the pros and cons of keeping your head in the sand, ignoring what's going outside of Java. It argues that when a language is in its prime, this is perfectly appropriate, even beneficial, as it's better to spend your time with the language du jour than to look for alternatives. But when a language starts to show signs of wear, it's time to start looking for alternatives. Is it time? The chapter uses the analogy of boiling a frog, which doesn't even realize it's boiling until it's too late.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
murphee
Offline
Joined: 2003-06-10

> In Ruby you would say:
> raise "Missing name" if name.nil?
> In Java you would say
> if (name == null) throw new Exception("Missing
> name");
> One is 33 characters long, the other is 54.

Erm... how about you compare some more telling code pieces, like reading the contents of a file:
Ruby:
IO.open(IO.sysopen("foooo.txt"), "r") do |aFile|
# ... do stuff with the file and it's contents
end

Java:
BufferedReader fis = null;
try{
fis = new FileReader("foooo.txt")
// Do stuff with the FileReader and file contents
} catch(IOException ex){
// handle me
ex.printStackTrace();
} finally{
try{
if(fis!=null){
fis.close();
}
} catch{
}
}

Now tell me... which one is easier to write and easier to read. Note how the Java developer has to jump through hoops to get the InputStream closed, whereas this is done implicitely in Ruby (the open method takes opens the file, executes the block that is given, then closes the file).
This pattern alone is very convenient and makes IO with Ruby much clearer and just as stable (Actually: I'm not sure that all programmers would actually jump through all the necessary hoops to ensure the file is closed in Java).
It's possible to do something similar in Java, but the verbose anonymous class syntax in Java still makes this longer than the Ruby version (not to mention some pragmatic problems; for instance: using anonymous is a problem with Hotswap because changing almost anything in an anonymous class makes Hotswap require a restart because the class changes).
Note also: Java devs have been discussing how to solve the resource deallocation problem for a long time, and many ideas have been proposed (mostly language changes like C# using keyword)... yet Ruby has this simple solution that only requires compact closures/blocks and a sensibly designed IO library.

tackline
Offline
Joined: 2003-06-19

At least that's a more convincing example than the code in the book. If I wanted to choose a programming language on the basis of writing an entire program to print a string four times, then Java isn't very good.

As you say, it would be quite normal if this were a common operation, to write the Java version in the same way as your Ruby version. The only real problem is Java's clumsy syntax and lack of target typing. There is certainly no need to write it out in full every time, as above, or make such a fist of doing so.

murphee
Offline
Joined: 2003-06-10

> At least that's a more convincing example than the
> code in the book. If I wanted to choose a programming
> language on the basis of writing an entire program to
> print a string four times, then Java isn't very
> good.

You'll have to consider that this idiom can be (and is used) in many libraries for various other uses (not just File IO).

It's very useful for code that needs to manually free resources. Thinks of network connections/sockets, database connections or... transactions (the code in the block would then be executed inside the transaction, if it fails then then changes are rolled back).

tackline
Offline
Joined: 2003-06-19

I am aware of the idiom. It's well known and often used. For instance, I happened to be looking in a completely unrelated context at Apache Jakarta Commons DBUtils. Guess what? It does much the same thing as I have done from about the same time I started writing in Java 1.1.

batate
Offline
Joined: 2004-03-12

I do think you need to take terseness into account, especially in a language as readable as Ruby. But that's only a small part of the equation. In Java, I moved from stills into motion pictures. In Ruby, I moved into color. The higher abstractions also have something to do with it (one-line if, unless and while modifiers, closures, parallel assignments, dynamic typing, open classes, exploration). First-class regular expression support. Ranges.

So do the frameworks, which all tend to have a better defaulting strategy than Java. Moving away from XML for the expression of data helps (but you've still got excellent XML tools, with closures, where they make sense). So I think from a language perspective, I can express myself much more quickly.

And Ruby on Rails is revolutionary. It's not for all problems, but you basically start with a working CRUD-based model. The scaffolding jump starts you, and it melts away when you don't need it anymore. The AJAX is amazing. And it's so easy to code with good structure. It's like I get a 3x improvement with Ruby over Java, and then another 3x with Rails.

But don't equate Beyond Java to Rails, unless you look at things from this perspective: I like dynamic languages, and I think Rails is a catalyst, and I think catalysts are important. So in some ways, I'm going to the dynamic language with a catalyst, but Smalltalk or Lisp would have both suited me nicely as well.

batate
Offline
Joined: 2004-03-12

> Those people that develop on 'vi' and complain about
> 'complexities' deserve all the complexities they
> get.
>
> It's like someone from 2000 years ago look at a tall
> building and say "Why do you complicate things so
> much, we can all live in huts", or look at car and
> say "I think I can find better horse, it's so much
> less complicated", exactly that, someone that ignores
> the platform and the proper tools is someone that is
> trying to find the "perfect horse" for competing with
> a car, the car would be the platform (libraries,
> middleware, dev tools) in general.
>
> My advice is:
>
> - It's unexcusable not to learn several kinds of
> programming languages and paradigms. Later you'll
> stick with the one that works for your problems.
>
> - Think "platform" and not "language", and a whole
> new world will open before your eyes. The people from
> C++ uses the underlying operating system as the
> platform, we have platform that runs on multiple
> platforms.
>
> I'm not american but the impression I have is the
> people there develops using HOP
> (Hype-Oriented-Programming).
>
> C# won't kill Java. Most of the developers that are
> there used already MS platform before and just
> migrated, and as a matter of fact, I have met some
> companies migrating from MS to Java here in Brazil,
> because the market was demanding it.
>
> Now the newest hype, the one that will give zero
> bugs, the answer to all problems, the panacea, the
> "philosopher's stone" of the day that will turn all
> your business into the purest gold, is Ruby. hehe
> Forget unit testing! Forget UML! Forget RUP! Forget
> fancy IDEs! Forget middleware that enables you to
> build escalable, robust, enterprise applications! All
> your problems are over, meet Ruby!!

Actually, RoR is just another tool in the tool box. I still do quite a lot of consulting on Java. But your characterization is not at all accurate; neither is the characterization about what's actually said in the book.

But I agree with your premise, that it's easy to give into hype. That's the point of the chapter. For a time, the smart programmer ignored the worlds beyond Java, because it was productive to do so. At some point, new languages will emerge, so this ignorance is more dangerous. The only real conclusions I draw in the chapter, and indeed in the book, are that

1) It's time to start paying attention again; and
2) It's a dangerous time for Java, because Java's abandoning its base.

murphee
Offline
Joined: 2003-06-10

I call bullshit on your FUD attempts... let's dispose of them:

> your business into the purest gold, is Ruby. hehe
> Forget unit testing!

Bullshit. RubyOnRails heavily favors testing, in fact: whenever you create controllers, models,... unit tests (or skeletons for them) are automatically created.
I can't say that for J2EE tools.

At RubyConf2005 there were several talks about various aspects of testing in the Ruby space, also about
ways of going beyond the state-of-the-art in Unit testing:
http://jroller.com/page/obie?entry=teclarative_synchronicity

> Forget UML!

Huh? Everyones using UML for design visualization,
for example see this article on modular APIs on
artima.com (the open minded artima.com guys have created
a Ruby magazine... imagine that... a heavily Java based website doing Ruby):

http://www.artima.com/rubycs/articles/modular_apis_with_rubyP.html

> Forget RUP!

Well... that's actually a good thing...

> Forget fancy IDEs!

Huh? Eclipse plugins for two popular dynamic languages:
are RDT for Ruby and pydev for Python.
Ruby on Rails also has a RadRails (based on Eclipse) to make RoR development even faster.

> Forget middleware that enables you to
> build escalable, robust, enterprise applications!

Huh? Hookup your Ruby app to more scalable backends if you already have them... what's the problem?

batate
Offline
Joined: 2004-03-12

> Just wanted to point out that the whole boiling frog
> thing is a myth. According to experts, the frog will
> jump out of your froggy bouillabaisse if it can, no
> matter how slowly you heat it.
>
> Come to think of it, I bet the ostrich and owl
> stereotypes aren't accurate either... both are
> admirable creatures in their own right, and I
> wouldn't dare trash talk either of them to their
> faces. Or talons.
>
> Even if these beliefs aren't accurate, they might
> still support the author's contention, ironically:
> it's very easy to regurgitate the same old dogma,
> , and fail to critically assess cherished beliefs.

I wish you had reviewed the book! ;) Three people have pointed that out to me.

But the metaphor is a good one to communicate the intent of the talk: some slower changes are harder to notice.

robilad
Offline
Joined: 2004-05-05

You seem to have missed that I said that there is no particular reason for them to look over the fence *right now*, instead of at any other point in the past five years.

But you asked about the book, so ...

I think O'Reilly's PR team is awesome. The "Beyond Java" book PR buildup is near perfect, and the "anecdotal evidence from one of us confirms superior technology exists" used to drive the point home is a nice device to get the target audience to take his points seriously, contrary to say, citing scientific studies going about the same point. His point is a good one, and I hope for O'Reilly that they'll succeed in marketing Ruby to Java developers, and spawn a new series of books to help them get into it. Best of luck to all involved.

My point is that the book is about nothing exceptionally newsworthy: Ruby On Rails has been around for a while, and it's nice, afaict. Technologies that do particular jobs better and make people more productive than pure java have been around since forever. See the JPL study from 2000 for a LISP vs Java comparison, where LISP shows as great results as Ruby does today. In words: five years ago.

So, what else is new?

cheers,
dalibor topic

rickcarson
Offline
Joined: 2004-03-04

So I was thinking I should have another look at Ruby.

In Ruby you would say:

raise "Missing name" if name.nil?

In Java you would say

if (name == null) throw new Exception("Missing name");

One is 33 characters long, the other is 54.

I'm going to discount whitespace, because I think proper whitespace is never a bad thing... and we have 30 vs 48... so in our scientific survey with a sample size of one, Java is 60% longer.

Does this mean it takes 60% more time to write Java than Ruby? My instincts tell me no. I think some people would say yes... you don't have to look far to get a comparison between various scripting languages for who can write the shortest Hello World program for instance.

I think those people are wrong, but even if I'm right, its not a 'bad' kind of wrong, and if they're happy then why fight about it?

Still... lets say for the sake of argument that terseness accounts for a small speed up... heck, lets be generous and say it gives Ruby a 2:1 speed advantage over vanilla Java. That still wouldn't account for the 'massive increase' that people claim for Ruby on Rails.

Perhaps the important part is not the 'Ruby' so much as the 'on Rails'. Is there any reason why Java couldn't emulate the important part? According to http://www.rubyonrails.org/ Rails is a 'full stack' language, ie you can do the whole thing without doing context switches to other languages.

Surely you can also use Java as a full stack language?

I wouldn't disagree that RoR is better and faster than a horrible mess of Struts & JSPs - but it is not even a fair comparison. What are the numbers like when we compare RoR with Java as the full stack? What happens when we throw off the tyranny of XML and (notoriously hard to debug) JSPs?

And if Java 'just can't do it' - well, what are the missing pieces? And for heavens sake, why not add them to Java???

tackline
Offline
Joined: 2003-06-19

I assume the magic ingredient is the absence of static typing. You can add milk to coffee, but you can't take it back out. Same goes for vats of wine and thimbles of sewage.

Say I have a class which implements the non-standard bits of a type. I want to automatically add the getters, setters, member variables and initialisers for a set of bog standard properties, for instance. Alternatively I might want to catch SQLException and throw a chained application exception based on the error code in its place. Either way the class interface changes.

In Java, sure I can generate code. I can write code such that the specific code generators in these cases become trivial.

But if I have actually used my class, I'm in trouble as the finished interface is not available initially. The obvious way out is to introduce an interface, but that's exactly the sort of work I was trying to avoid. I could layer my source: generate the service code and after that compile the client code. That makes things more complicated and prohibits cyclic dependencies (which IMO, are fine between peers).

batate
Offline
Joined: 2004-03-12

Dynamic typing does indeed provide some incredible benefits. For example, dynamic typing makes open classes possible. I can dynamically add methods to a class. For example, let's say I have a persistent Person class. At run time, I could detect that you've added a column to a database table. I could then add an attribute to the class, and use the new version of Person anywhere I used the old.

Rails uses open classes pervasively.

tackline
Offline
Joined: 2003-06-19

invalidname writes:
> But when a language starts to show signs of wear,
> , it's time to start looking for alternatives. Is it
> time?

The bulk of the Java language itself that we use from day to day, is pretty much what I signed up for when I started using JDK 1.02. We knew that method pointers were important, and inner classes comfortably surpassed my expectation. We knew we needed some analogue of C++ templates, and generics does that in bounds (even if the underlying implementation sucks).

The argument of the book appears to be dynamically typed languages trump statically typed languages. We could have had the same argument in 1975 with Smalltalk vs CLU (although I would have been three). It appears that the author was a Smalltalk programmer, so why he now has a revelation, I don't know.

rickarson writes:
> My question is: "What is the target audience for this book?"

I think the last two sentences of the back cover sum it up:

"Whether you stick with Java or adopt an alternative, this book will make you think about how you're writing software, what makes you productive, and what holds you back. And it will prepare you to recognize the next big development--whatever that may be."

So, the thinking Java programmer.

rickcarson
Offline
Joined: 2004-03-04

> invalidname writes:
> The argument of the book appears to be dynamically
> typed languages trump statically typed languages. We
> could have had the same argument in 1975 with
> Smalltalk vs CLU (although I would have been three).
> It appears that the author was a Smalltalk
> programmer, so why he now has a revelation, I don't
> know.

Which makes Objective-C an interesting derivative of smalltalk... It is very dynamic at runtime, but has the compiler time b&d of a statically typed language.

I seem to recall reading about the annual functional programming contests, and someone was remarking one year about how an entry from a dynamic functional language had almost managed to beat the strongly typed functional languages - apparently they'd consistently failed to match the 'productivity' of the other languages.

> rickarson writes:
> > My question is: "What is the target audience for
> this book?"
>
> I think the last two sentences of the back cover sum
> it up:
>
> "Whether you stick with Java or adopt an alternative,
> this book will make you think about how you're
> writing software, what makes you productive, and what
> holds you back. And it will prepare you to recognize
> the next big development--whatever that may be."
>
> So, the thinking Java programmer.

So then we'd need to look at what made Java successful ('the next big thing'), and look to see if there were any emerging languages that fit the bill. With the side note that from what I can tell from second hand sources (ie what people are saying about the book), the author seems to be suggesting that Ruby is 'the next big thing'. (But perhaps he's only saying that Ruby points the way to what the next big thing will be).

Factors of Java's success:
(1) When Java came out it was hailed as being revolutionary. However what it did was actually to bring together all the other 'good ideas' (eg Garbage Collection) that had been around for years already. Arguably we can see this process continuing with things like generics and aspect oriented programming - the things which people want to bolt onto Java are not original per se, but rather are people's favourite features from other languages.

So could a new language beat Java at it's own game? Simply by embracing more features than Java? I don't know how many other things are out there to grab. Maybe a better way to do arbitrarily large numbers (eg Fortran - but see BigDecimal) and things like closures and macros from Lisp. But who is to say that Java 1.8 won't have closures? It would be very hard to beat Java at this 'embrace and extend' game. C# tries, but then Java catches up quickly for instance.

So score -1 for 'the next big thing'... Java can play that game too.

(2) Large libraries. This is simply a matter of putting in the hard yards. Early on in Java history the ability to interface with jni was touted as a big deal, whereas nowdays hardly anyone talks about it because the number of Java libraries has grown so large. The next big thing will likely be able to interface to the Java libraries, like how Ruby(?) and Jython can already do.

So score 0, I'm calling this one a draw.

(3) Java had tight integration with an entirely new medium - the internet. Now arguably we haven't really done much with it, but if you wanted to do a network capable app back in say 1995-1998 nothing else came even close to the ease that Java offered. This theoretical 'next big thing' will have to be at least as good as Java over the net (and arguably that isn't a very high standard - eg Applets and Webstart). Though you could also argue that this market isn't very important because the programmers failed to capitalise on this and gain traction. In any case, the current leader of 'pretty shiny' over the net is actually Flash, not Java. So 'the next big thing' could gain traction by either trumping Flash at their own game (and also doing all the other stuff that Java does).

However the way that Microsoft has basically stalled browser development is a major impediment. Perhaps some kind of streaming bootstrapping mechanism for the 'next big thing' - eg a plugin to enable it which easily and painlessly downloads onto existing browsers the first time you hit content requiring the new language...? (Technical difficulty - off the chart).

Java really hit a sweet spot there where Microsoft was still allowing others to play with their toys while they were laying the smack down on netscape.

Also, I think it depends on large growth factors in the userbase. If you get enough new users you can break compatibility with the old ones (or tell the people stuck on Internet Exploder to 'get a life and upgrade to the latest version of firefox'). You don't have to worry about older users if the market doubles every six months or a year. So then you'd look for a new wave of growth.

What could spark that? Possibly the availability of cheap computers in the third world, plus the infrastructure to go with it (power and comms). But then since a lot of power generation is currently based off either petrochem (fat chance of that getting suddenly cheap anytime soon given the current US administrations vested interest in pushing up oil prices), or hydro, requiring large dams (hmm... is it the Yangtse that they're building that huge dam on?). Keep an eye on the international Fusion project which China is involved with, this seems like the only good candidate for a sudden (ie quick in the time scale of dam building) massive boost in power generation capability.

I note though that at one stage Freeman Dyson (I think it was) suggested that by connecting up all the power grids through Europe, Africa, Asia and even the Americas there would be efficiencies gained - since power demand typically peaks twice during the day, and then drops off during the night, since you have to have enough generation capacity for the expected maximum load, most of it is otherwise sitting around idle (and bringing generators up and down to handle that is *expensive*) - countries with low power demands (eg at 3am their time) can lend this excess power to countries at peak times (approx 9am and 6pm if I remember correctly). The caveat for that though would be the massive amount of political wrangling required due to the enormous number of people involved. Don't expect to see it inside of ten years and without an enormous amount of screaming and yelling.

The second part of the infrastructure equation is comms. Perhaps some kind of wireless solution, much like the high flying blimp idea, where it only takes a few to cover a whole city. This allows extremely rapid deployment of the capability compared to having to string billions of miles of cables all over the place. (Though arguably manpower is not something these places are short of).

Maybe sometime in the next 5-10 years we will see a sudden massive growth spurt in new connections to the internet.

The 'next big thing' will have to solve a massive distribution problem. Score: -1 for the 'next big thing'.

(Should be: minus lots and lots, but lets give it a chance)

(3) Readability. Keeping the language simple. Note the contrast here with point number one. Java was very small and simple, since the JVM did a lot, whereas over time it has become more barnacled with feature creep.

I look at some of the other languages around in terms of readability. Java piggybacked strongly off the syntax of C, without all the problems of C++ - and so because I was already comfortable with C-like languages it was easy for me to pick up. Whereas Objective-C looks and feels quite different with all the square brackets and variables in the middle of method names. Lisp is similarly hard to read because of its unusual indenting scheme (while I find that the bracketing that most people whinge about doesn't bother me nearly as much). Python is similar to Java so I find it fairly easy to read, Ruby is slightly less so because of their hungarian style notation for variable scoping on member names.

I think that the Java/C style is biased towards english speaking programmers. If we assume that there is a big wave of new connections coming, and that most of those people will not speak English (or American even :-), then I can easily believe that the 'next big thing' could trump Java's readability *for those new people*.

Perhaps this will be an IDE/Language combo thing. Eg if coding in French my IDE seamlessly changes all the 'while' keywords into 'tant que', and if I switch to Spanish 'un rato', or if I prefer perhaps 'acto' (Locientos no hablo Espanol).

Score: +1 for 'the next big thing'.

(4) Java solved a number of pains. Going from the MS world to the Java world was like ceasing to bang my head into a wall - it felt so good when I stopped. You know, its nine years on and the only time I ever feel like I'm back in the VB/MS saltmines with Java is when I have to deal with Struts or other frameworks where most of the logic has been moved out to XML.

Hence, the 'next big thing' will either eliminate the practice of putting logic into XML (though there is the matter of it being an own goal - you cannot legislate against stupidity), or it will somehow make the integration of code and XML much easier and better. Eg being able to access properties of xml as easily as though they were a bean (yes I know, but those libraries that do this in Java require overhead - I'm talking about something at the fundamental language level).

When we look at it though, this seems very similar to the prospect of mixing SQL into a traditional language. SQL, though widely hated, has persisted (nay, flourished) simply because it is so very good at what it does - which in mathematical terms is set manipulation. But of course that means that trying to integrate it into a programming language is like banging a square peg into a round hole - it always sticks out as there being 'something not quite right'.

I wonder whether the case will be the same for XML - that it is so good at what it does, that any attempt to integrate it into a programming language will fail.

Part of my problem with tools like Ant is that you look at a piece of Ant code, and you have no idea what the environment variables and context are... and I wonder if this isn't simply a matter of the extreme immaturity of the tools? What is the reason that the tool I'm using cannot tell me things like what would have been previously configured? Surely for any given Ant script it is possible to view it as a hierarchy - and at each point in the hierarchy the environment should be a deterministic thing? (Of course it will change over on my colleagues machine if he has a different JAVA_HOME than myself).

Another big change is the recent emergence of Ajax. Now Ajax looks like a difficult thing... perhaps we can make it much easier by introducing a new language? But wait... isn't most of the problem actually down on the browser end?? Isn't it the Javascript that is actually the problem?

So would the 'next big thing' beat out Java by trumping Ajax, to provide a good and easy consistent 'phat client' experience across a range of browsers? But doesn't that mean that they have to trump both Java *and* Javascript?

Well, the main problem with Javascript seems to be that it is fractured, because of all the 'special' case code for MS and Netscape (yes, Firefox is part of the problem, not part of the solution) and their different DOMs.

So... to recap... the next big thing requires:
(a) A massive influx of new users
(b) A massive increase in infrastructure (cheap computers, electricity and communications)
(c) A massive migration away from the current browsers
(d) Beating not one, but *three* other languages/platforms at their own game (Java, Javascript and Flash)
(e) Possibly an entirely new medium which replaces and/or obsoletes the internet

Note that some of these are related, eg (c) is not too hard to imagine if (a) happens, and if you have (c) then (d) might not be too hard either. And if you have (e), then you might have to give everyone new browsers to take advantage of it anyway.

My current thinking with Web 2.0 and social networking is that with a lot of these things we're handing off work from our local computer to the network. Eg the advantage of web based email, is that I can go anywhere and still read my email. The advantage of Flicker is that I can go anywhere and still view my photos (and I can share them with others). And so forth with things like podcasting and blogging. The net is becoming not so much a distributed processor, but a distributed data storage.

I think we will continue to see tools that enable people to easily move the content they create out onto the net (what is a home movie but a video podcast after all?).

But the interesting thing is that the net is language agnostic. I don't really care if the page which serves up my html is in Java, VB, Ruby or 'the next big thing'.

Perhaps I'll start caring if the state of the art on the front end can be advanced to become a much better user experience - a distributed phat client.

If that happens, then won't it be true that the network really is the computer?

chrisadamson
Offline
Joined: 2003-08-27

rickcarson writes:
> > invalidname writes:
> > The argument of the book appears to be dynamically
> > typed languages trump statically typed languages.

Minor nit: it was tackline who wrote that.

rickcarson
Offline
Joined: 2004-03-04

> rickcarson writes:
> > > invalidname writes:
> > > The argument of the book appears to be
> dynamically
> > > typed languages trump statically typed
> languages.
>
> Minor nit: it was tackline who wrote that.

My apologies. I blame the forum software :D

rickcarson
Offline
Joined: 2004-03-04

My question is: "What is the target audience for this book?"

I ask this because you got a variety of responses from different points of view.

Eg - is it:
(1) for people who are Java developers, who want to switch to another language
(1a) for Java Web App developers compelled by their corporation to use a particular framework, eg Struts + Hibernate
(2) for people in other languages, who want an excuse not to switch to Java (cf Paul Graham's 'Java is teh sux0rs' rant)
(3) for people just starting out, who want to know which way they should go in their careers

In reverse order - 3 seems plausible, due to the subtle insults directed at Java programmers in general, ie that they are conservative. This is, by the way, a particularly broad brush. Those of us who 'jumped on the bandwagon' 9+ years ago can tell you all about guts and balls, because we went against the MS tide at its strongest, when the 'bandwagon' was at its smallest and creakiest.

My brother was entering the job market when Java was still new, and my advice to him was to get on board. He chose instead to go with Microsoft. My hourly rate is about twice his, and I find it (in general) much easier to get work.

Programmers who've switched in the last 3-4 years or so might be the more conservative type, but my observation was that the MS crowd is much, much more conservative than the Java crowd, due to their wanting to go with the 'safe bet'. Actually, their risk is much higher. Microsoft could toss .Net out tomorrow and it wouldn't effect their revenue at all (none of *their* software is written in .Net after all) - and they have a history of churning technologies trying to find the right one (and a history of regurgitating the wrong technology, just by a different name... com, dcom, com+, activeX etc etc).

Number 2 seems also to fit the 'rhetoric' of the book. It is interesting to see someone who has written Java books lose interest in the language. But is there something genuinely 'wrong' with the language, or do they just need a change, some fresh air? I think that Java is still evolving, some good (annotations), some bad (generics), some in between (autoboxing seems like a good idea but I have recently seen some posts about nasty problems it can introduce with things like == ). Which is interesting. Up till about 1.3 I pretty much whole heartedly agreed with everything that went in (particularly 1.2 was a good step forward). Subsequently I do find myself a lot more in the 'conservative' or 'grumpy old men' camp.

Another way of phrasing this seems to be that it is good to know more than one language (comments like more tools in the toolbox etc). Well, not to get into a 'mine is bigger than yours' contest or anything like that, but I have actually used in the workplace well over 40 different languages (nb: the downside of getting a reputation for being able to fix the things that noone else is even willing to look at). I wouldn't claim to be a guru in all of them by any stretch, but good enough to fix a bug or two, sure. So as far as 'tools in the toolbox' goes, I had begun to feel that I have 'been there, done that, got the t-shirt'.

And yet, this year, for the first time in quite a while, I went out and bought books on learning not just one, but two completely new languages.

So what was my criteria for picking those languages? It was based on platform, on marketablility of 'shrink wrap' software. And here you have to think about things like Open Source - do I want to compete with people who hate money and have infinite time? (its a trick question btw)

Where are people actually making money from selling software? Joel of www.joelonsoftware.com has some interesting insights, I don't necessarily agree on his conclusions, but it is really interesting to find out what his thoughts are.

I don't agree with Paul Graham's anti-java flaming, but I do find his point about starting a company to be interesting. So from the point of view of #3, someone starting out, their choice of language(s) should be the one that offers them the most commercial opportunities. I'd be concerned if someone was working with two languages, one that they were 'forced' to do at work, and one they did at home for the love of it. My theory is that if you don't love what you do in your day job, you need to find a new job. As the saying goes, you cannot serve two masters, you will love one and hate the other.

I'm not convinced that Ruby offers significant advantages for a startup company. Paul Graham's conclusion if I recall was that people starting their own company should use Lisp - the oldest language on the block.

I find reasons like 'maturity', 'newness', 'gpl-ness', 'oo-ness', 'productivity' etc to be uncompelling, because they are subjective.

Let me be clear, if I really truly believed that Ruby would offer me a ten-fold increase in productivity, then I'd switch in a heartbeat. But instead I believe that the people who claim to be getting massive productivity increases never grokked Java in the first place.

Hey, if the Java glove doesn't fit their mindset, but the Ruby glove does, then bully for them.

But here the distinction between (1) and (1a) becomes important. I find that using the various web frameworks (struts et al) is too much like B&D, too hard, too slow. It's not just me, everyone I worked with on those projects was a lot slower and found it a lot harder going than they would normally. In that context, I can see someone switching to Ruby gaining an order of magnitude in speed. *However* that gain was from ditching the framework, and they confuse the issue by saying that it is the language that is the cause (probably they don't even realise it themselves).

For 1a I think the solution is to ditch frameworks and JSPs and go back to the metal, code in non reentrant Servlets where possible. If they find Hibernate is horrible, then they should just use JDBC. Five or ten years ago SQL was an expected part of the toolset for a programmer, and there are even tools that will generate the SQL for you and do fast prototyping of queries (eg Access, just don't make the mistake of trying to use it to prototype a UI... but for slapping together some queries on a small set of dummy data and seeing what works and what doesn't and then copying the SQL it is great).

erickson
Offline
Joined: 2004-07-07

Just wanted to point out that the whole boiling frog thing is a myth. According to experts, the frog will jump out of your froggy bouillabaisse if it can, no matter how slowly you heat it.

Come to think of it, I bet the ostrich and owl stereotypes aren't accurate either... both are admirable creatures in their own right, and I wouldn't dare trash talk either of them to their faces. Or talons.

Even if these beliefs aren't accurate, they might still support the author's contention, ironically: it's very easy to regurgitate the same old dogma, and fail to critically assess cherished beliefs.

Anonymous

Those people that develop on 'vi' and complain about 'complexities' deserve all the complexities they get.

It's like someone from 2000 years ago look at a tall building and say "Why do you complicate things so much, we can all live in huts", or look at car and say "I think I can find better horse, it's so much less complicated", exactly that, someone that ignores the platform and the proper tools is someone that is trying to find the "perfect horse" for competing with a car, the car would be the platform (libraries, middleware, dev tools) in general.

My advice is:

- It's unexcusable not to learn several kinds of programming languages and paradigms. Later you'll stick with the one that works for your problems.

- Think "platform" and not "language", and a whole new world will open before your eyes. The people from C++ uses the underlying operating system as the platform, we have platform that runs on multiple platforms.

I'm not american but the impression I have is the people there develops using HOP (Hype-Oriented-Programming).

C# won't kill Java. Most of the developers that are there used already MS platform before and just migrated, and as a matter of fact, I have met some companies migrating from MS to Java here in Brazil, because the market was demanding it.

Now the newest hype, the one that will give zero bugs, the answer to all problems, the panacea, the "philosopher's stone" of the day that will turn all your business into the purest gold, is Ruby. hehe Forget unit testing! Forget UML! Forget RUP! Forget fancy IDEs! Forget middleware that enables you to build escalable, robust, enterprise applications! All your problems are over, meet Ruby!!

Tom

I'd at least like to point out that unit testing is popular in Ruby-land. Easier to mock objects than in Java, and without the compiler safety, unit testing becomes all the more important.

rickcarson
Offline
Joined: 2004-03-04

Giving up the compiler is one of the things that I think is a big drawback about the 'scripting' languages.

I think it is also a big problem with any of the frameworks that move code out of Java and into XML. Even the most trivial spelling mistake and they grind to a halt.

The compiler catches things that I'd much rather find out earlier rather than later. That said, I have my own rigourous 'unit' testing (it is more incremental and coarse grained than the sort of 'unit' testing which TDD encourages), which would catch those kinds of bugs anyway. I have the feeling that I'm more productive with a compiler than I would be without, but I don't have any hard data to back that up.

olsonje
Offline
Joined: 2005-08-10

"tools they have at the moment work well for them with their current work tasks"

Just because they have tools doesn't mean the language in fact works well for current tasks. There could be many reasons a tools in use, some being that its the best fit, at the moment, for a given task or a given development shops knowledge set or prejudice or unwillingness to look outside the box. Just because you have a tool doesn't mean it truly works well. Some things other languages might present is a tool set to work with that makes a certain task much easier & executed better. It's up to everyone to know what fits the exact problem/task, currently, and try to solve the issue using the best tool at the time.

Or at least that’s my thoughts on it.

robilad
Offline
Joined: 2004-05-05

Yep. There are various alternatives, and surely some of them offer advantages for specific problem sets.

But I don't see Java developers switching over en masse to them, since afaict Java developers are conservative about change and passionate about what they have at their disposal. It already works good enough for them. It is a successful bread-and-butter platform, and delivers in the areas where it's used.

Java developers could have switched any time in the past five years to modern C++, python, C# or PHP, to name a few, but by and large, I didn't see a large exodus of Java developers.

I honestly doubt we'll see the massive switch of today's Java developers to Ruby or any other 'subjectively superior' technology soon, unless there is a significantly more compelling reason than that they've got better (language) technology.

There is no shortage of exciting programming languages. There is no particular reason for Java developers to favourably look at alternatives now in comparison with any other point in the past five years, and they have largely not switched away from it in the last five years, afaict.

For a word from the Sun folks about all that, see http://java.sun.com/javaone/sf/2005/fireside_chat.jsp which mentions Ruby, and the conservativism. For a proof of passion, see any Java vs. something else discussion :)

cheers,
dalibor topic

invalidname
Offline
Joined: 2003-06-09

[i]There is no shortage of exciting programming languages. There is no particular reason for Java developers to favourably look at alternatives now in comparison with any other point in the past five years, and they have largely not switched away from it in the last five years, afaict.[/i]

Actually, the point of the book is that there is a reason for Java developers to look favorably to other languages - people who've used PHP and Ruby on Rails say they're far more productive than Java, with all its configurations and deployment descriptors and whatnot. In section 1-1, Tate writes:

"My partner and I decided to implement a small part of the application in Ruby on Rails, a highly productive web-based programming framework. We did this not to satisfy our customer, but to satisfy a little intellectual curiosity. The results astounded us:

* For the rewrite, we programmed faster. Much faster. It took Justin, my lead programmer, four nights to build what it had taken four months to build in Java. We estimated that we were between 5 and 10 times more productive.

* We generated one-fourth the lines of code; one-fifth if you consider configuration files.

* The productivity gains held up after we moved beyond the rewrite.

* The Ruby on Rails version of the application performed faster. This is probably not true of all possible use cases, but for our application, the RoR active record persistence strategy trumped Hibernate's Object Relational Mapping (ORM) , at least with minimal tuning.

* The customer cared much more about productivity than being on a safe Java foundation."

By the way, dalibor, you're aware we're discussing the "Beyond Java" book here, right? None of your posts thusfar have specifically mentioned the book.

olsonje
Offline
Joined: 2005-08-10

I haven't recieved my copy of the book yet, so I can't answer this for myself, but does he take into account the time previously spent on understanding the project domain & any other issues in the inital creation of the java version and factered/considered that into the RoR time?

bruce tate

> I haven't recieved my copy of the book yet, so I
> can't answer this for myself, but does he take into
> account the time previously spent on understanding
> the project domain & any other issues in the inital
> creation of the java version and factered/considered
> that into the RoR time?

Let me go into the experience in a little more detail. Justin had been writing the code, and I'd been working as an analyst, and done some data modelling (and written some hibernate code for the app). I played with RoR after a couple of conversations with Dave Thomas. My goal was just to satisfy a nagging doubt...what if I'm wrong, and there's a better answer for my customer? I did just the Active Record model in just 2 days. I called Justin to brag, and suggest that RoR was in fact pretty clean and real (MVC; partials; templates; etc), and he'd started to play with it for the same reasons and had completed the app in 4 nights, blogged about it, and run performance tests. Selling to the customer was easy.

I've got no problems with people who say a job should be faster the second time...but that much faster??? I mean, we were doing CRUD with an existing data model. Not rocket science. Working against us was this: neither of us had ever written a line of Ruby in our lives.

So saying "it's much faster the second time" is kind of like saying "Yeah, but it's a dry heat" in a 120 degree Phoenix. I mean, give us a little credit. We've developed software before, and all great programmers have rewritten code. This was a much different experience.

But thanks for the question...and thanks for asking instead of jumping to conclusions.

olsonje
Offline
Joined: 2005-08-10

bruce: Thanks for the response, and your response is exactly what I was hoping for. Sorry if I gave the implication that it was much faster the second time, didn't mean it to come off that way, it was more wondering if that at all factored in. Thanks again! :)

Message was edited by: olsonje

batate
Offline
Joined: 2004-03-12

> bruce: Thanks for the response, and your response is
> exactly what I was hoping for. Sorry if I gave the
> implication that it was much faster the second time,
> didn't mean it to come off that way, it was more
> wondering if that at all factored in. Thanks again!
> :)
>
>
> Message was edited by: olsonje

I actually liked the way you asked the question instead of laying out the obvious. Kudos.

robilad
Offline
Joined: 2004-05-05

I found http://www-cs-faculty.stanford.edu/~eroberts/java/java-problem-taxonomy.... to be an interesting reading on the problems with Java as a first language for teaching. See also http://www.cs.luther.edu/~bmiller/Papers/paper20.pdf for positive experiences with python instead of Java. For positive experiences teaching 1.5 see 'Taming the tiger: teaching the next version of Java' by Jeremy D. Frens.

I'd say it's so-so: Java works well for certain problem sets, in particular since the language is not too complex, and there is a wealth of reusable open source software that helps solve problems falling into those problem sets.

But of course, there is a wealth of reuseable open source software in other programming languages as well, and there are programming languages that are subjectively experienced as at least as nice as Java to work with by developers using them (O'Caml for example, in my case).

I think the interesting question is: why does any of that matter to an average pure-java-for-life developer?

Traditional languages like C or C++ have been successfully lifting a lot of weight (kernels, toolchains, vms, desktops, office suites, web servers, web browsers, you name it ... the dominant open source implementations in those areas are not written in java) outside of the problem sets in which Java has made inroads, without seing very much attention from Java developers, afaict. I assume that's because those languages do not play a major role in those application areas where Java is largely used by its intended developer audience.

On the other hand, there are very nice languages and open source library stacks available for problems areas in which Java is strong atm, and I guess the question for a lot of pure-Java-only developers is how to compete with that. Or if to compete at all.

It will be fascinating to watch how all that unfolds, and which way the JCP decides to go regarding the further evolution of the platform. I'd expect a careful and conservative approach from the JCP, as in the last 10 years. Whether that will be good enough to keep Java ahead of the pack in the areas where it is currently ahead or to extend its outreach into other areas, will be a very exciting question for future core JSRs in the next 5-10 years.

cheers,
dalibor topic

robilad
Offline
Joined: 2004-05-05

And I might add, that I don't really think any of that (ruby, C++, C#, o'caml, perl6, python) matters too much for your average Java-only programmer anyway, since the tools they have atm work well for them with their current work tasks.

Given that the existing platform today is very successful, it's going to stay entrenched in the industry for a long time, whatever happens, just like COBOL, or FORTRAN are in their niches.

cheers,
dalibor topic