On Mon, May 3, 2010 at 17:31, Kevin Wright <[email protected]> wrote: > The biggest problem with Java is baggage, of two main varieties. > The first type is in backward compatibility. This includes maintaining the > CORBA API, as well as the hideous Date/Calendar stuff.
I think, with modularity, where the deprecated stuff (I would not put Date there) is loaded only if needed, would be a sufficient solution for that. And maybe have two different runtime packages where a smaller version may not include some of the very old stuff that is not used in newer projects because of the existence of better APIs. I heard this is coming with Java 7. > I shudder at the > thought of mutability in some of this, the API effectively states that you > can change May 5th to become September 22nd; Who cares? - Really: This is something, a professor at university may have a philosophic problem with - in the real world nobody had a problem with that before the functional and immutable hype. And BTW: Yes, it can make sense: Let's have a deadline on May 5th that is moving to September 22nd. Why shouldn't it be valid to change that date? - Not every date is a birthday. > There's a lot of inconsistencies and design patterns that have since > been superseded but have to be maintained in the libraries > for backward compatibility. In a private project these would be rapidly > deprecated and re-factored as code debt, this isn't an option for the Java > APIs. And I am so happy, that there is not such a wild refactoring. I am currently working with 3rd-party APIs that recently changed a lot due to refactoring. Documentation permanently outdated and so on. Puuh. > The second type of baggage is in the headspace of developers. Many Java > devs got taught how to use the language at university, then promptly stopped > learning once they entered a 9-5 job. Many people stop learning after a few years in the same 9-5 job. This is nothing, special to Java or IT. But regarding change: I find myself able to adapt to change - but I am looking very critical to new things because a) many new stuff is old stuff in new clothes and b) many new things are not really better than what I had/used before. I you want me to adopt new stuff, then that stuff has to be WAY better than what I used before. Otherwise I consider the cost of change being more than what I gain. > These are > the folk who think that other languages are about little more than syntax > and can't fathom what all the fuss is over closures and functional > programming. These people will continue to hold java back even if it gains > the new API and features that people are clamoring for Neither functional programming nor a lot of other stuff considered to be modern and better is really new and really better. For an advantage at one side you pay at another. > .NET doesn't have these issues because: > - It's a newer platform and didn't have to maintain compatibility with some > of Java's older and more glaring API flaws ROTFL - but yeah: Compatibility is usually "outsourced" at Microsoft to be done by 3rd party developers. Required changes in software that it continues to work with new versions of SQL Server or Windows usually need to be done by the 3rd party developers. Microsoft does not give that much on compatibility as one might think. Yet had an issue where I had to install a 10 year old Windows software on Windows 7 - guess what: Did not get it to work on Windows 7, but on Ubuntu with Wine. HA! Business customers give a lot on backward compatibility - they call that something like "return on investment". ;-) > - Microsoft were more willing to make breaking changes to the API in early > days, so as to make genuine improvements and grab mindshare amongst the more > passionate and influential developers Yep - see above - Microsoft usually breaks more than they get fixed with newer versions in the last years. Just my plain experience. I do not consider .NET being an exception there. > - They continue to be willing to add proven new techniques and patterns to > the platform and C# language. Such as dynamic lang support, FP constructs > via LINQ, sensible property handlers, delegates (method handles), closures, > etc. Java prevaricates over all of these. Guess what: I didn't miss any of that stuff in the last 15 years of development - so a) it can't be something real essential. And apart from that I currently don't see a particular situation currently where I would use any of that. Dynamic language integration would be the most important for me but I can also call Java code dynamically even with plain Java features (which I would need most likely in my current projects). And for LINQ: I can only see a mix of two separate things (SQL and programming language) that I wouldn't mix. > As a language I truly feel that Java has already become the next COBOL, it's > gone too far now to be able to revitalise itself, but as a platform it's > mindbogglingly amazing and a worthy competitor to .NET. And I find Java even better than .NET although I come from the Windows world and .NET would have been really the easier way for me. -- Martin Wildam -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
