No, it won't. OO has ruled the roost in the so-called Enterprise space for nigh-on 20 years now. Java hasn't (yet?) fully displaced C++ in 10 years despite, for this specific class of application, have several clear advantages. This is as much cultural as technological. Large corporations have a morbid (and self-fulfilling) paranoia about staff turnover and have adopted technologies such as OO because it is far easier to manage a hundred average coders each of whom has a clear boundary (the object) than it is to manage 10 rocket scientists. The power of the functional paradigm comes with a steep learning curve, there's no way around that.
The Java protection model is in many ways less strict than the process isolation model exploited in Erlang. Giving each programmer responsibility for their pool of classes may sound like a good way to limit their ability to damage the rest of the system, but as long as anyone else is dependent on the stability of their API (and the absence of unchecked runtime exceptions), a single bad line of code can easily bring down an entire system.
Also, while it may technically be a "functional" language by virtue of disallowing destructive update of values, it really reads more like a scripting language. Variables are dynamically typed, and the functions only have an arity, not a signature.
Programmers used to the expressive type systems and polymorphism of more "academic" functional languages like ML or Haskell, on the other hand, would probably chafe at Erlang's lack of support for any abstractions other than forking and message-passing.
Real rocket scientists, on the other hand, would probably like Erlang, since the semantics of the language are simple, and its fault-tolerance and concurrency features could be well-suited for high-availability systems like mission data collection. (Its lack of hard real-time features make it a non-starter for actual avionics.)
I don't think this is the issue. You could easily give each developer a Haskell module to flesh out, like:
foo :: Foo -> (Bar -> Baz) -> Quux
hello :: IO
this :: Is -> Starting -> To Get -> Boring
Arguably the restrictions they are bound to are much stricter than with Java.
But anyway, I don't think most Java programmers really "get" OO. So OO is not the reason they use Java -- there is something else. Probably a lot of marketing from Sun; constantly hearing about "certification" and whatnot makes the managers happy.
On a more serious note yes, but again that's a cultural thing. Languages like Erlang (and OCaml, and Haskell, and...), you spend more time thinking than typing. You don't (need to) write much code, and if you think of a better way you might completely overwrite yesterday's work. You might deliver a huge chunk of functionality in a couple of pages of code that took weeks of thought, but that looks like it was typed in a day (I have been in that situation). Functional languages don't fit big-company management comfortably. They don't look like "work" in the sense that most IT organizations are used to. Java will be with us for a long time.
If cutting out boilerplate to sharpen focus on the actual code doesn't help make it easier to understand, then something is seriously wrong.
Part of writing good code, whether two pages of brilliance or twenty of gradual brilliance, is conveying intent in the human-readable parts. The parser doesn't care if all the functions have names like doTheNextThing() or french_onion_soup, but it would be a slap in the face to any future maintainers.
Choosing informative names and separating a program along clear conceptual boundaries can be a greater aid to understanding than any syntactic redundancies. Well-placed comments help smooth things over, particularly notes on why a particular approach was chosen. The names themselves should be able to convey what is going on in most cases.
The biggest thing I learned from Forth is that if I'm about to add a comment inside a function because something needs clarification, I should probably try breaking it out and thinking up a descriptive name instead.
I think it's a lot easier to understand what some code does if you don't have to read a lot of language imposed cruft that surrounds the actual 'meat' of the algorithm.
Erlang really is easier than Java -- both to read and to write. I think people too often confuse "different" with "difficult".
For one thing, the pattern matching used in Erlang, ML, and Haskell can be quite easy to read.
For example, something like
let days_in_month m = match m with
| Jan | Mar | May | Jul | Aug | Oct | Dec -> 31
| Apr | Jun | Sept | Nov -> 30
| Feb -> if leap_year () then 29 else 28
It takes a small amount of context (all "| Val" sections without a -> ... side match together), but it's a pretty direct correspondence.
That's not much harder in C or Java, given appropriate enum declarations:
public int days_in_month(month) {
switch(month) {
case JAN:
case MAR:
case MAY:
case JUL:
case AUG:
case OCT:
case DEC:
return 31
case APR:
case JUN:
case SEPT:
case NOV:
return 30;
case FEB:
if(leap_year()) return 29; else return 28;
}
}
Pattern-matching really shines when you need to destructure the argument, then do something similar to the result regardless of which case resulted in the destructuring. For example, compare red-black trees written in Java:
I couldn't think of a better example at the time. Something that simultaneously matched several fields (whether destructured from one variable or not) and/or had guards would be a better example.
Maybe something like this (in pseudo-ML):
(* Look up order code for a Sci-Fi GadgetTM, units are in cm *)
let gadget_order_code width depth height color has_laser =
match (width depth height color has_laser) =
(* The original, simple code *)
| 5, 2, 1, Red, true -> "ZAP-X"
(* Most common width, color *)
| 4, d, h, Blue, true -> sprintf "ZAP-4-%d%d+" (str d) (str h) "+"
(* C for Custom Color *)
| 4, d, h, c, false -> "ZAP-4C-%d%d-%c" (str d) (str h) (color_code c)
(* Orange lasers are discontinued *)
| w, d, h, c, true when (w + d + h) < 15 and c != Orange ->
"ZAP-S-%d%d%d-%c" (str w) (str d) (str h) (color_code c)
| _, _, _, _, _ -> failwith "Unavailable"
That's a little complicated to determine with pattern matching or via a database, but doing it in a series of nested if statements would get mind boggling.
No it won't (this coming from someone who loves Erlang and has worked full-time with it for a year).
There has been way too much invested in both Java and conventional OOP for them to be displaced that fast. 2 years may be a long time in startup world, but in the enterprise world it's nothing.
Ruby has been growing rapidly for the last 3 years, and it's still nowhere as popular as Java. And Ruby's marketing has been way better than Erlang's.
It's actually not a long time in the startup world, either. The average life cycle in the valley for VC-backed startups from founding to exit is 7 years. There are always exceptions, of course. But two years isn't enough time, in general, for anything interesting to shake out--either in languages or in startup companies.
I doubt that, as well. Ruby still isn't all that popular a choice for startups, and it's had some astoundingly good marketing. I'd say maybe 20% of the startups I know personally are using Ruby, with the rest divided amongst PHP, Python, Java, and Perl (not necessarily in that order, though PHP is definitely at the top of the list by a large margin). Since RoR started gaining traction about three years ago, and RoR is still not the leading platform, the notion that Erlang could even become a contender (much less the leader) in two years is more than a little ridiculous.
Not to mention the fact that there's only one language at this point that is inevitably going to grow really rapidly in popularity (JavaScript). (Others will grow, but none so fast as JavaScript.)
In my experience, it takes at least a couple of years to introduce a new technology to a large corporate (i.e. the ones that actually run enterprise apps).
Many large corporates will have multi-year enterprise licenses for things like IBM WebSphere. It might be years before they even consider a technology shift, let alone that shift becoming dominant.
The reasons are many and varied - resistance to change, need to prove the technology, integrating the technology with existing systems, changes required to methodology and process, instrumenting the new technology, vendor support, cost, skills availability, access to quality training, access to recognised certifications, tooling (dev/test/deploy), infrastructure, regulatory compliance... The list goes on and on.
Even when you take all of these... Nobody ever actually decommissions anything.
Cultural and methodology changes are massive in the enterprise space.
Java is still the standard language in the vast majority of CS programs. Lots of programmers entering the enterprise only know Java, and if they know more languages they definitely don't know Erlang.
Certainly demand for Erlang programmers will increase over time...
History shows that the languages taught in CS and the languages used in industry don't need to be related at all. That the same language is popular in both at the same time is unusual.
You have to know how to navigate away from the many rocky shores littered with shit. I was embarassed to call myself a Java developer after going to J1 this year, so sad.
That being said, there are some amazing libraries out there.
Google Guice, Google Collections Framework, struts2, BDB JE to name a few. They help me ship.
Enterprises move slowly. 2 years is no time in the enterprise world. How many Erlang programmers are there? I love learning new languages, but there are a lot of crusty programmers out there who refuse to update their skill set - and they're often entrenched in enterprise settings.
This next part will probably some change over time. Erlang is slower than Java - even with the HiPE JIT compiler. Erlang's performance is more akin to Python. Plus, as much as I protest, "enterprisey" people seem to have a love affair with static typing. They also have a love affair for nicely UML-diagrammed objects and Erlang is functional.
But the most important reason why this won't happen is that the majority of "enterprisey" systems I know of are a ton less reliable than consumer systems. "Enterprisey" has become the term I associate with needing to have a programmer on call for. This might sound stupid, but so many programmers I know worry about job security - mostly because they won't upgrade their skill set. Something that obsoletes the need for them to babysit applications eats at that security.
Erlang will get (more) popular. Lots love the functional paradigm. It's really well implemented, reliable, etc. It just won't displace Java quickly, if ever.
The 2 year aspect of the argument is a bit absurd. These changes just do not happen that fast, especially with sqillions of entrenched java developers in the enterprise.
He also argues that Erlang has "already penetrated the enterprise." Might seem that way if you work at Ericsson, but otherwise I can't imagine making this statement.
This is not going to happen in 2 years, inertia is too high. Imagine all those projects that have just started now that aren't even out of analysis yet?
Scala is more likely perhaps? Since it builds on the JAVA platform but is a much more flexible language(functional/OO hybrid) and offers several ways of doing concurrency(including Erlang-ish message-passing/Acor model).
Not sure how limited the concurrency model of Scala is by the underlying architecture though.
