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

Why ML/OCaml are good for writing compilers (1998)

flint.cs.yale.edu

Post reply on HN
Print view View original

71–80 of 151 posts

Re: Why ML/OCaml are good for writing compilers (1998)

#71

Post by batmansmk »

throwaway7645 wrote: post #5
Dangeranger wrote: post #3

After learning Elm I wanted to understand ML/OCaml a bit more, so I worked through some documentation from the OCaml site and walked away pleasantly surprised. After using it for a couple of weeks I am confused why ML/OCaml aren't more popular. They are safe, functional, stable, fast, and have great tooling. They seem poised to take over the functional domain. While the syntax took a little getting used to ( emphasis…

Crappy windows support for OCaml. F# is similar to OCaml, but is very difficult for beginners and those not familiar with .NET. I also don't see a lot of beginner material for OCaml.

In France, my two first years of CS were taught in OCaml. 20k+ students are learning that way every year over there. We learn about recursions, complexity, types, compilers, language theory, graph theory ... without leaving the confort of one expressive language. I terribly missed OCaml when I had to realign with the technologies promoted in job offers and expected within the industry.

Re: Why ML/OCaml are good for writing compilers (1998)

#72

Post by 59nadir »

hyperpallium wrote: post #48
Drup wrote: post #36

Earlier quoted context omitted.

I would actually argue the opposite: ML languages propose the sweet spot of having functional features but still being flexible. Mutability, OO and various other feature are all there just when you need them. You don't need, like in Haskell, to do incredible contortions to be able to express things naturally. Regardless which algorithm and API you want, there is a pretty good chance you can express it in OCaml natura…

So, what's your answer to the question being asked, "why ML/OCaml aren't more popular" ? Sounds like you're in the same boat as the asker.

In practice languages don't need to be popular for you to use them. They might be hard sells to bosses and the like, but there is room for impopular technology in the market as well. All you need is a main advocate with enough sway with bosses and the like.

There are positions at companies using niche languages. Even though most companies prefer not to make broad technical decisions (even though they have CTOs, etc.), plenty of them do and so you're not going to find them making massively concurrent backends in Java.

Even in the situation where there are no jobs for a language, why would you really not use it if it's the best tool you have? The onus is not on the language/technology to make people realize it's great. The reverse is true too: It's not Java's, JavaScript's, C++, Ruby's or any other language's fault that people are stupid enough to make backends in them. Even if the majority of those languages/platforms were good it'd be stupid to use them for things they're designed not to do.

Re: Why ML/OCaml are good for writing compilers (1998)

#73

Post by 59nadir »

nv-vn wrote: post #17
akhilcacharya wrote: post #4

Earlier quoted context omitted.

>After using it for a couple of weeks I am confused why ML/OCaml aren't more popular For me, the issue is the GIL, although that is being worked on as we speak.

Sadly, I'm starting to lose my hope over multicore. It's been in the works for as long as I've used the language with much speculation of it being "almost done" or "in the next release" that have failed to materialize. That said, I don't have the time to really follow along with the compiler's development so take that with a grain of salt.

Precisely this is the reason I've lost hope with regards to OCaml as a main language. Multicore, specifically, is one of those things that has been "close" for so long that it's looking like a Duke Nuke'em Forever feature. I keep track of OCaml regularly because I love the language and I find that it's probably the best combination of features in one place, both in terms of my enjoyment as a programmer and in terms of the performance of the language.

I've come to realize later, though, that there's one glaring problem: Runtime inspection really is much more valuable to me than clean syntax and programmer comfortability when I'm building a system. With that in mind, maybe it'll never be very interesting to build a bigger system in a language like OCaml, even though it offers you a lot in terms of programmer efficiency as well as high performance.

Maybe it's better to glue together OCaml programs on the BEAM (The Erlang VM) so that you're able to orchestrate them and introspect them and get proper handling and oversight of the different components of your system. Maybe all that makes multicore in OCaml mostly pointless for you in practise.

Of course, not everyone will use the BEAM and OCaml together, so for them it matters a lot. I've come to see it as a worrying sign of a community that doesn't care to evolve enough, more than anything, and that's why OCaml is not as interesting as it could be.

It should be said that languages that supposedly are made for building systems also lack this runtime introspection and oversight. They have no way to locate and refer to their threads and no way to automatically handle their successes and failures. These languages are wildly popular, and so none of the above apparently matters to the vast majority of people. I think it's an interesting argument around (or against?) multicore in OCaml.

Re: Why ML/OCaml are good for writing compilers (1998)

#74

Post by idobai »

nikofeyn wrote: post #70
hongbo_zhang wrote: post #30

For web developers who are looking for an industrial strength functional language instead of JS, OCaml probably has the best story here. Actually it has two OCaml->JS compilers of very high quality The first one, js_of_ocaml, could bootstrap the whole compiler several years ago(probably the first one there). The recent one, https://github.com/bloomberg/bucklescript , push the JS compilation into next level, it genera…

better than clojure and f#?

Of course. f# is just an ocaml-copy. The other is just a lisp.

Re: Why ML/OCaml are good for writing compilers (1998)

#75

Post by willtim »

coolsunglasses wrote: post #29
rbehrends wrote: post #28

I'll note that some of the aspects don't necessarily work out like that in practice: 1. The GC part is true, but one has to remember that this was written at a time when GC was still a bit of an unusual feature in mainstream languages. 2. Tail recursion doesn't really make much of a difference for walking trees, which is recursive, but (mostly) not tail recursive. 3. OCaml in particular uses 63/31-bit ints due to imp…

>2. Tail recursion doesn't really make much of a difference for walking trees, which is recursive, but (mostly) not tail recursive. Non-strictness helps here more than TCO in a strict language. >4. ADTs can be good or bad for describing ASTs. Once you enrich ASTs with semantics shared by all variants (such as source coordinates), inheritance can become a better fit than ADTs. Since this article was written we have be…

More generally, functor sum and products allow composition of recursive data types. The cofree comonad, which Brian describes, is a special case of a functor sum.

Re: Why ML/OCaml are good for writing compilers (1998)

#76

Post by willtim »

rbehrends wrote: post #28

I'll note that some of the aspects don't necessarily work out like that in practice: 1. The GC part is true, but one has to remember that this was written at a time when GC was still a bit of an unusual feature in mainstream languages. 2. Tail recursion doesn't really make much of a difference for walking trees, which is recursive, but (mostly) not tail recursive. 3. OCaml in particular uses 63/31-bit ints due to imp…

ADTs and pattern matching are much more convenient and higher-level in practice than using OOP with inheritance. The visitor pattern, essentially just a fold, is the best one can do in an OOP language. With type-class abstractions and data type generic programming, the gap widens further.

In Haskell, my current FP language of choice, I can implement a complex transform such as Lambda lifting in a few 10's of lines of readable idiomatic code.

Re: Why ML/OCaml are good for writing compilers (1998)

#77

Post by cies »

haskellandchill wrote: post #42
atombender wrote: post #40

Earlier quoted context omitted.

I'm optimistic about Reason, Facebook's new syntax "skin" on top of OCaml. I find OCaml's syntax to be quite gnarly; of the MLs, F# is probably the cleanest and most modern-feeling. Something like F# without the .NET stuff could have been amazing.

I find OCaml's syntax simple and clear. I don't get the reason for Reason, but hope it leads to more OCaml adoption.

Reason is more then a "slightly improved syntax to help attract programmers from mainstream languages".

It also improves error messages and tooling. It has something akin to JSX built into the lang.

Re: Why ML/OCaml are good for writing compilers (1998)

#78

Post by cies »

jasim wrote: post #68
hongbo_zhang wrote: post #30

For web developers who are looking for an industrial strength functional language instead of JS, OCaml probably has the best story here. Actually it has two OCaml->JS compilers of very high quality The first one, js_of_ocaml, could bootstrap the whole compiler several years ago(probably the first one there). The recent one, https://github.com/bloomberg/bucklescript , push the JS compilation into next level, it genera…

And the OCaml-as-JS community is small and very welcoming. How often can you get first-class support from the compiler makers as a newbie? Hongbo Zhang and Jordan Walke and Cheng Lou are all on the Discord channel and are extremely helpful. Jump in fellas, the language is powerful, and the community is nice!

I can testify that the the Discord channels are a very welcoming place.

Re: Why ML/OCaml are good for writing compilers (1998)

#79

Post by cies »

nv-vn wrote: post #14
Dangeranger wrote: post #3

After learning Elm I wanted to understand ML/OCaml a bit more, so I worked through some documentation from the OCaml site and walked away pleasantly surprised. After using it for a couple of weeks I am confused why ML/OCaml aren't more popular. They are safe, functional, stable, fast, and have great tooling. They seem poised to take over the functional domain. While the syntax took a little getting used to ( emphasis…

I think MLs are kind of in limbo in regards to functional vs. imperative and OO vs. procedural programming. While they offer good OO, it's utilized very little. The functional features are used a ton, but don't dare approach the complexity of Scala, Haskell, etc., which is disappointing to a lot of more advanced functional programmers. They have reasonably good facilities for imperative programming, but these are mos…

> The whole language is, to an extent, a compromise over various paradigms that are very nearly mutually exclusive outside of ML.

I'd say the MLs are functional-first (with imperative/OO on top). Like Ruby OO-first (with some functional on top).

For me this type of multi-paradigm is ok. It starts to hurt when all the paradigms are "first", which I see in Scala.

Re: Why ML/OCaml are good for writing compilers (1998)

#80

Post by cies »

akhilcacharya wrote: post #4
Dangeranger wrote: post #3

After learning Elm I wanted to understand ML/OCaml a bit more, so I worked through some documentation from the OCaml site and walked away pleasantly surprised. After using it for a couple of weeks I am confused why ML/OCaml aren't more popular. They are safe, functional, stable, fast, and have great tooling. They seem poised to take over the functional domain. While the syntax took a little getting used to ( emphasis…

>After using it for a couple of weeks I am confused why ML/OCaml aren't more popular For me, the issue is the GIL, although that is being worked on as we speak.

Now that JaneStreet and Facebook are investing so much in the language, I think this feature is more likely to be implemented then ever.
Post reply on HN