41–50 of 112 posts
Earlier quoted context omitted.
Android doesn't run JVM.
Not technically, but practically speaking, you compile to JVM code & then it gets translated. This makes targeting the JVM & Android trivial.
Earlier quoted context omitted.
A runtime that can be used for a wide-variety of types of applications. JVM can really only be used for writing web servers and possibly daemons.
And building Twitter [1], and big-data next-generation databases [2], and android apps, and desktop apps, and big data [3], and as a platform for new languages (Clojure, Scala, Frege), and many more applications. Really, the JVM can be used for anything that _computers_ can be used for, and it does so in a way that the code is runnable across all major platforms and still maintains a top-5 language performance spot,…
Web server.
> and big-data next-generation databases [2]
Daemon.
> and android apps
No, Android doesn't have a JVM.
> and desktop apps
If you say so, I see very few of these in production.
> and big data
Daemon.
> Why do you feel that the JVM is limited in its applications as a development platform?
You can't write cli applications in a JVM language because the start-up time is too slow. Which means you can't compose scripts that call Java apps.
This is not just 1 type of application, it's the most important type of application by far. It's fundamental to how Unix operates. With Java you can't write small applications that do one thing well, you have to write big applications that are going to run for a very long time.
This is useful for things like web servers and daemons, but otherwise it sucks. It's why I can't get excited about JVM languages.
Earlier quoted context omitted.
I'd like something running on the CLR. Not because I think the CLR is very special; just because I really like Haskell but I have to work within a large ecosystem of existing .NET code.
Why not F#?
Earlier quoted context omitted.
Android doesn't run JVM.
Not technically, but practically speaking, you compile to JVM code & then it gets translated. This makes targeting the JVM & Android trivial.
Anything that replaces the horribly overengineered and bastardized Scala travesty is welcome.
I've worked quite a bit with CAL over the years and it has been used for some serious work. One of my big frustrations with it though has been the clunkiness of the Java interop, especially since this is one of the reasons you might choose to use a language on the JVM.
Looking at the Frege docs, I like the look of the way this has been handled - rather than using an FFI-style approach, things like Int, String etc map directly to Java types and Java classes can be used like ADTs, which would make life way, way easier.
Given the nature of the language calling Frege from Java is always going to be more complicated but it looks like they've done a nice "fluent" Java API for calling into the runtime.
Would be interesting to see how this performs relative to CAL, in terms of both speed and space.
Earlier quoted context omitted.
Your comment would be more useful if you elaborated on these claims.
The section on forkIO vs forkOS is interesting because the author does not mention implementing green threads atop the JVM. It would be feasible for Frege and its core libraries to use an implementation of "green threads" based on Promises or CPS under the covers in order to implement a concurrency model indistinguishable from Haskell's. While it is true that the vast majority of JVM code you interact with is blockin…
Earlier quoted context omitted.
I'd like something running on the CLR. Not because I think the CLR is very special; just because I really like Haskell but I have to work within a large ecosystem of existing .NET code.
Why not F#?
Earlier quoted context omitted.
And building Twitter [1], and big-data next-generation databases [2], and android apps, and desktop apps, and big data [3], and as a platform for new languages (Clojure, Scala, Frege), and many more applications. Really, the JVM can be used for anything that _computers_ can be used for, and it does so in a way that the code is runnable across all major platforms and still maintains a top-5 language performance spot,…
> And building Twitter [1], Web server. > and big-data next-generation databases [2] Daemon. > and android apps No, Android doesn't have a JVM. > and desktop apps If you say so, I see very few of these in production. > and big data Daemon. > Why do you feel that the JVM is limited in its applications as a development platform? You can't write cli applications in a JVM language because the start-up time is too slow. W…
You're right. In the case of small, fast applications designed to be called as part of shell scripts, the JVM does suffer start-up costs. Some testing on my personal machine shows the JVM to be 2x to 8x slower than a comparable Ruby or Python script in startup time. [1] Depending on the script, that startup time may or may not acceptable, and if the script runs for longer than a second, which is entirely possible for anything that goes beyond the local machine, the JVM will get progressively faster.
> This is not just 1 type of application, it's the most important type of application by far.
This needs more explanation. I've used Unix for many years, and I've definitely bought in to its philosophy of small and composable; It's a philosophy that in many ways mirrors functional programming. However, in my opinion, the most important type of application varies considerably by person. For you, the small, single-purpose applications may be what you use most.
And I agree, if you're programming for the Unix platform, the JVM would not be the best choice. Unix was built on C. A program that builds on that platform is probably a better choice.
But there are many more applications out there, and for any command-line program that operate in a time domain longer than 10 seconds, the JVM startup costs are mostly eliminated. This time-domain is very plausible for a command that operates on medium-scale databases or anything with network connectivity.
It's silly to completely dismiss an entire platform because it is not the absolute best choice for a single domain of programs.
I'm curious: What do you do where the short-lived, composable Unix functions are the most important programs?
Earlier quoted context omitted.
Why not F#?
I've been playing with it some. It's nice, but I still prefer Haskell. I want to be able to separate pure from impure code, but F# doesn't seem to enforce that. (Unless I'm missing something?)