9 ms·

A Language Is More Than a Language

74 points by guiambros 11y ago

rasengan0 11y ago
tl;dr: try elm
- Apanatshka 11y ago
  For those who don't want to google it: http://elm-lang.org/ http://elm-lang.org/
stevoski 11y ago
I think what Bruce Eckel is arguing here is that the creators of Java and the Java API would have done a much better job if they had applied the lessons in advance that they learnt from years of Java being actively used. Which is, in my opinion, a somewhat unfair and unrealistic point of view. But yes, a real Java 2 or Java++ or next generation Java would indeed be a good thing.
- zokier 11y ago
  > But yes, a real Java 2 or Java++ or next generation Java would indeed be a good thing. I though C# was considered pretty much Java with less warts.
  - stevoski 11y ago
    I agree. But, until recently, it had the huge disadvantage of being a Windows-only product.
    - bestusername111 11y ago
      So Mono being released in 2004, is recent?
      - ansible 11y ago
        There was that recent article about FogBugz vs JIRA, where a former FogBugz guy was participating. He said that the buggy and incomplete standard library for Mono was a large part of their product's failure on UNIX / Linux.
      - oblio 11y ago
        From almost everything I've seen so far Mono wasn't really considered production-ready until recently. I remember reading, for example, some horror stories from the early days of Fogcreek Fogbugz support on Unix via Mono. Even today, is any big company using Mono? Are there are any big commercial (or Open Source) applications using it?
        slapresta 11y ago
        Agreed on Mono hardly being production-ready until recently: that said, Unity uses Mono extensively for production purposes.
  - deleted 11y ago
    [deleted]
- jrochkind1 11y ago
  You don't have the benefit of retrospection in advance, it's true. But you can take more time before releasing major components/features, and try to get them right. Eckel thinks they could have done better if they hadn't been in such a hurry, and focusing on marketting over quality, and maybe had some more skilled people involved. Especially in a platform so committed to backwards compat, if you release something designed poorly, you're stuck with it. I guess the 'marketting' rejoinder would be if they had taken more time before releasing an attempted solution, it might have prevented Java's success in the 'market'. I don't know. But I think it's general consensus at this point that eg J2EE API's and design was/is pretty awful -- and I don't think it actually takes retrospection to see that, it was awful right away and was seen so by many right away too.
  - twic 11y ago
    Was J2EE obviously awful at the time? I'm honestly not sure. I had a summer job working on EJBs at a company that had built everything on CORBA. It was basically a research project; they knew they had to switch to EJB, because it was going to be the standard (ha), and they wanted to know how. This was in the EJB 1.x era, so somewhere between 1998 and 2001 - i don't remember exactly when! I remember thinking that it was all rather complicated, especially around persistence. And i remember being appalled that beans didn't actually implement their interfaces. We came up with some rather complicated pattern to work around that - i think there was a master interface where all the methods threw RemoteException, then the bean interface trivially extended that, and there was a local interface that extended it but overrode all the methods to not throw RemoteException, then the bean implemented that. And i spent most of my time there wrestling with the fact that the performance characteristics of local and remote calls are very different, and how that impacted design; we ended up with DTOs mirroring every entity bean to save network round-trips. But the thing is, there was nothing else around at the time that did anything similar. Remote object invocation, with declarative transactions, and container-managed object lifecycles, including pulling objects out of a database on demand. That seemed like saucer tech! So it seemed, glaring design flaws aside, fair enough that it was complicated. Hey, i might have to write an XML document, but at least it wasn't ten thousand lines of C++.
    - 11y ago
reilly3000 11y ago
Sounds like a good argument for Clojure.
- candeira 11y ago
  And the Oracle legal shenanigans seems like a good argument for Clojure on the CLR. I don't know how mature the CLR ecosystem is on Linux, but the licensing at least seems ok.
  - pjmlp 11y ago
    Android Java is J++ relaunched.
  - pron 11y ago
    > And the Oracle legal shenanigans You mean the Google legal shenanigans that tried to find loopholes around two Java licenses (one of them completely open-source, and the other would have cost them $25M) that would hopefully hold up in a court case (which they were sure would follow, because they went straight after Sun's business), failed, and in the process forked the ecosystem? Oracle did exactly what Google dared them to do (after a reprieve while Sun was dying). Only, to get what they wanted -- payment for the use of Java not under its open-source license -- they used whatever legal argument they could come up with, in the hope that one would stick. One did (well, at least partially), and now Oracle is at fault? This entire court case -- except the decision -- was orchestrated by Google. They could have avoided the whole thing by either abiding by the open-source license (which, BTW, is exactly the same as Linux's) or by paying Sun $25M. Oracle, OTOH, had no choice because Google went after them with their own weapon. Oracle didn't just go after someone who'd forked Java. They went after someone who'd forked Java with the intent to harm on of their main income sources from Java (at least at the time), while forking the ecosystem and breaking compatibility -- the ecosystem's prime directive -- and all that while Java was available under an open-source license, which Google rejected. They don't care about the principles of copyright. They just happened to use that in their arsenal of legal tools to go after a company that they believed had harmed them. Then, Google's PR tried to terrify the world with the possible repercussions of the one argument that did stick by blowing it out of proportion and neglecting to mention that it hardly applies to any software these days. Neither of these companies is a saint in this story. They are just two corporations playing their parts. But Google was the one who could have stopped all this, and blaming the whole thing on Oracle is just ridiculous.
nabla9 11y ago
"And you're right: we were not out to win over the Lisp programmers; we were after the C++ programmers. We managed to drag a lot of them about halfway to Lisp. Aren't you happy?" -- Guy Steele - Sun Microsystems Labs (about Java) source: http://www.ai.mit.edu/~gregs/ll1-discuss-archive-html/msg04045.html http://www.ai.mit.edu/~gregs/ll1-discuss-archive-html/msg040...
- pjmlp 11y ago
  Back then I was disappointed with the state of C++ compilers across vendors and OSes (the standard was still being defined). Meanwhile, I also had discovered that it was possible to use a GC enabled systems programming language for writing OS (Oberon and Modula-3). And was exposed to Prolog, Caml Light, Smalltalk and Eiffel. So Java seemed a nice compromise for industry adoption. Our university adopted it right away for its distributed computing and compiler development classes. However I never liked the religiosity about a JIT, preferring the .NET way of having a choice between JIT and AOT. So I still like C++ a lot, but unless I am shaving off ms or bytes from a specific algorithm or writing portable code for mobile devices, I tend to use other languages.
  - munificent 11y ago
    > However I never liked the religiosity about a JIT, preferring the .NET way of having a choice between JIT and AOT. I wonder how much of this comes down to the fact that Java methods are virtual by default and in C# they are not. The former makes devirtualization more important and is harder to do ahead of time.
    - pjmlp 11y ago
      Might be. Most other OOP languages back then (mid-90's) used static by default.
ExpiredLink 11y ago
I have no doubt that you cannot win the 'war' on the language front. All those bloggers, internet and conference luminaries that never write real-world production code miss the point. It's about the platform, the whole programming ecosystem not about 'beautiful' syntax. That's why Java - the platform (Java EE, Android, ...), not the language - won and is still going strong. New languages (D, Rust, ...) have not the ghost of a chance unless they are able to create a platform.
- Apanatshka 11y ago
  I agree. But don't forget that it took years of hard work to build up enough of "Java the platform". Things that help there is having traditional man-power, which costs money, and having a strong community, which takes lobbying/evangelising/advertising. In a way, all those "luminaries" you mention may or may not miss the point individually, but the buzz it creates is necessary to build the community that makes the platform, and that in turn makes the language succeed. Developers, developers, developers, developers, developers...
vmateixeira 11y ago
Can someone please clarify me... Not defending Sun/Oracle decisions in here but isn't Bruce Eckel confusing Java as a language with some Java libraries, of which some happen to be provided via JDK? This was what I felt while reading this presentation. Thanks
carapace 11y ago
A conference in Crested Butte, Colorado in February is kind of a bad idea. I lived up there one winter and it is very very cold and covered in snow and ice. It's the kind of place/season where you pretty much need special clothes to walk a block. Full disclosure: I grew up in SF and didn't really believe in seasons until that year I spent in CO, so take this comment with a grain of salt or better yet a big bag of that road salt they use to melt the ice on the roads, and a four-wheel drive vehicle with working heater, and winter underwear and a warm preferably-goose-down jacket and boots and "smart wool" socks, and hat and mittens. Seriously though, unless you like to ski or you're just really into ice and being cold and you can't get to Antarctica going to Crested Butte in winter is nuts. Nice town. Freezing cold.
YeGoblynQueenne 11y ago
Don't like Java? Try COBOL. Then you will like Java.

74 points by guiambros 11y ago

rasengan0 11y ago

tl;dr: try elm

Apanatshka 11y ago
For those who don't want to google it: http://elm-lang.org/ http://elm-lang.org/

stevoski 11y ago

I think what Bruce Eckel is arguing here is that the creators of Java and the Java API would have done a much better job if they had applied the lessons in advance that they learnt from years of Java being actively used. Which is, in my opinion, a somewhat unfair and unrealistic point of view. But yes, a real Java 2 or Java++ or next generation Java would indeed be a good thing.

zokier 11y ago
> But yes, a real Java 2 or Java++ or next generation Java would indeed be a good thing. I though C# was considered pretty much Java with less warts.
- stevoski 11y ago
  I agree. But, until recently, it had the huge disadvantage of being a Windows-only product.
  - bestusername111 11y ago
    So Mono being released in 2004, is recent?
    - ansible 11y ago
      There was that recent article about FogBugz vs JIRA, where a former FogBugz guy was participating. He said that the buggy and incomplete standard library for Mono was a large part of their product's failure on UNIX / Linux.
    - oblio 11y ago
      From almost everything I've seen so far Mono wasn't really considered production-ready until recently. I remember reading, for example, some horror stories from the early days of Fogcreek Fogbugz support on Unix via Mono. Even today, is any big company using Mono? Are there are any big commercial (or Open Source) applications using it?
      - slapresta 11y ago
        Agreed on Mono hardly being production-ready until recently: that said, Unity uses Mono extensively for production purposes.
- deleted 11y ago
  [deleted]
jrochkind1 11y ago
You don't have the benefit of retrospection in advance, it's true. But you can take more time before releasing major components/features, and try to get them right. Eckel thinks they could have done better if they hadn't been in such a hurry, and focusing on marketting over quality, and maybe had some more skilled people involved. Especially in a platform so committed to backwards compat, if you release something designed poorly, you're stuck with it. I guess the 'marketting' rejoinder would be if they had taken more time before releasing an attempted solution, it might have prevented Java's success in the 'market'. I don't know. But I think it's general consensus at this point that eg J2EE API's and design was/is pretty awful -- and I don't think it actually takes retrospection to see that, it was awful right away and was seen so by many right away too.
- twic 11y ago
  Was J2EE obviously awful at the time? I'm honestly not sure. I had a summer job working on EJBs at a company that had built everything on CORBA. It was basically a research project; they knew they had to switch to EJB, because it was going to be the standard (ha), and they wanted to know how. This was in the EJB 1.x era, so somewhere between 1998 and 2001 - i don't remember exactly when! I remember thinking that it was all rather complicated, especially around persistence. And i remember being appalled that beans didn't actually implement their interfaces. We came up with some rather complicated pattern to work around that - i think there was a master interface where all the methods threw RemoteException, then the bean interface trivially extended that, and there was a local interface that extended it but overrode all the methods to not throw RemoteException, then the bean implemented that. And i spent most of my time there wrestling with the fact that the performance characteristics of local and remote calls are very different, and how that impacted design; we ended up with DTOs mirroring every entity bean to save network round-trips. But the thing is, there was nothing else around at the time that did anything similar. Remote object invocation, with declarative transactions, and container-managed object lifecycles, including pulling objects out of a database on demand. That seemed like saucer tech! So it seemed, glaring design flaws aside, fair enough that it was complicated. Hey, i might have to write an XML document, but at least it wasn't ten thousand lines of C++.
  - 11y ago

reilly3000 11y ago

Sounds like a good argument for Clojure.

candeira 11y ago
And the Oracle legal shenanigans seems like a good argument for Clojure on the CLR. I don't know how mature the CLR ecosystem is on Linux, but the licensing at least seems ok.
- pjmlp 11y ago
  Android Java is J++ relaunched.
- pron 11y ago
  > And the Oracle legal shenanigans You mean the Google legal shenanigans that tried to find loopholes around two Java licenses (one of them completely open-source, and the other would have cost them $25M) that would hopefully hold up in a court case (which they were sure would follow, because they went straight after Sun's business), failed, and in the process forked the ecosystem? Oracle did exactly what Google dared them to do (after a reprieve while Sun was dying). Only, to get what they wanted -- payment for the use of Java not under its open-source license -- they used whatever legal argument they could come up with, in the hope that one would stick. One did (well, at least partially), and now Oracle is at fault? This entire court case -- except the decision -- was orchestrated by Google. They could have avoided the whole thing by either abiding by the open-source license (which, BTW, is exactly the same as Linux's) or by paying Sun $25M. Oracle, OTOH, had no choice because Google went after them with their own weapon. Oracle didn't just go after someone who'd forked Java. They went after someone who'd forked Java with the intent to harm on of their main income sources from Java (at least at the time), while forking the ecosystem and breaking compatibility -- the ecosystem's prime directive -- and all that while Java was available under an open-source license, which Google rejected. They don't care about the principles of copyright. They just happened to use that in their arsenal of legal tools to go after a company that they believed had harmed them. Then, Google's PR tried to terrify the world with the possible repercussions of the one argument that did stick by blowing it out of proportion and neglecting to mention that it hardly applies to any software these days. Neither of these companies is a saint in this story. They are just two corporations playing their parts. But Google was the one who could have stopped all this, and blaming the whole thing on Oracle is just ridiculous.

nabla9 11y ago

"And you're right: we were not out to win over the Lisp programmers; we were after the C++ programmers. We managed to drag a lot of them about halfway to Lisp. Aren't you happy?" -- Guy Steele - Sun Microsystems Labs (about Java) source: http://www.ai.mit.edu/~gregs/ll1-discuss-archive-html/msg04045.html http://www.ai.mit.edu/~gregs/ll1-discuss-archive-html/msg040...

pjmlp 11y ago
Back then I was disappointed with the state of C++ compilers across vendors and OSes (the standard was still being defined). Meanwhile, I also had discovered that it was possible to use a GC enabled systems programming language for writing OS (Oberon and Modula-3). And was exposed to Prolog, Caml Light, Smalltalk and Eiffel. So Java seemed a nice compromise for industry adoption. Our university adopted it right away for its distributed computing and compiler development classes. However I never liked the religiosity about a JIT, preferring the .NET way of having a choice between JIT and AOT. So I still like C++ a lot, but unless I am shaving off ms or bytes from a specific algorithm or writing portable code for mobile devices, I tend to use other languages.
- munificent 11y ago
  > However I never liked the religiosity about a JIT, preferring the .NET way of having a choice between JIT and AOT. I wonder how much of this comes down to the fact that Java methods are virtual by default and in C# they are not. The former makes devirtualization more important and is harder to do ahead of time.
  - pjmlp 11y ago
    Might be. Most other OOP languages back then (mid-90's) used static by default.

ExpiredLink 11y ago

I have no doubt that you cannot win the 'war' on the language front. All those bloggers, internet and conference luminaries that never write real-world production code miss the point. It's about the platform, the whole programming ecosystem not about 'beautiful' syntax. That's why Java - the platform (Java EE, Android, ...), not the language - won and is still going strong. New languages (D, Rust, ...) have not the ghost of a chance unless they are able to create a platform.

Apanatshka 11y ago
I agree. But don't forget that it took years of hard work to build up enough of "Java the platform". Things that help there is having traditional man-power, which costs money, and having a strong community, which takes lobbying/evangelising/advertising. In a way, all those "luminaries" you mention may or may not miss the point individually, but the buzz it creates is necessary to build the community that makes the platform, and that in turn makes the language succeed. Developers, developers, developers, developers, developers...

vmateixeira 11y ago

Can someone please clarify me... Not defending Sun/Oracle decisions in here but isn't Bruce Eckel confusing Java as a language with some Java libraries, of which some happen to be provided via JDK? This was what I felt while reading this presentation. Thanks

carapace 11y ago

A conference in Crested Butte, Colorado in February is kind of a bad idea. I lived up there one winter and it is very very cold and covered in snow and ice. It's the kind of place/season where you pretty much need special clothes to walk a block. Full disclosure: I grew up in SF and didn't really believe in seasons until that year I spent in CO, so take this comment with a grain of salt or better yet a big bag of that road salt they use to melt the ice on the roads, and a four-wheel drive vehicle with working heater, and winter underwear and a warm preferably-goose-down jacket and boots and "smart wool" socks, and hat and mittens. Seriously though, unless you like to ski or you're just really into ice and being cold and you can't get to Antarctica going to Crested Butte in winter is nuts. Nice town. Freezing cold.

YeGoblynQueenne 11y ago

Don't like Java? Try COBOL. Then you will like Java.