Java should stay Java (?|!)

December 16th, 2007

Josh Bloch’s talk at Javapolis caused quite a stir in the blogosphere, why is best summed up in a blogpost and its comments: Is Java a simple, less skill demanding language or is it - better can it be - also a home for programming geeks.There are two sides and a point can be made for both of them. As java had been need it was a geeky language - admittedly fueled by the internet hype - which attracted brillant minds. Thanks to these forerunners Java is now one of the top choices for mainstream programming. The ones of these who still stick around in the Java world now look with envy on Ruby, Scala and sometimes back on Smalltalk and want to use the ideas and techniques prevalent there in Java as well. But in practice - unless you happen to work at Google - most java programmers are not of this class. Big application written in Java are written and maintained by ordinary developers, not übergeeks that think in monads.The typical Java programmer in a large enterprise is more of the type of the VB programmer, perhaps he did some C or COBOL before. These people and their thinking about programming is deeply rooted in imperative style.A point could - and personally I think it should - be made if projects really require such large staff and if it weren’t better to use more advanced stuff to build it with fewer, but appropriately skilled developers (this is the Ruby claim), but face it, the enterprise world changes too slowly to accomondate for that.More than 10 years ago we evaluated some new development environments as a replacement for Oracle Forms 3. The most interesting candidates had been Forms 4.5 (obviously), Smalltalk (I don’t remember the vendor) and Franz Allegro CLOS (Ok, this had been the one I fancied). Java had been 1.1 or so in these days and the first looks at it were disappointing, C++ had been already in use, but there had been so many problems with it that it wasn’t ever really a consideration. Eventually we went for Forms because it would give our staff the easiest transistion. The main problem with Smalltalk and CLOS had been the paradigm shift. Neither the pure OO of Smalltalk nor the functional programming in Lisp were accessible to them.I think that the same could happen to Java if all the fancy functional programming (I love it!) would get into it. There are three problems

  • FP is not compatible with the mindset of the majority of enterprise programmers. Also FP programs are harder to debug - this is a problem for the prevalent trail-and-error programmer (aka debugging into existence)
  • Java is not Scala, one problem of BGGA is the non-local return. This isn’t an issue in true FP languages which are expression oriented, the statement oriented Java makes it awkward to deal with it
  • DSLs are in fashion and a powerful concept for layering a complex application, but they create as well new languages: You can’t hire a Lisp or C++ programmer and expect him to be immediately productive as they have to learn the DSLs of your projects first

I initially found CICE (which Bloch promotes) to come a bit short, but now I am convinced that this is the right way to change Java as it keeps the characteristics of the language and can easily integrate into larger teams in any organization.This is the curse of being a mainstream language, you most not let out you users in the cold.For the other classes of problems languages like Scala that run on the JVM could be chosen. There some research has to be done by the system architect(s) how such code can integrate with Java code and how maintenance can be organized. This isn’t a trivial problem as not everything from another JVM language integrates seemlessly with Java code (i.e. you use this code as if it was written in Java), as well the question has to be answered (in each indiviual organization) if there is enough stability in the project to support an other language throughout the life-cycle - imagine a freelancer writing some core code in a language only known by him.

5 Responses to “Java should stay Java (?|!)”

  1. Greg M Says:

    FP makes things much easier to debug IME - basically because state is explicit you don’t have the snapshotting problem, and it’s easier to isolate components for unit testing.

    Eventually the solution to all this is that people need to be introduced to programming via languages that don’t make them worse programmers than they were before. Procedural thinking is a learned helplessness.

  2. david Says:

    I agree, FP makes debugging easier.

  3. the_dormant Says:

    I’m still looking for a problem(a programming one) which can be better expressed/solved in Java than in Scala. Granted Java is better for solving HR problems, but if we want to start building the software of the future, we’d better teach our kids a better language/paradigm than Java, otherwise we’ll be stuck rewriting our information systems exactly the same way we’re doing it right now for still another decade. Java isn’t offering any new mean to change the status quo, beside some variations at the syntactic level. Every “innovation”(when you recover from blindness, everything is innovation) is coming from other communities. It’s probably a sign that java has reached its limits and that it’s probably the time to move.

  4. sapphirecat Says:

    I find the DSL argument curious. Let’s assume it takes 1 month to get up to speed on the DSLs, but afterward, it makes changes to the software happen twice as fast. Then in two months, you break even, and you end up being faster than your competitors.

    But “twice as fast” is an insanely conservative estimate. It’s my experience that any system small enough to hold the necessary pieces in my head at once can be developed around four to ten times as quickly (depending on how much backtracking there is as we learn more about the problem). At even a 5x rate, it would be a less than a week before that month-long investment paid off.

    If your programmers stay for less time than it takes to learn the DSL and produce a payback, then your hiring process or company culture is severely broken. If the DSL itself takes a really long time to learn, then you might not have hired a very good programmer.

    And kind of an aside: doesn’t the existing implementation and architecture form a ‘language’ of its own that new programmers have to get up to speed on? Just because it’s bog-standard Java or Blub doesn’t mean it’s instantly known. Your new hire still has to learn the classes, objects, patterns, and roles in your codebase. Likewise, coding in Blub doesn’t free them of the need to understand the business domain.

  5. Russell Ryan Says:

    Isn’t his name Josh Bloch ?

    thx, I corrected it

Leave a Reply