4 ms·

I like the ML languages a lot, OCaml could be a java replacement. There is the industry acceptance part that java has and then the runtime has been pretty wel

I like the ML languages a lot, OCaml could be a java replacement. There is the industry acceptance part that java has and then the runtime has been pretty well vetted and improved. I'd bet money that ML runtimes turn up with "issues" as larger more demanding applications are built. And what exactly is going on with SML these days?

yummyfajitas 16y ago
OCaml has a long way to go before it can replace java. http://caml.inria.fr/pub/docs/manual-ocaml/manual038.html http://caml.inria.fr/pub/docs/manual-ocaml/manual038.html "The threads library is implemented by time-sharing on a single processor. It will not take advantage of multi-processor machines. Using this library will therefore never make programs run faster. However, many programs are easier to write when structured as several communicating processes." Ocaml is a nice replacement for ANSI C, not for Java.
- loup-vaillant 16y ago
  Doesn't sound like a long way to me. Or is it just one of many problems?
  - yummyfajitas 16y ago
    Threading isn't optional and it isn't an easy project. It will take a long while for Ocaml to catch up, if it ever does. The other big problem is the underlying OS. Java lives on the JVM, Ocaml lives on Unix. Unix isn't a substitute for the JVM and vice versa. However, F# might be an ML based competitor to java. I don't know enough about the MS stack to say.
    - loup-vaillant 16y ago
      I'm surprised about threading being hard. I thought it was just a matter of imitating a state-of-the-art GC. And it's not like it has to play nicely with JIT compilation. Now I agree Ocaml has little chance to catch up, given their apparent interest in the matter. You're strongly suggesting that a Java replacement has to compile on some standardize byte-code… Might be a prerequisite for proprietary software, but otherwise looks unnecessary. Besides, what do you mean by "lives on UNIX"? Ocaml runs on Windows too… As far as I know, F# is currently unsuitable: that would be escaping the claws of Oracle to fall in the jaws of Microsoft. Now if Microsoft fully frees .NET, or at least abandons all patent claims regarding it, F# might do.
      - yummyfajitas 16y ago
        Threading is hard for even Haskell, which is a pure functional language (unlike ML). GHC has a bunch of fantastic people trying to do a good job, and they haven't finished yet, though arguably they are as good as Java in many ways. What I mean by "lives on UNIX/lives on JVM" is a fuzzy statement about the Right Way of Doing Things. The Java way is to build a large system, integrated with the rest of the world via one or more public interfaces, potentially accessed via RMI. You'll talk to the database via JDBC. There are highly configurable enterprise tools for almost everything. This is an ecosystem you need to replace if you want to replace java. The Ocaml way is to write a program that takes command line input and processes a stream of text (which can come from a file or stdin). To write a daemon, you double fork. Most of your interaction with the outside world is simply via a posix interface. That's not to say you can't write command line unix utils in Java, or gigantic enterprise daemons in Ocaml. But you'll be going against the grain.
- jamii 16y ago
  > Ocaml is a nice replacement for ANSI C, not for Java. That's pretty much how I use it. Ocaml is a great systems language.

yummyfajitas 16y ago

OCaml has a long way to go before it can replace java. http://caml.inria.fr/pub/docs/manual-ocaml/manual038.html http://caml.inria.fr/pub/docs/manual-ocaml/manual038.html "The threads library is implemented by time-sharing on a single processor. It will not take advantage of multi-processor machines. Using this library will therefore never make programs run faster. However, many programs are easier to write when structured as several communicating processes." Ocaml is a nice replacement for ANSI C, not for Java.

loup-vaillant 16y ago
Doesn't sound like a long way to me. Or is it just one of many problems?
- yummyfajitas 16y ago
  Threading isn't optional and it isn't an easy project. It will take a long while for Ocaml to catch up, if it ever does. The other big problem is the underlying OS. Java lives on the JVM, Ocaml lives on Unix. Unix isn't a substitute for the JVM and vice versa. However, F# might be an ML based competitor to java. I don't know enough about the MS stack to say.
  - loup-vaillant 16y ago
    I'm surprised about threading being hard. I thought it was just a matter of imitating a state-of-the-art GC. And it's not like it has to play nicely with JIT compilation. Now I agree Ocaml has little chance to catch up, given their apparent interest in the matter. You're strongly suggesting that a Java replacement has to compile on some standardize byte-code… Might be a prerequisite for proprietary software, but otherwise looks unnecessary. Besides, what do you mean by "lives on UNIX"? Ocaml runs on Windows too… As far as I know, F# is currently unsuitable: that would be escaping the claws of Oracle to fall in the jaws of Microsoft. Now if Microsoft fully frees .NET, or at least abandons all patent claims regarding it, F# might do.
    - yummyfajitas 16y ago
      Threading is hard for even Haskell, which is a pure functional language (unlike ML). GHC has a bunch of fantastic people trying to do a good job, and they haven't finished yet, though arguably they are as good as Java in many ways. What I mean by "lives on UNIX/lives on JVM" is a fuzzy statement about the Right Way of Doing Things. The Java way is to build a large system, integrated with the rest of the world via one or more public interfaces, potentially accessed via RMI. You'll talk to the database via JDBC. There are highly configurable enterprise tools for almost everything. This is an ecosystem you need to replace if you want to replace java. The Ocaml way is to write a program that takes command line input and processes a stream of text (which can come from a file or stdin). To write a daemon, you double fork. Most of your interaction with the outside world is simply via a posix interface. That's not to say you can't write command line unix utils in Java, or gigantic enterprise daemons in Ocaml. But you'll be going against the grain.
jamii 16y ago
> Ocaml is a nice replacement for ANSI C, not for Java. That's pretty much how I use it. Ocaml is a great systems language.