So now Haskell can produce native executable code, run in a JVM and as subset of it (https://github.com/faylang/fay/wiki) run in the browser. Now there is no excuse for me to NOT using Haskell ;)
Thanks for bringing Haskell to the JVM!
Pragmas now sorta start with @, and type classes are (in my opinion) kinda funky coming from Haskell.
If Frege isn't able to do any better with mutual recursion then that might be a severe limitation on its utility. Scala users can work around the issue by writing loops manually. In a pure language, not so much.
The only problematic point is recursion through a strict function argument, like in:
length (x:xs) = 1 + length xs
I loved Haskell the language. What I don't is third party libraries are usually directly or indirectly (through a dependency) tied to an OS. I've heard, even on irc's #haskell, that it's hard to reuse code unless you're on linux. Coming from Java, this is a deal breaker for me.
Then I tried Clojure. I liked it, but I found it very challenging to refactor and mentally debug my code. I missed all the benefits of static typing. core.typed seemed like an answer, but when you compare it to other languages it seems to triple the verbosity which is a real turn off.
I know very little about Scala, but I get a terrible impression from it. Where Clojure is about simplicity, Scala seems to be about complexity.
Since I learned Haskell, I wished there was a way I could use it and have it "just work" when I decide to use a library. Frege may be the answer. I've heard of it a long time ago. My concern is that I'd be 1 of 3 people who'd be using it. But nothing's perfect.
This concern is probably well founded. :)
And yet. Remember, you get Java source code from the Frege compiler, and once you pack up your JAR with Proguard, say, nobody will be able to tell you didn't write it in Java. (Well, slightly exaggerated, but you could have used some obscure library, who knows?)
So, if you have a small project, or some Haskell project without too many GHC extensions you want for some reason on the JVM, give it a try.
OTOH, it looks like the Poster did have bad experience with Haskell community, though.
A small community is superior insofar as they are more motivated to help, and are more likely to take (critical) feedback into account.
I think it is fair to say that the Frege community (currently about 6 more or less active contributors) does its best, judging from http://stackoverflow.com/questions/tagged/frege and https://groups.google.com/forum/#!forum/frege-programming-la...
Of course, if someone demands, say, to implements GADTs or multi-param type classes by tomorrow, the answer will be gentle, but not affirmative.
It sounds like multi-platform support is important to you, how do you intend to deploy your software? In many cases, you can get away with rolling up binaries and not worrying about trying to actually build the software on your target machine.
Most people in #haskell told me to switch to linux which seems like a ridiculous solution. I documented my struggle as another HN comment you can read here: https://news.ycombinator.com/item?id=5615683
Yeah, that's really unfortunate. This problem will continue to persist as long as people keep switching to linux to avoid it or abandoning the language altogether.
How long ago was your attempt and how did you install Haskell itself on your system?
I have the same opinion. I would really like to try a haskell on the jvm but I'd prefer if it'd be strict instead of lazy.
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.
Indeed. Do you have some CAL installation somewhere to make a comparison? (The links I find are all broken.)
I am not going to install this, even if I would find it somewhere, hence ....
Anyway, if you don't want to look at it, that's your loss - while I don't think CAL has much of a future a lot of work was invested in it by a very talented team and there is probably something to be learned from it.
Actually, I did look into it several years back. If I remember correctly, CAL was not pure and still lazy. (An explosive combination, if you ask me.)
I've seen these things used, but they're not super common. People still worry about not being able to input Unicode symbols in their editor! I personally think this is absurd in this day and age. Naturally, it's very easy to do in Emacs; somebody even wrote a Haskell input mode.
EDIT: How many people still have trouble with Unicode input? Should I publish my XCompose solution?
Today, it can be quite easy, in the best case you just Ctrl-C Ctrl-V
While it is true that the vast majority of JVM code you interact with is blocking and expects to own whatever OS thread it is running on, that could be treated as a concern of FFI, where untrusted/blocking code in Java land gets dedicated OS threads (similar to FuturePools/execution-contexts for scala Futures, or how you would manually isolate blocking code for Erlang or Go FFI.)
Additionally, the comment dismissing STM seems like an afterthought, because there are at least three JVM implementations (Clojure's, Scala's, and Multiverse)
But the main comment I was referring to was:
To do serious concurrent work in an JVM environment is
different and it will thus require different knowledge
This is not quite true (I am the author). Yet I know my limits. Every contribution from the community is welcome, OTOH.
The point of the blog posts was only to explore how far one can get with what Java has.
In other words: higher order functions.
Disclaimer: I had the privilege of meeting Dr. Finkel here at university a few times before I stumbled across his name in Wikipedia and in the front of a book in the library. Totally not biased.
See here, for example: http://books.google.de/books?id=OeAPiy-6L74C&pg=PA134&lpg=PA...
Actually it is the link to the blog entry that contains a link to the presentation.
I feel like most regular programmers could understand and benefit from using ML (or some similar language).
In Haskell, laziness kept the language pure while it was developing but now I'm not sure it should be the default. I like OCaml style opt in laziness.
For most people, they could get a lot of pretty vanilla typed functional programming language. Polymorphic type inference, algebraic data-types, pattern matching. That gets you really far.
--Edit-- is it the exact same syntax as Haskell? Unclear.
The language perhaps doesn't, but most actual programs do. I'm definitely not going to write my own standard library just because I can.
Now what could the "RT" part possibly mean?
The OOP part is rather coherent; I'm not sure what's bolted on - any examples? In fact, things like object expressions do parts of OOP even better than Java/C#. Overall the syntax for OOP is rather concise and neat.
Having proper interop with .NET and hence the OOP is ... pretty key to making a successful .NET language. Otherwise you lose one major point of being able to use .NET libraries.
I'm saying I'm not sure why the OOP exists at all. Someone else pointed at that OCaml has those elements as well, and maybe that's the reason. Just in my own use, I never felt the inclination to use the OOP at all, and their existence felt like this part of the language that I didn't understand, didn't want to understand, but was there nonetheless.
That is like saying that we should developer Windows apps because you can always deploy using wine on other systems.
If you're calling into question the portability of Java, then I can run the same bytecode on Windows, Mac, Linux, the browser (in theory) and, with a little transpiling, my Android.
If you're saying that that priority of decision drivers is backward, then I disagree:
If you want to develop a Windows app you start by saying "I want to develop something on Windows because my clients/customers run Windows". Then you work out how to do it on Windows.
If you start out saying "I want to write an app that does X" then you have the freedom to choose what balance of priorities affect you, including whether or not portability matters.
(For the record, I don't particularly agree with this. It seems like you could level the same criticism at nearly any language that has one person or stable group controlling it — for example, you could just as validly call Rubinius "WINE for Ruby".)
> A language that has a choice of runtimes from a choice of vendors like Java?
At least historically it wasn't much of a choice and I wouldn't put it past Oracle to continue in this fashion.
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, even beating C/C++ in some specific cases.
Why do you feel that the JVM is limited in its applications as a development platform?
> and big-data next-generation databases 
> 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
> 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.
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.  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?
With JVM you can't participate in writing software this way. Everything must revolve around the JVM and it's ecosystem.
The JVM and the Java ecosystem are basically all about long-running backend services. It's funny when you consider Java's roots as a simple language designed to enhance web pages.
I've never seen a AAA game written in Java. The non-deterministic GC is a dealbreaker as is the speed and space constraints of eg consoles.
The OP is generally correct: the JVM is a niche technology in a way. The Java ecosystem basically specialises in web apps and backend ESB-type stuff (shuttling data very quickly between heterogeneous applications). Of course, this is a very big, well-paying "niche" so it's not something to be afraid of.
That is the only example I can think of though, and it is certainly a stretch. (also their X-Box version isn't Java)
I would say compiled Scala runs well on the Dalvik VM.
All languages that do not need to generate (or load) class files at runtime should work well on Android. And that is because Dalvik does not run class files.
The whole point of the Frege project is to make up (insofar this is possible for a single person who is not SPJ) for the missing Haskell-JVM port.