Ask HN: Why does the enterprise have such a strong affinity to Java?
23 comments
Java got a couple of very important things right, at just the right time. And it tapped into some trendy / buzzwordy things at just the right time.
On the first point:
1. binary object compatibility. This was huge in a day when C++ and most other "cross platform" languages required you to ship libraries as source code, which bloated your code base and slowed down your compile times even further. Java nailed "library driven development" at a time when people were hungry for that.
2. Threading. Java's threading model is far from perfect, but it made using threads far more accessible, especially in a cross platform way, than what was previously possible in languages like C++ - especially while staying within the bounds of the language / standard library itself.
3. Garbage Collection - has it's pluses and minuses like everything, but a lot of C++ people who were tired of goofing around with manual memory management really embraced Java and it's simpler approach.
On point two above:
1. "Internet" programming. Java had good support for sockets and even basic HTTP stuff early on, and always seemed to do a decent to better-than-average job of supporting network programming (with a couple of glaring exceptions, like raw sockets)
2. "mobile code" - most people never wound up doing much with this, but it was trendy in the late 90's, early 2000's and Java was seen as a good platform for doing this stuff.
And probably some other stuff I'm forgetting. All in all, Java just did a nice job of hitting a good "sweet spot" at a good time and place. And that sweet spot was sweet enough to make it compelling, despite its warts.
On the first point:
1. binary object compatibility. This was huge in a day when C++ and most other "cross platform" languages required you to ship libraries as source code, which bloated your code base and slowed down your compile times even further. Java nailed "library driven development" at a time when people were hungry for that.
2. Threading. Java's threading model is far from perfect, but it made using threads far more accessible, especially in a cross platform way, than what was previously possible in languages like C++ - especially while staying within the bounds of the language / standard library itself.
3. Garbage Collection - has it's pluses and minuses like everything, but a lot of C++ people who were tired of goofing around with manual memory management really embraced Java and it's simpler approach.
On point two above:
1. "Internet" programming. Java had good support for sockets and even basic HTTP stuff early on, and always seemed to do a decent to better-than-average job of supporting network programming (with a couple of glaring exceptions, like raw sockets)
2. "mobile code" - most people never wound up doing much with this, but it was trendy in the late 90's, early 2000's and Java was seen as a good platform for doing this stuff.
And probably some other stuff I'm forgetting. All in all, Java just did a nice job of hitting a good "sweet spot" at a good time and place. And that sweet spot was sweet enough to make it compelling, despite its warts.
You should probably ask the question in reverse: why is Java seemingly so heavily criticised on HN when it is clearly an incredibly successful and productive platform that almost took over the whole enterprise world?
For its time Java was a god send. It solved a ridiculous number of problems that programmers today just don't even think about. We used worry about things like byte order when sending data between computers. We used to license libraries to provide basic things like lists, hashtables, string handling. Compiling things to work on multiple platforms was a nightmare, especially Windows. Developing on Windows and deploying on Unix was a pipedream. Java just swept all of this away and replaced it with a standard portable runtime that worked across Windows and Unix was free. The equivalents that offered these things (say, Perl) were not considered viable contenders at the time (dynamic languages in general did not gain a lot of trust until Ruby on Rails and PHP became so widely used - people just did not believe that you could build a large scale system with such languages and not have all fall apart if the type system wasn't rigorously checked).
For its time Java was a god send. It solved a ridiculous number of problems that programmers today just don't even think about. We used worry about things like byte order when sending data between computers. We used to license libraries to provide basic things like lists, hashtables, string handling. Compiling things to work on multiple platforms was a nightmare, especially Windows. Developing on Windows and deploying on Unix was a pipedream. Java just swept all of this away and replaced it with a standard portable runtime that worked across Windows and Unix was free. The equivalents that offered these things (say, Perl) were not considered viable contenders at the time (dynamic languages in general did not gain a lot of trust until Ruby on Rails and PHP became so widely used - people just did not believe that you could build a large scale system with such languages and not have all fall apart if the type system wasn't rigorously checked).
>We used worry about things like byte order when sending data between computers
Isn't it always just in network order?
Isn't it always just in network order?
For the containers, sure. Not for the contained messages that are opaque payload.
Java was marketed in the 1990s as a cross-platform language that was basically a better version of C++ for use on the web. Of the languages that were associated with the early web, Java was the only one with large corporate support. (Contrast to the then-dominant web language, Perl. And consider that the phrase "open source" had not yet been coined.) First from Sun, and then from other companies like IBM and Oracle that feared an all Microsoft future.
Thanks to the corporate support that went into it, Java built strong ecosystems in a number of areas. The viability of multiple strong corporate supporters made it a safe choice for any enterprise that wanted an option that was tied to the web which wasn't tied to Microsoft. This gave them a base that it never lost.
It is worth noting that Microsoft took note of this competitor, and did their standard "embrace, extend, extinguish" approach. However they got sued by Sun for adding Windows only extensions, and after they lost that, Sun was able to ensure continued consistency.
Random note. Java is far from the first portable cross-platform language to be marketed on that basis. See COBOL.
Random amusing note. While Java was marketed as being cross-platform, it used threading in a way that Solaris was designed for and competing Unix systems were not. I've never considered it coincidence that Solaris wound up soundly beating the other Unix systems in "portable Java benchmarks" and that was when it became the dominant version of Unix.
Thanks to the corporate support that went into it, Java built strong ecosystems in a number of areas. The viability of multiple strong corporate supporters made it a safe choice for any enterprise that wanted an option that was tied to the web which wasn't tied to Microsoft. This gave them a base that it never lost.
It is worth noting that Microsoft took note of this competitor, and did their standard "embrace, extend, extinguish" approach. However they got sued by Sun for adding Windows only extensions, and after they lost that, Sun was able to ensure continued consistency.
Random note. Java is far from the first portable cross-platform language to be marketed on that basis. See COBOL.
Random amusing note. While Java was marketed as being cross-platform, it used threading in a way that Solaris was designed for and competing Unix systems were not. I've never considered it coincidence that Solaris wound up soundly beating the other Unix systems in "portable Java benchmarks" and that was when it became the dominant version of Unix.
Random note. Java is far from the first portable cross-platform language to be marketed on that basis. See COBOL.
Yes, and that's why COBOL was the last big enterprise language. Java is the new COBOL. A lot of corporations hung onto COBOL through the 80s and early 90s, skipping the C/C++ wave, and going straight to Java.
Yes, and that's why COBOL was the last big enterprise language. Java is the new COBOL. A lot of corporations hung onto COBOL through the 80s and early 90s, skipping the C/C++ wave, and going straight to Java.
Can you talk more about Solaris threading and how it was leveraged by the JVM? I'm interested. Or if you have a link.
Basically Solaris was the first Unix to make it cheap to have lots and lots of threads constantly being spawned and destroyed. But this optimization did them no good with existing C and C++ programs which didn't use the feature. But with Java it did. And even more in the early days when all I/O was blocking so you had no choice about spawning new threads at every turn.
In the defense of competing systems, the POSIX standard for threads was released in 1995 and Java was released in 1996. So they can hardly be blamed for not having optimized for that then uncommon use case. But by the time they fixed that, Solaris had already taken a solid market lead. Which helped Sun become "the dot in dot com".
In the defense of competing systems, the POSIX standard for threads was released in 1995 and Java was released in 1996. So they can hardly be blamed for not having optimized for that then uncommon use case. But by the time they fixed that, Solaris had already taken a solid market lead. Which helped Sun become "the dot in dot com".
>> It is worth noting that Microsoft took note of this competitor, and did their standard "embrace, extend, extinguish" approach
That was gold. Thank you for that.
Based on your answer, seems like there was an extremely close alliance between the big corps (sans MSFT) and the early Java dev team; I'm tempted to think that the creators (Gosling et al) could have taken cues from Java's corporate supporters to factor in designs that help address problems that those companies were facing. This really helps tie in how the Java "ecosystem" came to being because right from the beginning it seems like it was trying to solve "enterprisey" problems. Is that a fair assumption?
That was gold. Thank you for that.
Based on your answer, seems like there was an extremely close alliance between the big corps (sans MSFT) and the early Java dev team; I'm tempted to think that the creators (Gosling et al) could have taken cues from Java's corporate supporters to factor in designs that help address problems that those companies were facing. This really helps tie in how the Java "ecosystem" came to being because right from the beginning it seems like it was trying to solve "enterprisey" problems. Is that a fair assumption?
In the really early days of Java, there wasn't: it started out as part of small-team project aimed at embedded systems, then set-top boxes http://www.blinkenlights.com/classiccmp/javaorigin.html . By the time work started on the specification, about 1995-6, Sun was soliciting feedback from a wider base of people http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/m... http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/m... http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/m... . Even by '96 I think everyone was still mostly thinking of Java as a client-side Web and OS-native application language, though: it wasn't until later that it began to be strongly associated with server-side programming and "enterprisiness".
This is true. But at the point where Java broke out, there were a lot of big businesses behind it.
For instance even though Java 1.0 was released in 1996, IBM got on board in 1995 and by the start of 1997 had contributed good internationalization. (See http://www.icu-project.org/docs/papers/history_of_java_inter... for a reference.) By late 1997 when I became a software developer, there was already a feeling that Java was "the official corporate future of the web". (At least by those who didn't expect Microsoft to take over the world.) But in the meantime would I mind learning Perl and CGI to teach my co-workers how to get small stuff done?
I never looked back. :-)
ADDITION: See http://articles.chicagotribune.com/1998-09-11/news/990112009... for an early timeline. Note the many, many corporate licensees very early in the process.
The truth is that everyone was deathly afraid that Microsoft would destroy the industry. The web was seen as a godsend, and the fact that Java wound up tied to the web by Netscape right at the beginning meant that everyone jumped on Java with the web. By the time the dust settled, you had a ton of big corporations involved, and it was guaranteed at that point that the language would evolve to suit their needs.
For instance even though Java 1.0 was released in 1996, IBM got on board in 1995 and by the start of 1997 had contributed good internationalization. (See http://www.icu-project.org/docs/papers/history_of_java_inter... for a reference.) By late 1997 when I became a software developer, there was already a feeling that Java was "the official corporate future of the web". (At least by those who didn't expect Microsoft to take over the world.) But in the meantime would I mind learning Perl and CGI to teach my co-workers how to get small stuff done?
I never looked back. :-)
ADDITION: See http://articles.chicagotribune.com/1998-09-11/news/990112009... for an early timeline. Note the many, many corporate licensees very early in the process.
The truth is that everyone was deathly afraid that Microsoft would destroy the industry. The web was seen as a godsend, and the fact that Java wound up tied to the web by Netscape right at the beginning meant that everyone jumped on Java with the web. By the time the dust settled, you had a ton of big corporations involved, and it was guaranteed at that point that the language would evolve to suit their needs.
Yup -- I was taking intro & mid-level CS courses in 1996/7, and they set us up to code in Java (with an IDE called Roaster) as the "wave of the future", and easier to work with than C or C++ (though we used C for some classes).
We were mostly writing applications, applets, and command-line stuff, and my first server-side code was in a long-forgotten CGI-based scripting language, but I seem to recall it wasn't too long after that that ColdFusion was re-written into Java (so that even if you build your site in CF, it was actually executing on Java); that was a pretty strong corporate & technical endorsement.
We were mostly writing applications, applets, and command-line stuff, and my first server-side code was in a long-forgotten CGI-based scripting language, but I seem to recall it wasn't too long after that that ColdFusion was re-written into Java (so that even if you build your site in CF, it was actually executing on Java); that was a pretty strong corporate & technical endorsement.
I would say that is true. Furthermore the Sun team had the advantage of starting with a group of people who had done extensive work on Smalltalk. This gave them both specific technical advantages, such as state of the art experience in JIT optimization, and the general advantage of starting with better OO design experience than was widely available.
The impact of corporate support can't be understated. Corporations love to buy support, meaning, have someone they can blame when things go awry, and charge if they're not fixed on time. Usually, it's little more than a security blanket, but that blanket helps the C-levels sleep at night.
The support aspect isn't about blame. As a corporate customer, I want to know that if I build my operation to depend on a third party product (ERP, etc) that somebody will be there to help in the event that it becomes problematic. In many cases, buying support coverage is much cheaper than having product experts on staff to address unusual but costly issues.
A product that comes with support necessarily implies that when something goes wrong, the product can be blamed and the vendor can be leaned on for "support" to fix it. So while the support aspect itself may not be about blame it is bundled into that line of thought.
IBM adopted Java early on as a client side development technology to be used in client/server computing that was so prevalent in the 90s. IBM also had a lot of their customers rebuilding 20-30 year old applications in Java to address Y2K issues. IBM supports Java running on their zSeries and pSeries systems. IBM supports Java applications using JMS over MQSeries to interoperate with legacy applications and supports Java accessing DB2 databases. IBM even has tools to allow COBOL copybooks to be exposed as web services, which Java can then easily consume. There's still a ton of legacy COBOL applications and thanks to IBM, Java can interoperate with that legacy code and extend its functionality.
And it's not all about IBM either. Obviously Oracle, another enterprise favorite, is playing in the Java space these days and provide an application server, WebLogic, along with great support for accessing Oracle's RDBMs from Java. Oracle also has several industry vertical solutions all based on Java.
Finally there's Red Hat. Lots of enterprises run RHEL when running a Linux server and their JBoss application server is highly regarded.
Java then offers enterprises a lot of flexibility. There's multiple vendors from which they can choose to procure application servers, there's little risk of platform lock-in, they can fully interoperate with legacy applications and there's a ton of reasonable cost developers available - who are mostly happy with a language that's fairly modern. There's actually quite a bit for an enterprise to like about Java.
And it's not all about IBM either. Obviously Oracle, another enterprise favorite, is playing in the Java space these days and provide an application server, WebLogic, along with great support for accessing Oracle's RDBMs from Java. Oracle also has several industry vertical solutions all based on Java.
Finally there's Red Hat. Lots of enterprises run RHEL when running a Linux server and their JBoss application server is highly regarded.
Java then offers enterprises a lot of flexibility. There's multiple vendors from which they can choose to procure application servers, there's little risk of platform lock-in, they can fully interoperate with legacy applications and there's a ton of reasonable cost developers available - who are mostly happy with a language that's fairly modern. There's actually quite a bit for an enterprise to like about Java.
Great point about the y2k but. My aunt was a systems engineer at CSX and was one of the people that led their Y2K group (partially because she was one of the only people they had employed that was still expertly proficient in COBOL) and a lot of what she did, in addition to fixing the COBOL bits, was rewrite stuff in Java and build out Java connectors.
It's funny, I remember learning J++ in 1998 when I was like 15, around the same time she was knee-deep in the y2k thing. And we would email an call one another commiserating, because she was learning Java too (albeit at a much higher level and with real stakes).
As shitty as Java is for a lot of things, it is a godsend for dealing with legacy apps and code. And the thing is, those legacy systems are some of the most important systems around (banking, transpiration, health care records, major utilities like water and power, etc).
If I ever need to give myself nightmares, I just start to contemplate the infrastructure of our most important entities.
It's funny, I remember learning J++ in 1998 when I was like 15, around the same time she was knee-deep in the y2k thing. And we would email an call one another commiserating, because she was learning Java too (albeit at a much higher level and with real stakes).
As shitty as Java is for a lot of things, it is a godsend for dealing with legacy apps and code. And the thing is, those legacy systems are some of the most important systems around (banking, transpiration, health care records, major utilities like water and power, etc).
If I ever need to give myself nightmares, I just start to contemplate the infrastructure of our most important entities.
We could pretend that this is all about the incredibly unique properties of Java and "what it got right." But that isn't really true. It's just wrong to frame the question as "what was special about Java" let alone "what can I do with language x to duplicate its success?"
As of today, the reason is it's old and established and a safe choice, everyone knows about it, and everyone else uses it, and so many people write it, and there's so much existing code in it. Even if it sucks for some purpose, that's what you pay Java developers for.
The story of how it got there is again not about the incredible unique properties of Java but about the decisions of large companies in the contexts of the 90s, both in adopting and contributing to the development of Java.
Those decisions had a broad political and business context, and insofar as they had anything to do with the language itself that would have been in comparison to what were perceived to be the serious languages of the time, like COBOL or C++.
As of today, the reason is it's old and established and a safe choice, everyone knows about it, and everyone else uses it, and so many people write it, and there's so much existing code in it. Even if it sucks for some purpose, that's what you pay Java developers for.
The story of how it got there is again not about the incredible unique properties of Java but about the decisions of large companies in the contexts of the 90s, both in adopting and contributing to the development of Java.
Those decisions had a broad political and business context, and insofar as they had anything to do with the language itself that would have been in comparison to what were perceived to be the serious languages of the time, like COBOL or C++.
I found this comment very insightful. It may not fit everybody's worldview, but that's no reason to downvote, right?
I can give you some sense of why I use Java and enjoy it today in an "enterprise" setting. The JVM is excellent. Java 8 in particular is quite fun to use, streams in particular. The tool support isn't quite there yet for all of Java 8, however. In recent versions the concurrency APIs are quite diverse and easy to use (as much as multithreaded programming can be). There are also lots of good libraries -- Guava, Guice, and jOOQ to name a few. Java is also quite fast -- it's consistently outperformed by C and C++ but it's still competitive and much easier to write.
Faster than Python
Easier to avoid mistakes than C/C++
Easy to break into component parts that can be maintained separately
Don't have to worry about handling memory
Works the same on Windows, Linux, X86, ARM, etc. so your developers can be working on OS X and deploying on BSD for all you care
Static typing (remarkably important when you've got a team of 30 working on a large codebase)
Easier to avoid mistakes than C/C++
Easy to break into component parts that can be maintained separately
Don't have to worry about handling memory
Works the same on Windows, Linux, X86, ARM, etc. so your developers can be working on OS X and deploying on BSD for all you care
Static typing (remarkably important when you've got a team of 30 working on a large codebase)
The "it's impossible/unmaintainable to develop a huge/enterprise codebase in a dynamically typed language" meme is really sad here on HN, specially for some one who works/maintains a huge/enterprise codebase in a dynamically typed language with a big team and have no problems at all.
Anyway I agree static typing was a big plus for java for the sole reason many people believe dynamic languages are just for scripts and small hacks.
Anyway I agree static typing was a big plus for java for the sole reason many people believe dynamic languages are just for scripts and small hacks.
Team of 30? Team of 3000!
Everyone seems to have covered the "dumbed down language" perspective. And there's definitely truth to that. Enterprises hire tons of developers, but Enterprises are terrible at determining which candidates are good developers. So there are a lot of mediocre ones.
However, there is another side of the coin that must be acknowledged. When Java came out, there was no Python or Ruby. Java let you be enormously more productive than C++ for apps for which garbage collection was fine. The VM offered features which weren't common, like reflection. Of course, Java came with a huge library. Java was a great option for a JFDI (Just Fucking Do It) language, and there weren't a lot of other options back then.
This doesn't solve the whole mystery. Why didn't SmallTalk or some other options that were available at the time do better? I don't really know. Java just took off like a rocket, in the same way that pet rocks and hula hoops did. There were some good reasons, but those reasons can't explain the whole phenomenon. And now, after that adoption tsunami is complete, Java is the safe, established (but boring, mediocre) answer that Enterprises like.
However, there is another side of the coin that must be acknowledged. When Java came out, there was no Python or Ruby. Java let you be enormously more productive than C++ for apps for which garbage collection was fine. The VM offered features which weren't common, like reflection. Of course, Java came with a huge library. Java was a great option for a JFDI (Just Fucking Do It) language, and there weren't a lot of other options back then.
This doesn't solve the whole mystery. Why didn't SmallTalk or some other options that were available at the time do better? I don't really know. Java just took off like a rocket, in the same way that pet rocks and hula hoops did. There were some good reasons, but those reasons can't explain the whole phenomenon. And now, after that adoption tsunami is complete, Java is the safe, established (but boring, mediocre) answer that Enterprises like.
Why didn't SmallTalk or some other options that were available at the time do better?
Smalltalk was expensive (VisualAge, VisualWorks, for example) and wanted to own the world (image-based). With the web suddenly solving all deployment problems everywhere (at least, that was the rhetoric), paying thousands of dollars per developer for tools seemed silly.
Smalltalk was expensive (VisualAge, VisualWorks, for example) and wanted to own the world (image-based). With the web suddenly solving all deployment problems everywhere (at least, that was the rhetoric), paying thousands of dollars per developer for tools seemed silly.
Sigh. I thought it would be obvious to people that I was speaking of traction. Ruby and Python were not viable Enterprise options back then. And even if someone claims they were, they did not have that perception.
Yes, I could've been more precise in my wording. But a lot of people could be less pedantic too. I already interact with a compiler all day long. Didn't think I was talking to a bunch of compilers here too.
Yes, I could've been more precise in my wording. But a lot of people could be less pedantic too. I already interact with a compiler all day long. Didn't think I was talking to a bunch of compilers here too.
When Java came out, there was no Python or Ruby.
Python is four years older than Java. When the latter was released, Python was already at 1.0.
Python is four years older than Java. When the latter was released, Python was already at 1.0.
Traction, of course. Perl and TCL were far more popular when Java was exploding.
Both Python (1991) and Ruby (1995) existed at the same time Java (1995) was coming to the market.
And both could as well not exist at all as far as adoption was concerned. Nobody used Python before around '97, and nobody used Ruby before 2000. Well, some did, but very small amounts of "some".
- it is stable (both the language spec and the JVM)
- new versions are backward-compatible
- the language is simple therefore easy task are easy (junior devs can slowly get up to speed)
- it still has a lot of momentum (momentum = a new corporate project is easy to start in Java)
- there's been a lot of experience accumulated throughout the last two decades
All in all, it's good enough and it does not really have any glaring flaws.
All in all, it's good enough and it does not really have any glaring flaws.
People are overrating language features I believe. The thing Sun did really well was marketing. They didn't go only to the core "tech" people in the enterprise: they reached _everybody_, and made it look like every company had to "move" to Java because it was the "future" even if few people understood what it was. Soon there were CEOs and CFOs and whatever talking on Bloomberg (or whatever) about how they were "moving" to Java.
For whatever reason IBM also jumped on that ship, and Oracle, and HP, and even Microsoft (albeit reluctantly) so "nobody ever got fired for choosing Java" became a reality.
Now that Java has been around for a long time we tend to forget this, but people couldn't even define what they were talking about back then - was it a language? JEE? A runtime environment? But they sure as hell were moving to Java.
Same as this "Internet" thing really.
For whatever reason IBM also jumped on that ship, and Oracle, and HP, and even Microsoft (albeit reluctantly) so "nobody ever got fired for choosing Java" became a reality.
Now that Java has been around for a long time we tend to forget this, but people couldn't even define what they were talking about back then - was it a language? JEE? A runtime environment? But they sure as hell were moving to Java.
Same as this "Internet" thing really.
And of course "JavaScript". A moment's reflection tells you all you need to know about Java's unique combination of ambiguity and marketing power in the mid/late 90s.
Ask yourself: What other language could those enterprise projects have used?
Of course there's the whole C/C++ world, but people were starting to realize that managing memory can be a pain, and that text-based preprocessors can be a pain too. In comparison, Java seemed easier.
Fortran was known to be good for numerical applications, but had a bad reputation for everything else.
Pascal? COBOL? really??
(Actually I don't know why people didn't consider Pascal more seriously; maybe it lacked corporate backing?)
Of course there were scripting languages, but big corps are conservative, so it had to be statically type-checked.
Many other languages came later, or weren't seen as mature enough back then (C#, Haskell).
Java, OTOH, had a few pluses: static typing, OO, easy to learn (because it was a small language, and had similar syntax to C/C++), and a very well-documented standard library.
Of course there's the whole C/C++ world, but people were starting to realize that managing memory can be a pain, and that text-based preprocessors can be a pain too. In comparison, Java seemed easier.
Fortran was known to be good for numerical applications, but had a bad reputation for everything else.
Pascal? COBOL? really??
(Actually I don't know why people didn't consider Pascal more seriously; maybe it lacked corporate backing?)
Of course there were scripting languages, but big corps are conservative, so it had to be statically type-checked.
Many other languages came later, or weren't seen as mature enough back then (C#, Haskell).
Java, OTOH, had a few pluses: static typing, OO, easy to learn (because it was a small language, and had similar syntax to C/C++), and a very well-documented standard library.
Delphi could of been a competitor, but there's barely any books on it. Also it was way too Windows centered, they should of invested in other platforms. I'm surprised they never bought out FreePascal and developed both a free and open source version of Delphi and a commercial version of it. Oh well. I really don't like some things about Java, but that's because I'm spoiled by C#.
I work at a programming lab as a assistant or tutor to students, I usually find myself helping people with Java the most, and it's not my strongest language, but I still manage to figure out my way around it.
I work at a programming lab as a assistant or tutor to students, I usually find myself helping people with Java the most, and it's not my strongest language, but I still manage to figure out my way around it.
Other way to say the same on the answers on this thread:
Because MS own the enterprise/market and more exactly, the market for developers. So, apart of MS, what was left? C/C++?
Back in the days, the push of MS for developers was huge. Even in a latin america country (where I live) the MS conferences in a secondary city were huge. Everyone meet there. Even the people that do mainframes, netware, and be part of other communities like delphi, sybase. etc.
So, Java was the first concerted effort that intent to do the same. IBM/SUN/Others start to push for the community (because: How take of C/C++? Nobody). It start to show some kind of documentation, books, examples, etc. And provide a alternative, like everyone else explain here.
In short: Java explode because try harder to be the pepsi of the MS coca-cola.
Because MS own the enterprise/market and more exactly, the market for developers. So, apart of MS, what was left? C/C++?
Back in the days, the push of MS for developers was huge. Even in a latin america country (where I live) the MS conferences in a secondary city were huge. Everyone meet there. Even the people that do mainframes, netware, and be part of other communities like delphi, sybase. etc.
So, Java was the first concerted effort that intent to do the same. IBM/SUN/Others start to push for the community (because: How take of C/C++? Nobody). It start to show some kind of documentation, books, examples, etc. And provide a alternative, like everyone else explain here.
In short: Java explode because try harder to be the pepsi of the MS coca-cola.
The "dumb-proof" bit is from people that themselves are not strong in CS, typically... It's just snark as you say.
There was incredible demand for something like Java, gigantic efforts were put in to place to standardize the many different UNIX like OSes but apps were still incompatible. ANDF was an effort by the OpenGroup, I'm not aware of any real implementations of it. The big powers, save for MS, all wanted to build platforms where vendors could write applications that could run. Then along comes Java, it has all the modern bits in a language that people deemed needed at the time, there were plans for performance, it was fairly easy to implement a VM, it had a robust library, C-inspired syntax (Pascal vs C might have been the last big war before Java,) it had real binary compatibility. Sun, IBM, Oracle, just about every major company backed it, even MS sort of did. The performance got better, etc.. When the whole industry buys in to something, it'd have been amazing if it didn't get adopted. Then compared to C++ or C, the productivity gains were (and still are) staggering, GC and real stack traces are manna from the gods at the time.
Fast-forward to now, it's still got top shelf managed language performance, the tooling is maybe only matched by MS's tools. The counter question I'd ask, what has come up lately that could possibly replace Java? There are some interesting JVM languages, the CS dork in me would love for Scala to take off more but not for any qualitative reason that I could point to to say it's really better; I'm a functional believer but I'd estimate that less than 3% of the code written in any language anywhere is functional. Rust and Go are neat, but if you look at the whole picture, I don't think there is anything close to providing what Java does that would justify replacing it; save for possibly .net but then you lose the compatibility which was one of the primary desires from the start. I'd think something would have to outdo java or the game would have to change pretty dramatically and enterprises would start needing different kinds of software and I don't see that happening any time soon.
How many major technologies get replaced with nothing?
There was incredible demand for something like Java, gigantic efforts were put in to place to standardize the many different UNIX like OSes but apps were still incompatible. ANDF was an effort by the OpenGroup, I'm not aware of any real implementations of it. The big powers, save for MS, all wanted to build platforms where vendors could write applications that could run. Then along comes Java, it has all the modern bits in a language that people deemed needed at the time, there were plans for performance, it was fairly easy to implement a VM, it had a robust library, C-inspired syntax (Pascal vs C might have been the last big war before Java,) it had real binary compatibility. Sun, IBM, Oracle, just about every major company backed it, even MS sort of did. The performance got better, etc.. When the whole industry buys in to something, it'd have been amazing if it didn't get adopted. Then compared to C++ or C, the productivity gains were (and still are) staggering, GC and real stack traces are manna from the gods at the time.
Fast-forward to now, it's still got top shelf managed language performance, the tooling is maybe only matched by MS's tools. The counter question I'd ask, what has come up lately that could possibly replace Java? There are some interesting JVM languages, the CS dork in me would love for Scala to take off more but not for any qualitative reason that I could point to to say it's really better; I'm a functional believer but I'd estimate that less than 3% of the code written in any language anywhere is functional. Rust and Go are neat, but if you look at the whole picture, I don't think there is anything close to providing what Java does that would justify replacing it; save for possibly .net but then you lose the compatibility which was one of the primary desires from the start. I'd think something would have to outdo java or the game would have to change pretty dramatically and enterprises would start needing different kinds of software and I don't see that happening any time soon.
How many major technologies get replaced with nothing?
Java 1.0 and 1.1 were mainly targeted at browser applets. Applets were maybe a bit before their time as the download speed was slow and there were issues with downloading the JVM. The JVM was a really big download for the time, with many users still on dialup or maybe slow DSL. You could never rely on which particular JVM the user had, and this was a cause of compatibility problems. At the time windows was almost completely dominant as an end user operating system. And as others have said Microsoft's embrace, extend, extinguish didn't help. Microsoft came out with a relatively decent IDE for java, but then started pushing a technology I think they called J/Direct that let you make windows system calls directly from Java, which was kind of useful, but also completely tied you in to windows.
The enterprise/server usage of Java really took off with JDK 1.2, AKA Java 2 Enterprise Edition. Sun and also IBM put a lot of effort into promoting this version of Java. It coincided with the dot-com boom, every company suddenly needed web applications, and Java was the best way to build them. All the popular programming books from O'Reilly and others were about various Java related technologies, and I guess all the good jobs were working in Java. IBM did a 'World Tour' promoting Java and even produced/produces their own Java runtime (based on Sun's version).
Windows was the standard desktop operating system in corporates, and it was a real advantage that developers could develop locally on windows and then deploy on a Sun/IBM/HP server.
Java application servers became a thing. Sun bought NetDynamics, one of the first application servers. Basically an application server gave you all the needed structure and plumbing to build your enterprise application, whereas often in earlier projects developers built this all from scratch.
Java was designed to make code reuse easier, libraries could be packaged into jars and due to the language's consistency it was easier to combine code from others than it is in languages like C/C++. A lot of the tools you needed to build internet apps were built first (or only) for Java. Things like crypto libraries, SOAP tools, XML, XSLT, all the new stuff at the time.
UML became a popular standard for design documentation at the same time too, and java was well suited to building UML based designs. UML came about by merging many of the leading OO design methodologies of the time to create one overall standard. It combined the methodologies of many of the leading OO proponents of the time, including Grady Booch, Ivar Jacobson, and James Rumbaugh. There were a number of good UML tools, starting with Rational Rose (purchased by IBM) that really suited designing enterprise systems and then realising them in Java. Java was useful here because of its consistent object-orientedness.
It was also accepted wisdom at the time that you could hire a team of average developers and they could produce decent Java code, you couldn't rely on the same result from C++ where there were many more ways to shoot yourself in the foot. It also helped that at the same time there were huge numbers of Indian developers entering the job market at reasonable pay rates.
Java quickly became the standard, using anything else was either risky due to lack of support, didn't have the libraries or tool support, or maybe didn't have a large enough base of skilled developers available. So Java was the safe choice.
The enterprise/server usage of Java really took off with JDK 1.2, AKA Java 2 Enterprise Edition. Sun and also IBM put a lot of effort into promoting this version of Java. It coincided with the dot-com boom, every company suddenly needed web applications, and Java was the best way to build them. All the popular programming books from O'Reilly and others were about various Java related technologies, and I guess all the good jobs were working in Java. IBM did a 'World Tour' promoting Java and even produced/produces their own Java runtime (based on Sun's version).
Windows was the standard desktop operating system in corporates, and it was a real advantage that developers could develop locally on windows and then deploy on a Sun/IBM/HP server.
Java application servers became a thing. Sun bought NetDynamics, one of the first application servers. Basically an application server gave you all the needed structure and plumbing to build your enterprise application, whereas often in earlier projects developers built this all from scratch.
Java was designed to make code reuse easier, libraries could be packaged into jars and due to the language's consistency it was easier to combine code from others than it is in languages like C/C++. A lot of the tools you needed to build internet apps were built first (or only) for Java. Things like crypto libraries, SOAP tools, XML, XSLT, all the new stuff at the time.
UML became a popular standard for design documentation at the same time too, and java was well suited to building UML based designs. UML came about by merging many of the leading OO design methodologies of the time to create one overall standard. It combined the methodologies of many of the leading OO proponents of the time, including Grady Booch, Ivar Jacobson, and James Rumbaugh. There were a number of good UML tools, starting with Rational Rose (purchased by IBM) that really suited designing enterprise systems and then realising them in Java. Java was useful here because of its consistent object-orientedness.
It was also accepted wisdom at the time that you could hire a team of average developers and they could produce decent Java code, you couldn't rely on the same result from C++ where there were many more ways to shoot yourself in the foot. It also helped that at the same time there were huge numbers of Indian developers entering the job market at reasonable pay rates.
Java quickly became the standard, using anything else was either risky due to lack of support, didn't have the libraries or tool support, or maybe didn't have a large enough base of skilled developers available. So Java was the safe choice.
Windows was the standard desktop operating system in corporates, and it was a real advantage that developers could develop locally on windows and then deploy on a Sun/IBM/HP server.
This is a pretty big factor, that it's actually portable. Develop on Windows workstations, deploy to either Windows or UNIX servers without changing anything. Thats just not possible with C/C++. Difficult to even do with Ruby or Python.
Also, the class-based OOP design and interfaces make it easy for many programmers to work on little compartmentalized parts of the same massive system. And of course it lacks the dangerous features of a language like C++. Everything is an object with attributes and methods, and the objects can have a hierarchy. It's an abstraction that's pretty easy to understand conceptually without much CS knowledge, and it's easy to model business processes with it, so managers like it.
This is a pretty big factor, that it's actually portable. Develop on Windows workstations, deploy to either Windows or UNIX servers without changing anything. Thats just not possible with C/C++. Difficult to even do with Ruby or Python.
Also, the class-based OOP design and interfaces make it easy for many programmers to work on little compartmentalized parts of the same massive system. And of course it lacks the dangerous features of a language like C++. Everything is an object with attributes and methods, and the objects can have a hierarchy. It's an abstraction that's pretty easy to understand conceptually without much CS knowledge, and it's easy to model business processes with it, so managers like it.
I don't know about Ruby, but can you please elaborate about Python? I'd argue that non-cross platform Python code is actually quite uncommon.
There are of course OS-specific features that can be bound to Python code, but those can be bound to Java code as well.
There are of course OS-specific features that can be bound to Python code, but those can be bound to Java code as well.
Getting the development environment set up on Windows can be a pain. Trying to build an existing project that was developed on UNIX, you have to replace any shell scripts, make sure your Windows Path variable is right, set up a new virtualenv, etc. But the biggest problem isn't the Python code, it's compiling the libraries that are written in C/C++, Fortran, etc. It can be a struggle to get some of those to compile on Windows, and they do not support Cygwin either.
I landed at a large bank in 2000 just as J2EE was exploding onto the scene. Looking back it was the app servers that mattered more than the language (though the language made the app servers possible).
BEA Weblogic was particularly popular. Its text (later XML) based configuration made it easy to get going (more so than IBM's competing WebSphere, where somebody had been too clever and used entity beans for config, so you needed to work with a DBA just to get started).
Weblogic also came with really good samples and examples, which covered pretty much all of the useful areas of the J2EE frameworks. Just about every app that made it to production started out with the sample code and got modified until it was doing what was needed.
There were of course other app servers. Cold Fusion had a loyal following for a while, but never escaped out of web apps and into line of business apps.
The move of J2EE and accompanying app serves from web to line of business (starting in the back office) was mostly down to productivity and skills. The main alternative was generally C++, which was viewed as harder to do and harder to hire for. There were of course many arguments over performance, but eventually the JVM got plenty fast enough and people learned to avoid the 'Bitter Java' anti patterns.
BEA Weblogic was particularly popular. Its text (later XML) based configuration made it easy to get going (more so than IBM's competing WebSphere, where somebody had been too clever and used entity beans for config, so you needed to work with a DBA just to get started).
Weblogic also came with really good samples and examples, which covered pretty much all of the useful areas of the J2EE frameworks. Just about every app that made it to production started out with the sample code and got modified until it was doing what was needed.
There were of course other app servers. Cold Fusion had a loyal following for a while, but never escaped out of web apps and into line of business apps.
The move of J2EE and accompanying app serves from web to line of business (starting in the back office) was mostly down to productivity and skills. The main alternative was generally C++, which was viewed as harder to do and harder to hire for. There were of course many arguments over performance, but eventually the JVM got plenty fast enough and people learned to avoid the 'Bitter Java' anti patterns.
I don't know if I'm phrasing this in a calm, reasonable way, but your "snarky" reason has a lot to do with it. Not only was Java (pitched as) fool-proof (garbage collection!), managers really really did think that invoking "object oriented" like a magic word would help. I think that being able to develop on Windows NT (early 2000s context, right?) and run on something bigger was also a help.
I think that being able to develop on Windows NT (early 2000s context, right?) and run on something bigger was also a help.
Indeed. The company I was working for from 2000-2004 started down the Java path about 2000 (part of the reason I was hired, I guess) and one of the things people loved about Java early on was how you could program and build your code on a Windows box, then sftp the jar to an AIX box, and run it there unchanged.
"Write once, run anywhere" might not have worked out perfectly, but it was actually pretty good, especially if you were doing server-side stuff and avoided Swing and AWT.
Indeed. The company I was working for from 2000-2004 started down the Java path about 2000 (part of the reason I was hired, I guess) and one of the things people loved about Java early on was how you could program and build your code on a Windows box, then sftp the jar to an AIX box, and run it there unchanged.
"Write once, run anywhere" might not have worked out perfectly, but it was actually pretty good, especially if you were doing server-side stuff and avoided Swing and AWT.
About 10 years ago, at a Q&A session with the almost-CTO of a Fortune 100 enterprise:
carlsborg: how much java does your company use compared to c++, and where do you see that going? cto: we're at about 50% java - 50% c++, and we want to go to 90-10 carlsborg: why? cto: its costs less to do it in java
(While this math might not hold true today, at the time it did - java 1.4 was relatively easy to master in its entirety, and universities were adopting it as the de facto programming language)
I think what he meant was that it cost less to develop java applications compared to C++ ones, in the fairly common situation where you didn't need the low level power and performance of C++.
Personally, I think what helped adoption was the boatloads of high quality middleware, multiple vendor support, and a relatively fast moving and open standards process. The latter playing an important role - when a language/technology stack stagnates, early adopters tend to go elsewhere looking for an "edge" and take their allegiance with them.
carlsborg: how much java does your company use compared to c++, and where do you see that going? cto: we're at about 50% java - 50% c++, and we want to go to 90-10 carlsborg: why? cto: its costs less to do it in java
(While this math might not hold true today, at the time it did - java 1.4 was relatively easy to master in its entirety, and universities were adopting it as the de facto programming language)
I think what he meant was that it cost less to develop java applications compared to C++ ones, in the fairly common situation where you didn't need the low level power and performance of C++.
Personally, I think what helped adoption was the boatloads of high quality middleware, multiple vendor support, and a relatively fast moving and open standards process. The latter playing an important role - when a language/technology stack stagnates, early adopters tend to go elsewhere looking for an "edge" and take their allegiance with them.
I think it is simply economics. Its the new Cobol, lots of lines of code to maintain, lots of developers know Java, so the cost of maintenance can be kept low. So when you build something new, the developers want to use Java because that is what they know and all the tools they have invested in are Java based.
You've captured a very fundamental perspective here since the time spent on maintaining software is significantly more than building it (not sure what the Fred Brooks percentage is but I would guess 80/20 for the larger orgs).
Do you know of any small companies that grew to a point and said "Well, we've got a hiring bottleneck since there are much fewer good Python devs out there. So let's migrate to Java which will then pay dividends over the years since the cost of maintenance will be low."
Do you know of any small companies that grew to a point and said "Well, we've got a hiring bottleneck since there are much fewer good Python devs out there. So let's migrate to Java which will then pay dividends over the years since the cost of maintenance will be low."
A company I worked at was a Perl shop (online academic publishing) but we found it almost impossible to recruit anyone who had even the smallest of skills in it.
At the same time the colleges and universities were churning out Java trained graduates that you could scoop up for a dime a dozen.
Java devs were cheap and as long as you believed that all you had to do was throw more bodies at the problem then you were in a sweet spot.
Having said that the company is still going strong and doing very well thank you.
What it comes down to, and I suspect that this is especially true for large companies, is that if you need a lot of programmers then there are far more Java candidates available that you can hire. They are cheap and replaceable.
Any other language, even hot languages like Python and Ruby, are harder to recruit in numbers and consequently more expensive and harder to replace.
Not sure where PHP figures in all this :)
At the same time the colleges and universities were churning out Java trained graduates that you could scoop up for a dime a dozen.
Java devs were cheap and as long as you believed that all you had to do was throw more bodies at the problem then you were in a sweet spot.
Having said that the company is still going strong and doing very well thank you.
What it comes down to, and I suspect that this is especially true for large companies, is that if you need a lot of programmers then there are far more Java candidates available that you can hire. They are cheap and replaceable.
Any other language, even hot languages like Python and Ruby, are harder to recruit in numbers and consequently more expensive and harder to replace.
Not sure where PHP figures in all this :)
From Python? Not off of the top of my head.
But Amazon, eBay and Citysearch are examples of companies that started with Perl and then made such transitions to Java/C++. (With an exact mix and history that varies. For instance I believe that Amazon still uses all three, while eBay went from Perl to C++ to Java in complete rewrites.)
But Amazon, eBay and Citysearch are examples of companies that started with Perl and then made such transitions to Java/C++. (With an exact mix and history that varies. For instance I believe that Amazon still uses all three, while eBay went from Perl to C++ to Java in complete rewrites.)
This definitely seems like a cyclical thing. I'm aware that PayPal (owned by eBay) also went through a rewrite from C++ to Java over the last couple of years for its mid-tier web service stack (most but not all). The funny thing is that some of the services that never made it to the Java rewrite are now being considered to be rewritten in Scala.
You can write background, web, and desktop apps with Java. It is statically compiled and works very well.
I use C# for all the same reasons. Versatile, good tool set and does everything I need.
I use C# for all the same reasons. Versatile, good tool set and does everything I need.
Influence in the enterprise you have to look at the large consultants and integrators as bigco IT is taking their direction from them. IBM made Java the base technology of their stack in the late 90s and that's the primary reason. I would note that MS is extremely widespread as well as windows server, ad, mssql and dot net are prevalent, even more so as you get into the Smb market.
Others have elaborated on historical reasons that made Java popular with the enterprise and correctly noted that the size of the existing codebase and amount of trained developers alone gives Java enough momentum to perpetuate long into the future.
However, on a different level there's a reason why people prefer Java and don't push for alternative languages. Namely, a program that would have 200 LoC in C could be re-written (assuming that you are using the right set of enterprise tools/frameworks) as a 2000 LoC program in Java. And, if you ever worked in enterprise, you know how useful that is. Think of the need to grow the development team, job security, fulfilling arbitrary goals set by the management etc.
However, on a different level there's a reason why people prefer Java and don't push for alternative languages. Namely, a program that would have 200 LoC in C could be re-written (assuming that you are using the right set of enterprise tools/frameworks) as a 2000 LoC program in Java. And, if you ever worked in enterprise, you know how useful that is. Think of the need to grow the development team, job security, fulfilling arbitrary goals set by the management etc.
It's popular with universities, this is probably the biggest reason.
Actually, I think you have it reversed. It's popular with universities (which is just one of the reasons I find most CS programs lacking because they don't even touch on other languages until the 4000s so you have a bunch of grads who never even learn Python unless they are naturally curious until after they graduate, but that's a separate rant) because it is popular in corporate environments.
I know on HN most people dont approach software development from a corporate or enterprise POV, but that's where the majority of CS grads end up working. At small, medium and large size corporate shops doing custom software usually based on outdated models and working with legacy systems. Java is perfect for that.
Ok, that was totally unfair. There is a lot of stuff that Java can do really well. And I'm not a developer by trade (I'm just a hobbyist who likes to tinker and in another life would probably be a mobile or front-end dev; maybe next decade if I'm bored with media), so I can't even really speak from expeienece implementing Java. As others have stated, it came among at the right time, perfectly timed with the explosion of "the web" and became really easy to be a drop-in for a lot of places for C++. Plus, it was portable, which is a huge thing when you have so many environmental variables.
Schools started to teach it as soon as they saw that it was what all the big businesses were adopting. It also happens to be a very easy language to teach, even if one could argue (and I would be one of those) that teaching C first would be a much better first-language just to get the fundamentals down. But I mean, it's not just colleges that teach Java, they started teaching Java (replacing VB, which was I "learned" (read: slept through)) to kids two years behind me back when I was in high school. And that was like 2001.
I know on HN most people dont approach software development from a corporate or enterprise POV, but that's where the majority of CS grads end up working. At small, medium and large size corporate shops doing custom software usually based on outdated models and working with legacy systems. Java is perfect for that.
Ok, that was totally unfair. There is a lot of stuff that Java can do really well. And I'm not a developer by trade (I'm just a hobbyist who likes to tinker and in another life would probably be a mobile or front-end dev; maybe next decade if I'm bored with media), so I can't even really speak from expeienece implementing Java. As others have stated, it came among at the right time, perfectly timed with the explosion of "the web" and became really easy to be a drop-in for a lot of places for C++. Plus, it was portable, which is a huge thing when you have so many environmental variables.
Schools started to teach it as soon as they saw that it was what all the big businesses were adopting. It also happens to be a very easy language to teach, even if one could argue (and I would be one of those) that teaching C first would be a much better first-language just to get the fundamentals down. But I mean, it's not just colleges that teach Java, they started teaching Java (replacing VB, which was I "learned" (read: slept through)) to kids two years behind me back when I was in high school. And that was like 2001.
It is my impression that it's exactly the other way round: it's popular with universities precisely because it's popular in the industry.
Many professors would like to teach something much purer (Smalltalk or Eiffel for OO, Lisp or Haskell for functional programming), but they also often have trouble forming a consensus on any of those. So it's easy to give in to the pressure from the industry, and simply teach Java.
Many professors would like to teach something much purer (Smalltalk or Eiffel for OO, Lisp or Haskell for functional programming), but they also often have trouble forming a consensus on any of those. So it's easy to give in to the pressure from the industry, and simply teach Java.
1. It got many important things right, like Unicode by default. It has a strong garbage collector and no GIL. The language may be stale but therre's a lot to recommend the platform.
2. Sun. It ended badly, but that's a company that was synonymous with innovation for quite a good run. Just as Google has energized Go (another not great, but solidly good by the standards of its time, language) having Sun behind Java was a major advantage.
3. Lack of a suitable challenger. PHBs will always see Python as unsuitable for production (and they're wrong) but mediocre programmers will never learn Haskell or Clojure. In my estimation, Go is the challenger, and it's only 5 years old.
2. Sun. It ended badly, but that's a company that was synonymous with innovation for quite a good run. Just as Google has energized Go (another not great, but solidly good by the standards of its time, language) having Sun behind Java was a major advantage.
3. Lack of a suitable challenger. PHBs will always see Python as unsuitable for production (and they're wrong) but mediocre programmers will never learn Haskell or Clojure. In my estimation, Go is the challenger, and it's only 5 years old.
Mediocre programmers can learn scala, and the idea is that over time scala can help them become less mediocre. Or at least shift the bar in the right direction.
That's a pretty strong opinion. Scala is statically typed, runs on the JVM, is Java compatible, is both object-oriented and functional, and is not verbose.
Care to elaborate why Scala is bound to attract only mediocre programmers?
Care to elaborate why Scala is bound to attract only mediocre programmers?
dustingetz didn't say "Scala is bound to attract only mediocre programmers". He (I presume) said "Mediocre programmers can learn Scala". I presume the intent was "Even mediocre programmers can learn Scala", that is, you don't have to be a rock star.
I'd rather see a discussion of why Scala is unsuited to mediocre programmers, because it's type system - particularly as applied by the standard libraries - is too complex and baroque for mere mortals.
1. Features. Core functionality that the language/ecosystem provides like the JVM, portability, relative ease in multi-threaded programming, garbage collection etc) 2. Timing. Was there a specific problem during the late 90s or early 2000s that was a sweet spot for solving using Java? Seeing that this was around the time when the internet really became mainstream, was Java primed to benefit from this in a way that set it apart from the then-contemporary programming ecosytems? 3. Scalability. In terms of the number of people you can hire while "growing" your company; could the popularity of SOA/WebServices fueled this as well?
Disclaimer: I'm not generalizing that every "big" company uses Java and I'm not saying that the ones that do are obviously doing it for the right reasons; I'm purely looking at this from academic interest since there's so much rich nuanced history that I feel I don't understand. Such a discussion could be easily extended to ask "What does this mean for functional programming languages based on the JVM like Clojure and Scala". Like Mark Twain said: "History may not repeat itself, but it certainly rhymes."