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

Comparing OCaml and Standard ML

adam.chlipala.net

Post reply on HN
Print view View original

51–60 of 71 posts

Re: Comparing OCaml and Standard ML

#51

Post by jdh30 »

profquail wrote: post #17
CmonDev wrote: post #6

Wow, ML syntax is actually better than OCaml. It's a shame the former was used as a base for F#.

One thing I think F# got right is that it removed some of the "flexibility" in OCaml's syntax. For example, it uses significant whitespace to define scoping, which removed (in nearly all cases) the need for the 'in' keyword and lots of parentheses and semicolons. That may not sound like a huge deal, but it does greatly improve the readability of F# code (all other things being equal).

> One thing I think F# got right is that it removed some of the "flexibility" in OCaml's syntax. For example, it uses significant whitespace to define scoping, which removed (in nearly all cases) the need for the 'in' keyword and lots of parentheses and semicolons. That may not sound like a huge deal, but it does greatly improve the readability of F# code (all other things being equal).

I must disagree. I once translated a significant (15kLOC) commercial OCaml code base into F# and took the opportunity to quantify the syntactic benefits as <3% by volume of code. The flipside is that F# misinterprets code pasted from the web, rendering most code on the web useless. That is a crippling deficiency of F# in my eyes and a major reason to go back to the superior OCaml solution.

Re: Comparing OCaml and Standard ML

#52

Post by jdh30 »

CmonDev wrote: post #6

Wow, ML syntax is actually better than OCaml. It's a shame the former was used as a base for F#.

> Wow, ML syntax is actually better than OCaml. It's a shame the former was used as a base for F#.

I prefer this:

http://www.ffconsultancy.com/languages/ray_tracer/code/1/ray...

to this:

http://www.ffconsultancy.com/languages/ray_tracer/code/1/ray...

Re: Comparing OCaml and Standard ML

#53

Post by pjmlp »

avsm wrote: post #48
pjmlp wrote: post #34

Earlier quoted context omitted.

That was my biggest disapointment with "Real World OCaml", as the book requires OPAM to follow along. Apparently it works with WOBI, an OCaml distribution for Windows. I haven't tried it though. When on Windows I just go for F#.

WODI (not WOBI) didn't exist when we started Real World OCaml, and we developed OPAM along the way. We've also started putting Windows support in place via Appveyor: https://github.com/ocaml/opam/blob/master/appveyor.yml It just can't be activated by default since GitHub doesn't support multiple commit updates yet, so we have to chose between Travis and Appveyor. When GitHub sorts that out, we can have Linux, OSX and…

> WODI (not WOBI) didn't exist when we started Real World OCaml, and we developed OPAM along the way.

Yeah, I was on the phone and did not check the right name. Thanks for the correction.

It is just that the work laptops I carry around are Windows based, so it was a bit limiting in that sense.

In spite of that, the book is quite good and I really enjoyed reading it.

> We've also started putting Windows support in place via Appveyor

Thanks for the heads up.

> In general, help porting packages to Windows is very welcome from interested parties.

Agreed, but on my specific case given that work is on the JVM/.NET ecosystems I am limited on time availability.

But at least now I can already give a better update on the current status.

Congratulations on the work that you guys are doing.

Re: Comparing OCaml and Standard ML

#54

Post by Raphael_Amiard »

marktangotango wrote: post #27
Raphael_Amiard wrote: post #10

Earlier quoted context omitted.

> For me the object system on Ocaml was just too much What do you mean by that ? The current consensus about the object system in OCaml is "don't use it", even if there might be cases where it will describe your system better. The standard library (both the real stdlib and Jane Street's Core library) don't use objects so you can pretty much ignore this part of the language if you want to.

Since that is the 'current consensus' as you say, it seems like the ocaml community converged on the opinion I formed 10 years ago. But it wasn't necessarily the consensus then.

Ok, makes perfect sense !

Re: Comparing OCaml and Standard ML

#55

Post by adultSwim »

sgeisenh wrote: post #2

Purity is almost used in a pejorative sense throughout the page. If it wasn't for poor library support, I would prefer using SML to OCaml. SML is syntactically simpler and both SML/NJ and MLton have a lot to offer that I haven't yet found with OCaml. I think one of the biggest mistakes in the life cycle of SML was premature specification. As a result of the language definition, SML has stagnated for almost 20 years.…

I would note that several SML extensions were made by adding on to existing compilers (e.g. Concurrent ML). The Haskell community has used this model to great effect (testing/refining new features as add-ons to existing compilers and then moving some of them into the main language).

Any ML would be good. The basic features of the language are the best. "Vanilla" ML would suit most people's needs (preferable replacement to many popular languages).

Re: Comparing OCaml and Standard ML

#56

Post by adultSwim »

jdh30 wrote: post #49
sgeisenh wrote: post #2

Purity is almost used in a pejorative sense throughout the page. If it wasn't for poor library support, I would prefer using SML to OCaml. SML is syntactically simpler and both SML/NJ and MLton have a lot to offer that I haven't yet found with OCaml. I think one of the biggest mistakes in the life cycle of SML was premature specification. As a result of the language definition, SML has stagnated for almost 20 years.…

> SML has stagnated for almost 20 years I'm still waiting for OCaml to get decent multicore support, decent Windows support and an FFI that doesn't suck donkey brains through a straw (which is why so many OCaml libraries, like OpenGL bindings, suck beyond belief). Multicore became ubiquitous 10 years ago. Last I looked the vestigial OCaml community still hadn't noticed.

The netmulticore library [1,2] worked well for me. The style there is to spawn worker processes and pass messages between them. I'm not sure how popular that library got but that style of programming seems to be pretty popular among OCaml users who need it. Many projects use something lighter-weight or just roll their own (e.g. Parallel in Jane Street's ocaml-core looks pretty good [3]).

I certainly wouldn't mind if you could swap out the garbage collector (a la Java - where you can choose between a fast serial garbage collector and a parallel garbage collector). However, I don't think it's the right tool for many tasks.

[1] http://blog.camlcity.org/blog/multicore1.html

[2] http://projects.camlcity.org/projects/dl/ocamlnet-4.0.0test2...

[3] https://ocaml.janestreet.com/ocaml-core/109.24.00/doc/parall...

Re: Comparing OCaml and Standard ML

#57

Post by adultSwim »

a0 wrote: post #30
mercurial wrote: post #11

Earlier quoted context omitted.

I'm curious about what you find particularly confusing about OCaml. I'm a (relative) newcomer to the language, but I find it extremely readable, even if it's a bit clunky at times.

Good OCaml code is one of most readable in the category of static languages, I agree. But it's less "writable" than readable in my opinion. Of course you can get used to the syntax, but for me expressiveness and clarity of comprehension comes from both: simplicity of writing and reading. Often I feel like there is a barrier between your thoughts and their execution which does not exist in Python or Ruby for example.…

Learning Python was certainly easier for me. I could really hit the ground running. OCaml had a much steeper learning curve. It took me a while to get used to the compiler and the different style of programming.

However, I'm a professional. Some of the powerful tools I use take a serious investment to learn. Here it paid off well.

Now I find that Python programs are easy to start but OCaml programs are easy to finish. The compiler is an invaluable helper that I miss when using other languages. Some syntax is clunkier than others but to me having good types (and a good compiler) makes or breaks a language. I can get my work done in anything but this is an area where the language really helps me out.

Re: Comparing OCaml and Standard ML

#58

Post by edwintorok »

jdh30 wrote: post #49
sgeisenh wrote: post #2

Purity is almost used in a pejorative sense throughout the page. If it wasn't for poor library support, I would prefer using SML to OCaml. SML is syntactically simpler and both SML/NJ and MLton have a lot to offer that I haven't yet found with OCaml. I think one of the biggest mistakes in the life cycle of SML was premature specification. As a result of the language definition, SML has stagnated for almost 20 years.…

> SML has stagnated for almost 20 years I'm still waiting for OCaml to get decent multicore support, decent Windows support and an FFI that doesn't suck donkey brains through a straw (which is why so many OCaml libraries, like OpenGL bindings, suck beyond belief). Multicore became ubiquitous 10 years ago. Last I looked the vestigial OCaml community still hadn't noticed.

Have a look at the 'Multicore OCaml' presentation here: https://ocaml.org/meetings/ocaml/2014/

TBH I don't miss multithreading in OCaml, if you write applications which expose some sort of API over a socket that will scale to clusters, not just multicore. And you can program those kinds of applications quite nicely with Lwt or Async already.

Regarding FFI, ocaml-ctypes is interesting, it allows you to bind to a C library at runtime using pure OCaml (and a wrapper around libffi), or to generate C stubs.

Regarding OpenGL there is a new binding called 'tgls' for OpenGL 3.x/4.x (besides LablGL) that is mostly generated from the XML description of the OpenGL APIs.

Regarding Windows support I can't say much because I don't use it at all, but there was a new 'Self-containted OCaml distribution for Windows' called ocpwin-distrib posted to the ML recently. If you care about Windows support you should probably give them feedback on what is missing.

Re: Comparing OCaml and Standard ML

#59

Post by shadowfox »

edwintorok wrote: post #58
jdh30 wrote: post #49

Earlier quoted context omitted.

> SML has stagnated for almost 20 years I'm still waiting for OCaml to get decent multicore support, decent Windows support and an FFI that doesn't suck donkey brains through a straw (which is why so many OCaml libraries, like OpenGL bindings, suck beyond belief). Multicore became ubiquitous 10 years ago. Last I looked the vestigial OCaml community still hadn't noticed.

Have a look at the 'Multicore OCaml' presentation here: https://ocaml.org/meetings/ocaml/2014/ TBH I don't miss multithreading in OCaml, if you write applications which expose some sort of API over a socket that will scale to clusters, not just multicore. And you can program those kinds of applications quite nicely with Lwt or Async already. Regarding FFI, ocaml-ctypes is interesting, it allows you to bind to a C lib…

Side note on Windows distributions: Besides ocpwin-distrib there is also Wodi [1] which started as a port of Godi and is fairly stable on windows.

[1] http://wodi.forge.ocamlcore.org/

Re: Comparing OCaml and Standard ML

#60

Post by imanaccount247 »

edwintorok wrote: post #58
jdh30 wrote: post #49

Earlier quoted context omitted.

> SML has stagnated for almost 20 years I'm still waiting for OCaml to get decent multicore support, decent Windows support and an FFI that doesn't suck donkey brains through a straw (which is why so many OCaml libraries, like OpenGL bindings, suck beyond belief). Multicore became ubiquitous 10 years ago. Last I looked the vestigial OCaml community still hadn't noticed.

Have a look at the 'Multicore OCaml' presentation here: https://ocaml.org/meetings/ocaml/2014/ TBH I don't miss multithreading in OCaml, if you write applications which expose some sort of API over a socket that will scale to clusters, not just multicore. And you can program those kinds of applications quite nicely with Lwt or Async already. Regarding FFI, ocaml-ctypes is interesting, it allows you to bind to a C lib…

>if you write applications which expose some sort of API over a socket that will scale to clusters, not just multicore

And it will be way slower for all those use cases where I don't need to scale to clusters. Or where it won't actually scale to clusters because I need shared memory, the latency to ask another node is simply too high. I had to move to haskell specifically because of ocaml's "who cares about multicore" stance.

Post reply on HN