Live data from Hacker News

What I wish I knew when learning OCaml (2018)

baturin.org

51–60 of 88 posts

Re: What I wish I knew when learning OCaml (2018)

#51
post #40

ML really is a beautiful and under-appreciated family of languages. Haskell is a bit too supernatural for my taste, but ML and its derivatives hit the sweet spot between powerful type systems and natural syntax. As a Kotlin developer, I find reading OCaml code a breeze and the compiler is refreshingly snappy (much faster than Gradle). I just wish it had better developer tools.

I like Rust for syntax, tooling, and ML ideas but I wish there was a "Rust-lite" that was garbage collected.

Re: What I wish I knew when learning OCaml (2018)

#52
post #15

Earlier quoted context omitted.

The syntax is not great, the standard library is very sparse, and the error messages from the compiler and interpreter are terrible (and used to be worse). The OCaml team used to treat the native code compiler (ocamlopt) as a second-class citizen, but it's the implementation that matters for performance. Since the end of Dennard scaling about 15 years ago, OCaml's lack of multithreading has also been a pain point, on…

Why do you think that the native compiler was treated as a second class citizen? This is quite strange take from my point of view. For instance OCaml native compiler was available on the M1 Macs two months after the M1 release. Similarly, all major CPU architectures (x86, ARM, PowerPC, RISC-V, s390x) have been supported for years.

20 and 25 years ago, the attitude (as I remember it) was that the native-code compiler was not very important because the bytecode interpreter was fast enough for most uses.

It's true that that is no longer the attitude. But if we want to understand why one language is more popular than another, we usually need to look at things that happened in the past, not just things that are happening right now. Even C's meteoric rise took 15 years from the first C compilers until it was the undisputed queen of programming languages, partly as a result of missteps made by the communities of ALGOL-68, ALGOL-W, Lisp, PL/I, SNOBOL, TRAC, FORTRAN, BCPL, and, perhaps most interestingly, MULTICS, 20 years earlier.

(It's also possible that my memory that the OCaml team treated the native-code compiler as a second-class citizen is incorrect, either because I misremember what they were saying or because I misinterpreted it.)

Re: What I wish I knew when learning OCaml (2018)

#53
post #40

ML really is a beautiful and under-appreciated family of languages. Haskell is a bit too supernatural for my taste, but ML and its derivatives hit the sweet spot between powerful type systems and natural syntax. As a Kotlin developer, I find reading OCaml code a breeze and the compiler is refreshingly snappy (much faster than Gradle). I just wish it had better developer tools.

I fully agree. F# is my favorite language, and it almost feels like a statically typed Scheme at times, just with built-in pattern matching and pipes thrown in. It's a really great way to program, and it's easy to go imperative or OOP when needed without friction.

The only thing missing from F# is an Elixir/Erlang/OTP-like process system (`MailboxProcessor` is pretty good though), but then again, every language except Elixir/Erlang/OTP is missing that.

Re: What I wish I knew when learning OCaml (2018)

#54

I tried OCaml a long time ago, and one of the things that really turned me off of it was all the inscrutable error messages. I went to #ocaml on Freenode for help, and when I had the error messages explained to me I asked how the person who explained them knew what they meant. He told me that the reason he knew was because he took a couple of semesters of type theory courses at his university. I didn't want to have t…

I haven't actually used OCaml in any depth, but I have found that F# tends to have quite good error messages. In the Programming Languages Coursera course, I found that SML has pretty bad error messages.

Re: What I wish I knew when learning OCaml (2018)

#55
post #15

Earlier quoted context omitted.

I wonder why this is the case. Ocaml syntax doesn't seem very arcane, it is not hell-bent on functional purism and pragmatically allows for imperative code. Performance seems quite reasonable. What does it lack that prevented it from gaining wider acceptance? Surely buy-in from a large company was an issue, but even F# hasn't seen any significant uptake. Is it really the lack of curly brackets? That didn't stop Pytho…

The syntax is not great, the standard library is very sparse, and the error messages from the compiler and interpreter are terrible (and used to be worse). The OCaml team used to treat the native code compiler (ocamlopt) as a second-class citizen, but it's the implementation that matters for performance. Since the end of Dennard scaling about 15 years ago, OCaml's lack of multithreading has also been a pain point, on…

All those things you mentioned in the first two paragraphs are fixed by F#, however, it is still not popular.

The reasons in that case are that .NET was not originally cross-platform, which was a major blunder for Microsoft, C#, and especially F#. The other is that people have some weird stigma against Microsoft, despite it not applying in many cases. Although they should have started off cross-platform, the transition from .NET Framework, to .NET Core, and now to .NET 5/6/7 has been really impressive. That along with GitHub and Visual Studio Code, it's pretty amazing how much progress Microsoft has made for developers.

I just wish it would bring more people to F#, as it's sort of a Goldilocks language since it hits so many sweet spots.

Re: What I wish I knew when learning OCaml (2018)

#56
post #50

Earlier quoted context omitted.

That was mostly a man-power issue. The good news is that nowadays such nonsensical error messages are near the top of my personal development priority for OCaml.

During those 25 years OCaml gained native-code compilers for new architectures, labeled arguments, and polymorphic variants, among other things. How could it be mostly a manpower issue?

Work and time contributed by open source collaborators on their free or academic time cannot be magically converted from one subsystem to another. It is honestly very easy to have progress on the aspects that spark interest while some subsystem are starved from attention when there are no full-time developers working on a project.

Re: What I wish I knew when learning OCaml (2018)

#57

Could someone please explain ? : type 'a list = 'a :: 'a list | [] The article says "::" is a Data Constructor. I can make sense of type 'a = Left of 'a | Right of 'a where Right and Left are the Data constructors but I don't see the link with the part I don't understand.

`|` is read as "or". `::` is syntax for what Lisp and Scheme call `cons`, which places an element onto either a list or the empty list, `[]`. The syntax `'a` is a type variable, which means that `'a` can be any type but it must all be the same type everywhere `'a` appears.

So this type definition means that `'a list` is a list of elements of type `'a`, and it's defined by being something of type `'a` consed onto either another list of type `'a` OR the empty list, represented by `[]`.

Re: What I wish I knew when learning OCaml (2018)

#58
post #52

Earlier quoted context omitted.

Why do you think that the native compiler was treated as a second class citizen? This is quite strange take from my point of view. For instance OCaml native compiler was available on the M1 Macs two months after the M1 release. Similarly, all major CPU architectures (x86, ARM, PowerPC, RISC-V, s390x) have been supported for years.

20 and 25 years ago, the attitude (as I remember it) was that the native-code compiler was not very important because the bytecode interpreter was fast enough for most uses. It's true that that is no longer the attitude. But if we want to understand why one language is more popular than another, we usually need to look at things that happened in the past, not just things that are happening right now. Even C's meteori…

Ah yes, it might be possible that during the time of Caml light, the bytecode compiler was for a time considered to be fast enough. I am not sure that a ephemeral stance from 25 years ago on an ancestor language still really matters nowadays.

Re: What I wish I knew when learning OCaml (2018)

#59
post #40

ML really is a beautiful and under-appreciated family of languages. Haskell is a bit too supernatural for my taste, but ML and its derivatives hit the sweet spot between powerful type systems and natural syntax. As a Kotlin developer, I find reading OCaml code a breeze and the compiler is refreshingly snappy (much faster than Gradle). I just wish it had better developer tools.

I like Rust for syntax, tooling, and ML ideas but I wish there was a "Rust-lite" that was garbage collected.

It's got its warts, but Ocaml (and ReasonML if you want a more familiar syntax) are right in that sweet spot for me.

Re: What I wish I knew when learning OCaml (2018)

#60

Earlier quoted context omitted.

I like Rust for syntax, tooling, and ML ideas but I wish there was a "Rust-lite" that was garbage collected.

It's got its warts, but Ocaml (and ReasonML if you want a more familiar syntax) are right in that sweet spot for me.

I need to give ReasonML another shot. It's been a few years, but at the time it really only seemed to work if you were targeting BuckleScript and even then you had to write a bunch of Makefiles and jump through other weird hoops. Beyond that, it suffered from some other OCaml issues--multiple "standard" libraries, different packages using different async libraries, some gratuitously abstract libraries, etc.

I'm really hoping it breaks into the mainstream such that it gets the investment that other mainstream languages get (hopefully said investment will smooth out these rough edges).

Post reply on HN