Home

Bruce Eckel has written an article on Artima, saying that Java should not change much any more, that maybe "the right thing to do is just not add the feature at all (what fun is that?). That if you can't do it right then maybe the language should stop growing and become stable. That it should stop chasing every language feature du jour."

"Arguably one of the best features of C is that it hasn't changed at all for decades. C++ has also been very stable. In that context it doesn't sound so bad that Java stabilize.
This isn't to say that features like generics and closures are "bad." Not at all. When well-designed into a language, they can be clear and powerful. But Java had that chance, back at the beginning: Bill Joy made a strong argument to include things like closures and generics before the initial release of the language, but was ignored.
People lived tolerably for many years, then suddenly it became essential that generics be shoehorned into the language. This was remarkably coincidental with the appearance of generics in C#, which also appeared to produce several other features in Java 5. It seems that the urgency of these features came not from solving true problems in the Java language, but in Sun trying to maintain the perception of competitiveness against Microsoft's C#. This is probably not so far off the mark, because the reason that Java had to be rushed out in rough form in the first place was the belief that there was a market window that must be captured. A programming language designed by following marketing impulses is eventually going to end up chasing its tail.

Never mind that C has changed significantly in the last decade, with C99 , but his point is that Java is as useful as it is because of its stability, and the emergence of other languages on the JVM is more valuable than the existence of Java on the JVM.
He closes with:

If Java is to be saved at all, it needs to become like C; a workhorse that you can rely upon. In fact, any future changes to the language need to be things that simplify and clarify the language and its use (say, fixing the classpath problem), and flesh out (for example) incomplete libraries that have languished (like JMF).
But we need to become especially conservative when considering major, fundamental language features like closures which, while they can be very appealing in theory, may have a cost that is too great in practice when they are forced into a language that values backward compatibility over the clarity of its abstractions.

What do you think? Do new features in the Java language make sense to you? What about Eckel's mention of combinatorial complexity, the complexity arising when you combine new features with each other, often in ways the original designers may not have thought of?
He mentions Scala as "the current best exit strategy for Java." Have you looked at Scala at all? What are your opinions of it? Why?

C99 isn't really that big a change. It's more like a standardization of extensions that most compilers have already been offering. So in a sense, C99 certified that programs are MORE compatible. Java language changes, on the other hand, had the opposite effect.
I'm not a big fan of Bruce Eckel, but I'm with him on this one. Java needs to stabilize, and stablize hard. No more language changes. Fully and correctly specced VM and libraries (I'm so fed up with how IBM JVM behaves differently from Sun's). GC behaviour also needs to be more deterministic.
About Scala: it looks sweet, and it really is a nice escape exit from Java. With Scala, you can let Java freeze rock solid, and keep evolving the underlying technologies from a clean(er) slate.

I don't understand this point of view at all. If you don't think the features in the next release will benefit you, just stay with the jdk you are already using!
I WANT closures. I want function types (eventually -- Josh Bloch convinces me that I may not want them half baked in JDK 7). I want generic reification. I want list and map literals and better collections support. These features will improve my productivity. People that don't want to have to learn new things can stay with the existing versions. I'm not willing to sacrifice the improvement mentality to coddle lackards.
And now that java is open source, you don't have a choice: if Sun stops adding, someone else will and we'll just see the fragmentation of java.

I don't understand this point of view at all. If you don't think the features in the next release will benefit you, just stay with the jdk you are already using!

This is a myopic and/or disingenuous misrepresentation of the situation of most companies with substantial Java investments. They need steady improvements and evolution from new JVM versions and their libraries, including for existing software. Learning new things is well and good -- if there is sufficient value to justify it.
Not all features are good, however, and some potential features have a tremendous cost to many such organizations. For instance, adding features that are very hard to learn to read and/or use properly will dramatically increase training costs in large organizations. Adding features that are easily misused or easily lead to hard to read or maintain code greatly increases maintenance costs (and/or code checkin policing and review costs).
Also for software development writing new code is a small part of its cost. Extending and maintaining existing code is a much bigger portion of the cost. This means for instance, that the need and cost for everyone in an organization to learn and remember all the cute syntactic sugar, while not of absolute import, should be weighed carefully against saving keystrokes!

Oh great, so large heartless corporate bean counters are driving innovation in the java space now? We might as well just stop using it altogether then.

Also for software development writing new code is a small part of its cost. Extending and maintaining existing code is a much bigger portion of the cost. This means for instance, that the need and cost for everyone in an organization to learn and remember all the cute syntactic sugar, while not of absolute import, should be weighed carefully against saving keystrokes!

Oh great, so large heartless corporate bean counters are driving innovation in the java space now? We might as well just stop using it altogether then.

Also for software development writing new code is a small part of its cost. Extending and maintaining existing code is a much bigger portion of the cost. This means for instance, that the need and cost for everyone in an organization to learn and remember all the cute syntactic sugar, while not of absolute import, should be weighed carefully against saving keystrokes!

This isn't about corporate bean counters -- it's about saving *me* and other developers' time and knowing that over time I have to read, maintain and extend various people's code, not just write it.

Perhaps I'm not thinking creatively enough, but I don't see a need for closures, function types, etc.. I don't just mean that _I_ don't have a need, I mean I've not seen an example where it helps.
Most example I see are quite trivial and go against the grain of a type-safe object-oriented language. A function is not an Object, but a functor is. A close is not an Object, not a FooContext is.
I realize that the above alternatives are more verbose than if java supported true function types, closures, etc. Is verbosity such a bad thing. Often, creating an Object to fulfill such needs gives you the ability to do a lot more, too.
I know there are dozens of languages that support these features, and many of them now run on the JVM and even support binding to Java libraires/objects. Why not use those?
I fear Java may be turned from a language that's good at one style of programming, into a language that's mediocre at everything.

I fear Java may be turned from a language that's good at one style of programming, into a language that's mediocre at everything.

Yeah... any programming language is just syntactic sugar for underlying computing model. But it does not mean Java should not be enhanced with new features. It is like that airplanes have been working on the same principles but today's airplanes have huge number of differences and improvements over the one created by the Wright brothers.
I have no problem with adding functional language supports, closures, (strong) type inference, parallel computation supports, or even Smalltalk-like message passing. I like the help and conveniences from those features as long as it does not give up on strong type-safety; otherwise, non of these dynamic language features are of any use to me.
After years of working in this field, I found that the difficult aspects of programming are (1) trying to make sure whatever I do does not introduce bugs somewhere else; (2) deal with large number of library APIs. Coding the "business logic" itself is rather the trivial part.
No dynamic language can give you the level of assurance of strong typing and consequently their IDE's content assist feature is fuzzy at best. Strong typing is like the lanes and dividers in the freeway, it won't prevent cars running into each other but without lanes, the freeway will be a mess. (Whereas these functor and closure are more like carpool lanes.) With good content assist, I can at least keep more hairs on my head.
So one can strong typed invent languages with functional/pure OO idioms, but if so, why not enhance Java with those nice features?
Today the hard part is not creating new language. It is to make sure you can get decent IDEs and the zillion of libraries if you need it. Java 1.5 adds generic but the Lucent API does not use it yet; too bad, but my program using Lucent still run without any change and I can continue to program with it on JDK 1.5. Try that if you switch over to Scala or Ruby or Python.

Because, as has been mentioned already, without breaking backwards compatibility, these features are hard to implement in an elegant way.

Some maybe but we have to judge on a case-by-case base. Also absolute elegance is not necessary. Like you may argue generic in Java 1.5 being not elegant but I found most quirks (most of them are either implementation issue or rules that are a bit too restrictive and can be relaxed safely) can be understood and handled after some initial uses and generics are very useful overall.
Language designer and computer scientists are not God; they make mistakes just like the ones who created Python, ruby or whatever; and those mistakes will have to stick around as long as the language is used. If there is any new "in-elegance" introduced, I doubt it can surpass the stupidity of the Date class.

Because, as has been mentioned already, without breaking backwards compatibility, these features are hard to implement in an elegant way.

Some maybe but we have to judge on a case-by-case base. Also absolute elegance is not necessary. Like you may argue generic in Java 1.5 being not elegant but I found most quirks (most of them are either implementation issue or rules that are a bit too restrictive and can be relaxed safely) can be understood and handled after some initial uses and generics are very useful overall.

They are useful but I think the cost is too great. You need a lawyer to decipher the JLS now. OK, it was already a little convoluted in areas but now it's insane.

Language designer and computer scientists are not God; they make mistakes just like the ones who created Python, ruby or whatever; and those mistakes will have to stick around as long as the language is used. If there is any new "in-elegance" introduced, I doubt it can surpass the stupidity of the Date class.

I agree but you can only apply so many changes over top of mistakes. It's like trying to lay a new floor over and existing floor. If the old floor isn't level, neither will the new one be level. And in any case you eventually will need to rip the whole floor down to the joists and start over if you want to change the floor again.
IMO opinion, Java has run a situation of diminishing returns. I actually think a Functor syntax should be added and then just stop and focus on the VM and new languages.

They are useful but I think the cost is too great. You need a lawyer to decipher the JLS now. OK, it was already a little convoluted in areas but now it's insane.

Well... I have only briefly skimmed over some chapters of the JLS since Java 1.0 and I have not actually read the new changes for generics, but I have no problem using it after going through some tutorials. JLS is hard to read because it is written in rather formal language. Try reading the XML Schema specification, which I had gone through several times and still did not get most of it out, JLS, under comparison, is as easy as a children's story.

I agree but you can only apply so many changes over top of mistakes. It's like trying to lay a new floor over and existing floor. If the old floor isn't level, neither will the new one be level. And in any case you eventually will need to rip the whole floor down to the joists and start over if you want to change the floor again.

I actually had two real experiences with un-level floors in two of my previous houses. I didn't need to rip the whole floor down. For one, I needed to lift the foundation a bit and for the other I needed to replace a few columns (in the first floor of the house.) Yeah... it would cost you $30K to $50K but it is rather standard fixes for contractors. But you don't need to rip apart or the house.

They are useful but I think the cost is too great. You need a lawyer to decipher the JLS now. OK, it was already a little convoluted in areas but now it's insane.

Well... I have only briefly skimmed over some chapters of the JLS since Java 1.0 and I have not actually read the new changes for generics, but I have no problem using it after going through some tutorials. JLS is hard to read because it is written in rather formal language. Try reading the XML Schema specification, which I had gone through several times and still did not get most of it out, JLS, under comparison, is as easy as a children's story.

It used to be easy to read. That's my point. And the other problem with Java now is that people read the tutorial and think they know everything about Java generics. What's explained in the tutorial is just the tip of the iceberg. There are so many pitfalls you won't know about unless you run into them or read the generics forums on sun's site regularly. Generics are vastly more complex than any other part of Java. In my estimation they are about as complex as the whole language prior to 1.5. And most of the complexity doesn't have anything to do with utility. It's duct-tape to hold the whole mess together.
Consider the change in PDF size:
Version 2: 4420K
Version 3: 7932K
A nearly 80% increase.
Here's a nice section from: http://java.sun.com/docs/books/jls/third_edition/html/expressions.html15.12.2.4 Phase 3:Identify Applicable Variable Arity Methods
Let m be a potentially applicable method (§15.12.2.1) with variable arity, let e1, ..., ek be the actual argument expressions of the method invocation and let Ai be the type of ei, 1ik. Then:
* If m is a generic method, then let F1 ... Fn, where 1nk+1, be the types of the formal parameters of m, where Fn = T[] for some type T, and let R1 ... Rp p1, be the formal type parameters of m, and let Bl be the declared bound of Rl, 1lp. Then:
o If the method invocation does not provide explicit type arguments then let U1 ... Up be the actual type arguments inferred (§15.12.2.7) for this invocation of m, using a set of initial constraints consisting of the constraints Ai << Fi, 1in and the constraints Aj << T, njk.
o Otherwise let U1 ... Up be the explicit type arguments given in the method invocation.
Then let Si = Fi[R1 = U1, ..., Rp = Up] 1in, be the types inferred for the formal parameters of m.
* Otherwise, let S1 ... Sn, where nk+1, be the types of the formal parameters of m.
The method m is an applicable variable-arity method if and only if all three of the following conditions hold:
* For 1in, the type of ei, Ai, can be converted by method invocation conversion to Si.
* If kn, then for nik, the type of ei, Ai, can be converted by method invocation conversion to the component type of Sn.
* If m is a generic method as described above then Ul <: Bl[R1 = U1, ..., Rp = Up], 1lp.
If no applicable variable arity method is found, a compile-time error occurs. Otherwise, the most specific method (§15.12.2.5) is chosen among the applicable variable-arity methods.

I agree but you can only apply so many changes over top of mistakes. It's like trying to lay a new floor over and existing floor. If the old floor isn't level, neither will the new one be level. And in any case you eventually will need to rip the whole floor down to the joists and start over if you want to change the floor again.

I actually had two real experiences with un-level floors in two of my previous houses. I didn't need to rip the whole floor down. For one, I needed to lift the foundation a bit and for the other I needed to replace a few columns (in the first floor of the house.) Yeah... it would cost you $30K to $50K but it is rather standard fixes for contractors. But you don't need to rip apart or the house.

It's just an analogy but I'm not talking about if the joists are sagging or something. I mean if you want a new floor and the current floor was laid improperly, laying another floor on top of it probably won't fix it and might even make things worse. And you can only put so many floors on top of each other until you are too high up.
You can only adapt a language so many times. Eventually you have to start over to support the features that were never considered in the beginning. If Java broke backwards compatibility, you could renovate. But the problems with the original spec have become much worse when combined with generics. It's all over, IMO. The language has been irreparably scarred.

I agree with him and with the complexity thing, that is the same argument of Joshua Bloch - if I'm not wrong - for keeping a "low profile" with closures just simplifying the anonymous classes syntax. I agree that if people really want real closures and more stuff, that should go for a separate language that compiles on the JVM platform. Being able to support multiple languages and share the VM runtime is a great thing.
I also agree with the idea of Java becoming a workhorse in the long term (I see in the long term because to me it's still the best generic purpose language around).
For what concerns "flushing out" semi-aborted APIs, it's probably a non-issue if the Java 6 Update N will be implemented as I imagine - I mean, at that point the only real distinction will be between the tiny "core" and the "rest" that gets downloaded and installed on demand, and semi-aborted APIs can live there. BTW, if I'm not wrong, people in Sun are working on reviving the JMF for Java 7.
For what concerns Scala, it's a reasonably good designed language, but I really don't see it to bring people at large. I followed my first presentation about it at JavaPolis, and together a few other people I know we shared the same opinion. It's powerful but not easily readable and this, together with the operator overloading thing, calls really for messy code when you give it to Joe Average. Unfortunately a lot of people design things thinking that all the world of programmers are smart, well educated and trained, etc... The world is just a bit different.
This sums up pretty well my thoughts: http://stuffthathappens.com/blog/2008/01/02/scala-will-do/

Well, he *may* be right from a CS perspective but definitely not from a marketing perspective.
The reality is that technology-less managers are easily swayed by headlines like "wealth of new features in C# 3.5!" vs. "Java 7 brings no changes" and equate:
lots of new features = the future, we should use it
no changes = legacy, needs to be abandoned
Sure, C++ hasn't changed...and who is using it these days for new projects?
Whether like it or not, Java needs to keep up with C# in the "new features" war (to the extent it makes sense, no reason to go overboard) and keep up the image of a language that is still at the cutting edge of computer science.

For the sake of supporting my arguments (and because it's where most of my experience is) let's say it's for mass consumption by mostly retarded users with limited computing resources.
I've done it in both c++ and java and found that even though java was easier to write it was a nightmare to get installed / running happily with the target audience.
no matter though, java is nice too. (and this thread is taking things off topic too much probably, sorry for that)

Heh, fair enough.

Playing devils advocate poker - which language would you choose to write a new commercial desktop application with? (ie one you intend to have directly affect your income)

Honestly, C++ wouldn't be on the short list. It's kind of hard given such vague requirements, though.

For the sake of supporting my arguments (and because it's where most of my experience is) let's say it's for mass consumption by mostly retarded users with limited computing resources.

Sounds like a Windows app ;-) Then I gotta go with .NET.
I'll readily admit that Java is lacking in the desktop arena. It's painful to build a gui in Swing (I've done it quite a few times).
Personally I think that the JVM stack needs a VB-esque scripting language for building guis. I've even contemplated writing one myself. I would make it build the GUI in Swing and allow users to drop to Swing if they need to but make boilerplate a lot easier.

For a desktop application that does not require threads Adobe AIR would be on my short list.
The FLEX/AIR API is simpler to use than C++ libraries like MFC, it doesn't have the problems that Java has with users having to install JRE, and has good support for connectivity via web services.

That looks like a bug. Of course there are no bugs in any c++ libraries :-).
The reason he decided to try ActionScript is because there is a bug in the Leopard File.upload() method.
I guess we should also avoid using Leopard because it has a bug.
Just curious, how much Flex / AIR development have you done?

Maybe you are using a special version of it that my friend doesn't have access to.

Sure, C++ hasn't changed...and who is using it these days for new projects?

Jacek,
You must be pretty clueless or just a minor troll.
Millions still use C++ and will continue to do so when lowlevel system programming or high-scale performance computing is required.
There is a number of *classes of projects* where experienced people don't even consider Java, .NET and scripting languages.
I personally use whatever suits the situation. For system level programming, it's usually C++. For the typical business app backend, it's usually Java. For the typical frontend, it's usually .NET. For the typical maintenance tool, it's usually a scripting language, like Perl or Ruby.

I mean, why didn't they keep the syntax closer to Java if it is going to be pimped as "Java with extra features"? Square brackets instead of angle brackets for generics, defining parameters as "param: String" instead of "String param"... Switching back and forth between Java and Scala is not the easiest, personally I found Python (and even Ruby) easier.
Groovy is by far the best "complimentary" language when coming from Java. It provides all the trendy language features. Does Scala have String interpolation? I mean, come on, what language doesn't have "Hello $null it is now ${date}"?? I've already used Groovy in production on several project and it makes development effort so much easier. Add to that the fact that you are working with the same API idioms and support for things like Spring and you have a winner.

Just because the language doesn't feel natural to you because you've been dabbling and are used to another language(s), doesn't mean that their approach is wrong. Seriously, open your mind and look at it from a language and program design perspective, not from "easy to remember" syntax perspective.

Just because the language doesn't feel natural to you because you've been dabbling and are used to another language(s), doesn't mean that their approach is wrong. Seriously, open your mind and look at it from a language and program design perspective, not from "easy to remember" syntax perspective.

True enough, but Java and C# both did something smart -- they leveraged the market's comfort with C/C++ syntax where they sensibly could. There's nothing wrong with languages that don't but they automatically incur a resistance from those most comfortable with the syntactical traditions of C, C++, Java, and C#. Presumably this was a conscious choice, but it definitely limits their market penetration.

Very true. I think scala has similar syntax to that of C family languages (not that it's a good thing). But it feels a lot more concise and natural, at least for me.
I think the advent of DSLs and virtual machine runtimes that allow multiple language executions, will finally break the barrier to adaption of languages. It would be nice if people start designing and writing software from a domain perspective vs. from a language idiom/architecture perspective. Eventually I see software written in many languages that are able to interoperate on a particular or multiple VMs. So say if you're writing a subsystem of the application that requires parallelization, you'd pick the DSL that would best help you accomplish that like Erlangs and/or Scala's actors framework. Another subsystem that say requires a rich object/relational persistence would use java with it's wealth of ORM frameworks.
I think new languages are also going to be developed as DSLs, though not trying to be the best at everything and/or become a general purpose language, rather they'll be good at a few things that matter.
Ilya

Very true. I think scala has similar syntax to that of C family languages (not that it's a good thing). But it feels a lot more concise and natural, at least for me.

I think the advent of DSLs and virtual machine runtimes that allow multiple language executions, will finally break the barrier to adaption of languages. It would be nice if people start designing and writing software from a domain perspective vs. from a language idiom/architecture perspective. Eventually I see software written in many languages that are able to interoperate on a particular or multiple VMs. So say if you're writing a subsystem of the application that requires parallelization, you'd pick the DSL that would best help you accomplish that like Erlangs and/or Scala's actors framework. Another subsystem that say requires a rich object/relational persistence would use java with it's wealth of ORM frameworks.

I think new languages are also going to be developed as DSLs, though not trying to be the best at everything and/or become a general purpose language, rather they'll be good at a few things that matter.

Ilya

For me most DSLs require taking too much on faith as to what's really going on. With Java I know when a method is being called and on what. With Ruby, I could know this if the code was written in some styles, but by the time parens and returns are dropped, it becomes obfuscated to the point of knowing only what the author is trying to say should happen -- with little notion of what *is* happening.

For me most DSLs require taking too much on faith as to what's really going on. With Java I know when a method is being called and on what. With Ruby, I could know this if the code was written in some styles, but by the time parens and returns are dropped, it becomes obfuscated to the point of knowing only what the author is trying to say should happen -- with little notion of what *is* happening.

This is an interesting discussion to me because when you build a 'proper' domain model in Java, you are in effect, building a DSL where the syntax is Java's.
What if there were an approach to build DSLs with Java (or other similar language) where the syntax is consistently and reliably directly translatable to the longer form. Would this address your concerns?
I work in a business where there logic of the business is large and very complex. Coding these in a language like Java isn't feasible. The signal to noise ratio is too low. However, like you, I think one of the strengths of Java is (was?) that you could look at a snippet of code and know what it does. I don't what to have to crawl through the DSL's interpreter to know how it's evaluating the syntax to understand very precisely what is happening.

Ok, again the comments are directed towards not understanding a particular syntax. Same can be said for someone coming to java from a functional language or a non-C derivative saying that in their language of choice they know what is happening and in Java they feel lost. Yes, some training will be required. Coding in DSLs will not be an overnight success story. You have to read the specs and understand the language semantics.
Are we just coding java because most of use came from C/C++ and it feels familiar or is java truly an expressive powerful language/system?

Ok, again the comments are directed towards not understanding a particular syntax. Same can be said for someone coming to java from a functional language or a non-C derivative saying that in their language of choice they know what is happening and in Java they feel lost. Yes, some training will be required. Coding in DSLs will not be an overnight success story. You have to read the specs and understand the language semantics.

Are we just coding java because most of use came from C/C++ and it feels familiar or is java truly an expressive powerful language/system?

Yes, I mean no, er... yes. It's more expressive than some languages and less expressive than others. Personally I think, aside from some glaring flaws, Java makes has a pretty good power to weight ratio.
Personally I think the direction of Scala has taken a wrong turn by accommodating the desires of academics and theoreticians despite pleas from people trying to get stuff done. Not that academic and theoretical is bad it's just that Scala was supposed to be a language for 'real-world' development. I think this blog pretty much sums it up:
http://creativekarma.com/ee.php/weblog/comments/my_verdict_on_the_scala_language/
Note especially the section on:
def sum(l: List[int]): int = (0/:l){_+_}
While gratifying to certain programmers, it's not readable or intuitive to most programmers.
There was a study in the UK not long ago about teaching developers and predicting how successful they would be. The main result was that the closer the students guesses about what syntax mean prior to learning the language, the better they fared in learning it.
Conversly, this implies to me that more closely a language's syntax matches the expectations of the untrained, the easier it will be to use. I highly doubt that the above syntax shown to anyone who has never programmed would mean anything. More likely, they would be completely intimidated by it and programming in general.

Personally I think the direction of Scala has taken a wrong turn by accommodating the desires of academics and theoreticians despite pleas from people trying to get stuff done. Not that academic and theoretical is bad it's just that Scala was supposed to be a language for 'real-world' development.

Hi James,
I don't think it's trying to accomodate theoriticians' pleas. I joined the main Scala mailing list a week ago and have already seen Martin Odersky flamed for including OO language features. (To which, he politely explained that his own experience in application development points to using OO sometimes and FP other times depending on the situation.)
Granted the line of code you pulled from the blog is cryptic, but the great thing is that you don't have to program that way. You have the choice. I've seen some cryptic C code as well, but that was the choice of the developer. For the most part, when I read someone else's code, my biggest problem is understanding the problem context and not the language constructs used to express the solution.
I don't come from an academic background - all my experience has been learned in the field over 16 or so years - but I don't find anything in Scala above my head so far. (Having a copy of the recently published book is extremely helpful.) I see tools I don't recognize a use for right now.
I know you were excited about the language a few months ago. I wouldn't write it off yet. If you don't have a copy of the book, it's worth the price and you get some good explanations of features.

Personally I think the direction of Scala has taken a wrong turn by accommodating the desires of academics and theoreticians despite pleas from people trying to get stuff done. Not that academic and theoretical is bad it's just that Scala was supposed to be a language for 'real-world' development.

Hi James,

I don't think it's trying to accomodate theoriticians' pleas. I joined the main Scala mailing list a week ago and have already seen Martin Odersky flamed for including OO language features. (To which, he politely explained that his own experience in application development points to using OO sometimes and FP other times depending on the situation.)

Let's be clear Martin Odersky is one of the good guys. I was especially impressed that in his recent Java Posse interview he explicitly stated that most real world applications are built with mutable state and that the conclusion needs to be that this is useful and should be included.
That Martin Odersky is at the helm give me hope that things will pull through.

Granted the line of code you pulled from the blog is cryptic, but the great thing is that you don't have to program that way. You have the choice. I've seen some cryptic C code as well, but that was the choice of the developer. For the most part, when I read someone else's code, my biggest problem is understanding the problem context and not the language constructs used to express the solution.

Here's the problem with that. In the business world, given any piece of code more than a couple years old, more people have had their hands on it than a faded dollar bill. One of the great things that Java gives you is that the syntax is constrained in a way that makes it a lot easier to understand what other people's code does. Not that you can't write incomprehensible code in Java, it's just harder. And before anyone says anything you can't always stop it. When I come into a new shop, I have to work with what they have no matter what processes or expertise they had or didn't have. Scala gives you a lot more rope than Java. If a language has a feature, it will be used.
Ironically the "you don't have to develop code that way" is an argument I hear from the COBOL world. When I piss on COBOL for allowing all kinds of abhorrent garbage, I'm told that it's not "good COBOL". IMO, it doesn't matter. In the end these features creep into the code base. Maybe it's a process problem but I can't rebuild the dike, I need a plug.

I don't come from an academic background - all my experience has been learned in the field over 16 or so years - but I don't find anything in Scala above my head so far. (Having a copy of the recently published book is extremely helpful.) I see tools I don't recognize a use for right now.

I know you were excited about the language a few months ago. I wouldn't write it off yet. If you don't have a copy of the book, it's worth the price and you get some good explanations of features.

I'm actually still excited. I think there's a lot I can learn from using it and I might even take advantage of it on a open-source project. But no matter how much I might personally revel in the power of the language, I can't see myself ever recommending using it anywhere I have ever worked. Most developers I work with are not CS majors. I had to give a half hour explanation the other day about how this:
methodA(methodb())
Is not the same as "passing a method to a method" during an attempt to explain what functional programming is. And this is my best prospect for mentoring someone into a decent developer.
What I see in the Scala community is a lot of FP people who are trying hijack the language. Personally, if they don't like mutable state, I think they should find another language. But they seem to be winning.
I got into it with someone on the Scala mailing list about why this code:
byte[] buffer = new byte[1024];
for (int read; (read = inputStream.read(buffer)) >= 0;) {
// do stuff
}
Is a lot faster than this (at least in Sun's JVM):
int oneByte;
for (int oneByte; (oneByte = inputStream.read()) >= 0;) {
// do stuff
}
And I was told that because I was using an arbitrary sized array, it was "wrong". I never understood how reading one byte at a time isn't arbitrary but in any event, the fact that the second version takes about 30 times longer for a local file didn't matter to him. That kind of nonsense is a big turn off, even though it's not coming from the Scala development team.

Here's the problem with that. In the business world, given any piece of code more than a couple years old, more people have had their hands on it than a faded dollar bill. One of the great things that Java gives you is that the syntax is constrained in a way that makes it a lot easier to understand what other people's code does. Not that you can't write incomprehensible code in Java, it's just harder. Scala gives you a lot more rope than Java. If a language has a feature, it will be used.

You're right, the business world nowadays requires fast and furious changes. A finance company I worked in bought and sold other companies quicker than a day trader trades stock. New portfolios, new lines of business, merging new lines with old lines, etc. Java makes it tougher to make a mess, but never doubt how creative some developers can be at making messes! I'm not sure I can buy the argument that you should limit poor developers' messes by giving the team a more limited language. Why did we leave COBOL and go to C? Certainly C gives you a lot of rope that COBOL didn't?

What I see in the Scala community is a lot of FP people who are trying hijack the language. Personally, if they don't like mutable state, I think they should find another language. But they seem to be winning.

Then you are exactly the person Martin needs to hear from. You have the experience and you're trained academically for CS. You understand the issues, the terminology, and the concepts. Most of the FP stuff is new to me so my opinion is of limited value.

I got into it with someone on the Scala mailing list about why this code:

And I was told that because I was using an arbitrary sized array, it was "wrong". I never understood how reading one byte at a time isn't arbitrary but in any event, the fact that the second version takes about 30 times longer for a local file didn't matter to him. That kind of nonsense is a big turn off, even though it's not coming from the Scala development team.

And he was a hack in the worst sense of the word. 8 years ago I worked in a small IT shop. The client/server team leader was a self-proclaimed expert in OO. He had both a BS and MS in CS from good universities in Boston as well as 15 years of experience in the field. His idea of using sockets was to open/close TCP sockets after each message was passed. His idea of serializing an object was to do a socket write for each attribute of the object. His rules of OO were:
1. all attributes must have get/set methods
2. all classes must have print/display methods
3. all classes must have toString methods.
Needless to say his code was horrendously slow and bloated.

You're right, the business world nowadays requires fast and furious changes. A finance company I worked in bought and sold other companies quicker than a day trader trades stock. New portfolios, new lines of business, merging new lines with old lines, etc. Java makes it tougher to make a mess, but never doubt how creative some developers can be at making messes! I'm not sure I can buy the argument that you should limit poor developers' messes by giving the team a more limited language. Why did we leave COBOL and go to C? Certainly C gives you a lot of rope that COBOL didn't?

I don't mean limited in terms of power. What needs to be limited (for a business focused language) is overlapping and redundant syntax. It also needs to avoid arcane, unintuitive syntax. I like Scala because it is a more powerful language but every hand-waving argument about how developers don't need to understand the language fully represents (to me) problems that will be realized in a business environment.

What I see in the Scala community is a lot of FP people who are trying hijack the language. Personally, if they don't like mutable state, I think they should find another language. But they seem to be winning.

Then you are exactly the person Martin needs to hear from. You have the experience and you're trained academically for CS. You understand the issues, the terminology, and the concepts. Most of the FP stuff is new to me so my opinion is of limited value.

Partly because I switch majors and took CS credits from some Physics courses, I never was exposed to FP in school either. My education, I think, gives me a some tools for understanding some of the more academic documentation but that's all. I am almost completely ignorant of FP approaches. I probably think I know more than I do.
But I'm not against FP and I'm not even against languages without mutable state. What I am against are people trying to twist a language away from the stated goals of it's creator and condescending to people who attempt to use it for what it was designed for.

And I was told that because I was using an arbitrary sized array, it was "wrong". I never understood how reading one byte at a time isn't arbitrary but in any event, the fact that the second version takes about 30 times longer for a local file didn't matter to him. That kind of nonsense is a big turn off, even though it's not coming from the Scala development team.

And he was a hack in the worst sense of the word.

I think he's probably a pretty smart person. Well, he's what I call a dumb-smart guy. I had a Physics professor who could build all kinds of crazy electronics but would say the dumbest things. Once he told me that operating systems would become obsolete as computing power became cheaper. He had no idea why anyone would need a mouse and ran Windows without one (a really amusing thing to watch, actually.) I could go on but the point is that this kind of person is really bad at steering communities.

8 years ago I worked in a small IT shop. The client/server team leader was a self-proclaimed expert in OO. He had both a BS and MS in CS from good universities in Boston as well as 15 years of experience in the field. His idea of using sockets was to open/close TCP sockets after each message was passed. His idea of serializing an object was to do a socket write for each attribute of the object. His rules of OO were:1. all attributes must have get/set methods2. all classes must have print/display methods3. all classes must have toString methods.

Needless to say his code was horrendously slow and bloated.

Academia and engineering don't really mix all that well. My dad has a similar problem with Phd mechanical engineers. They know all the high tech science but know basically nothing about putting these ideas into practice. They screw things up like welds which might seem minor but are extremely costly and risk the entire project. The biggest problem is that they don't realize their weaknesses.
I don't want to get on my stump (again) but we really do need a more rigorous engineering discipline. Classic CS is more akin to math or physics and newer style CS programs focused on producing developers lack rigor.

What I am against are people trying to twist a language away from the stated goals of it's creator and condescending to people who attempt to use it for what it was designed for.

Unfortunately, it happens in every discipline. Individuals have their own agendas and designers will design to the community making the most noise.

I think he's probably a pretty smart person. Well, he's what I call a dumb-smart guy.

He sounds like someone who can quote dogma well. It's a different kind of intelligence and probably even useful in some circumstances. Still, not enjoyable for people who feel compelled to put out a product people can use.

I don't want to get on my stump (again) but we really do need a more rigorous engineering discipline. Classic CS is more akin to math or physics and newer style CS programs focused on producing developers lack rigor.

The professor who taught my class this past Fall put it well: CS ungrads are engineers in that they are supposed to use existing knowledge/techniques of the field to produce products whereas professors are scientists who are looking to extend the field.
I agree that software engineering principles should be ingrained in anyone in the field. The method of disseminating is my only concern.
As far as Java goes, everything I've read suggests that some of the latest tools added, e.g. generics, have made the language less appealing. Sun should probably stop adding and shore up problems. It sounds like exposure of primitive types may have ripples into the problems experienced in adding features. How to close this one up when companies transacting billions of dollars through Java software would be adversely impacted is a huge question - and a fine business opportunity if anyone figures it out.
From my perspective, when I used Java it was welcome because it took away some of the problems with pointer syntax. It also removed the confusion over when to use pointers vs. references in C++; added standard libraries; etc. I'd like to use it still.

I don't want to get on my stump (again) but we really do need a more rigorous engineering discipline. Classic CS is more akin to math or physics and newer style CS programs focused on producing developers lack rigor.

The professor who taught my class this past Fall put it well: CS ungrads are engineers in that they are supposed to use existing knowledge/techniques of the field to produce products whereas professors are scientists who are looking to extend the field.

I agree that software engineering principles should be ingrained in anyone in the field. The method of disseminating is my only concern.

As far as Java goes, everything I've read suggests that some of the latest tools added, e.g. generics, have made the language less appealing. Sun should probably stop adding and shore up problems. It sounds like exposure of primitive types may have ripples into the problems experienced in adding features. How to close this one up when companies transacting billions of dollars through Java software would be adversely impacted is a huge question - and a fine business opportunity if anyone figures it out.

From my perspective, when I used Java it was welcome because it took away some of the problems with pointer syntax. It also removed the confusion over when to use pointers vs. references in C++; added standard libraries; etc. I'd like to use it still.

I think Scala approach of close coupling to Java and the JVM is a good one for this problem. It's integration is better than Jython or example where Java primitives and Strings are not recognized as the corresponding type in Python.
I'm still on the fence about Scala. I'm waiting for things to stabilize a little more and common idioms to be fleshed out. Hopefully my fears about it being to arcane for business development will prove to be unfounded.

We are coding java because most of use came from C/C++ and it feels familiar

Very bad excuse for not learning another way to express yourself. With the least benefit being able to express yourself better with java because you've seen it done using a different language.
I always thought that learning the basics of language design is probably the biggest benefit a programmer will get. Unfortunately many curriculums these days just straight into coding after learning machine architecture (if that). People tend to associate learning new languages with their immediate usefulness. Same goes for people saying, I don't care about compiler/interpreter design because I'll never write a compiler/interpreter. I really disagree as I think learning design and different programming paradigms makes you a better programmer/designer, even if it's using a language that you'll never code outside of.

java is truly an expressive powerful language/system.

Compared to what? Have you studied different programing paradigms? Have you tried programming outside of imperative paradigm and C family languages?
Powerful I'd agree, but mostly due to the amount of high quality libraries. The libraries are getting better, with library designers finally having learned every pattern in the GoF book, actually starting to apply them as needed with refactoring in mind, not blindly as is very evident from a lot of early JDK libs.
Expressive, that's very subjective. It would depend on what you're comparing it to and if you've actually learning a different language with an open mind, not with the goal of discounting it and seeing what the hype is all about.
Ilya

We are coding java because most of use came from C/C++ and it feels familiar

Very bad excuse for not learning another way to express yourself. With the least benefit being able to express yourself better with java because you've seen it done using a different language.

I always thought that learning the basics of language design is probably the biggest benefit a programmer will get. Unfortunately many curriculums these days just straight into coding after learning machine architecture (if that). People tend to associate learning new languages with their immediate usefulness. Same goes for people saying, I don't care about compiler/interpreter design because I'll never write a compiler/interpreter. I really disagree as I think learning design and different programming paradigms makes you a better programmer/designer, even if it's using a language that you'll never code outside of.

java is truly an expressive powerful language/system.

Compared to what? Have you studied different programing paradigms? Have you tried programming outside of imperative paradigm and C family languages?

Powerful I'd agree, but mostly due to the amount of high quality libraries. The libraries are getting better, with library designers finally having learned every pattern in the GoF book, actually starting to apply them as needed with refactoring in mind, not blindly as is very evident from a lot of early JDK libs.

Expressive, that's very subjective. It would depend on what you're comparing it to and if you've actually learning a different language with an open mind, not with the goal of discounting it and seeing what the hype is all about.

I definitely agree with Bruce. I think Sun should concentrate on JVM optimizations and most likely touch up of Swing libraries (or even redesign it). Don't get me wrong, I think Sun should still focus on market trends of business need so they optimize by adding some little features to the language but they should be pretty cautious on this one because of too many trend-like hypes especially .NET ones. Microsoft is very strong in marketing so they know how to use visual effects very well to confuse people what's right or wrong.

Joshua Bloch has pointed out some major problems with Generics and I agree with Bruce that in general we have sacrificed too much usability at the alter of backwards compatibility (especially since enterprises are *still* using JDK 1.4, backwards compatibility doesn't seem to encourage them to upgrade).
Things to consider:
- Removing Generics wildcards. Most developers find them difficult to understand and they produce very ugly compiler errors. You rarely need them anyway so removing them would have a minimal impact.
- Reifing Generics. Accessing types at runtime isn't as big a deal as the fact that this will allow us to simplify the syntax. For example, we can simplify the syntax by allowing:
[code]
Map foo = new HashMap();
[/code]
where the type-parameters are picked up from the left-hand side automatically. Erasure has prevented many such readability simplifications.

- Reifing Generics. Accessing types at runtime isn't as big a deal as the fact that this will allow us to simplify the syntax. For example, we can simplify the syntax by allowing:

Map foo = new HashMap();

You can always do Map foo = new HashMap(), just that the unchecked warning would stick with it if you don't turn off that warning.
That warning is as useful as warning against regular typecasting -- good for beginner.
void f(Object obj) {
String s = (String)obj; // anybody wants this be warned as unsafe?
}

Removing Generics wildcards. Most developers find them difficult to understand and they produce very ugly compiler errors. You rarely need them anyway

I disagree. Code I write uses wildcards often and they are just the right thing that helps generified code, because you can say "a Foo with some parameter I don't know right now and I don't care". Believe me, I wrote in a language that had generics but no wildcards and the inability go write that killed me.
Plus: I find an API that uses wildcards often easier to read than without. Which one do you prefer:
void addAll(Collection c);
or
<U extends T> void addAll(Collection<U> c);
And I'm all for fixing compiler error messages instead of the type system.

Reifing Generics. Accessing types at runtime isn't as big a deal as the fact that this will allow us to simplify the syntax.

Wrong answer. One has nothing to do with each other. Type inference is a compile-time construct that is independent of whether the runtime object carries information about type parameterization.
There are some tragic aspects to Java Generics, I agree (varargs/arrays interop, verbosity). But they are far from disaster. They are actually well done given the constraints at hand.

Java is like any software application. The design phase was rushed to meet a deadline. It was imperfect but workable when it was released. Over time a number of changes – new features and fixes – were added. Eventually refactoring was needed in order to “clean it up”. At some point though refactoring isn’t enough and it needs to be replaced.
The problem with adding new features and fixes to a flawed design is that you still must support a lot of the bad things you are trying to “fix”. That’s why things begin to get messy. The more flawed the design the faster that messiness accumulates. Refactoring often includes sacrificing some backward compatibility (deprecation), but only in very limited ways. (Technically it’s not supposed to change any external behavior, but it almost invariably does in at least small ways.) Assuming your application was successful, i.e. it’s being used by a lot of people, then you are bound by a contract with your users and breaking it will lead to outright rebellion. What would happen if Java dropped primitive types and immutable classes? These things should have been JVM implemented optimizations and should not have been exposed in the language syntax. I think Java is stuck with them forever.
Of course I’d like a new Java replacement, a language that is elegant and most importantly, consistent. However, I also don’t think that one language can be all things for all people. Any new language should be designed with a specific scope and purpose. General purpose languages are a good thing, but so are special purpose languages.
I also don’t think it’s necessarily a good idea that new languages should intentionally share symbol and syntax conventions with older ones or even contemporaries except where their compile and run-time behaviors are identical. If it looks the same most people assumes it behaves the same. It is more important that a language’s syntax be expressive, easy to understand and consistent. Resembling another language’s syntax should not be a design goal.

Exactly, and like any other piece of software it degrades over time. PHP, Perl, Python, Ruby etc. all acknowledge that backwards compatibility is nice but not at the expense of fixing the language. This is my big issue with Java, it has been over 15 years since its inception and it really REALLY shows when given the chance to work with languages and API's designed with Java mistakes in hindsight.

And come on, what is the problem with running several versions of JVM anyway? I know of plenty of software (Oracle Discoverer to mention an example) that requires a certain version of Java in spite of Java's backwards compatibility claim. With such a static language and the Jackpot transformation engine, it should even be possible to provide porting tools to bring a code base up to speed.

Having written this, I am probably already stamped a troll by Java purists, that's certainly the stereotypical thing that happens when speaking ill of Java. Few can do it without being ridiculed, Bruce is one of the few who can!

So please Sun, if you are listening, forget about inventing other scripting languages and fix your main product, give us Java 3!

Java is like any software application. The design phase was rushed to meet a deadline. It was imperfect but workable when it was released. Over time a number of changes – new features and fixes – were added. Eventually refactoring was needed in order to “clean it up”. At some point though refactoring isn’t enough and it needs to be replaced.

Spot on. I don't understand why most people miss this plain historical fact. Java was behind the times even when it was launched. Where Java excelled was in skillful feature and syntax selection and marketing to meet an immediate market opportunity, unfortunately computer science lost out. If you go back and read the original position paper for Java it reads like a marketing blurb with all the right buzz-words.

The problem with adding new features and fixes to a flawed design is that you still must support a lot of the bad things you are trying to “fix”. That’s why things begin to get messy. The more flawed the design the faster that messiness accumulates. Refactoring often includes sacrificing some backward compatibility (deprecation), but only in very limited ways. (Technically it’s not supposed to change any external behavior, but it almost invariably does in at least small ways.)

Gosling insisted on a minimal feature set for Java which is ideal for getting mainstream programmers on-board, but a disaster when it comes to language evolution. Languages like Lisp and Smalltalk have radically evolved over their life time due to their superior meta features which they had at the outset. Because of this they still manage to be leading edge even today. Any useful change to Java is likely to break backwards compatibility, which is why the language has stagnated and even modest changes have proven problematic. Who would have guessed 10 years ago that we would be talking about Java like this today? Commenting on the "small foot print" of Java when compared to C++ Byrne Stroustroup made the same point many years ago, "wait until they all start asking for new features".

Assuming your application was successful, i.e. it’s being used by a lot of people, then you are bound by a contract with your users and breaking it will lead to outright rebellion. What would happen if Java dropped primitive types and immutable classes? These things should have been JVM implemented optimizations and should not have been exposed in the language syntax.

More sense. Agreed. Primitives should not have been there in the first place. Moores law always ensured that they offered only a short term advantage.

I think Java is stuck with them forever.

Of course I’d like a new Java replacement, a language that is elegant and most importantly, consistent. However, I also don’t think that one language can be all things for all people. Any new language should be designed with a specific scope and purpose. General purpose languages are a good thing, but so are special purpose languages.

There are many new Java replacements out there. Scala is one, you could argue that C# is another, Boo yet another. Having just one tool in your tool box was never the way it was meant to be. People have always used different languages for different purposes. If you want alternatives to the static imperative approach then there are dynamic languages like Ruby and functional languages like F#. Personally, I believe that Moores law has put pay to Java's niche, and it would have very limited appeal if it was a new language launched today.

I also don’t think it’s necessarily a good idea that new languages should intentionally share symbol and syntax conventions with older ones or even contemporaries except where their compile and run-time behaviors are identical. If it looks the same most people assumes it behaves the same. It is more important that a language’s syntax be expressive, easy to understand and consistent. Resembling another language’s syntax should not be a design goal.

And this is the historical lesson to be learnt from Java. Sun rushed a C-like VM based language to market, because they saw a commercial opportunity. Taking some things from Smalltalk, but missing most of the really important stuff. Then hampering the language with many of the limitations of C because C/C++ was the popular language of the time. Personally, I don't believe software vendors are good custodians of programming languages. Programming languages should be based on computer science, not short-term commercial opportunism.
Universities, Research labs, and programming communities are better custodians IMO. Computer Programs last for a very long time, so language custodians should be taking a long term view when it comes to language design. Languages should ideally serve their user community. Vendors should stick to products (which could be language implementations like ANSI C), but they should not try to "own" programming languages.
Imagine if a single publisher "owned" the English language? How bizarre!
Alan Kay once said that Java is the worst thing to happen to computer science since MSDOS, and time is proving him right.
Paul.

Gosling insisted on a minimal feature set for Java which is ideal for getting mainstream programmers on-board, but a disaster when it comes to language evolution. Languages like Lisp and Smalltalk have radically evolved over their life time due to their superior meta features which they had at the outset. Because of this they still manage to be leading edge even today.

Well, having to read other people's code on a day to day basis, I would argue they "stay leading edge" because people were then able very easily to build programs no one but the original programmer (if only!) could understand. The minimal feature set has the advantage that also a averagely talented programmer can create usable, understandable and maintainable code. Given the vast amount of development that is outsourced and offshored today, I can't even see how any language but a (mostly) statically typed imperative languages like C++, C# or Java can be used for the next decade to come, not only for maintenance reasons, but also for the need of being able to assess the quality of the delivered software.

Gosling insisted on a minimal feature set for Java which is ideal for getting mainstream programmers on-board, but a disaster when it comes to language evolution. Languages like Lisp and Smalltalk have radically evolved over their life time due to their superior meta features which they had at the outset. Because of this they still manage to be leading edge even today.

Well, having to read other people's code on a day to day basis, I would argue they "stay leading edge" because people were then able very easily to build programs no one but the original programmer (if only!) could understand. The minimal feature set has the advantage that also a averagely talented programmer can create usable, understandable and maintainable code. Given the vast amount of development that is outsourced and offshored today, I can't even see how any language but a (mostly) statically typed imperative languages like C++, C# or Java can be used for the next decade to come, not only for maintenance reasons, but also for the need of being able to assess the quality of the delivered software.

Hi Karl,
I actually agree. Dumbing down programming to "painting by numbers" and off shoring "coding" to any part of the world as an activity that can be performed by cheaper "lesser" programmers does need a language with certain characteristics and Java does fit this role well.
Many however are realising that this approach to software development is flawed, and that real economies can only be made by skilling-up rather than dumbing down.
I think it is this realisation, lead by the Agile Development movement that is driving the demand for languages with more advanced features.
The thing is that programming is not like digging a hole it is an intellectual exercise, and it is intellectual capital that counts the most wen it comes to productivity, and delivering high business value over the full system life cycle, not cheap "bums on seats".
Paul.

I actually agree. Dumbing down programming to "painting by numbers" and off shoring "coding" to any part of the world as an activity that can be performed by cheaper "lesser" programmers does need a language with certain characteristics and Java does fit this role well.

Many however are realising that this approach to software development is flawed, and that real economies can only be made by skilling-up rather than dumbing down.

I think it is this realisation, lead by the Agile Development movement that is driving the demand for languages with more advanced features.

The thing is that programming is not like digging a hole it is an intellectual exercise, and it is intellectual capital that counts the most wen it comes to productivity, and delivering high business value over the full system life cycle, not cheap "bums on seats".

Paul.

I am of the opposite opinion: You have to drive for "digging a hole" kind of simplicity/limitation in order to achieve effective mass production in any industry. Software is no exception.
And Java was intended to be that kind of "blue collar" language to begin with. If you want to play programming like it is an art rather than engineering, go for some other "better" language because Java is probably not your cup of tea.

I actually agree. Dumbing down programming to "painting by numbers" and off shoring "coding" to any part of the world as an activity that can be performed by cheaper "lesser" programmers does need a language with certain characteristics and Java does fit this role well.

Many however are realising that this approach to software development is flawed, and that real economies can only be made by skilling-up rather than dumbing down.

I think it is this realisation, lead by the Agile Development movement that is driving the demand for languages with more advanced features.

The thing is that programming is not like digging a hole it is an intellectual exercise, and it is intellectual capital that counts the most wen it comes to productivity, and delivering high business value over the full system life cycle, not cheap "bums on seats".

Paul.

I am of the opposite opinion: You have to drive for "digging a hole" kind of simplicity/limitation in order to achieve effective mass production in any industry. Software is no exception.

And Java was intended to be that kind of "blue collar" language to begin with. If you want to play programming like it is an art rather than engineering, go for some other "better" language because Java is probably not your cup of tea.

Yes I agree. Some think that software development is analogous to manufacturing where you can split the job into simple parts and de-skill the work force. This is what Henry Ford did. He hired cheap Immigrants which he could hire and fire.
Others think that Software Development is more closely analogous to New Product Development where creativity counts and where you need a small highly skilled team, of self organised and empowered professionals. People over processes and tools.
Even in manufacturing, the idea of creativity and worker empowerment through quality circles, where people continually improve how the job is done has proven to be the most efficient approach. Take a look at Toyota and their Lean approach to everything.
Some think, that Agile/Lean thinking could do to mainstream programming, what the Japanese motor industry did to American car manufacture in the 1970's. Time will tell, but there is already evidence of this happening in the Web2.0 arena (Java and Waterfall thinking is almost non-existent here).
The good thing is that with the breakdown in the "dumb programming down" consensus , new languages and approaches are merging and we now have a choice. Choice has got to be a good thing.
Something that you may not know. Agile development was born out of peoples experiences with OO programming and Smalltalk in the 1990's. This implies a link between the language (tool) and how best to organise the work (people). The mainstream are beginning to catch up with this thinking, and I believe that this is what is generating the demand for new features in Java.
Like I say we now have tools which support different ways of working (e.g. Ruby), giving us all a choice. My choice just happens to be different from yours.
Paul.

This rant just proves my point. Choice is good. If Ruby is not for you then choose something else.
With Java and C# dominating mainstream software development, for many years there was no choice. Now with the rise of dynamic and functional languages we now have real choice for the first time in over a decade. There has also been a resurgence of pure, message based OO, providing an alternative to the hybrid, static form we've all got so use to.
Pay your money and take your choice. The fact that Java people are looking enviously at features from these other languages and exploring how they could be incorporated into Java is telling in itself.
Paul.

With Java and C# dominating mainstream software development, for many years there was no choice. Now with the rise of dynamic and functional languages we now have real choice for the first time in over a decade. There has also been a resurgence of pure, message based OO, providing an alternative to the hybrid, static form we've all got so use to.

Pay your money and take your choice. The fact that Java people are looking enviously at features from these other languages and exploring how they could be incorporated into Java is telling in itself.

Paul.

Paul, I do in fact agree that "choice is good". But I don't buy the point. Take "plain OO" as an example. For years there was Objective-C available in the marketplace that offers quite a good smalltalk like approach to object orientation and outperformed Java by orders of magnitude. Yet its market penetration outside the Mac OS/X world is very close to zero.
Ruby is nothing new, nor is Scheme, nor is Lisp, nor is Python. These languages were alive and kicking about the same time Java was or even earlier. Take Python: At the very advent of the first usable "J2EE Appplication Servers" you were able to use something like Zope for Web development. The first "web application servers" that I can remember used JavaScript - they are no more.
All these languages did not account for the majority of web development - Perl did, later Java and PHP or mainstream software development where C++, C, Java and other ruled (and still do). Even now, I would consider the impact of Ruby and the like as marginal. They mostly play the part TCL did for C applications. While there were various application written in pure TCL/Tk, this proved to be an evolutionary dead end.
Agile development is still alien to a lot of organizations if only because they are not prepared pay the price of engaging into the software development process in the required way.
People will alway look at certain features they find usable in a certain context. That does not necessarily mean that they are "better" and it does not mean that the added complexity of the language outweighs the advantages! This is were the choice comes in. However to choose, one needs to be well informed about the strengths and weaknesses of the available approaches - which leaves me somewhat pessimistic.

With Java and C# dominating mainstream software development, for many years there was no choice. Now with the rise of dynamic and functional languages we now have real choice for the first time in over a decade. There has also been a resurgence of pure, message based OO, providing an alternative to the hybrid, static form we've all got so use to.

Pay your money and take your choice. The fact that Java people are looking enviously at features from these other languages and exploring how they could be incorporated into Java is telling in itself.

Paul.

Paul, I do in fact agree that "choice is good". But I don't buy the point. Take "plain OO" as an example. For years there was Objective-C available in the marketplace that offers quite a good smalltalk like approach to object orientation and outperformed Java by orders of magnitude. Yet its market penetration outside the Mac OS/X world is very close to zero.

Ruby is nothing new, nor is Scheme, nor is Lisp, nor is Python. These languages were alive and kicking about the same time Java was or even earlier. Take Python: At the very advent of the first usable "J2EE Appplication Servers" you were able to use something like Zope for Web development. The first "web application servers" that I can remember used JavaScript - they are no more.

All these languages did not account for the majority of web development - Perl did, later Java and PHP or mainstream software development where C++, C, Java and other ruled (and still do). Even now, I would consider the impact of Ruby and the like as marginal. They mostly play the part TCL did for C applications. While there were various application written in pure TCL/Tk, this proved to be an evolutionary dead end.

Agile development is still alien to a lot of organizations if only because they are not prepared pay the price of engaging into the software development process in the required way.

People will alway look at certain features they find usable in a certain context. That does not necessarily mean that they are "better" and it does not mean that the added complexity of the language outweighs the advantages! This is were the choice comes in. However to choose, one needs to be well informed about the strengths and weaknesses of the available approaches - which leaves me somewhat pessimistic.

Hi Karl,
Lots here! Objective-C lost out to C++, but in the long run Steve Jobs was proved right, which is why NextStep/MacOSX is vastly superior to Windows XP.
Smalltalk was killed off by Java. Mostly because many thought that Java was a "good enough" Smalltalk without the performance penalty (and the licensing costs!). People who had performed years of OO research made the point quite vocally that it was not, hence Alan Kays "Java is the worst thing to happen to computer science since MSDOS". But these words fell on death ears.
The reality is that most developers have very little choice over the language they use. Languages and tools are sold to management, and management like to stick with the herd. Now the herd is Java, before that it was C++. This doesn't mean that either of these languages where the best of breed at the time. They just so happened to be top of the pops.
You only need to look at the efforts made to create a late-bound component model for C++ (COM, DSOM, OpenDOC, CORBA, Taligent etc). To see that computer science has very little to do with it. You got late-binding out of the box with Objective C. There were great components available for NextStep in the early 90's, yet Windows in C++ dominated. Explain that?
We are in an industry where science plays a secondary role to commercial interests and marketing. Who do we have to blame for this? Ourselves. The vendor marketing machine leads, and us the technologists follow. They say everything should be C++ or Java and we follow.
The main concern of the average Java programmer is that he can find a job. Period. Computer science is not his concern.
The side effect of broader choice is that development teams will have to choose for themselves. No more safety in numbers, no more following the herd. We will need to become informed and make appropriate choices, or we are likely to be killed off by competitors who do (thats my hope :^)).
Personally, I don't think the dominance of any single language is a good thing. I like Ruby, but I would never like it to become as popular as Java. I think the problem is the herd mentality itself.
Paul.

Yes I agree. Some think that software development is analogous to manufacturing where you can split the job into simple parts and de-skill the work force. This is what Henry Ford did. He hired cheap Immigrants which he could hire and fire.

Others think that Software Development is more closely analogous to New Product Development where creativity counts and where you need a small highly skilled team, of self organised and empowered professionals. People over processes and tools.

Even in manufacturing, the idea of creativity and worker empowerment through quality circles, where people continually improve how the job is done has proven to be the most efficient approach. Take a look at Toyota and their Lean approach to everything.

Some think, that Agile/Lean thinking could do to mainstream programming, what the Japanese motor industry did to American car manufacture in the 1970's. Time will tell, but there is already evidence of this happening in the Web2.0 arena (Java and Waterfall thinking is almost non-existent here).

The good thing is that with the breakdown in the "dumb programming down" consensus , new languages and approaches are merging and we now have a choice. Choice has got to be a good thing.

Something that you may not know. Agile development was born out of peoples experiences with OO programming and Smalltalk in the 1990's. This implies a link between the language (tool) and how best to organise the work (people). The mainstream are beginning to catch up with this thinking, and I believe that this is what is generating the demand for new features in Java.

Like I say we now have tools which support different ways of working (e.g. Ruby), giving us all a choice. My choice just happens to be different from yours.

Paul.

That is exactly right. Back to the topic, though, instead of demanding "new features" in Java, which is "barking on the wrong tree", people should look else where for something new that they really need, and let Java be Java. It's a tool that works well in its intended domain. This is not to say that Java should not add anything new, but should add new things in a "Java" way - things like wild card in generics and closure certainly don't fall into this IMO.

I am of the opposite opinion: You have to drive for "digging a hole" kind of simplicity/limitation in order to achieve effective mass production in any industry. Software is no exception.

This assumption is incorrect. The reality is that modern production depends largely on automation. Automation (e.g. robotics) requires highly skilled technicians. The history of manufacturing has shown that automation eventually replaces unskilled labor. Effectively a few highly trained technicians do replace a large number of largely untrained workers.
Only in places where labor costs are artificially low (i.e. where economic development has constrained) does the idea brute manual labor make sense. In my estimation there is no place in the world where programmer cost is so cheap that it can make up for the inefficiencies inherent in the assembly line approach.
The idea that dumbing-down is required to scale up is in fact century-old thinking. There are much more effective strategies than the assembly line.

This assumption is incorrect. The reality is that modern production depends largely on automation. Automation (e.g. robotics) requires highly skilled technicians. The history of manufacturing has shown that automation eventually replaces unskilled labor. Effectively a few highly trained technicians do replace a large number of largely untrained workers.

Disagree. Automation should not require higher skilled workers, it should result in same skilled workers being more productive. And again Java is intended to be a blue collar language in the first place as opposed to robotic modules.

This assumption is incorrect. The reality is that modern production depends largely on automation. Automation (e.g. robotics) requires highly skilled technicians. The history of manufacturing has shown that automation eventually replaces unskilled labor. Effectively a few highly trained technicians do replace a large number of largely untrained workers.

Disagree. Automation should not require higher skilled workers, it should result in same skilled workers being more productive.

The statement I responded to was 'You have to drive for "digging a hole" kind of simplicity/limitation in order to achieve effective mass production in any industry.' There is nothing about skilled workers in that statement. Unskilled workers do not maintain highly technical automation. Unskilled workers are eliminated by automation.

And again Java is intended to be a blue collar language in the first place as opposed to robotic modules.

I, in fact, agree that Java should have stayed simple. I'm not even sure that moving to use the 1.5 and above syntax is worth the cost. But this is orthogonal to my response to your statement.
You made a claim that all efficiencies in any industry are derived from dumbing things down so that anyone can do it. That is verifiably false.
The other thing about this is that software is inherently mass-producible. It is written once and can be copied essentially an infinite number of times at negligible cost. Coding is more comparable to designing the product and/or the production process in manufacturing.
The comparison of producing code to producing parts is corrosive to the software/IT industry. It leads to processes that produce more code instead of good code. And as we all (should) know: mo' code, mo' problems.

The statement I responded to was 'Automation (e.g. robotics) requires highly skilled technicians'. Now seeing more of your args, I realized we might be talking about different things: "Coming up" with good automation may need highly skilled workers, but "making use" of automation in manufacture definitely should not. Otherwise it simply says the automation is not good enough. That's why I said automation should "result in" average workers being more productive. If you recognize Java as blue collar language, perhaps you'd also see it fall in the "make use" end of the deal.

You made a claim that all efficiencies in any industry are derived from dumbing things down so that anyone can do it.

You are the only one who said that so far, which is a misinterpretation. What I said was, any industry that needs mass production should drive for simplicity in order to be effective. That's very different than what you said above. Matter of fact, you'd really need to "smart up" in order to make things simple. You sure can disagree with that, but pls get the point straight first. And after that I'd be very interested in knowing how that's "verifiably false" although that's off topic.

What I said was, any industry that needs mass production should drive for simplicity in order to be effective.

That, I can agree with but what I responded to was 'You have to drive for "digging a hole" kind of simplicity/limitation in order to achieve effective mass production in any industry.'
Which is a different statement.

That's very different than what you said above. Matter of fact, you'd really need to "smart up" in order to make things simple. You sure can disagree with that,

I completely agree. I believe that smart people figure out how to solve things in simple ways.

And after that I'd be very interested in knowing how that's "verifiably false" although that's off topic.

Well to be clear, there is no such thing as mass produced software. Every application is developed individually. I know of no software methodology that produces a large number of applications at once.
It's verifiably false that efficiencies can only be derived by dumbing things down to the lowest common denominator and hiring the cheapest workers. If this is not what you meant then perhaps we don't have any disagreement but a lot of people do believe this and use manufacturing as an example. But if you look at manufacturing trends (even in low wage areas) that's not what manufacturers are doing.
My father works in manufacturing and they get their machining done in Italy by mom and pop operations. They do this because it's the cheapest source in the world for machining. These shops have a high level of automation and low overhead.
It seems to be only in software that people believe that what Henry Ford was doing in the beginning of the 20th century makes sense in the 21st. And that makes me think that no matter how clever we think we are, we are the dumbest industry with the least time spent on critical thinking and our results prove it.

Well to be clear, there is no such thing as mass produced software. Every application is developed individually.

Hi James,
I was trying to keep out of this one, but you are spot on. We do not do manufacturing in software we do New Product Development. Each project is unique. Construction in Software is performed by the compiler, and mass manufacture is copying executables :^).
Like you say the fact that we can't even agree on this says a lot about our industry.
BTW since the 1980s manufacturing has been everything but dumb. The Taylorist approach of Henry Ford only survives in the Software Industry :^) Everyone else is doing TQM, Six Sigma, Lean, JIT, TPS and a bunch of other acronyms derived from the work of Edward Deming.
To work in a team on a modern production line means taking ownership of continually improving the manufacturing process. To do this you need to be smart and well paid.
Paul.

Well to be clear, there is no such thing as mass produced software. Every application is developed individually. I know of no software methodology that produces a large number of applications at once.

It seems to be only in software that people believe that what Henry Ford was doing in the beginning of the 20th century makes sense in the 21st. And that makes me think that no matter how clever we think we are, we are the dumbest industry with the least time spent on critical thinking and our results prove it.

Well, all this is a bit OT. But I have to admit you got me thinking twice about that - I would've said right away that you were wrong.... However, have you considered the other side of the story - the possibility that CS and SE, unlike physics and mechanical engineering, have not even reached the maturity level to make things like mass production possibly happen? Maybe there is such thing, and we just have not seen it. Too many times, people have ignored the lessons from history, thinking that the problem they have at hand is so unique, specific, and new that they have to tackle it differently....

Well to be clear, there is no such thing as mass produced software. Every application is developed individually. I know of no software methodology that produces a large number of applications at once.

It seems to be only in software that people believe that what Henry Ford was doing in the beginning of the 20th century makes sense in the 21st. And that makes me think that no matter how clever we think we are, we are the dumbest industry with the least time spent on critical thinking and our results prove it.

Well, all this is a bit OT. But I have to admit you got me thinking twice about that - I would've said right away that you were wrong.... However, have you considered the other side of the story - the possibility that CS and SE, unlike physics and mechanical engineering, have not even reached the maturity level to make things like mass production possibly happen? Maybe there is such thing, and we just have not seen it. Too many times, people have ignored the lessons from history, thinking that the problem they have at hand is so unique, specific, and new that they have to tackle it differently....

I'm a little confused by your saying that it's "the other side of the story" because my point is precisely that software engineering is immature and for that reason we are misapplying a manufacturing analogy and ignoring the changes and developments in manufacturing that have happened in the last century. Everyone learns about the assembly line in high school and that's where the average software industry person's education about manufacturing ends.
Producing a new application is like producing a new product, say a refrigerator. You've got some requirements (hopefully) and you might have some previous systems (or products) that you can pull from for the new design. You might even be able to reuse things from the old system (or product) like a database API (or a compressor motor.)
Once you have your design, making that into reality is the next step. In manufacturing, this means designing the manufacturing process. Assembly line, cell, perhaps you just want to do a rapid prototype. This is what coding is analogous to.
The last part is the actual production and what people want to (wrongly) equate coding to. A more proper analogy is to what the compiler, computer, and the program itself do. I think that part of the problem is that because production is so cheap and easy for software, it's invisible.
Mechanical Engineers don't mass produce designs and I highly doubt they ever will.

I'm a little confused by your saying that it's "the other side of the story" because my point is precisely that software engineering is immature and for that reason we are misapplying a manufacturing analogy and ignoring the changes and developments in manufacturing that have happened in the last century. Everyone learns about the assembly line in high school and that's where the average software industry person's education about manufacturing ends.

Producing a new application is like producing a new product, say a refrigerator. You've got some requirements (hopefully) and you might have some previous systems (or products) that you can pull from for the new design. You might even be able to reuse things from the old system (or product) like a database API (or a compressor motor.)

Once you have your design, making that into reality is the next step. In manufacturing, this means designing the manufacturing process. Assembly line, cell, perhaps you just want to do a rapid prototype. This is what coding is analogous to.

The last part is the actual production and what people want to (wrongly) equate coding to. A more proper analogy is to what the compiler, computer, and the program itself do. I think that part of the problem is that because production is so cheap and easy for software, it's invisible.

I agree with your analogy as to equating coding to design of manufacture process. But I am not sure that it can't be mass produced. Maybe not yet today in SE, but can't say never. And depending on the perspective, mechanical engineers do mass produce designs. Not every average Joe's (a ME undergrad on the street) ME design is the best or even good for that matter, but the ME industry is mature enough to have tools (compared to languages in SE) and processes simple enough for even average Joe's design work. And I believe that's what we are really talking about in this Java topic.

I agree with your analogy as to equating coding to design of manufacture process. But I am not sure that it can't be mass produced. Maybe not yet today in SE, but can't say never...

Hi Ric,
Yes you're you can, All you need is a silver bullet :^). Try reading Fred Brooks.
Paul.
PS. I don't mean to be condescending, but Fred Brooks dismissed this myth over 30 years ago. I don't mean to pick on you because you aren't the only one who thinks this way (I would say about 90% of Software Managers think like this). But if we can't get passed this thinking, then no wonder Gosling was able to get away with his "Blue Collar" pitch.
I know it seems off topic, but I don't think it is. This is how it happens. Perfectly good science is overlooked in favor of snake oil. I'm a qualified Electronic Engineer, and I've worked in Telecommunications, and trust me compared to other technical professions the Software "professional" is not very smart!

Yes you're you can, All you need is a silver bullet :^). Try reading Fred Brooks.

Paul.

PS. I don't mean to be condescending, but Fred Brooks dismissed this myth over 30 years ago. I don't mean to pick on you because you aren't the only one who thinks this way (I would say about 90% of Software Managers think like this). But if we can't get passed this thinking, then no wonder Gosling was able to get away with his "Blue Collar" pitch.

I know it seems off topic, but I don't think it is. This is how it happens. Perfectly good science is overlooked in favor of snake oil. I'm a qualified Electronic Engineer, and I've worked in Telecommunications, and trust me compared to other technical professions the Software "professional" is not very smart!

I honestly don't think that I'd read a book just because you said so, nor will I take your comments as intentionally condescending, although it does look like so, since you seem to be having trouble making a point. (Go read a book is not a point.) And qualification has little to do with the point, either. As a mechanical engineer holding an MSME from a reputable US university who had some years around Detroit, I understand what it looks like outside of the software world. Will have to end it here as both the topic and the tone are off.

Yes you're you can, All you need is a silver bullet :^). Try reading Fred Brooks.

Paul.

PS. I don't mean to be condescending, but Fred Brooks dismissed this myth over 30 years ago. I don't mean to pick on you because you aren't the only one who thinks this way (I would say about 90% of Software Managers think like this). But if we can't get passed this thinking, then no wonder Gosling was able to get away with his "Blue Collar" pitch.

I know it seems off topic, but I don't think it is. This is how it happens. Perfectly good science is overlooked in favor of snake oil. I'm a qualified Electronic Engineer, and I've worked in Telecommunications, and trust me compared to other technical professions the Software "professional" is not very smart!

I honestly don't think that I'd read a book just because you said so, nor will I take your comments as intentionally condescending, although it does look like so, since you seem to be having trouble making a point. (Go read a book is not a point.) And qualification has little to do with the point, either. As a mechanical engineer holding an MSME from a reputable US university who had some years around Detroit, I understand what it looks like outside of the software world. Will have to end it here as both the topic and the tone are off.

Fred Brooks wrote the Book "The Mythical Man Month" which included a number of papers on Software Engineering and Project Management including "No Silver Bullet". Perhaps I shouldn't of said that Software Professionals aren't smart, what I should have said is that as a whole they aren't well informed.
I don't know why this is, but like Karl I'm pessimistic of it ever changing. Even so there is no excuse for venting my frustration on you.
Sorry Paul.

I'm a little confused by your saying that it's "the other side of the story" because my point is precisely that software engineering is immature and for that reason we are misapplying a manufacturing analogy and ignoring the changes and developments in manufacturing that have happened in the last century. Everyone learns about the assembly line in high school and that's where the average software industry person's education about manufacturing ends.

Producing a new application is like producing a new product, say a refrigerator. You've got some requirements (hopefully) and you might have some previous systems (or products) that you can pull from for the new design. You might even be able to reuse things from the old system (or product) like a database API (or a compressor motor.)

Once you have your design, making that into reality is the next step. In manufacturing, this means designing the manufacturing process. Assembly line, cell, perhaps you just want to do a rapid prototype. This is what coding is analogous to.

The last part is the actual production and what people want to (wrongly) equate coding to. A more proper analogy is to what the compiler, computer, and the program itself do. I think that part of the problem is that because production is so cheap and easy for software, it's invisible.

I agree with your analogy as to equating coding to design of manufacture process. But I am not sure that it can't be mass produced. Maybe not yet today in SE, but can't say never. And depending on the perspective, mechanical engineers do mass produce designs. Not every average Joe's (a ME undergrad on the street) ME design is the best or even good for that matter, but the ME industry is mature enough to have tools (compared to languages in SE) and processes simple enough for even average Joe's design work. And I believe that's what we are really talking about in this Java topic.

Can you give an example of an engineer 'mass producing designs.' How would one go about producing 1000s or millions or designs at once and what purpose would be served by doing so?

Can you give an example of an engineer 'mass producing designs.' How would one go about producing 1000s or millions or designs at once and what purpose would be served by doing so?

If you are referring my previous comment 'ME engineers mass produce....'. Notice the plural form of engineers. And by that I meant the engineers in the ME industry, which is mature enough to have tools and processes in place to make average Joe's design tolerable and workable in most cases, as well as to make "mass production" of average Joes possible.

Can you give an example of an engineer 'mass producing designs.' How would one go about producing 1000s or millions or designs at once and what purpose would be served by doing so?

If you are referring my previous comment 'ME engineers mass produce....'. Notice the plural form of engineers. And by that I meant the engineers in the ME industry, which is mature enough to have tools and processes in place to make average Joe's design tolerable and workable in most cases, as well as to make "mass production" of average Joes possible.

I don't think engineers are "average Joes". Engineers are highly skilled individuals who, in general, have much more rigorous training than software developers.
You seem to have changed the subject. 'Mass production' has nothing to do with what you are talking about about. If it did, then the cottage industries of the pre-industrial age would also be considered "mass production". The whole point of mass production is to produce a lot of the same thing. There is no reason to produce a lot of the same software design. There is no value in duplicating a design.

Can you give an example of an engineer 'mass producing designs.' How would one go about producing 1000s or millions or designs at once and what purpose would be served by doing so?

If you are referring my previous comment 'ME engineers mass produce....'. Notice the plural form of engineers. And by that I meant the engineers in the ME industry, which is mature enough to have tools and processes in place to make average Joe's design tolerable and workable in most cases, as well as to make "mass production" of average Joes possible.

I don't think engineers are "average Joes". Engineers are highly skilled individuals who, in general, have much more rigorous training than software developers.

You seem to have changed the subject. 'Mass production' has nothing to do with what you are talking about about. If it did, then the cottage industries of the pre-industrial age would also be considered "mass production". The whole point of mass production is to produce a lot of the same thing. There is no reason to produce a lot of the same software design. There is no value in duplicating a design.

Well, seems the subject was changed for a long while by a lot of people.... If this can bring things back a little: You tried to make the distinction between "engineers" and "software developers" (which, for anther subject, I don't completely agree, nor do I completely agree with the average Joe subject) - a reminder is that Java is used by "software developers" (as well).

I am of the opposite opinion: You have to drive for "digging a hole" kind of simplicity/limitation in order to achieve effective mass production in any industry. Software is no exception.

I agree that simple, repeatable processes are pre-requisites for mass production in any industry. However, developing a simple, repeatable process is premised on your customer's willingness to accept certain limitations of the product he/she purchases. For example, mass producing burgers is something McDonalds specializes in. If you have ever worked in one, they have simple, repeatable processes that a novice cook can follow. When going into a McDonalds as a customer you give up rights of customization: type of meat used in your burger, leanness of meat, type of mustard/cheese/lettuce used, how well cooked the meat is, etc. Switching back to software development, most of my customers have been adamant that having customized software is the differentiator between their business and their competitors' businesses.
Until our customers are willing to accept more "genericity" (not in the programming language sense) in their software, mass producing it will continue to be a frustrating exercise.

I am of the opposite opinion: You have to drive for "digging a hole" kind of simplicity/limitation in order to achieve effective mass production in any industry. Software is no exception.

I agree that simple, repeatable processes are pre-requisites for mass production in any industry. However, developing a simple, repeatable process is premised on your customer's willingness to accept certain limitations of the product he/she purchases. For example, mass producing burgers is something McDonalds specializes in. If you have ever worked in one, they have simple, repeatable processes that a novice cook can follow. When going into a McDonalds as a customer you give up rights of customization: type of meat used in your burger, leanness of meat, type of mustard/cheese/lettuce used, how well cooked the meat is, etc. Switching back to software development, most of my customers have been adamant that having customized software is the differentiator between their business and their competitors' businesses.

Until our customers are willing to accept more "genericity" (not in the programming language sense) in their software, mass producing it will continue to be a frustrating exercise.

That's a very good point. Simplicity implies certain level of limitation. I think that is also very relevant to the Java topic here: You can't smoke from both ends - Simplicity of the language vs. feature richness. They are not completely against each other, but that holds up only to some extend.

Overloading a language with unnecessary features is a good way to kill it. Java is now used for running serious business, language specifications shouldn't anymore stay under the control of techies which just want to play with their favorite toy. I think it's better to add different, more domain-oriented and specialized languages to the JVM instead of bloating Java itself.

I like bruce Eckel but I can not agree with him on this.
I have a question. Would PHP be more successful if it would stick with version 3 or 4? In my opinion definitely no. By introducing PHP 4 and 5 (and better OO structures) we have been able to see frameworks like Symphony, ZendFramework, CakePHP, Codeignitor which have totally changed the PHP world from what we used to know a few years ago. If you want to remain in the market you should remain competitive and if you that late, it will be late. Fortran was a popular language (also Cobol) and there is no reason if we do not introduce updates to java it will not become another Fortran (rather than C).
Introducing Generics was a very good thing happened to Java. Think of an ideal language which can find every single problem in compile time instead of run time. We are trying to have a more update and useful language. Evolution is always good. People like better working things .

I am glad Generics, Enums, improved for loop, etc. were added to Java. I much prefer working with Java 5 than Java 1.4. I don't like the way annotations were implemented, but I'd still rather have them than not.
I look forward to continuations instead of anonymous inner classes.
Java must evolve or die IMO. Sun et al have been great stewards of the language and platform (not perfect but darn good). Keep up the good work.
BTW I think the death of Java has been greatly exagerated.
job graph from indeed.com
If you are looking for a job, it is still the best langague to know.

"The right thing to do is just not add the feature at all (what fun is that?). That if you can't do it right then maybe the language should stop growing and become stable.

I have always admired dudes like Bruce Eckel who are able to articulate so clearly what is at best vague thoughts in my head. I totally agree with him. For all practical reasons, Java is perfect. Long live Java!
Regards,
Slava Imeshev

TechTarget provides technology professionals with the information they need to perform their jobs - from developing strategy, to making cost-effective purchase decisions and managing their organizations technology projects - with its network of technology-specific websites, events and online magazines.