4 ms·

The power of Java is not the VM, or even the system runtime, but the open source libraries available for it. It is time to create a "new language" whose compile

The power of Java is not the VM, or even the system runtime, but the open source libraries available for it. It is time to create a "new language" whose compiler will accept Java, and whose VM implementation is unencumbered by legitimate patents. Hm. If Dalvik isn't it, then something similar will be created. I, for one, would like to help. Anyone else up for it?

prodigal_erik 16y ago
Java is the prototypical Blub. It's saddled with a type system that wasn't even state of the art in 1991, motivating gigantic enterprisey libraries of RequestSpecificProcessorFactoryFactory crud. The VM is the reason we grudgingly tolerate it where I work.
- dkarl 16y ago
  It may be "prototypical Blub," but it has attracted a lot of bright and effective programmers, including several top-ten finishers in the Google AI Challenge and many, many people writing oodles of useful, practical code. I think it's fair to say from history that if you want to get things done in a cool, nicely designed language, it helps if your cool, nicely designed language runs on a platform that is dominated by a popular Blub language. Proof: If there's no Blub on your platform, you'll exclude the vast majority of people who might write useful code you can use. If there is a Blub on your platform, its popularity will ensure that the vast majority of useful code on your platform will be written in Blub, and first-class language status on your platform will be defined by ability to interoperate with Blub. Therefore, the best case scenario is for your favorite language to be a minor player on a Blub platform.
  - JoachimSchipper 16y ago
    Why Java interoperability instead of a good C FFI? That's what Perl/Ruby/Python/Lua/... are doing, and it works for them.
    - dkarl 16y ago
      C is another Blub, so you aren't contradicting my point, but I would say that the reason C isn't a good replacement for Java is that C has no support for garbage collection. C and Java both have a large amount of valuable, working code that programmers can utilize from other languages, but a language written on top of C has to accept that whenever a C library is used, someone must deal with C memory management, either the programmer who writes the bindings or every programmer who calls the bindings. They may have to deallocate memory and they may have to reason about the lifetime of memory deallocated by library code. Scala programmers can call Java code with no such worries. If they wrap a Java API in a Scala API, it is only for style and convenience. A Scala programmer would not use a C library lightly, certainly not without bindings that ensured memory safety, and writing such bindings would require a lot of care. The difference in practice is obvious: there is no Scala "FFI" to Java, at least not one that is visible to programmers. You just instantiate Java objects and call their methods. Ruby programmers do not blithely write calls directly to C functions in their Ruby code. They look for bindings, write the bindings themselves if necessary (making sure the bindings handle all the C memory management safely,) and then call the bindings from their Ruby code. Where increased performance is worth such an investment of time and care (and a little bit of unavoidable risk) it makes sense to build a language on top of C. Java caters to a different set of needs, where convenience and safety trump performance. P.S. The Java community went through a phase back in the day when many libraries were wrappers around C libraries, for performance reasons or simply because there was no Java implementation available, and it was a big problem because it invalidated some of the guarantees that attracted people to Java in the first place. Almost all (very, very close to all) of the cross-platform discrepancies encountered in server-side Java code were because the same C library behaved differently on different platforms.
kaffiene 16y ago
Not true. The VM is very important. The consistent & unified memory model is why Java can do synchronising, threading, garbage collection efficiently, cross platform and consistently. Also, HotSpot is really important. Java is an acceptable systems language at 80-110% the efficiency of C. It's not at 50% or less.
- binaryfinery 16y ago
  As can many other languages. However, when I use .NET, I find myself wishing for maven and all the libraries immediately available. Without the VM, there would be no point in having the source. However, even with a great VM, other languages fall short of Java, IMHO. YMMV. There are also areas where the Java VM totally sucks, frankly. How is it that we only have decent IO after more than 10 years? Sun and now Oracle hold the Java community hostage with the VM and runtime. Time to move on.

prodigal_erik 16y ago

Java is the prototypical Blub. It's saddled with a type system that wasn't even state of the art in 1991, motivating gigantic enterprisey libraries of RequestSpecificProcessorFactoryFactory crud. The VM is the reason we grudgingly tolerate it where I work.

dkarl 16y ago
It may be "prototypical Blub," but it has attracted a lot of bright and effective programmers, including several top-ten finishers in the Google AI Challenge and many, many people writing oodles of useful, practical code. I think it's fair to say from history that if you want to get things done in a cool, nicely designed language, it helps if your cool, nicely designed language runs on a platform that is dominated by a popular Blub language. Proof: If there's no Blub on your platform, you'll exclude the vast majority of people who might write useful code you can use. If there is a Blub on your platform, its popularity will ensure that the vast majority of useful code on your platform will be written in Blub, and first-class language status on your platform will be defined by ability to interoperate with Blub. Therefore, the best case scenario is for your favorite language to be a minor player on a Blub platform.
- JoachimSchipper 16y ago
  Why Java interoperability instead of a good C FFI? That's what Perl/Ruby/Python/Lua/... are doing, and it works for them.
  - dkarl 16y ago
    C is another Blub, so you aren't contradicting my point, but I would say that the reason C isn't a good replacement for Java is that C has no support for garbage collection. C and Java both have a large amount of valuable, working code that programmers can utilize from other languages, but a language written on top of C has to accept that whenever a C library is used, someone must deal with C memory management, either the programmer who writes the bindings or every programmer who calls the bindings. They may have to deallocate memory and they may have to reason about the lifetime of memory deallocated by library code. Scala programmers can call Java code with no such worries. If they wrap a Java API in a Scala API, it is only for style and convenience. A Scala programmer would not use a C library lightly, certainly not without bindings that ensured memory safety, and writing such bindings would require a lot of care. The difference in practice is obvious: there is no Scala "FFI" to Java, at least not one that is visible to programmers. You just instantiate Java objects and call their methods. Ruby programmers do not blithely write calls directly to C functions in their Ruby code. They look for bindings, write the bindings themselves if necessary (making sure the bindings handle all the C memory management safely,) and then call the bindings from their Ruby code. Where increased performance is worth such an investment of time and care (and a little bit of unavoidable risk) it makes sense to build a language on top of C. Java caters to a different set of needs, where convenience and safety trump performance. P.S. The Java community went through a phase back in the day when many libraries were wrappers around C libraries, for performance reasons or simply because there was no Java implementation available, and it was a big problem because it invalidated some of the guarantees that attracted people to Java in the first place. Almost all (very, very close to all) of the cross-platform discrepancies encountered in server-side Java code were because the same C library behaved differently on different platforms.

kaffiene 16y ago

Not true. The VM is very important. The consistent & unified memory model is why Java can do synchronising, threading, garbage collection efficiently, cross platform and consistently. Also, HotSpot is really important. Java is an acceptable systems language at 80-110% the efficiency of C. It's not at 50% or less.

binaryfinery 16y ago
As can many other languages. However, when I use .NET, I find myself wishing for maven and all the libraries immediately available. Without the VM, there would be no point in having the source. However, even with a great VM, other languages fall short of Java, IMHO. YMMV. There are also areas where the Java VM totally sucks, frankly. How is it that we only have decent IO after more than 10 years? Sun and now Oracle hold the Java community hostage with the VM and runtime. Time to move on.