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

What I wish I knew when learning OCaml (2018)

baturin.org

Post reply on HN
Print view View original

11–20 of 88 posts

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

#11

Post by pmoriarty »

WastingMyTime89 wrote: post #9
pmoriarty wrote: post #7

Earlier quoted context omitted.

"adding type annotations in some places will help with error messages." I annotated the hell out of my programs, and completely avoided OCaml's type inference as much as I could because I saw that it could not guess what I meant. I still had tons of problems understanding the error messages. Error messages like "This expression is of type X but an expression was expected of type X" were not uncommon, and super frustr…

> I annotated the hell out of my programs, and completely avoided OCaml's type inference as much as I could because I saw that it could not guess what I meant. The type checker and the type inference parts of the compiler are one and the same. If the type checker can’t infer what you mean you are most likely writing invalid code. > Error messages like "This expression is of type X but an expression was expected of ty…

"you are most likely writing invalid code"

Of course I'm writing invalid code: that's why I'm getting error messages. The problem is that I'm having trouble understanding why it's invalid. Error messages are supposed to help me here, but quite often they didn't.. they just led to more confusion... especially in complex code, where I needed help and clarity most.

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

#12

Post by dgan »

gpderetta wrote: post #10
nnoitra wrote: post #4

Earlier quoted context omitted.

They're barely used in industry.

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…

Libraries!!! Python is "batteries included" while OCaml barely has insulation around electrical wires. EDIT: okey that actually maight be a chicken-egg reasonning

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

#13

Post by WastingMyTime89 »

gpderetta wrote: post #10
nnoitra wrote: post #4

Earlier quoted context omitted.

They're barely used in industry.

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…

If Ocaml had been designed in the USA it would have been widely successful. It’s main drawback was being mostly a French project.

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

#14

Post by asplake »

nnoitra wrote: post #4
pharmakom wrote: post #2

A good list. ML languages push you (kicking and screaming) into the pit of success.

They're barely used in industry.

But look at their influence: TypeScript and Rust, not to mention Elm, PureScript and other less mainstream languages

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

#15

Post by kragen »

gpderetta wrote: post #10
nnoitra wrote: post #4

Earlier quoted context omitted.

They're barely used in industry.

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, one which is finally starting to improve in the last year or two.

I don't think being labeled "functional" was ever a huge stigma. Being labeled "Haskell" is a huge stigma in some circles, but OCaml's never been labeled "Haskell". Until about 10 years ago functional programming didn't become popular enough to have any kind of popular opinion, positive or negative, and the people who knew about it generally thought it would be nice to do more of it.

Mostly I think people use a programming language either because they already know it or it's the scripting language for an environment they have to use. Assembly was the scripting language for your CPU, especially in mainframe days. BASIC was the scripting language for personal computers. Visual Basic was the scripting language for WIMPs. VBA was the scripting language for Excel and Word (previously Excel had a table-based macro thing). sh was the scripting language for the Unix filesystem; C was the scripting language for the Unix system call interface, and a nice upgrade from assembly. JS was and is the scripting language for the browser. Lua is the scripting language for WoW, Roblox, and Minetest. Perl was the scripting language of the WWW, then PHP was, or Ruby if what you really want to script is Rails. SQL is the scripting language for your database. Objective-C was the scripting language for NeXTStep; now Swift is. MATLAB was the scripting language for EISPACK and later *PACK and BLAS, though it had some competition from IDL for a while. Now Python is the scripting language for Numpy (and thus BLAS), Matplotlib, and TensorFlow. Only a few popular languages are exceptions to this rule: Fortran, COBOL, C++, Java, R, Pascal, Golang, and C#.

OCaml? OCaml is the scripting language of ocamlyacc and Coq. If you write OCaml then it's probably because you like Coq. This may have been a public relations problem in the Anglosphere, especially before same-sex marriage.

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

#16

Post by usrnm »

WastingMyTime89 wrote: post #13
gpderetta wrote: post #10

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…

If Ocaml had been designed in the USA it would have been widely successful. It’s main drawback was being mostly a French project.

> If Ocaml had been designed in the USA it would have been widely successful

I doubt that. There are plenty of American SML dialects and F# is about as American as it gets, but neither of these languages saw any commercial success.

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

#17

Post by kragen »

WastingMyTime89 wrote: post #9
pmoriarty wrote: post #7

Earlier quoted context omitted.

"adding type annotations in some places will help with error messages." I annotated the hell out of my programs, and completely avoided OCaml's type inference as much as I could because I saw that it could not guess what I meant. I still had tons of problems understanding the error messages. Error messages like "This expression is of type X but an expression was expected of type X" were not uncommon, and super frustr…

> I annotated the hell out of my programs, and completely avoided OCaml's type inference as much as I could because I saw that it could not guess what I meant. The type checker and the type inference parts of the compiler are one and the same. If the type checker can’t infer what you mean you are most likely writing invalid code. > Error messages like "This expression is of type X but an expression was expected of ty…

> Ocaml is a strongly typed static language. As such your code has to respect type constraints. It’s very much a feature not a bug.

That's reasonable if the error message were "This expression is of type X but an expression was expected of type Y". But the worst error message in the OCaml interactive toplevel is when they're the same. This happened when you defined a new type named X (which, incidentally, must be lowercase), but there were still references to things of the old type X.

I think this has been fixed in recent versions of OCaml.

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

#18

Post by chii »

gpderetta wrote: post #10
nnoitra wrote: post #4

Earlier quoted context omitted.

They're barely used in industry.

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…

It's not that there's stigma, but that it is probably more difficult to think functionally when most programming education teaches imperative methods.

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

#19

Post by kragen »

yodsanklai wrote: post #6
pmoriarty wrote: post #3

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 think both of these points can be alleviated with certain coding habits that come with practice. For instance, adding type annotations in some places will help with error messages. And using "assert false" (which has type 'a) will let you run an incomplete/broken program. As for the error messages requiring expertise in type theory, it sounds as an exaggeration, esp. when not using advanced features.

Hey, thanks for that "assert false" trick! I never knew that!

I don't know much about type theory but I did eventually manage to learn to interpret OCaml's type errors well enough to get things to compile. It still feels like driving a car by scraping it along a highway guardrail but it's often better than testing. I have to write twice as much code as in Python, it takes me longer to get it to run, and I still can't call it from C or Lua, but it runs twenty times as fast as Python and the process of thinking through the types helps me a lot to write code that works.

I keep hoping I'll internalize the type system enough that my programs run the first time they way they do in Python, but it hasn't happened yet.

I still often write a prototype in Python, though.

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

#20

Post by kryptiskt »

dgan wrote: post #5

TIL that Ocaml/SML are compiled into lambda expressions... I literally thought lambda calculus is only used in CS classes. OCaml's syntax is pretty annoying but type inference is actually amazing.. I changed my mind over it, as previously I thought explicit type annotations are simpler. Turns out, it would be humanly impossible to explicitly annotate every piece of OCaml, just let the compiler do it for you

GHC's Core language is amazingly small https://gitlab.haskell.org/ghc/ghc/-/wikis/commentary/compil..., and it's just polymorphic lambda calculus (with coercions added a while ago).
Post reply on HN