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?
Problem is that Java programmers have been bought up by big companies deploying enterprise applications and they really haven't been contributing to open source projects. With all the PHP projects out there that you can just download and deploy and tinker with it is no wonder why php is all over the web now. Java should be easier to deploy as .wars and just as easy to tinker with. But it just seems like every open source J2ee app out there dies on the vine, probably because the java developers got real jobs or else they decided they could sell their software as an "enterprise" product.
Why oh God WHY did ATI move to .Net. I HATE the driver interface in that it now REQUIRES MS.Net to be installed. At first, we were given the option to use drivers that used it or not. Now with 5.12v, it's required to have any of the advanced options available.
.Net
It's just added Bloat. So why even use it on Windows? I sure hope nVidia doesn't start using
Life is not for the lazy.
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.
Yes they are, coding in Ruby or Python is actually geniuinely fun and rewarding. Not having the language go in the way and prevent you from thinking about the program (the forest) because you have to think about the code (the tree) is like discovering programmation over again. Being 5 times more productive with a third of the code lines without losing any clarity or expressiveness (quite the opposite in fact) is refreshing.
There is no reason for programming language to not be sexy but the ones you accept when you use crappy languages.
I perfectly agree with the "Use the right tool for the right job", you can't use high level interpreted language when performances and memory footpring are issues, but you won't use Java either anyway...
"The way we can tell it's C# instead of Haskell is because it's nine lines instead of two." -- wadler
So, what do you want to do today; be correct or be productive?
"Can there be a Klein bottle that is an efficient and effective beer pitcher?"
It's all perspective I suppose. I used to code in Java, then got elbowed into Microsoft(.NET) shops. C# is very Java-like. .NET DOES run a virtual machine. But API-wise, the .NET framework is more of a wrapper around the Win32 API. The Java SDK, is a little "cleaner", in my opinion, and it heeds the spirit of OOP more closely. But for people who are transitioning from VB, and C++ to C#, .NET seems pretty great. I'm indifferent at this point. I try to keep my Java skills sharp, and will continue to do so. The whole "Java is Dying" FUD is ridiculous and without any real evidence.
.NET. He had NO clue what he was talking about. I asked him if he knew what the significant differences were between Java and .NET, and he just bumbled his way through some snake-tongue babble.
On a sidenote, I had a recruiter try to tell me that Java was on its way out, and that EVERYONE was moving to
Languages always have their places. It's important to see what's happening to Java. There was a point when every job description had Java in it. Java java java. Java was used for everything. Web applets. Full fledged GUI programs. Command line. Server side. I think people are finally realizing Java isn't good for everything. I think we are finally reaching an age which Java is finding it's place. It's meant for full fledged, cross platform, programs. GUI or command line. Programs that are meant to be kept open and running for awhile. This is where Java excels.
Java has had a terrible history. It's a lot of people's faults. PHB's, HR depts, Marketing, Bad programmers, Sun, companies releasing Java tools. I think most people on slashdot have a pretty strong opinion of Java. Love it or hate it, they have a strong opinion. The initial GUI implementation was awful. People were expeted by PHB's and Marketing to learn the new buzzword language in weeks, when in reality Java is the type of language you need to spend years studying. It's huge and complex. Just like C++. Java came into wide spread usage in the 90's, when computers were still a bit slow for it. It isn't until now that Java is really finding it's place. It's not as grand as the original plan for it was. If you talk to people, most of them have stale opinions of Java. Their view of Java is Java 8 years ago. And little will change their opinion.
If an officer ever threatens to taze you, say you have a pacemaker.
.Net may not be ideal but to say that it is dying away is simply wrong. My impression is that for not so mission/performance critical enterprise (yes enterprise) apps that Microsoft/.Net has been dominant. I think that among the more hardcore they are gaining a bit of ground (thanks in part to c#). Reuters now offers .net api in addition to there C api and just look at the number of .net components!
I think it is Java that never really lived up to the hype.
I've watched Java ever since it first started making waves, back when Sun thought it would be the ubiquitous language for rich web content running in browser plugins, and had demos of a little anthropomorphisized coffee been dancing across your netscape browser that we had to show off at trade shows.
Java sucks. I've been saying it for so many years that I've mostly given up on mentioning it anymore. But I'm taking the effort today to make another rant about it, since this article happened to bring it up.
Java has never been hip. Everyone I've ever known or heard of that was a Java advocate or a Java programmer was never really a programmer to begin with. All the hard-core guys I've ever met, who really know how to code well in any language (and who know how to do really clever things for fun, but then smartly avoid cleverness when at all possible in production code), never liked Java. Java is an industry buzz pushed around by publicists, managers who don't know better, vendors who could care less what the right answer is, and "coders" who learned from a Java for Dummies book which they had time to read after being layed off from yet another position in which they were useless and incompetent. The vast majority of Java source code I've ever read has made me want to puke. What can be expressed succinctly in 40 lines of instantly recognizable code in any other language becomes a multiple-inheritance heirarchy of 40 classes in the hands of a "professional java developer". All those people who seem to succeed at navigating twisted inefficient beauracracies for a living, and twisting them further as they go, seem to be exactly the kind of people who love a language like java.
And while we're at it, "LAMP" isn't really a good term for what's killing Java. For starters, Java can kill itself just fine without any external help. Secondly, the idiom that most people mean when they say "LAMP" can be had without those specific technologies (Linux, Apache, MySQL, Perl). Some people do it with FreeBSD, Lighttpd, PostgreSQL, and Ruby (but FLPR doesn't have the same ring to it). My point is, this isn't the victory of Apache, or Linux, or MySQL, or Perl. It's a victory of concise, well-built, community-maintained, open-source software over corporate-inspired and corporation-pleasing bloated nasty red-tape-tangled environments like Java (or SAP, or any of a number of stupid software ideas to come along in recent decades).
11*43+456^2
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
I wholeheartedly agree. The biggest strengths of Java are its cross-platform compatibility, its garbage collection, and its multithreading support (since the introduction of version 1.5). It's also useful as a research platform for computer scientists/engineers, because it allows for full control over both software and the (virtual) machine that it's running on. You can't get that in any other production software environment.
Some people (including me, soon) are taking advantage of this flexibility to try to improve Java's speed: Sable Lab
By the time I seriously started playing with PHP I already knew Java, yet it felt compelling somehow. I think it's just because it seems simpler, because the default choice is to put everything right in the page, rather than writing some JSP, some servlets, some EJBs and so on.
Writing JSP pages isn't really that much different from writing PHP pages; you can write them in a PHP style. But Java people tend to be degreed software engineers moreso than PHP hackers, so they make things complicated and build up layer upon layer of infrastructure, and you need to know a lot more to be able to deal with all those layers effectively. (And you end up needing to use struts, or EJB, for example, not because it's easy, but because management or coworkers pressure you into it.) Alternatively you can just do your database queries right in the JSP pages, which is ugly in a design sense (schema changes can be harder to propagate through the whole system) but very PHPish, and at least the whole pile of code will be smaller and more manageable if you have fewer layers to deal with.
The myth of software engineering is "after I write this nifty abstraction layer I'm never going to think about this facet of the problem again" (whether it be hardware abstraction, dealing with the database, the GUI API, dealing with web-based transactions and user-specific "state", or anything along those lines that you don't enjoy and would like to box up and forget about). The reality is that every layer you write also requires some maintenance, so you cannot avoid having to think about any of those things again. PHP hackers are just more likely to suck it up and deal with these annoyances head-on, with as terse code as possible, rather than try to abstract them away.
But some of the abstraction layers that have been created for Java applications are really elegant. Some much more than others.
Another factor is that large projects, for which more people are hired than is really necessary, with too much management, tend to take the long way around, in the name of elegance and maintainability. If programmers are smart enough to invent really elegant abstractions, and they have the time to do it, most will do it. But if you're on a scrappy underfunded little project you just take the most direct path to get the job done.
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.
I've never understood how job openings on a job board give any indication of how popular a programming language is. If my company posts 10 .NET Programmer openings and 10 Java Programmer openings on Monster.com, and we have 6 .NET developers apply and get hired and have 2 Java developers apply and get hired; then you go out to Monster and run some sort of statistic on it, what do you see? 4 .NET openings and 8 Java openings. That must mean Java is more popular!?! Nope, just means it's harder to fill the positions because it's becoming less popular. (This is just one way to look at it, not saying .NET is more popular than Java or the other way around).
Languages don't cause bad programs to be written -- bad programmers do! It's just a sign of the decline in pure programming skills.
Right and guns don't people, people kill people, but it's a lot easier to kill people if you've got a gun, non? I think it can be legitmately said that the nature of Java is better lended to well structured code. It doesn't mean you can't write well structured Perl, but on the average, people will write better code in Java than they will in Perl. Sure, a good programmer can write good stuctured code in any language, but you have to accept the reality that there's far more demand for code than there are top notch coders. That doesn't reflect a decline in pure programming skills, it reflects a vast increase in the need for people with any skill at all.
I find these language debates kinda dumb, frankly. Here's the thing, with everything being web based, it doesn't matter a lick what you run it on. If Java works best for you, great. If LAMP works best for you, great. Personally I prefer LTPJ (Linux, Tomcat, PostgreSQL, Java), but then I know Java a lot better and I know how to make it do neat tricks I'd have to learn over again in PHP. Besides, can you even write threads in PHP?
But if you all websites work with the same browsers and all websites communicate with eachother in the same way, the code could be running off of punch cards for all it matters. In the long run that openness will tend towards minimizing the influence of any one platform or company. People will go with the tools that suit them best.
Articles like this one are even more stupid than the debate because it's clear they do no understand the technology. They talk about people using Linux and Apache as though that means they couldn't be using Java. In the end, you can totally mix and match Apache, Linux, Java, PHP, etc, to best suit the environment you're working with. But of course that doesn't make for as interesting an article, does it?
This sig has been temporarily disconnected or is no longer in service
Yes they are, coding in Ruby or Python is actually geniuinely fun and rewarding. Not having the language go in the way and prevent you from thinking about the program (the forest) because you have to think about the code (the tree) is like discovering programmation over again.
This is absolutely true. After wanting to take a look at Python for a while, I finally wrote my first program in it this weekend. It's a simple script that finds all words in a Boggle grid. (Useful for cheating here). It took maybe an hour of looking up the proper syntax for reading files and creating lists and such (all of which are intuitive and easy to remember, unlike Perl), and it worked perfectly on the first run. It was only then that I realized how little code it had taken and how *pretty* it was: Java would have had loads of redundant code with classes and casts and explicit list creation and copying, and Perl would have had about the same line count but peppered with inane "@$" prefixes for the lists of lists.
Python is good. Check it out, even if you think the significant whitespace is silly. (I'm still undecided; I don't like being at the mercy of how text editors interpret spacing, but it does improve readability somewhat).
How to solve most of our problems: 1.Lots of nuclear plants. 2.Cure aging.
I'll point out one place where Java has it all over the other webserver languages. When you issue a HTTP request to PHP (the 'P' in LAMP), what happens? Off-the-shelf, it's gotta tokenize the scripts (and in any decent-sized web app there are MANY), then it has to execute it. Then it loads all the data needed to regain the client's context. Finally, now your request can be serviced. HUGELY INEFFICIENT and a really poor design.
With Java, you can connect with a pre-compiled, already-running servlet or JSP page that's part of a *continuously* running system. Shazam! The data's already there! You've got a pool of objects, threads and database connections, all ready to roll.
Whatever minor inefficiencies you point out with JVMs, having a continuously-running website application scores first place. Perl has the potential for this, but then you're stuck with its obscure syntax (not a biggie, but..), limited object orientation and too-new threading feature. Java works better for server apps.
I'd like to see the Ruby crowd compare on this basis. (Not against Ruby, just not familiar enough.)
Cheers.
O lord, bless this thy holy hand grenade, that with it thou mayest blow thine enemies to tiny bits, in thy mercy.
Things like JCL weren't under source control. Testing was usually ad-hoc to non-existent.
It's a matter of care/professionalism on the part of both IT & System Owners.
Been places where some of the stakeholders can't event be bothered to turn up to Planning/Information meetings. I know, I fell asleep in one once! (It was in another city & I c'ld sleep the night before.)
I've seen 3rd Party vendors ripping off organizations blind (for customization)!
Is your Mainframe system organized because your site is well run & professional or because it's 'functionally stable', i.e. dead!
How do their market shares compare to 20 years ago. What will their market shares be in 10 years time? Are they being pecked to death by new companies running blade farms?
I wont use the name 'Open Systems', in this case it's a wrong term! (When did Wintel become an open system?)
It's not the scale of the hardware that is the issue. It's the utility of the software. Generally the newer the software, the better its utility! It's a matter of trade offs. When does the cost of upgrading worth the benefits of the extra utility!
These small systems run the newest software.
All things considered, I'ld rather work with more recent software. Why, one word, UTILITY. Better software tools, if used in a professional & disciplined way, led to better systems that can evolved in a more timely manner.
In a COBOL environment you are fighting the language to be disciplined and structured. The grain of the COBOL language is too course! Which would you rather Unit Test, a 30K LOC of COBOL program or a 50 LOC java method?
A quiz for you!
Question: What are the four division of the COBOL program.
Awnser:
IDENTIFICATION DIVISION.
ENVIRONMENT DIVISION.
DATA DIVISION.
SPAGHETTI DIVISION.
A good manager makes sure their staff have good tools!
Gnoll110
See, there is your problem, the definition of a powerful language.
/.
A powerful language for me is one that can be highly factored and is still completely readable. It means that nothing is hidden and no function is less than obvious.
Most importantly, a programming language is a communication medium between human and human, not just human and computer.
How well do the languages you listed help you communicate with some arbitrary programmer that you have never met and do not get to explain anything to face-to-face. As you add multiple languages into the mix (AJAX, etc) you make this human to human communication even more difficult.
Forget the libraries and J2EE, These are the things that, for me, makes Java a good enterprise tool:
Automatic documentation generation with the code being the source!
(This is one of the most important things ever done)
Simple, clean, consistent code
The ability to create clearly defined interfaces between sets of code (objects, in this case).
OO!
Deterministic--a GUI Editor always knows just what can be done with any given object at any time.
Shies away from adding features--towards consistency.
Garbage Collection
(Not simply because it makes code more reliable, because it makes it MUCH more clean/factored. If you've never had to fight the design battle of who owns/gets to destroy an object used by multiple other objects, you pretty much either aren't a programmer or you've always used a language with GC.)
I guess it all comes down to Elegance in code. Being able to do a lot with one line of code or being able to type 50% fewer LOC to do your job has no place in programming today and is, in fact, counter-productive. If you are actually thinking faster than you type when you're programming, you need to think more, not type less! (If you honestly disagree with this, try APL, you'll love it)
If you think that J2EE/Libraries are a reason to switch, you are exactly the person I was talking about in my previous post... the power is in the Language, not these add-ons. The language features I listed are exactly what allowed these complicated, complete, reliable toolsets to be built in the first place.
People that pick Java for the toolsets/libraries are completely missing the point. They are probably also the same ones complaining on every Java article to hit
>> Anything you can do with a flashy GC in Java, you can code up the same memory management algorithms in C++ if you really need it.
Why? I can download Java from Sun and it has this built in.
Performance hasn't been the issue with Java since 1.1, maybe 1.2. If you want to write embedded systems, device drivers, software with a small memory footprint, maybe Java isn't a good choice.
>> If the Java evangelists were right, and Java really was rivalling the performance of C++ and easier/safer/more productive today, then it's strange that the entire industry I work in, with all its R&D, hasn't noticed.
Ignoring performance, writing in Java _is_ easier/safer/more productive today than writing in C++.
People make fewer mistakes. People write better code. People don't have to spend weeks trying to write GC instead of just downloading something so efficient it's inadequate 1 time in 10,000.
I have deployed, at three companies now, Java based web applications handling millions of pounds of business, serving terabytes of dynamically created content, underpinning the leading websites in their industries.
Performance issues? Sure, we've had some. We've dealt with them. Good application design helps immensely, good hardware is cheap, basic measures such as caching data in memory, reducing network calls and writing stateless code all impact performance several orders of magnitude beyond the language used.
Is Java as performant as C++? In terms of money spent, on hardware, on developers, on design and analysis, to get web pages to users within 5 seconds? Yes.