Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why OCaml, why now? (2014)

spyder.wordpress.com

Post reply on HN
Print view View original

21–30 of 132 posts

Re: Why OCaml, why now? (2014)

#21

Post by jfeser »

rdtsc wrote: post #8
melling wrote: post #3

Earlier quoted context omitted.

Is there somewhere one can follow the Mac and Linux ports? I'm stoked about F#/OCaml too.

Have you tried Mono and Monodevelop? I have used C# with Mono and for back-end work (non-GUI) and it works pretty well so far. I think they have F# support as well.

I can confirm that MonoDevelop works reasonably well for F#, but the documentation for F# on Mono isn't great. Coming from OCaml, I love F# as a language, but the tooling isn't as good as it is for OCaml. Might be better on Windows with VS, but I haven't looked closely at that.

Re: Why OCaml, why now? (2014)

#22

Post by vog »

dbpatterson wrote: post #5

I think the author doesn't give enough credit to things that OCaml has that Haskell doesn't have: a powerful module system (ie, functors), polymorphic variants/subtyping, etc.

Also, provable performance properties are a big plus, caused by making lazy evaluation optional rather than mandatory. This aspect is explained quite well by Robert Harper:

https://existentialtype.wordpress.com/2012/08/26/yet-another...

(although he doesn't mention OCaml, and probably has other, even better future languages, in mind)

Re: Why OCaml, why now? (2014)

#23

Post by nicklovescode »

didyoucheckthe wrote: post #4

> The first question I usually get ... is “Why not Haskell?”. > The answer is JavaScript. My current favorite language for this is Elm[1]. It compiles to JS, is based on Haskell, and has a few simple differences between either[2]. Elm doesn't let you use the tons of available Haskell libraries, and makes it slightly painful to integrate with JS. But it's the coolest thing for the web so far. And here's why: It uses a…

hey didyoucheckthe I'm working on a new programming language that I think you may be interested if you like Elm. Couldn't find your email in your profile, but mine is cammarata.nick@gmail.com. I'd love to show you

Re: Why OCaml, why now? (2014)

#24

Post by purescript »

didyoucheckthe wrote: post #10
jarcane wrote: post #7

Earlier quoted context omitted.

Purescript[1] is also gaining some traction and even has a pretty nice looking book out. [2] It has some changes however; most notably it's strictly evaluated rather than lazy, and there are differences in how it handles type variables. [3] Personally though, I've grown more fond of F# than Haskell; I only wish the documentation for Websharper and Funscript was more solid. [1] http://www.purescript.org/ [2] https://l…

Elm is actually 3 things rolled into one: 1. an language very similar to Haskell 2. a set of runtime libraries 3. a technique for modeling a GUI as a declarative state machine PureScript only competes with #1 and #2 here. Where Elm really shines is #3, which #2 helps with a lot. Technically #3 could be done in any language. But it really helps to model it in such an expressive language with immutable data and no side…

I won't argue that Elm does anything other than an exemplary job at #3, but it is worth noting that there are some interesting efforts to build similar functionality in PureScript libraries:

https://github.com/paf31/purescript-thermite

https://github.com/kRITZCREEK/reactive-psc

https://github.com/bodil/purescript-signal

https://github.com/michaelficarra/purescript-demo-mario

https://github.com/mechairoi/purescript-frp-rabbit

To me, this is the benefit of PureScript - yes, you have to do a little more work, because you don't get these things for free from the compiler and tools, but you gain complete control over your application structure. You're not forced to work in some ambient Signal category.

Re: Why OCaml, why now? (2014)

#26

Post by more_original »

amirmc wrote: post #11
dbpatterson wrote: post #5

I think the author doesn't give enough credit to things that OCaml has that Haskell doesn't have: a powerful module system (ie, functors), polymorphic variants/subtyping, etc.

Toolchains also matter and OPAM (the package manager) has gone from strength to strength since this post. It's the basis for the OCaml Platform which combines a number of useful tools and libs into a coherent workflow (making development much more productive).

Also merlin is worth mentioning explicitly. It finds and highlights errors during editing (in emacs, vim and co), does autocompletion, shows types and since recently can also write pattern matches automatically.

http://the-lambda-church.github.io/merlin/destruct.ogv

Re: Why OCaml, why now? (2014)

#27

Post by jordwalke »

didyoucheckthe wrote: post #4

> The first question I usually get ... is “Why not Haskell?”. > The answer is JavaScript. My current favorite language for this is Elm[1]. It compiles to JS, is based on Haskell, and has a few simple differences between either[2]. Elm doesn't let you use the tons of available Haskell libraries, and makes it slightly painful to integrate with JS. But it's the coolest thing for the web so far. And here's why: It uses a…

Could anyone summarize how well PureScript and Elm treat sourcemaps/debugging in the browser? For a while I thought that js_of_ocaml didn't support sourcemaps, but it turns out, one of my dependencies wasn't compiled with debug flag (-g) and I was able to get a pretty good sourcemaps/debugging experience in Chrome dev tools once I fixed that issue. Is there something js_of_ocaml can learn from PureScript/Elm's JS compilation toolchain? Or should we look to CLJS (which I'm also really excited about) as the best example?

Re: Why OCaml, why now? (2014)

#28

Post by BSousa »

integraton wrote: post #20
tejinderss wrote: post #2

Now that .net is going cross platform, I see a great future of f# (another variant of ML family). Its got multi processors support too.

F# seems like a very nice language, but it won't really be compelling outside of the Microsoft bubble until it's divorced from the thick layer of Microsoft .CORP Brand Identity 2010, Visual Studio Visual Studio Visual Studio, and posts from Microsoft Outreach Engineers. Compare these two Stack Overflow "getting started with" answers for Haskell http://stackoverflow.com/a/1016986 and F# http://stackoverflow.com/a/1197…

mac:

brew install mono

run f# console/repl: fsharpi

compile files: fsharpc file.fs

Not sure about linux, but should be simple as well.

And as with Haskell and cabal, you have FAKE ( http://fsharp.github.io/FAKE/ ) which isn't exactly the same but similar

The main difference between those two answers is that for Haskell, the author pointed to generic Haskell resources while F# pointed to windows ones. I've been developing with F# for a while on the Mac and found no issues whatsoever. There is also MonoDevelop/Xamarin if you want a more complete IDE which is better than anything I found for Haskell (but there maybe new stuff I'm missing, having messed with Haskell in a while) but SublimeText and Vim work fine.

Re: Why OCaml, why now? (2014)

#29

Post by lomnakkus »

vog wrote: post #22
dbpatterson wrote: post #5

I think the author doesn't give enough credit to things that OCaml has that Haskell doesn't have: a powerful module system (ie, functors), polymorphic variants/subtyping, etc.

Also, provable performance properties are a big plus, caused by making lazy evaluation optional rather than mandatory. This aspect is explained quite well by Robert Harper: https://existentialtype.wordpress.com/2012/08/26/yet-another... (although he doesn't mention OCaml, and probably has other, even better future languages, in mind)

Naw, Harper is SML-all-the-way (AFAICT).

Btw, Haskell is technically not "lazy", it's "non-strict".

Now, I think he has a good point, but I don't think think there's any general consensus within the FP community which one of non-strict/strict is "better". Personally, I don't think there's a "right" answer.

Earlier on in my career, I would have said that "non-strict/strict" should have a part of the type of a term, but after non-trivial experience with O'Caml and Lazy.t, I'm not so sure. I'm definitely sure that it lead to an absurd proliferation of incompatible interfaces.

And, as SPJ has opined, laziness forces you to be honest about side effects, which is not a trivial thing!

Re: Why OCaml, why now? (2014)

#30

Post by lomnakkus »

jordwalke wrote: post #12
dbpatterson wrote: post #5

I think the author doesn't give enough credit to things that OCaml has that Haskell doesn't have: a powerful module system (ie, functors), polymorphic variants/subtyping, etc.

There's a bunch of other nice features of OCaml such as named arguments, fast compile times, strictness, c-types, and reasonable records. To achieve (some of the feature in) Elm style "structural subtyping" records in OCaml you use the more verbose "object" keyword which is just a record with row polymorphism. Most choose to stick with standard records because they compile to more efficient code. I think the ML modul…

Agreed on the ML module system. It's a damn shame that Haskell has this anemic probably-historical-accident namespacing-only module system that we're stuck with. On the plus side, there seems to be some real impetus to implement the Backpack system, though there are still unexplored points in the design space behind Backpack, especially wrt. type classes.

FWIW, I think type classes are actually what make Haskell more appealing to me than O'Caml, even though O'Caml's modules technically subsume type classes (for most purposes anyway). In practice it just gets too verbose.

That, and enforced purity.

Post reply on HN