Wow do I wish betting markets had that title as a wager.
Erlang will replace Java in the next 2 years as the standard for Enterprise Applications
31–40 of 40 posts
Re: Erlang will replace Java in the next 2 years as the standard for Enterprise Applications
#32Re: Erlang will replace Java in the next 2 years as the standard for Enterprise Applications
#33No, 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 easie…
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
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.
Re: Erlang will replace Java in the next 2 years as the standard for Enterprise Applications
#34Earlier quoted context omitted.
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".
I wasn't thinking Java. I was thinking lisp or python.
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
Re: Erlang will replace Java in the next 2 years as the standard for Enterprise Applications
#35Earlier quoted context omitted.
I wasn't thinking Java. I was thinking lisp or python.
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;
}
}
http://www.docjar.com/html/api/java/util/TreeMap.java.html
vs. those written in Haskell:
http://www.cse.unsw.edu.au/~dons/data/RedBlackTree.html
The rebalancing code in Java is 80 lines long. The rebalancing code in Haskell is 6.
Re: Erlang will replace Java in the next 2 years as the standard for Enterprise Applications
#36Earlier quoted context omitted.
That's nice, but how easy is it to understand those 2 pages of brilliance later and how brittle are they? Remember - the author is the smartest person who will ever see a given piece of code. The reader, even if it's the same person, will be dumber. Programming isn't literature or poetry. No one ever had to add a mail reader to"Ode to a Grecian Urn".
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…
I have that book, and I am a big fan of Forth.
It's not unusual now for some of my source files to be more comments than code, the comments explain my intent and the assumptions I have made.
I'm gonna call a function french_onion_soup tomorrow just for larks :-)
Re: Erlang will replace Java in the next 2 years as the standard for Enterprise Applications
#37Earlier quoted context omitted.
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…
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)
"ZAP-S-%d%d%d-%c" (str w) (str d) (str h) (color_code c)
| _, _, _, _, _ -> failwith "Unavailable"
Re: Erlang will replace Java in the next 2 years as the standard for Enterprise Applications
#38Earlier quoted context omitted.
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…
I have that book, and I am a big fan of Forth. It's not unusual now for some of my source files to be more comments than code, the comments explain my intent and the assumptions I have made. I'm gonna call a function french_onion_soup tomorrow just for larks :-)
For leeks, you mean. :)
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.
Re: Erlang will replace Java in the next 2 years as the standard for Enterprise Applications
#39Earlier quoted context omitted.
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…
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 origina…
(oops. lost the sprintfs...)
Re: Erlang will replace Java in the next 2 years as the standard for Enterprise Applications
#40Scala 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.