TSS Asks: Why resist change to Java?

Discussions

News: TSS Asks: Why resist change to Java?

  1. TSS Asks: Why resist change to Java? (55 messages)

    A user sent this in as a possible post. TheServerSide would like to throw it to you, the TSS community, to gather your thoughts on the issue.
    It was not long ago the self proclaimed Java programming extraordinaire Yakov Fain posted an article resisting all changes to the Java platform. Why is it, always, that the ones to resist changes/additions to the platform are all senior developers who have been using the Java platform since its birth. What is it that they want? By now we can pretty well conclude that they do not want to learn anything new and that they will block others from doing the same. Does Java really need these blokes to be their spokespersons? Why can't simplifications to programmers be awarded even if it comes with a slightly complex mental model? Those who go the extra yard will always get it, and those who do not will still reap the benefits of the larger effort. One thing is for sure, your children will always be samrter than you! [Editor's note: I don't have any idea if this was intentional or not. So I'm leaving it.]
    Yakov's article on Javalobby was fairly short, and basically said that Java is good enough as it is:
    Is Java the primary language that pays my bills today? Yes it is. Are there other languages/technologies I work with? Yes, there are. Do I want to see new language constructs in Java? No, I do not. People propose adding closures to the language. There are some attempts to introduce data binding to Java Beans. I do not think you can teach an old dog new tricks. If you remember, Java has been created as a simple version of C++. Let's keep it as simple as possible. When I hear about all these additions to Java, I see an aging woman that keeps coming to her doctor for another Botox injection. These doll-looking faces do not trick men anymore. Keep Java simple, let it age gracefully! It’s a very robust platform for enterprise and mobile applications and let’s leave it right there. Fine-tuning of the JVM is fine, but I do not need new language features. I'd rather use some other modern languages that can be easily integrated with Java EE. Sun Microsystems has excellent engineers who can craft a brand new language in a year or so. May be creating a new language is better than trying to add patches to Java here, there and everywhere? I'd rather see a new cool and light-weight language from Sun, especially for the GUI development that can compete with offerings from Microsoft (WPF and WPF/E) and Adobe (Flex and Apollo).
    What do you think?

    Threaded Messages (55)

  2. This guy talks like a kid.
  3. This guy talks like a kid.
    Perhaps he should at first complete high school?
  4. This guy talks like a kid.
    I guess he talks about people like you. But I definitely think his kids will be samrter then him, whatever samrter is.
  5. This guy talks like a kid.
    Many of the young always believe they know better than their elders. Sometimes they are right, usually they are wrong. The problem in this industry is that there is an unbalanced approach to dealing with this conundrum. Some teams reject all the ideas of the young and stagnate. Other teams accept all of the ideas of the young and repeat the mistakes of the past. The only way to really move forward is to have open honest discussion about change. I see very little of this. Anyone who weighs the pros and cons of an idea without bias is generally attacked by partisans from all sides.
  6. Many of the young always believe they know better than their elders.
    You are right about that for sure, man I used to be so freaking obnoxiously pedantic when I just discovered the miracles of programming. My pedantry nowadays is nothing compared to what it used to be.
  7. Apologies for responding to the thread personally, but I didn't feel like it was my place to offer my opinion in the post itself:
    • Not everyone who resists change is a "senior engineer" - and even if they were, that's not good enough. Change introduces instability, and when you rely on Java being stable, looking at something that affects that will be met with resistance.
    • Resistance to change isn't all bad - consider what we'd have if there was no resistance to change: Perl. Or worse.
    • I don't see anyone saying "thou shalt not learn anything new!" Nobody's forcing you to not learn Python or Ruby.
    • Simplifications that come with a more complex mental model aren't necessarily simplifications.
    • Yakov isn't a "spokesperson" for Java any more than anyone else is.
    • Yakov's statement that Java doesn't need to advance is silly; we don't need another COBOL. We've still got COBOL itself for that. Unrestricted change is bad: no change at all is probably worse.
  8. closures are evil[ Go to top ]

    Closures is a nice feature, but it is evil for Java. If one is eager to use this fancy colsure feature - there are a lot of relevant tools for that - JRuby or Groovy. But in real Java closures are unwanted as their bring spagetties to the code.
  9. Re: closures are evil[ Go to top ]

    Closures is a nice feature, but it is evil for Java. If one is eager to use this fancy colsure feature - there are a lot of relevant tools for that - JRuby or Groovy.
    But in real Java closures are unwanted as their bring spagetties to the code.
    Almost every other modern language supports closures. Even C++ has an upcoming spec change for them. They're genuinely useful, if you take the time to learn about them. Only bad programmers dislike closures.
  10. Re: closures are evil[ Go to top ]

    I'd say if you don't like changes made since Java vX.Y, then stick to Java vX.Y. I don't see why this has to be a debate. Better yet, if you absolutely need to use J2SE 6 for some feature but you don't like the others, then don't use them. Just because someone put a drill in your toolbox doesn't mean you need to start punching holes everywhere. This being said, while I think change is generally good, redundancy of functionalities is most likely a bad thing (thinking for example about the controversial Logging package). Nobody likes having two drills in their toolbox. Or worse, having your tools selected for you by someone else.
  11. Re: closures are evil[ Go to top ]

    I'd say if you don't like changes made since Java vX.Y, then stick to Java vX.Y. I don't see why this has to be a debate.
    Because you have to understand the full range of a language in order to be proficient in it. Even if you don't actively use a feature others will do and you will be in need of understanding it.
  12. Re: closures are evil[ Go to top ]

    I'd say if you don't like changes made since Java vX.Y, then stick to Java vX.Y. I don't see why this has to be a debate.

    Better yet, if you absolutely need to use J2SE 6 for some feature but you don't like the others, then don't use them.
    Avoiding features you don't like is much easier said then done when working in a large organization. Moreover many features look fantastic when viewed solely through the lens of initial coding in a small-group. When you look at these same features through the lens of maintenance and troubleshooting over many years in a large organization beyond the initial authoring group, many of these same features are truly horrific. Operator overloading is a prime example. New features are nice, but they have to be weighed against the increased conceptual complexity of the overall language (e.g. how long it takes a newbie to learn the meaning of all basic syntax) and readability/maintainability (it should be obvious at a glance from a dumb printout [not an IDE] how many method calls are made in a line, which lines can/cannot have side-effects, etc). What's needed is *balance*, not "oooh, all these features are cool in some cases, so let's just throw them all in" or "no new features -- we have enough" mentalities.
  13. Re: closures are evil[ Go to top ]

    Avoiding features you don't like is much easier said then done when working in a large organization. Moreover many features look fantastic when viewed solely through the lens of initial coding in a small-group. When you look at these same features through the lens of maintenance and troubleshooting over many years in a large organization beyond the initial authoring group, many of these same features are truly horrific. Operator overloading is a prime example.
    No, the person you replied to is exactly right. Use whatever leverage you have in your organization to pull for whatever language(version)/style you want, but you have no influence on other organizations. And better yet, Java will be open source so do whatever you want with it. But guess what. Java 7 will get closures no matter how much whining is done here and the disaster that is Javalobby. Because there will be no technical, objective consensus on whether this feature or that feature is right, the political forces involved will push features into the language. In a possible ideal world, we would have Sun, IBM, Google and whoever get together and develop a new language from scratch on top of the JVM, but I see no sign of that, so you'll get features. The last thing Sun wants is developers really liking what they see in C# 3.0.
  14. Re: closures are evil[ Go to top ]

    Instead of trying to fix Java by adding in everything that should've been there from day one, which at this point is virtually impossible without breaking all the legacy code out there, we should focus on better, more expressive languages, such as Groovy and Scala
    I would agree with the above, leave Java alone and if there are other new languages out there, then further their development. I feel that the inability to clean up Java as the various versions were released has only succeeded in growing the API into a hugely obese monster. We should leave well enough alone and maybe even take the best from Java, the 'real' core of what it offers and use that as a basic for a newer, cleaner, sleeker language. Look at it this way, in reality, you probably have a very small proportion of Java implementations using these 'new' and additional features, while the small guy inherits the bloat that the big players seem to add to it
  15. I think the key issue is that any new language features will likely be introduced under the constraints of a very strict form of backwards compatibility, to ensure that Java 7 code will continue to interoperate with Java 1.3 code without recompilation. It's this kind of binary compatibility constraint that led to the problems with generics and erasure. Because of the negative experience of erasure, many people are nervous about future changes in case they become "another generics". On the other hand, generics probably was a necessary and important feature, and in my opinion should have been part of the language from day one... if only Bill Joy had had his way! It seems to me that there are only two possible ways forward: (1) only introduce changes that can be made compatible with respect to existing binary code without erasure-like hacks (2) allow for binary compatibility to be broken, as long as old code can be recompiled under the new javac. It's probably too late to do (2) in Java 7, but it might be worth considering going there for Java 8.
  16. ecause of the negative experience of erasure, many people are nervous about future changes in case they become "another generics". On the other hand, generics probably was a necessary and important feature, and in my opinion should have been part of the language from day one...
    Who's really had that many problems due to erasure? I've used generics quite extensively for 2 years now and only felt pain due to erasure a handful of times. Without erasure (or some other equally backwards-compatible solution) I and many, many others wouldn't realistically be using generics in any significant way for years -- due to real, hard requirements to interoperate with existing libraries and sources. Erasure detracts from the ivory tower vision, but overall this was a fabulously effective compromise for many real Java users.
  17. http://www.joelonsoftware.com/articles/APIWar.html
  18. Apron strings[ Go to top ]

    I think the key issue is that any new language features will likely be introduced under the constraints of a very strict form of backwards compatibility, to ensure that Java 7 code will continue to interoperate with Java 1.3 code without recompilation.
    Would it be so bad to cut the strings to these older versions. If someone is still on 1.3 then they still have an upgrade path to 1.6/1.7 before their code breaks?? I think we need to be strong and cut loose, clip the bloat and re-emerge with a language that is free again to accept whatever advances may be made in the future, without worrying about ancient codebases. While painful in the short term, this approach, long term is much more beneficial. The people who have the strength to make the decision will weather a storm that the developers following will thank them for...
  19. He's Absolutely Right[ Go to top ]

    Java is a deeply flawed language and has been since it's introduction. Recent additions such as generics and annotations have improved it, but at the end of the day it's just putting lipstick on a pig. Instead of trying to fix Java by adding in everything that should've been there from day one, which at this point is virtually impossible without breaking all the legacy code out there, we should focus on better, more expressive languages, such as Groovy and Scala, that also run on the JVM. That we can preserve our investment in existing code (have our cake) while taking advantage of more powerful language constructs (and eat it too).
  20. May be creating a new language is better than trying to add patches to Java here, there and everywhere?
    That's his main point. Although I admit his argument is somewhat muddied, that doesn't mean he's wrong. If you look at how some of the new features are implemented they don't actually make things run better and in some cases (generics) can make your code run worse because of how they are implemented. At some point, you have to question whether or not it is in Java's best interest to be all things to all use cases or specialize in the ones that it was originally intended to solve.
  21. I would have more faith in changes. They can't even do a logging api that's better than Log4J. You have got to be kidding me. Annotations are hard-coded abominations. Configuration that requires code recompilation? Don't tell me that's not what they are intended for. It's what they are used for, and that's all that matters. Generics... um, thanks? Was it worth new syntax to increase detection of bad casting by 1%? They still haven't fixed or improved Swing after four major releases. EJB 3 is a big shoulder shrug. Including an embedded SQL server? Thanks, I think. The worst thing of all: this piecemeal introduction that fundamentally kludges the improvement, while simultaneously creating a guessing game for reading source code: was this written for 1.1? 1.2? 5? 6? 7? Ridiculous. If Java wants improvement, get together hundreds of experienced users, find out what they would want, and create a clean break language. These are the truly revolutionary things that java could have: - support aspects (despite their GOTO-ish aura) - mixins for more flexible object composition - exception clauses where the catch and finally clauses can see variables declared in the try - property reference syntax that behave like method invocations that descend the class hierarchy. - better dynamic proxy support - christ, how about map initialization shorthand, like javascript? - integrating JoSQL And Groovy has tons of interesting features.
  22. They still haven't fixed or improved Swing after four major releases.
    Yes they have.
  23. Ummm....No. I'll know when they've fixed swing when I'm using a half-dozen applications that look and work great, and then later I find out they're using Swing, and say, wow, I couldn't tell the difference between that and any other apps. Azureus is the last java app I used and I dropped that for uTorrent in a heartbeat.
  24. Ummm....No.

    I'll know when they've fixed swing when I'm using a half-dozen applications that look and work great, and then later I find out they're using Swing, and say, wow, I couldn't tell the difference between that and any other apps. Azureus is the last java app I used and I dropped that for uTorrent in a heartbeat.
    But Azureus is built using SWT not Swing...
  25. Why resist change?[ Go to top ]

    Because some of the changes in tha past were BAD. Generics were OK other than that I'd like to see 1.5 changes undone. I really dislike annotations for turning java into a 2 in 1 language. I can not avoid using them because API's and frameworks I need rely on them, making my code harder to understand. I dislike autoboxing for sucking up to script kiddies and generally doing more harm than good, saved typing from not having to type new Integer(x) & x.intValue(), is more than offset by increased complexity when tracking down exceptions. New loop was unnessesary.
  26. Re: Why resist change?[ Go to top ]

    Because some of the changes in tha past were BAD. Generics were OK other than that I'd like to see 1.5 changes undone.
    I really dislike annotations for turning java into a 2 in 1 language. I can not avoid using them because API's and frameworks I need rely on them, making my code harder to understand.
    I dislike autoboxing for sucking up to script kiddies and generally doing more harm than good, saved typing from not having to type new Integer(x) & x.intValue(), is more than offset by increased complexity when tracking down exceptions.
    New loop was unnessesary.
    Okay, while I've voiced concern/caution about change and most especially about breaking backwards compatibility, I'd have to say this is the reactionary extreme -- except on the auto-[un]boxing note. Generics and annotations (and to a lesser degree enums) have made a huge difference in practical use of Java 5 for me. I'm ambivalent on autoboxing/unboxing, though. That really was rather unnecessary and hides too much of what lines of code are implicitly doing -- hiding performance and other bugs. I still use it, though -- just with a lot more caution than most.
  27. Just FYI - Azureus is SWT. Not Swing. And again, FYI, SWT uses native widgets to paint the screen. I could understand your point of view if you'd mentioned a Swing application - which incidentally keeps getting better with each new release of the JDK. There are high-quality Swing "skins" that, while they may not really look like anything else on your OS, look very polished and nice. Again, FYI, you might want to note that even Firefox isn't really a native UI. The UI is defined in XML and rendered by a rendering engine. This is just to prove that a UI doesn't have to be native to be good.
  28. exception clauses where the catch and finally clauses can see variables declared in the try
    Don't declare variables in the try. Declare at the top of the method and you can see it in the catch and the finally. All variables should be declared at the top of the method. It's cleaner and more flexible.
  29. One problem Java has is that it mixes too many things - a runtime platform, a virtual machine (byte code), a high level programming language, and libraries of "standard" code and API's you're expected to use. Microsoft has the right idea, sort of, they don't confuse the CLR with any one language. Separation of concerns anyone? Anyone who has worked on an older system knows that at some point refactoring can go no further and you need to replace. Anyone who has worked with PL/I or ADA knows that a language can become too big and try to do too many things. Java in all its facets is beginning to have that problem. We need a JVM that supports multiple programming languages and we need to keep the standards libraries separate from the language and its distribution. Then we could even consider a replacement or replacements for Java without losing backward compatiblity at the run-time level. While I'd prefer a simple and consistent strongly typed OO language (e.g no primitives - a compiler problem I shouldn't see)while others could have more dynamic languages with duck typing or whatever. We could have languages designed to address certain kinds of problems if we wished instead of making the UI guys use the same language I use for backend components and services. Of course the calling conventions and binding rules have to be spelled out or there will be chaos in the run-time. What we shouldn't do is to continue gunking up one language with every feature we can think of from every problem domain. COBOL has fewer than 1 major revision every 10 years. It does what it does and I don't have to use it yet I can still inter-operate with it if I have too. I don't believe there will ever be one universal programming language that is wonderful for every problem. And I don't mind that a bit. Is that "samrt" or what?
  30. I don't believe there will ever be one universal programming language that is wonderful for every problem. And I don't mind that a bit. Is that "samrt" or what?
    I completely agree with this but I wish there were a way to prove it. The problem is that there are many people out there that hold the exact opposite opinion i.e. the perfect language is the one that solves all problems and the more problems a language solves the better it is. Generally the arguments for this language are logistical: the less languages that you need to know the better. My counter argument is any all-encompassing language will be so vast and complex that it's easier to know many focused languages. Of course I don't believe in a language for every problem e.g. DSLs for everything. Somewhere in the middle there's good mix of complexity and focus. The key to making the many language paradigm work is integration. And in this respect, the Java language is succeeding splendidly. Personally I think the future of Java should be on becoming a really great foundation language that acts as a glue between other languages on the JVM. To this end, I think function pointers would be a great addition (perhaps closures, I don't have a strong opinion on them.)
  31. There's a ton of dynamic languages that run on the JVM. The language spec is out there. Anyone with the skills and courage can write a compiler to produce bytecode. the CLR has better support for dynamic languages, but that doesn't mean the bytecode spec for Java doesn't support or allow multiple languages. I won't bother listing all the languages that run on the JVM. peter lin
  32. There's a ton of dynamic languages that run on the JVM.
    I assume you're referring to this site when talking about "a ton of dynamic languages that run on the JVM". I would advise taking a closer look at that list and then pruning those that aren't real languages or aren't even close to being production-worthy, or even sub-production worthy. You'll get a much, much shorter list. Besides Groovy (I wouldn't call JRuby there yet), what other dynamic languages are usable?
    The language spec is out there. Anyone with the skills and courage can write a compiler to produce bytecode. the CLR has better support for dynamic languages, but that doesn't mean the bytecode spec for Java doesn't support or allow multiple languages. I won't bother listing all the languages that run on the JVM.

    peter lin
    I'm actually surprised that there aren't more production-worthy languages out there for the JVM. I guess it doesn't help when Sun has always seemed to conflate Java and the JVM, and Gosling poo-pooing "scripting" languages.
  33. There's a ton of dynamic languages that run on the JVM. The language spec is out there. Anyone with the skills and courage can write a compiler to produce bytecode. the CLR has better support for dynamic languages, but that doesn't mean the bytecode spec for Java doesn't support or allow multiple languages. I won't bother listing all the languages that run on the JVM.

    peter lin
    Hi Peter, Yes, if you don't mind your dynamic languages running like a dog. Gilad Bracha has a great presentation where he demonstrates the limitiations of the JVM as a platform for dynamic languages. The CLR is not much better either. http://download.microsoft.com/download/9/4/1/94138e2a-d9dc-435a-9240-bcd985bf5bd7/GiladBracha-final.wmv These VMs are built for static languages. In truth if you want a performant dynamic language then you need to look to a different VM. The JVM or the CLR are just not built for this, what people do is write another dynamic VM on top of these platforms to run dynamic code, which is a ugly solution IMO. Paul.
  34. It doesn't have to be dog slow. I used to read Bracha's blog. If you look at the recent blogs about JRuby, you'll see they've made big performance gains. That doesn't necessarily mean the JVM couldn't use some tweaking to make it more friendly to dynamic languages. My rule engine has a "lisp like" interpreter, since it's a port of CLIPS rule engine. From my own experience, performance doesn't necessary have to suck. Take JESS for example, it's wicked fast and provides many dynamic capabilities. My bias perspective is the JVM could be improved to make dynamic languages easier. With the current JVM it's possible to write fast and efficient dynamic languages. peter
  35. It doesn't have to be dog slow. I used to read Bracha's blog. If you look at the recent blogs about JRuby, you'll see they've made big performance gains. That doesn't necessarily mean the JVM couldn't use some tweaking to make it more friendly to dynamic languages. My rule engine has a "lisp like" interpreter, since it's a port of CLIPS rule engine. From my own experience, performance doesn't necessary have to suck. Take JESS for example, it's wicked fast and provides many dynamic capabilities. My bias perspective is the JVM could be improved to make dynamic languages easier. With the current JVM it's possible to write fast and efficient dynamic languages.

    peter
    Hi Peter, Yes, the perfromance of JRuby can be made comparable to Ruby (perhaps even faster), but the Matz Ruby interpreter is dead slow. Please remember that Ruby is an open source language written by a bunch of part timers. The JVM is a professional industrial strength static VM, where millions of dollars have been spent on optimisation (I believe making the JVM support multi-core CPU's took a masssive team years). So Ruby is a bad example when it comes to the performance of a native dynamic interpreter versus a JVM implementation. I don't know about JESS, but if you want to look at a high perfomance dynamic VM take a look at Strongtalk: http://www.strongtalk.org/ This uses type-feedback techniques to dynamically compile byte code to machine code. In fact it was the Strongtalk VM people that Sun used to create the Java Hotspot JVM. The power of the Strongtalk VM is that it can also de-optimise code on the fly from machine code back to byte code inorder to maintain dynamic semantics. So my point is that Ruby implemented on the Strongtalk VM would be an order of magnitiude faster then Ruby implemented on the JVM. This is just a fact. Also Java implemented on the Strngtalk VM is likely to be relatively quick too. So my basic point is that we have ended up with the wrong VM for dynamic features because of decisions made in the past. Getting the JVM to compete with a type-feedback VM like Strongtalks is not possible whilst maintaining backward compatibility. The odd byte code (invoke-dynamic) will not cut it, and as we speak people are considering porting dynamic languages like Ruby to a high performance dynamic VM like Strongtalks. Ruby also has a native VM of it's own (YARV) in the pipline too. If and when this happens Ruby will not need to depend on C as it does today for much of it's libraries, also Ruby will become applicable to a wider range of applications (other than I/O bound web apps and Rails). I'm talking longer term, and on a long term basis JRuby, Jyphon, Groovy etc are short term kludges. If dynamic languages are to become general purpose then a fast dynamic VM will be needed in the future.
  36. It doesn't have to be dog slow. I used to read Bracha's blog. If you look at the recent blogs about JRuby, you'll see they've made big performance gains. That doesn't necessarily mean the JVM couldn't use some tweaking to make it more friendly to dynamic languages. My rule engine has a "lisp like" interpreter, since it's a port of CLIPS rule engine. From my own experience, performance doesn't necessary have to suck. Take JESS for example, it's wicked fast and provides many dynamic capabilities. My bias perspective is the JVM could be improved to make dynamic languages easier. With the current JVM it's possible to write fast and efficient dynamic languages. peter
    Hi Peter, Yes, the perfromance of JRuby can be made comparable to Ruby (perhaps even faster), but the Matz Ruby interpreter is dead slow. Please remember that Ruby is an open source language written by a bunch of part timers. The JVM is a professional industrial strength static VM, where millions of dollars have been spent on optimisation (I believe making the JVM support multi-core CPU's took a masssive team years). So Ruby is a bad example when it comes to the performance of a native dynamic interpreter versus a JVM implementation. I don't know about JESS, but if you want to look at a high perfomance dynamic VM take a look at Strongtalk: http://www.strongtalk.org/ This uses type-feedback techniques to dynamically compile byte code to machine code. In fact it was the Strongtalk VM people that Sun used to create the Java Hotspot JVM. The power of the Strongtalk VM is that it can also de-optimise code on the fly from machine code back to byte code inorder to maintain dynamic semantics. So my point is that Ruby implemented on the Strongtalk VM would be an order of magnitiude faster then Ruby implemented on the JVM. This is just a fact. Also Java implemented on the Strngtalk VM is likely to be relatively quick too. So my basic point is that we have ended up with the wrong VM for dynamic features because of decisions made in the past. Getting the JVM to compete with a type-feedback VM like Strongtalks is not possible whilst maintaining backward compatibility. The odd byte code (invoke-dynamic) will not cut it, and as we speak people are considering porting dynamic languages like Ruby to a high performance dynamic VM like Strongtalks. Ruby also has a native VM of it's own (YARV) in the pipline too. If and when this happens Ruby will not need to depend on C as it does today for much of it's libraries, also Ruby will become applicable to a wider range of applications (other than I/O bound web apps and Rails). I'm talking longer term, and on a long term basis JRuby, Jyphon, Groovy etc are short term kludges. If dynamic languages are to become general purpose then a fast dynamic VM will be needed in the future.
    I agree with a lot of what you say. If the JVM was designed from day 1 to support dynamic typing, it would make life easier. I wouldn't consider the current crop of dynamic languages on the JVM as hacks. They just might be good enough to last a long time. As the strongtalk website says, the future is up to the open source community. Maybe apache harmony can learn from strongtalk and incorporate some of the advanced features. Who knows, maybe one day Java will run on a different VM that is a descendent of strongtalk VM. In a sense, one could say the current JVM is a descendent of strongtalk VM. I'm sure many of the techniques, ideas and improvements have found their way to the current JVM. peter
  37. I agree with a lot of what you say. If the JVM was designed from day 1 to support dynamic typing, it would make life easier. I wouldn't consider the current crop of dynamic languages on the JVM as hacks. They just might be good enough to last a long time.

    As the strongtalk website says, the future is up to the open source community. Maybe apache harmony can learn from strongtalk and incorporate some of the advanced features. Who knows, maybe one day Java will run on a different VM that is a descendent of strongtalk VM. In a sense, one could say the current JVM is a descendent of strongtalk VM. I'm sure many of the techniques, ideas and improvements have found their way to the current JVM.

    peter
    Yes, I agree Peter it is up to us. I think the history of Strongtalk is instructive. It was the first really fast Smalltalk with optional static type checking and it existed before Java, but the startup which created it was bought out by Sun before they were able to release Strongtalk into the market. Sun kept Strongtalk buried until only very recently, but now it's open source. It will be interesting to see how things develop over the next few years. I think there is mileage in JRuby and Groovy and they will introduce many Java programmers to dynamic languages. When change does come to the market though, it is likely to be swift, much like the fall of the Berlin Wall. Here are some numbers: * Java: 0.7s * Strongtalk Smalltalk: 7.0s * Squeak Smalltalk: 70s * Ruby: 200s Taken from this blog: http://smallthought.com/avi/?p=17 JRuby is about the same speed as Ruby I believe, so the numbers speak for themselves. I think having a dynamic language under your belt places you in a good position what ever happens. Besides, dynamic languages are fun!
  38. People talk about wrapping in XML directly to java, and all the groovy syntactic sugar, and things like embedded SQL and LINQ-style stuff. Plus the abomination/hack that is the JSP page. We need to quit beating around the bush and if you want java to be a flexible language, provide a means to inject other syntaxes directly into traditional java source code that clearly differentiates that alternate syntax to maintainers and IDE syntax coloring. I'm thinking something like this (too bad annotations took the @ sign already): // traditional java code int j = 1; boolean blah = true; while (blah) { // begin non-java code injection @Groovy{ // some groovy code injected }@Groovy // how about some XML String xmlstring = @XML{ abook }@XML } SQL, XML, XSLT, templating languages like Velocity, Groovy expressions, regular expressions, collections initialization, and tons of other stuff. By definition, it would be backwards compatible. If java launched this with templating (velocity or groovy-style), XML, XSLT, SQL/JDBC shorthand, and a couple others, it would catapult the language forward.
  39. ...provide a means to inject other syntaxes directly into traditional java source code ...
    Don't you think this would turn out to be a messy nightmare? Sorta like if I started speaking spanish, then japanese, then english at the same time.
  40. ...provide a means to inject other syntaxes directly into traditional java source code ...

    Don't you think this would turn out to be a messy nightmare? Sorta like if I started speaking spanish, then japanese, then english at the same time.
    spanglishanese! I just think it's unnecessary. To me it assumes a very linear procedural development style is necessary and desirable. From a Java perspective XML is a persistence mechanism just as SQL is. Embedding XML or database structures in code is a "bad idea"™. It's an extremely brittle approach and it doesn't really make things much easier anyway.
  41. People talk about wrapping in XML directly to java, and all the groovy syntactic sugar, and things like embedded SQL and LINQ-style stuff. Plus the abomination/hack that is the JSP page.

    We need to quit beating around the bush and if you want java to be a flexible language, provide a means to inject other syntaxes directly into traditional java source code that clearly differentiates that alternate syntax to maintainers and IDE syntax coloring.

    I'm thinking something like this (too bad annotations took the @ sign already):

    // traditional java code
    int j = 1;
    boolean blah = true;
    while (blah) {

    // begin non-java code injection
    @Groovy{
    // some groovy code injected
    }@Groovy

    // how about some XML
    String xmlstring = @XML{

    abook

    }@XML

    }

    SQL, XML, XSLT, templating languages like Velocity, Groovy expressions, regular expressions, collections initialization, and tons of other stuff. By definition, it would be backwards compatible.

    If java launched this with templating (velocity or groovy-style), XML, XSLT, SQL/JDBC shorthand, and a couple others, it would catapult the language forward.
    This is probably not the best idea. The point of using a higher-level language isn't just for little scripty procedures burried in normal Java. I'm not sure if you'd be able to use much of Groovy's power appropriately in this manner. Groovy isn't just syntatical sugar tacked on top of Java, it is its own language that happens to compile down to bytecode. If you are going to use a higher level language like Groovy then use it as a real language. Looking at examples in Grails you can't deny that it can get a lot done with a very small amount of code. Some of this is the configure-by-convention but much of it is Groovy's power to dynamically add functionality to existing classes. Of course, all JVM compatible languages come with some way to invoke them from straight java: XScript x = XScriptLoader.load(new File("myScript")) x.put("some key", "some value") x.evaluate() String answer = x.get("some key"); JDK 1.6 introduces a more standard way to do this, which is nice.
  42. "We need some way to inject other syntaxes into java" We do? I can't believe the crazy ideas you have listed here. You're one of those academic geeks, aren't you? Quit dreaming and get some work done.
  43. Change[ Go to top ]

    I am still confused about how wholeheartedly people embraced changes to the Java language. Generally I refuse to believe that making a language "richer" improves quality and productivity. In the end, what it may improve is the quality of the code. I would much rather see Java 1.4 properly debugged than any new feature introduced since Java5. Autoboxing? What a bizarre idea, because noone had the guts to do away with primitive types altogether! Generics? Why the hell? Did no-one tell Sun that there is no segmentation fault any more? Is it to much to ask from API vendors to document there product or use arrays instead? Enums? There are basic patterns that do the same thing, and in any complex classloading interaction they break down anyway. Static imports? Extended for loops? Syntactical sugar! And so on.... Oh, the one thing I could do with is true properties (syntactical sugar as well of course). Also, I think that the documentation quality with the advent of Java5 has broken down significantly. Trying to find out how things work is not straightforward and easy anymore, because documentation has retreated to "documentation by example". This tends to happen if a framework starts to exceed a certain complexity. And once the door is open, there will be no holding back. I am pretty sure that I will live to see operator overloading and true multiple inheritence in Java. Not a shadow of a doubt. Instead of concentrating on the obvious: Creating a stable standard application framework for desktop applications, making swing work right, supplying richer gui components, give apps proper control of the tcp stack.....
  44. Re: Change[ Go to top ]

    I am still confused about how wholeheartedly people embraced changes to the Java language. Generally I refuse to believe that making a language "richer" improves quality and productivity. In the end, what it may improve is the quality of the code. I would much rather see Java 1.4 properly debugged than any new feature introduced since Java5.

    Autoboxing? What a bizarre idea, because noone had the guts to do away with primitive types altogether!

    Generics? Why the hell? Did no-one tell Sun that there is no segmentation fault any more? Is it to much to ask from API vendors to document there product or use arrays instead?

    Enums? There are basic patterns that do the same thing, and in any complex classloading interaction they break down anyway.

    Static imports? Extended for loops? Syntactical sugar!

    And so on.... Oh, the one thing I could do with is true properties (syntactical sugar as well of course).

    Also, I think that the documentation quality with the advent of Java5 has broken down significantly. Trying to find out how things work is not straightforward and easy anymore, because documentation has retreated to "documentation by example". This tends to happen if a framework starts to exceed a certain complexity.

    And once the door is open, there will be no holding back. I am pretty sure that I will live to see operator overloading and true multiple inheritence in Java. Not a shadow of a doubt. Instead of concentrating on the obvious: Creating a stable standard application framework for desktop applications, making swing work right, supplying richer gui components, give apps proper control of the tcp stack.....
    Hi Karl, I agree with what you say. I believe Java should be left alone. In fact I would roll back the Java 1.5 changes if it ws up to me. The problem I believe is that Java is mostly used for purposes that dynamic languages are better suited to. I believe Ruby which isn't exactly a "state of the art" dynamic language, has brought to the atention of main stream developers the limitations wrt web applications and OO capabilities that has been inherent in Java from the very beginning. C++ is a low level OOish "system" language. Smalltalk is a pure OO "application" language. Back in 95 Java filled the gap, offering high performance and borrowing some high level features from Smalltalk. As moores law has delivered better hardware performance, the need to use a system language like C++ to develop applications no longer exists. C/C++ still has it's place, device drivers, 3D graphics engines etc. Moores law is putting pay to the need for a hybrid static/dynamic language like Java too. What is needed for OO applications IMO is DSLs, late-binding, Mixins etc. In hindsight Java should have borrowed more from Smalltalk, but it didn't, and cannot support these types of features at a fundamental level. Also Java is not written in Java in the way that Smalltalk is written in Smalltalk, so to change Java is inherently difficult, without breaking byte code backward compatibility, hence the kludges that we've seen recently (Generics, annotations etc). For the web we need to look towards true dynamic languages. Ruby is OK, but Smalltalk is better. Also if we want to retain static typing, then how about Strongtalk? As for the future of Java? I don't really see a niche for a language like Java (or C# for that matter) in the future. The strength of Java is the available libraries, but as Ruby is showing it doesn't take long for "the right" language to catch up in this regard. Sun, with it's experience of Self and Strongtalk could launch a 21st century dynamic language that would kick Ruby into touch if they really wanted to. The problem though is that they have invested a lot in the Java brand and the JVM and are unlikely to do so. Change is inevitable. So why the big concern? As programmers we are free to use what ever language we like. The only issue I see is that people don't want to learn something new. As for me, I've recently picked up Ruby and am busy learning Lisp. It hasn't been difficult and I've found it a lot of fun!
  45. Re: Change[ Go to top ]

    I don't really see a niche for a language like Java (or C# for that matter) in the future. The strength of Java is the available libraries, but as Ruby is showing it doesn't take long for "the right" language to catch up in this regard
    Industry has yet to determine if one can effectively write multi-million-line Ruby apps that are maintainable and extensible over many years of life. The Moore's law arguments are compelling in terms of needing higher-and-higher level languages, but the same trends demand the ability to safely manage and maintain larger and larger bodies of code (no matter how wonderfully powerful each line is). Type-safety, amenability to static analysis, and WYSIWYG/principle-of-least-surprise programming syntax are all hugely valuable in this regard -- and all areas where Java is still ahead of most dynamic languages. Actually, the more some try to make Java into a "dynamic" language the more we compromise WYSIWYG programming syntax, which is not a good thing in this regard.
  46. Re: Change[ Go to top ]

    I don't really see a niche for a language like Java (or C# for that matter) in the future. The strength of Java is the available libraries, but as Ruby is showing it doesn't take long for "the right" language to catch up in this regard


    Industry has yet to determine if one can effectively write multi-million-line Ruby apps that are maintainable and extensible over many years of life.

    The Moore's law arguments are compelling in terms of needing higher-and-higher level languages, but the same trends demand the ability to safely manage and maintain larger and larger bodies of code (no matter how wonderfully powerful each line is). Type-safety, amenability to static analysis, and WYSIWYG/principle-of-least-surprise programming syntax are all hugely valuable in this regard -- and all areas where Java is still ahead of most dynamic languages. Actually, the more some try to make Java into a "dynamic" language the more we compromise WYSIWYG programming syntax, which is not a good thing in this regard.
    Hi Jess, This is a good argument. I definately think that manifest type annotations or type inference has a role to play, especially for large complex systems. To me this role has more to do with tool support like name completion in Eclipse and code comprehension, navigation and documentation. What a lot of people don't realise is that static type checking and late-binding are orthogonal concerns. So you can have static type checking with a dynamic language. Strongtalk as I have mentioned before is an example of this. So the bottom line is that we can have our cake and eat it too, if if we so choose.
  47. Moore's Law[ Go to top ]

    The Moore's law arguments are compelling in terms of needing higher-and-higher level languages
    Why does everyone seem to take it for granted that higher-level language == less computationally efficient language? It seems like a really blinding assumption to me. I think it's a false trade.
  48. Re: Moore's Law[ Go to top ]

    The Moore's law arguments are compelling in terms of needing higher-and-higher level languages


    Why does everyone seem to take it for granted that higher-level language == less computationally efficient language?

    It seems like a really blinding assumption to me. I think it's a false trade.
    I agree. Personally I think part of the blame lies in academics who feel it is sufficient to argue why higher-level languages like Greek philosophers. I was recently discussing with a functional language junky the benefits of using a small 1kB buffer with an InputStreamReader instead of using the one byte at a time read() method in Java. I was told that I was was wrong and that using the array didn't make it faster because I was just 'moving the boundary' etc. I provided an example that demonstrated a 2500-3000% speed up with the array and received no response. Literally it was the difference between reading about 1MB a second and 25MB a second from a local file. While I was sympathetic to his cause, I can't ignore what is real. He made no attempt to demonstrate his assertions. I believe that it is possible to make these constructs as efficient as bit-twiddler code but that's a very different thing that saying it is as efficient. I think this is exactly the kind of thing that helps keep people in lower-level constructs. A lot of theoretical hand-waving and very little in the way of demonstration. I actually read a paper recently testing the theory that functional languages are trivially parallelizable. The results were fairly unimpressive. You see a lot of claims about this but very little proof.
  49. Re: Moore's Law[ Go to top ]

    But isn't that just a normal part of life :) ? I've had debates with people about RETE. Many people who don't know it and have never tried to implement RETE algorithm say "it's easy, what's so hard about implementing RETE?" It's only after hours of explanation that "some" people realize it is very very difficult. I think high level languages are good, but the "over selling" gets old. I don't envy the job of guiding Java and being a good caretaker. No matter what Sun does, some people are going to disagree. I personally would like to see the JVM add support for dynamic languages, but doing that is likely going to be very hard and annoy a significant percent of the java developers. Resistance to change isn't necessarily an evil of itself. it's good to have differing opinions and have people debate the pros/cons. peter
  50. Re: Moore's Law[ Go to top ]

    I personally would like to see the JVM add support for dynamic languages, but doing that is likely going to be very hard and annoy a significant percent of the java developers.
    It probably will annoy a significant percentage of Java developers, but it shouldn't. Lots of real processors have opcodes that most software never uses. Java-the-language doesn't need to use any new opcodes added to the Java-the-Virtual-Machine to help support dynamic languages, and at long as Java-the-Library is still written in Java-the-Language, people programming in Java-the-Language don't even have to know it is there.
  51. Re: Moore's Law[ Go to top ]

    But isn't that just a normal part of life :) ?

    I've had debates with people about RETE. Many people who don't know it and have never tried to implement RETE algorithm say "it's easy, what's so hard about implementing RETE?"

    It's only after hours of explanation that "some" people realize it is very very difficult.
    ??? I looked at some article with a diagram that you pointed me to (I think it was you) for about 2 minutes and figured that out. I know there are smarter bears out there than me but that's hard to understand, let alone implement.
    I think high level languages are good, but the "over selling" gets old. I don't envy the job of guiding Java and being a good caretaker. No matter what Sun does, some people are going to disagree.

    I personally would like to see the JVM add support for dynamic languages, but doing that is likely going to be very hard and annoy a significant percent of the java developers. Resistance to change isn't necessarily an evil of itself. it's good to have differing opinions and have people debate the pros/cons.

    peter
    I think that the JVM is going to have to improve support for dynamic lanugages in order to stay in the running as a platform of choice in the future. It's inevitable in my opinion. The question is whether the Java language needs to keep evolving or whether it should remain fairly static like C and let it's progeny carry the torch forward. Personally I think Java has too many warts. Fill in the gaps (function pointers, please!) and move on.
  52. Re: Moore's Law[ Go to top ]

    nothing like money to motivate SUN to keep improving Java language and the JVM. if SUN doesn't do it. I'm sure some person or company will step in and fill the need. I agree that SUN will have to do something. Whether it can do it effectively is anyone's guess. If it was up to me, I'm pretty sure I'd screw it up. Sun has done a decent job so far, so I'm inclined to wait and see what happens :) peter
  53. I do not think you can teach an old dog new tricks
    Of course you can it just depends on the dog
  54. This guy is a total jerk.
    Why is it, always, that the ones to resist changes/additions to the platform are all senior developers who have been using the Java platform since its birth. What is it that they want?

    By now we can pretty well conclude that they do not want to learn anything new and that they will block others from doing the same.
    I'm a senior developer whose worked with Java full-time since JDK 1.0.1 (aka 6 months after Java's initial public release). I do not resist change. I embrace change when its for the better. I learn new things everyday. Most recently AJAX. This jerk needs to ask himself, if this senior developer is resisting change, do they know more than I do? I strongly suspect the answer is YES they know tons and tons more than you do!
  55. I don't want to call this guy a kid or a jerk, but obviously he slept in his programming languages class (if he ever attended one) in college. He missed the whole point of Java language and how the industry ended up here. C. A. R. Hoare thus talked about simplicity in programming languages while he recalled his painful experience with the ambitious PL/I project and the charging force behind it: "At first I hoped that such a technically unsound project would collapse but I soon realized it was doomed to success. Almost anything in software can be implemented, sold, and even used given enough determination. There is nothing a mere scientist can say that will stand against the flood of a hundred million dollars. But there is one quality that cannot be purchased in this way--and that is reliability. The price of reliability is the pursuit of the utmost simplicity. It is a price which the very rich find most hard to pay."
  56. Java is not a programming language but a platform, including virtual machines, APIs, IDEs, tools, and so on. Maybe young developpers are not aware of the time it took to achieve such a stability and performance with different OS. The first Java versions were very slow. But it was interesting because Java was running on Windows, Apple and Unix. Java was not an obvious choice and we had to convince a lot of people (especially IT managers.Senior developpers were not an issue). They heard so many bad things : Java is very slow, it needs a lot of memory, it is poorly written,... At these times MS evangelists tried to kill Java and were doing a lot of benchmarks showing that Java was 10 to 30 times slower than VB or VC++. Eventually Java has win. Because it offered than other don't (portability, performance, object model, stability). Java will not last for ever. Its successor will have to offer more than Java.