Slashdot Mirror
Java Is So 90s
An anonymous reader writes "Some of you may recall last year's Java vs. LAMP Slashdot
flamewar. The fight has now "brewed" (couldn't resist) into the mainstream press at
BusinessWeek." From the article: "Yared says developers far and wide are creating a new generation of Internet-based applications with LAMP and related technologies rather than with Java. Can it possibly be that Java -- once the hippest of hip software -- has become a legacy technology, as old and out of style as IBM's (IBM) mainframe computers and SAP's corporate applications? Mounting evidence points to yes. Reports by Evans Data Corp., which does annual surveys of the activities of software developers, show Java use is slipping as LAMP and Microsoft's .NET technology gain traction."
When I think of the 90s, I think of my days designing in RIPterm and uploading and downloading warez while chatting with Bimodem while trying to figure out the best initialization string to take advantage of the V.42 modem I used.
I definitely do not think of Java as a 90s scripting/programming language -- although I do get very frustrated when Java apps don't run properly on my PDA. I do think that Java is an outdated language that always seemed unfriendly to users and caused a lot of extra cost/headache to my customers when every software company we supported seemed to attempt to create a Java app to access their software engines.
I think Java has (had?) some features that made it easier to program in, especially for not-so-wise programmers. The automatic garbage collection allowed my guys to make quick fixes without worrying about memory management (I am being sarcastic here, I had some real dumb asses subcontracting some of my work). The speed of Java was great too (still sarcastic), and the consistency of the output code was always a positive (yes, still sarcastic).
I guess my big concern with LAMP is what the hell is the P? PHP? Python? Perl? They're all very powerful and they all have their own positives and negatives in regards to quick scripting solutions, but all of them still allow bad programs to churn our badly written programs. I'm guessing that is the trade-off: the more complex programs you can write, the more likely you are to see badly written programs.
It is very hard not to be sarcastic when talking about Java. Every CEO of every company I consulted with loved to spew the big tech words, and Java haunted me for years. I'm glad I don't hear it anymore -- should I thank the dotbomb for that?
In the long run, I think the 90s client-server systems will come back into use. Software companies have every reason to move back to controlling their applications and charging for use rather than licensing the code out to end users. I seriously believe the push for faster cable modems and DSL to the home is through the software developers (and music and video publishers) in order to just stream everything rather than offer the user the ability of unlimited copying. Once you have 2MB WiFi nation wide, there is no need to ever store your programs or your media anymore, right?
What worries me is that I teach at a community college. One of my colleagues subscribes to Business Week and takes them quite seriously. I'd rather not have to get into a curriculum battle over this. Business week just needs to STFU about technology in industry, because people who have limited contact with it (either by not interacting with the technology or not interacting with industry) will often take their ill-informed articles as Truth. (Incidentally, I left industry 4 years ago and am close friends with others still in various sectors. Even after only 4 years, I'm very suspicious of my own first thoughts on the way industry is going, and I always get first-hand input.
I'll grant that Java requires a significant learning curve.. But not for people that have been initiated into the computer-science field.. Java was specifically meant to have a low-learning curve... For EXISTING programmers of the langauges of it's day.. C, C++, and friends.
But this is a misnomer.. Take a person off the street and teach him a "hello world" program in python or basic.. He'll say "Wow, I'm a programmer now!!".
Then ask him to synchronize two credit card databases of different structures with it. Ops, learning curve!
It's a damn-simple thing to do, but you needed to learn an API, and a bunch of underlying concepts first.
Same thing with java.. It is designed rigidly so that the programmer can make assumptions that make their life easier. You have to explicitly manage errors for one.. Doing so means whenever you change the form of data, you are forced to think about it to make sure that the data has exchanged correctly. In Python, perl, numbers become strings become floats become triggers based on how you tickle the data (not necessarily access). These are simply two different assumptions about the significance of the data. If I wanted to have refactor a perl object definition (say change a method name), it would be damn near impossible to do. I couldn't just perform a text-search for the method name because it would probably overlap w/ other methods that had similar names.. But in Java, that rigidity means I can clearly know exactly who uses this exact method.
If you're writing small apps and your definitions are distinct enough this isn't a problem.. But in my 15 years of programming, I've had to do a lot of refactoring, and in c or perl-type languages, I almost always resorted to work-arounds instead of true data-migration; as it just wasn't worth it.
I perfectly agree w/ KISS.. But Simple and concise are not the same thing... Perl/Python/Ruby provides conciseness (saying a lot with a little), but at the expense of convoluted code (your rails project has the name of a method mean several different things). Java provides preciseness (and of course the ability to shoot yourself in the foot by being non simple, non-concise and non-precise). You are able to be concise in Java if you make use of rails-like-APIs.. Essentially modularize/aspectize your code so that the complexity is held elsewhere to define a type of work.. Then you concisely write the core of your application. Hibernate + xdoclet or attributes provides an example of this.. EJB provides a means of isolation of units-of-work in a way that is scaleable, clusterable, and safe all at once.. (Not that I ever use EJBs directly; but there are plenty of EJB-like services). This is not to say that RAILS can't be made similarly.. But to my knowledge you are still choosing a particular framework, and don't have a lot of flexibilty to alter those large units-of-work outside of the original author's inception.
I've regularly hooked together many open-source units-of-work in ways that I'd never seen done before, and Java has always made this not only easy, but reliable (providing thread-safe, classloader independent, order-of-execution-safe, work-flows out of the box). Of course almost all of my units of work live inside of a serlvet engine.. Rolling your own main means that your mileage may vary.
-Michael
People always blame C++, but I still think that the problems with C++ come from two sources, neither of which are the language itself:
1) lack of a single, dominant library for all the things that Java provides (like serialization, gui, etc.) and generally fugly APIs for the ones that are mainstream.
2) coders who treated C++ as "C, with some new features" rather than treating it like "Java where you can import C functions". Use vectors, smart pointers, etc. and the language miraculously changes from fugly to pleasant.
If Java was just a C++ library and a good free compiler, we might have dodged this whole mess. The only loss would be applets (not gonna run untrusted C++ code on the browser) - and who would miss those? Really, who uses the hardware-agnosticism of Java anyways? If the hypothetical "Java Library for C++" was created to be platform agnostic (just as Java is) then you'd have the same functionality in C++ - after all, it's pretty easy to write C++ code that will compile/run everywhere if your libraries work the same everywhere, and your compilers actually follow the standards.