in defense of Java, again [was: Re: Task Scheduling]

Bryan Sant bryan.sant at
Wed Jan 25 16:37:44 MST 2006

On 1/25/06, Jonathan Ellis <jonathan at> wrote:
> Oh, crap.  Somebody pushed Bryan's "Rabid java defense" button.

That's right!  And I'll do it again ya hear?!  :-)

> Have you actually used a modern dynamic language like Python for more
> than a couple days?  Have you used it with a similarly modern IDE,
> like Wing or Komodo?

No, but this sounds like a great PLUG presentation.

> I come from the Java camp.  I've presented at the Utah Java UG, twice.
> I'm no novice.  But I started doing Python full-time about a year ago
> and I feel _hugely_ more productive.

Really?  I have my doubts -- but hey, I've been wrong before.  If
someone could out-code me in <lange of choice> with <tool of choice>
doing the things I typically do, I would be really impressed.  That is
to say, if you can parse a text file much quicker and easier with perl
-- that's great -- but I don't do that often, so it's less impressive
to me (not that it isn't impressive in its own right).

Another example is Rails.  Rails is cool.  Now make a GUI app.  Make
an image manipulation program.  Make an enterprise scale system.  I
don't think Ruby is up to the task.  I gain some things but loose a
lot more.  Nonetheless, I'll surely learn Ruby because it's fun.

> It frustrates me: there's this growing camp of people saying,
> "We've been there!  We know Java!  But we recognize a better thing
> when we see it!" but [some] Java people stick their heads in the sand
> and say, "I do not like green eggs and ham!  I do not like them,
> Sam I Am!"

I do not like green eggs and ham!  I do not like them Sam I Am!... 
Wo.  Was I chanting again?

> And to a point it's understandable when you've invested all this
> time and effort in a system, to not want to start over in a new one.
> But it's still disappointing to see.

I like being a bigot and yet claim that I'm open minded.  It's really
convenient.  But honestly, I'd like to think that if I saw something
better I would recognize it and admit it.  There is some really
impressive stuff out there.  Ruby on Rails is awesome.  But honestly,
I can do similar things in Java with similar productivity and not
loose out on the runtime performance gains of Java or the massive
amounts of pre-existing OSS apps and libs nor do I need to abandon my
investment in knowing Java very well.

These other languages are improvements for certain problem domains. 
But I personally haven't seen anything in another language that just
made me want to dump Java because it was so much better (if better at
all).  Perhaps I just see what I want to see.

> > So long as it is small enough for a single person or small group to
> > maintain.  For larger projects, type-safety and mature frameworks save
> > time and reduce errors.
> I used to think this, too.  Now, I'm not so sure.
> But, since I'm going to do my best to never work for a large company
> again, I don't really care too much.  The amount of functionality
> a small group can achieve in Python is staggering.  The vast majority
> of projects won't _need_ more than a handful of developers, with
> the acompanying exponential increase in time lost to communication
> impedance.

Regardless of language you're always going to have better productivity
per head when you have fewer people on a project.  However, some
projects are just big.  Some are needlessly big because management is
bad, but other times, the problem being solved is just big.

Partly I feel this is why dynamic languages are praised so much.  They
are often used for small projects that require fewer people.  The
natural consequence is that the team is more productive (because it's
small, not necessarily because of language X per se).

As dynamic languages gain popularity, they will be used for bigger and
bigger projects with bigger and bigger teams and I believe we'll see
productivity tank.  The human dynamic is a far bigger productivity
issue than any underlying programming language used.

> > > - Need for consultants goes down
> >
> > If your staff isn't skilled enough to work with Java, then I'm sure
> > this is true.
> Oh, come on.  Let's be honest here.  Look at poor Ryan over there --
> he's barely sure what J2EE _is_, let alone whether his project needs it.
> With very few exceptions (*cough* twisted *cough*) you don't
> see this kind of bloated monstrosity in the Python world.

Good.  A lesson learned by evaluating what Java did wrong.  Keeping
things light is the right answer.  We all know this.  We all learned
it at school or through practical experience.  Keep it Simple
Stud-muffin.  Java has adapted and there are very popular alternatives
that keep things as simple or more simple than the next framework.

> Now, here we're conflating Java-the-language with Java-the-set-of-
> standards.  But you don't see one without the other very often,
> and that's where the consultants suck the blood out of the industry.

Surely this is the case for those who wade into overly-complex
systems.  EJB is overly-complex for most needs.  However, Spring and
Tomcat isn't complex at all.  The documentation is great.  There a
billions of great books on any conceivable Java topic.  The choice to
bring in a consultant is either A) laziness or B) we're stuck with a
really complex framework that we don't care to learn how it works
(aka. EJB 2.x).


More information about the PLUG mailing list