Slashdot Mirror
If Java Wasn't Cool 10 Years Ago, What About Now?
10 years ago today on this site, readers answered the question "Why is Java considered un-cool?" 10 years later, Java might not be hip, but it's certainly stuck around. (For slightly more than 10 years, it's been the basis of the Advanced Placement test for computer science, too, which means that lots of American students are exposed to Java as their first formally taught language.) And for most of that time, it's been (almost entirely) Free, open source software, despite some grumbling from Oracle. How do you see Java in 2014? Are the pessimists right?
Java is moving into archaic irrelevance faster than ever. That is, the language itself.
The JVM, however, is now more useful and relevant than it ever was. It used to be naught but an implementation detail. Now, rather, it's central to an entire ecosystem of languages that will inevitably send Java the way of C: used only when the greatest speed is necessary.
Scala is basically a next-generation Java. Java with functional programming, or really, vice versa. JRuby make Ruby actually scalable, given the presence of native threads and interoperability with existing enterprise libraries that commonly only ship in the form of Java or C# libraries. Clojure enables LISPers of yore and Schemers of new import explore functional programming as it used to be, without having to drop the wealth of Java libraries available. Ceylon, Groovy, Jython, and dozen of others are paving a way to give the JVM much more to do after Java becomes obsolete.
Java will never die - it'll just become like COBOL, Fortran, and C before it: used in enterprise software, operating systems, and outdated educational assessments.
Colin Dean Go a year without DRM
It was just coming into favour when I left. When I was around it was Modula-2 and Eiffel (for OOP) at University. I have always found Java to be absolutely horrific in practice, being pretty much the worst of all worlds. Today C# is far superior, whatever you think about Microsoft, and it's a real shame that .NET was mishandled at birth in the way that it was.
You only need to learn one oo procedure based language. All others are just a book exercise.
One assembly language and how compilers translate stuff.
And then you should also learn scheme.
That will handle basically everything, reducing it to a book learning experiment.
There almost needs to be two separate considerations. From a language standpoint Java is a bit middle of the road. It has some well known pain factors, but more or less it's one of the easier OO languages to master. It's used in a lot of high profile web site.
The VM on the other hand does a lot of interesting things under the covers that make the language quite fast. When JRuby hit the scene it was faster than the core ruby project at quite a few things because the VM was doing all sorts of optimizations behind the scenes. Also, because the Java OP code is so stable with relatively few changes per major release you have a bit of a boom in languages you can run inside the Java VM. You get all the benefits of the R&D Sun and Oracle put into JIT, while retaining the ability to do interesting and contemporary things with your language.
Clojure, Groovy, Scala, Python being the primary languages with another 16 that can compile to Java Op code.
Were Java fails mostly is as a client application, running with some sort of Windows GUI. Sure, you can do it, but it realistically people who do Java Swing apps are writing some sort of thick client that could almost always could run inside a contemporary browser without any plugins.
It's a compromise language. Compromises are, in fact, a good thing but purists hate them. Of course. That's what purism *is*. But really, who cares if it's cool? We're geeks, I thought we were supposed to be opposed to "cool" anyway?
It's a known quantity and before you dismiss it you should consider the truly vast amount of software that's been successfully implemented in Java.
Personally I like it. It has it's niggles (if I were king I'd change oh so many things) but it keeps on succeeding like most good compromises.
--- These are not words: wierd, genious, rediculous
What good engineer gives a f**k about what language "cool", aside from considering his/her ability to hire hipsters to staff the project?
If you're worried about the "coolness" of a language when doing your day job, you're almost certainly doing your job poorly.
The alternative view is that it is fast enough to do the things that need to be fast and cleaner than all those scripting languages.
Here's the thing. Java applications are VERY EFFICIENT. It may be difficult (not impossible but a pain in the ass) to write Java code which performs a specific task in a deterministic period of time. In other words it is not really a real-time sort of thing. OTOH if you want a perform a large number of operations with maximum overall throughput and a fairly stable task completion time then you cannot beat Java. You could do it in C/C++, but you'll spend a lot more time and effort to get the same results. 10 years I coded large high capacity high speed feed handlers in Java and people said I was crazy, but that application continues to exist and outperform anything that tries to rival it while being highly portable, scalable, and superbly reliable.
The thing with scripting languages is they are for small projects. Sure, its MUCH easier to whip out a perl script or something to do a small job. Its faster at run-time as well, but as soon as that task grows to somewhere in the 5-20k lines of code range you simply cannot do it using a scripting language anymore and stay sane. Inconsistencies creep in, problems pile up, the code starts to have to be used and understood by many people, and its just not possible to maintain the level of determinism required of a large code base. At this point you NEED something like Java.
And yes, C# is a perfectly nice language, but it is only really usable on Windows in any consistent fashion. I see no reason to be limited to that platform. Most of my customers are perfectly comfortable with *nix systems and for high reliability high capacity line-of-business applications no version of windows holds a candle to RHEL and isn't even on the same planet with Solaris.
"Malo periculosam, libertatem quam quietam servitutem." -- Jefferson
One of the main reasons Java may be "cooler" today than when it was first introduced is performance.
In the early days of Java, it's VM architecture meant that it was significantly behind fully compiled languages like C/C++ in terms of performance. People were supposed to sacrifice speed for portability. Even for non-speed critical applications, slower languages were thought to be "less cool". Real men used C, and real, real men still coded in assembly language.
But the VM technology in Java has gotten so sophisticated that it isn't significantly behind languages like C/C++ in terms of performance, and that can't be ignored. This is allowing some of the advantages of Java over C/C++ such as garbage collection, dynamic class loading, a certain degree of reflection, various safety systems, etc., to win over some programmers. Java may well be cooler today than it was 10 years ago, because it's really grown up and become a fairly useful language.
If I can be modded down for being a troll, can I be modded up for being an orc, or a balrog?
I wouldn't state that C# is superior to Java from a language perspective, both are essentially derived from Ada and C with influences from C++.
If Ada had been more open and better promoted then it would have been a far better choice.
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
If speed is absolutely critical, you're going to go with C/C++/ASM/whatever native-compiled-language works well for your problem.
If speed is not absolutely critical, there's plenty of "scripting" languages that get the job done more easily with less code.
Yeah, this is how most 2+-sigma programmers on the right side of the standard distribution of programmers approach problems.
All the rest (the vast majority) need languages with good error messages, good error landing, decent garbage collection, a lack of value/reference handling, etc., and frankly being more procedural than functional is an asset to a below-average programmer.
Code density is not the criterion most mid-level enterprise IT managers need to deal with. Even with a complex project and a team, you can take one guy and have him write the JNI bits in C++ for performance (BTDTGTTS) while the rest of the team handles other parts and they don't have to know as much. It's actually really bad economics to have all top-notch programmers on your team if your project does not require that.
And before all you kids who got trophies for losing a soccer game get into a snit - by mathematical definition, half of all programmers are below-average.
And Java works pretty well for them, and there are stable and scalable deployment platforms for their code. Expect the "cool kids" to be wondering about Java in 2024 - even if there were a better replacement available today (there isn't), the extant code bases would not get replaced in one decade.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
I'm in the process of hiring software engineers right now, so I've been exposed to a lot of resumes and had the opportunity to talk to a lot of people on the phone (standard phone screen). Invariably, all recent CS graduates list C on their resume as one of their languages. One of the things I ask every candidate to do on the phone is to describe how C strings work. This is my "marker", the test of how much time they've spent in C (vs Java, or ObjC, or whatever). If you're a serious C programmer, you know how C strings work. No exceptions. If you've spent your entire time in college (or even professionally) programming within an environment where strings are handled by object abstraction, you've probably never had to deal with C strings directly. A suitable answer to the question is as simple as "A C string is an array of chars with a null termination at the end".
You'd be surprised at how many people fail the screening process (and thus are rejected) based on this single question. Probably close to 75%, and every single one of them has a CS degree.
People who say "sheeple" have about as much sophistication as an AOL user, and in fact are probably actually AOL users.
Those "suits" you refer to included every major hardware vendor on the planet. Java was only sold as a silver bullet for portability, not speed, not efficiency, not scalability, but solely for it's ability to be shifted from one vendor's platform to another's.
When it comes to straight forward business service and batch job processing, it succeeds admirably at that goal, which is rather rare for what you claim was a "silver bullet."
The "problem" is that all kinds of people have visions of Java doing this, that, and the other thing, ranging from the addition of database bindings that don't allow for stored procedures to 3D graphics. Java's "problem" is that it's gradually becoming too much of a "kitchen sink" instead of staying focused on what it was designed for: portable business programming.
I do not fail; I succeed at finding out what does not work.
A big problem with duck-typed scripting languages, such as Python, is that the absence of explicitly stated type requirements in the source code. Using types in function signatures and variable declarations is an extremely useful tool for developers to indicate not only how a system is decomposed, but also what potential future usages they intend to support vs. not support.
I've worked on reasonably large Python, C++, and Java projects. The Python code was by far the hardest to make sense of due to the duck typing and other Python idioms (metaclass, i.e. self-modifying code).
I wrote compilers for Modula-2 in University, and was minimally exposed to Java (thank God). I have seen fans of it, but my own experience is that Java is a narcoticized slug. Its bloated (worse than COBOL), and has a learning curve steeper than a cow's face. Worse, unlike C, which is a compact language (you can learn all of the data structures can be easily described in 2-3 pages of any textbook or manual), Java goes on and on and on (the smallest book I've seen is 850 pages). There are 10,000,000,000,000 libraries, with that number being modified every year, and offers by exponents of the language to offer another 3-5 libraries for every one available already. In order to be productive in any way (eg: Hello World), you need to call in at least half of all available libraries (each, seperately, and in the correct sequence), and then hope that all of your current libraries are up to date and work with each other. Then you run the program, and wait, and finally it gives you your output: "Hello World".
I wouldn't state that C# is superior to Java from a language perspective, both are essentially derived from Ada and C with influences from C++.
Haven't used C# that much myself (and am totally out of touch with Java these days) but when I first used it just over ten years ago C# *did* strike me as very obviously a Java workalike, albeit one with a few nice improvements. Of course, it had quite obviously enjoyed the benefit of hindsight over Java, picking and choosing the aspects which worked and being able to ignore the dead-ends and mistakes, as well as the legacy library cruft which- even by the early-2000s- Java already had quite a lot of (mainly stuff from the early versions which was later deprecated).
What is cool? Programming isn't cool. Programmers aren't cool. Being a guitar player in a great band is probably cool. Being a chick magnet might be cool. When has being a Java dev gotten anybody laid?
The only people who care about how "cool" a language is are posers. A professional developer is going to choose the tool that is going to let him/her build what he/she wants with the least fuss. For a lot of today's applications, that tool may well be Java.
What's uncool is a skill that won't get you a job. Java can get you a job, help you buy a car, a house, live your life.
there are 3 kinds of people:
* those who can count
* those who can't
It sorta got there. It's an unmitigated disaster on the browser, for example. It is also awfully touchy about what version of java you're running. The desktops with native java CPUs never happened.
Java definitely isn't Hip and never will be. It is, however, the new COBOL which means it'll be around for a long time.
The one exception is it's use in Android. I wouldn't say the language is hip there but it is tolerated because mobile is hip.
Jeebus people, just open the story from 10 years and press "reload." There you go, you asked again and got the answers again.
It might be that there are real pros and cons for languages. It might be that the reasons languages are "un-cool" are because they address the needs of the pointy-haired, and don't support pocket protectors.
And it does make perfect sense for Java to be the 1 required language in a CS course; it might be the only way to get kids to learn it, since it is so un-cool, lame, and inefficient for the small projects that students are working on. In a well designed CS course, very few problems have a required language past the basic algorithms classes. (Where standardization allows for a higher quality class when the teachers are grad students)
Anyways, it makes sense to teach Java, because the best use case for Java is to be able to use massive teams of low quality developers, potentially with high turnover, and still make working software. These are the people most in need of the job training type of education. People who are going to work in almost any other area are going to have to be able to learn new tools quickly based on the manuals, and it won't matter what they studied.
You don't need an "OO... language" because OO is a methodology. You can learn pure, real OOP using almost any language. Plain C works fine.
You can also write bad procedural code in an "OO language" because that is also a methodology. I see that crap all the time; giant 50+ line methods that do a bunch of things and all the utility functions are procedural-style class methods. Lots of Rubyists don't have any idea even what the difference between OOP and Procedural is, they just assume they must be doing OOP since they're using an "OO language."
Same thing with learning scheme; when you associate functional programming with a language instead of a methodology, the first thing new people do is try to find a way to fake some state and they end up with spaghetti procedural instead of functional.
You only need to learn one oo procedure based language. All others are just a book exercise.
The problem with that is most people think because they can program in that language they understand the paradigm.
There are tons of c++ and c# programmers out there who think object orientation is only about turning UI controls into objects. All other code is more of a mix of bad OO and imperative programming.
I would revise your original statement to you only need to learn one oo language well. Same for functional languages. You are have to know a language well to understand the paradigm.
COBOL was never cool, either, but is still in use in enterprises.
For learning the craft, they should use what's best to teach it, not necessarily what's relevant at the time (unless it's a job school).
Lawyers aren't cool, and they make almost as much money as COBOL programmers. They even have their own schools.
Everybody should learn COBOL though. "Okay class, now we're going to learn what it is like when you only have pass-by-value, and no references. At the end of the unit we will understand why all modern languages use pass-by-reference, except for optimizing literals, and why modern COBOL programmers write all their new code in C libraries."
All browser plugins are unmitigated disasters.
Java cleaner than python? Tell me you're kidding.
It is meaningless to argue that one unless you attempt to define "clean," and then both sides will turn out to be using different meanings. Using his meaning of clean you'd probably be forced to agree with him; and using yours, he would likely agree with you.
Is boilerplate dirty, is it cruft, or is it O(1) stuff that isn't even counted and is effectively free? That is the real underlying issue. If boilerplate is cruft, then Java isn't clean. If boilerplate is free and to be ignored, then Java is still verbose, but clean.
Most people who ignore boilerplate probably are using tools that write most of it for them anyways, which brings in its own issues and differences of opinion.
Of course he totally ignores the possibility of using efficient methodologies to write large codebases using "scripting" languages. It certainly can and is done. But you can't hire Dilberts to do it, the way you can with Java. If you're planning to be undisciplined except for the what the language forces you into, then he's right.
Yeah, sorry, I maintain LARGE complex code bases. There's zero chance that's going to be easier using a loosely typed language with porous ideas of module boundaries, etc. I've been there, and a well-architected system built with a classic OO language like Java is just a lot more manageable. Also a lot of the advantages in brevity of things like Python or Perl evaporate when you try to apply some sanity to their use, but the disadvantages are still there to bite you. A 500 line Perl script is undoubtedly a LOT more compact and succinct than some java app built to do the same thing, which will be 2-3 thousand lines long probably. But when you start building well-designed class hierarchies in Perl? You're code will rapidly become just as large and verbose as its Java counterpart. Python and Ruby aren't better, in fact no scripting language will improve on this because all that stuff is NEEDED at scale. I'm an exceedingly accomplished Perl programmer and I can certainly code in other 'P languages' perfectly well, but they aren't the same thing. Each tool to its place.
"Malo periculosam, libertatem quam quietam servitutem." -- Jefferson
I've written a lot of code in the 'P languages' and I don't really believe that anymore. A 15k python app might be perfectly fine, but loose typing and the lack of a standard error handling strategy bite you in the end. I don't actually think that Perl is any weaker here than Python. You may be more familiar with one and comfortable with it, but I've written some pretty large programs in Perl. It HAS the tools, and I'm not the only one. Ruby is probably the cleanest of this sort of languages, but its still things like loose typing and the attendant inability to enforce calling semantics that hurts in all cases the most. When I write Java I know that if I call a method I have the right type of arguments at least, and that if somehow I manage to partially subvert that with reflection or whatnot that my error will be quickly outed by the run time. In dynamic languages you really don't know what the data is supposed to be until something goes wrong. Mostly though you lack the ability to have your IDE vet everything, you can't do static validation, etc. On big projects things like code validation, test coverage, etc are big deals, as is code GENERATION for that matter. All of these things are vastly better supported and easier to do in a statically typed language like Java.
"Malo periculosam, libertatem quam quietam servitutem." -- Jefferson
Back in my (pre PC) college days, COBOL was big in business but wasn't taught or used by anyone in the Computer Science department. If you wanted to learn COBOL, those courses were offered through the school of Business.
And APL was taught by the department of Mathematics, to the extent that APL packages were used in the statistics classes.
Computer science classes weren't about teaching programming languages (we probably went through a dozen or more, from Algol and assembler to Lisp and Simula and Snobol -- we were expected to learn them ourselves depending on the assignment), but about how to think about programming (and operating systems and so on).
-- Alastair
Java combines the wonderfull readability of C++ with the blazing speed of smalltalk. C# is an innovative language from Microsoft that takes those two features of Java and adds in the portability of Visual Basic.
We suffer more in our imagination than in reality. - Seneca
Duck typing is a mixed bag. You can make the requirements clearer in comments and the doc string. It also has great advantages in being more concerned with attributes than declared type or lineage. It allows modules to deal with classes that weren't even imagined when they were written.
The problem is that by an large, code can't be automatically checked against doc strings. (If it could be, then you'd just have a classic type system again.)
As far as supporting unplanned extensibility, it seems to me that interfaces (or pure virtual base classes in the case of C++) provide that functionality in more statically typed languages, so I don't see that as an advantage peculiar to duck-typing.
Java owes little to Ada. Ada has one of the most rigorous data typing systems of any programming language, but its roots are in Pascal, and thence descend to Algol.
Java's syntactic roots come from C through C++, which added OOP capabilities.
C# is somewhat of a zig-zag. In part, it's Microsoft's alternative after they were prevented from hijacking Java. In part, it's reaching back to C++. Along the way, they attempted to cure some of Java's warts.
One bit of irony. Both Java and C# are programming languages designed and "owned" by private organizations, each of which also owns at least one major OS. Java users always had a high degree of confidence that Sun would never abuse that position and attempt to use Java to lock them into Solaris. C# never enjoyed that confidence, which is why there's precious little C# work done on the non-Windows OS's.
LOL, I don't know what sort of disasterously bad Java shop you work for... I've got a VERY large Java code base. We use a number of the tools you mention and they are quite powerful and useful. There's nothing in the 'steaming mass' category about it. Perhaps you need some new developers! OTOH The last big project I did with a dynamic language became hideously complicated with constant undocumented dependency issues and bizarre almost untraceable bugs that it was finally just literally delivered by the prime contractor as it was. Luckily the whole issue became largely moot as external forces cut the project back. It IS still in use, 7 years later, but if I were to do that sort of project today I wouldn't even consider a dynamic language. Not with the schema complexity and other aspects of it as it was. Java has a vastly more powerful infrastructure for dealing with complex data for one thing.
"Malo periculosam, libertatem quam quietam servitutem." -- Jefferson
Java as a language is a pain to develop with. Java selling points have always revolved around the JVM itself and a bullet proof, over-engineered backbone that is needed for "enterprise" workloads. In big company's who don't have urgent timelines where they are willing to invest time to micro-engineer solutions it's used very heavily. For applications under heavy workloads, the high stress parts are usually built in Java for maximum efficiency but it's been the JVM, JDBC, server infrastructure and the polished library of tools around it that have buoyed it's success.
With the ability to run other languages on the JVM and get ALL those benefits without actually being required to code in Java though...now that's pretty cool. jRuby, Scala, Groovy, Clojure, etc are making the Java world a heck of a lot more interesting. If the early rumblings around the dramatic gains that jRuby is making with Java 8 are true you might just see the world implode at the idea of Java performance with Ruby development timelines. Early public benchmarks on Techempower are already looking about 30% faster than Scala.
"Don't teach a man to fish, feed yourself. He's a grown man. Fishing's not that hard." - Ron Swanson
C# never enjoyed that confidence, which is why there's precious little C# work done on the non-Windows OS's.
Well, let's be clear: it's not just because Sun had more goodwill than Microsoft.
For a start, Sun made JVMs for all major platforms. Microsoft made .Net for Windows only. They made Silverlight for Windows and Mac, granted, but never even a nod to Linux. Mono had to make its own way.
Oh, and that in Java, the 'culture' is to deliberately avoid anything non-standard or specific to any JVM. In the C# world, though, there are things like WinForms: vital parts of the 'ecosystem' which are platform-specific and non-standard.
Almost. It was designed for running untrusted code delivered via the network to set top boxes and consumer electronics. There are many things that can be said about this, and how well it translated into the world of the web, but consider what Java gave us.
The JVM is a clean bytecode virtual machine, which can be implemented in hardware and reasonably compiled to native machine code. An implementation can statically verify that the code will not misbehave in certain ways. It scales on platforms varying in size from a 1990s-era smart card to a modern cluster.
It gave us the first garbage collected language that the commercial world could handle. It gave us the first programming language which the open source world took seriously and wasn't C. It sparked a new world of research into previously neglected areas, such as JIT compilation, concurrent garbage collection, and so on. It gave us the notion of an "app" and an idea of apps could achieve in the Internet era.
Java may never have been cool, but it deserves an honoured place in the history of computer science and software engineering.
sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
Java isn't available on iOS
Yes, it is.
it isn't really available on Android
Bullshit. Android's implementation may not be completely up-to-date, but it is absolutely a version of Java. Only trademark and licensing issues prevent Google from claiming that it is.
OSX comes (used to come?) with outdated versions where a lot of Java programs don't run properly
Who cares what version is installed by default? OSX can be upgraded to the latest version, and any application that needs it ought to provide an installation package that does precisely that, or at least clear instructions to the user on how to do it.
Linux comes with OpenJDK which doesn't run quite a lot of Java programs either
As of version 8, OpenJDK is the reference implementation. Any Java program that doesn't run on OpenJDK is not a conforming pure Java application. Besides, it is perfectly possible to install Oracle Java on a Linux system if you prefer it. Depending on your distribution, it may be as simple as a single command, or you may need to add an update source first (which turns it into 3 commands on Ubuntu, for instance).
It's "cross platform" only if your definition is "it's a huge pain and doesn't work properly on any platform without extensive workarounds"
I'd hardly call any of these "extensive workarounds". Yes, you may have to refrain from using the latest APIs if you want to target certain platforms. Or you may have to have the end user install an upgrade to their preinstalled Java system. Neither of these is actually that hard.
If you're done everything on Sun Java 1.5, and suddenly Oracle changes it to "Oracle Java" 1.6, you're SOL.
??? I've been writing Java applications since 1.1 was the current version, and I've never had one stop working with a version update.
The only experience I've had with such failures are 3rd party applications where the developer has used the deprecated com.sun.* APIs. The guidelines on using these have been quite clear from the very beginning, though: don't, unless you want to create compatibility problems for your users.