Live data from Hacker News

My thoughts on OCaml

osa1.net

61–70 of 230 posts

Re: My thoughts on OCaml

#61
post #3

Why would a company use ocaml? I’ve worked in software now for most of my life, from small to the biggest companies. I’ve watched teams with senior developers use non mainstream languages to build services and just about every time those devs get board again, leave the team, leaving them stuck with this system that’s hard to develop and different from the rest of the orgs, eventually resulting in a complete rewrite.…

> Why would a company use ocaml?

Why wouldn't a company use Brainfuck?

Re: My thoughts on OCaml

#63
I used OCaml as my daily driver in grad school and my postdoc, and recommend my students use it. I think the main benefits of OCaml are:

Functional Has mutable references Not lazy

Haskell's type system is just better. But for large, complex systems that require performant code, it can be quite difficult to track the laziness, and sometimes life is just easier if I can use a mutable references.

The author is completely correct that there's a big failure in the lack of a type-class-like system. This is why people ask so much for modular implicits. Core is also a decent standard library (though I don't know why they require sexp_of_t and t_of_sexp on like all their data structures).

So I'd gladly use a different functional language with mutable references and strict evaluation. But there isn't any besides F#, and I have a Mac and don't personally want to figure out .NET on Mac.

Re: My thoughts on OCaml

#64

> Another example is the sequencing syntax ; and productions with as the right-most symbol: let test1 b = if b then print_string "1" else print_string "2"; print_string "3" > Here print_string "3" is not a part of the if expression, so this function always prints “3”. Well, yeah. Here's the equivalent Java code: void test1(bool b) { if (b) print_string("1"); else print_string("2"); print_string("3"); } You've chosen…

> You could argue that Java (and C, and C++, and Javascript, and...) has the same "ambiguous parsing problem", then -- except that it doesn't

The author didn’t claim there’s any ambiguity in parsing, only ambiguity in reading as a human. And I would agree that all the languages you mentioned have the same problem. And this is a real problem as long as people use this form of if (which they do). New languages avoid this pitfall by mandating the use of braces, in return dropping the parens, and I think that’s great.

Re: My thoughts on OCaml

#65

> Another example is the sequencing syntax ; and productions with as the right-most symbol: let test1 b = if b then print_string "1" else print_string "2"; print_string "3" > Here print_string "3" is not a part of the if expression, so this function always prints “3”. Well, yeah. Here's the equivalent Java code: void test1(bool b) { if (b) print_string("1"); else print_string("2"); print_string("3"); } You've chosen…

Agreed except for the part at the end: Java, C, C++, and JavaScript definitely do have the "dangling else" problem! It's a manifestation of the same basic issue. Who is saying they don't? You just showed how they do! It is a real problem and they all have it. The takeaway here isn't that those languages don't have the issue. They do. It's just really common in language design, that's all; certainly not something to single out OCaml about. Apple's infamous "goto vulnerability" was directly caused by this language design issue in good old C.

https://en.wikipedia.org/wiki/Dangling_else (just to show that this is something people commonly consider to be a problem with Java, C, C++, and JavaScript)

Re: My thoughts on OCaml

#66
post #57

Earlier quoted context omitted.

F# is such a great language. The fact Microsoft seems to pretend it doesn't exist is bewildering. Surely the .Net ecosystem can have two languages being promoted.

Before F# came into VS 2010, we already had C#, VB, C++/CLI (nee Managed C++), IronPython, IronRuby, and all the third parties targeting the CLR. It is really not having a clue what purpose they want for F#, I bet they have repented to ship it on VS2010. First it was for libraries only, then during the VS Express days it was for Web development, now they are trying to pivot it into data analysis and ML, while DevDiv…

F# was originally just kind of a passion project that MS insisted get productized to continue development. It's still very much an internal favorite within Microsoft Research and the Bing team, from my understanding.

Re: My thoughts on OCaml

#67
post #26

I don't the author really gave Ocaml a chance. He argues that every language needs to have interfaces. I agree somewhat with that statement, but I think the truer statement is to say that every language needs to have some way of defining composition at a structural level. An interface allows you to pass different "structures" to the same function so long as they adhere to the same spec. In Ocaml this is accomplished…

Politely, I feel like this is the issue with OCaml as a community. You gave a beautiful answer about programming language design and composition. But how does it feel to write the language? How can you print a user defined data type? From reading around, it seems like your options are: explicitly pass a print function for that specific type, use a third party library for printing, or (my "favorite") don't. Or how does it feel to write a function that takes a generic that can be printed, checked for equality, and read? Or to convert one type into another type?

And we're still talking about semantics here. How does it feel to use the language server? How does it feel to read the code? To build the language? Ultimately that's what users judge a language on. Yes, Rust in some ways has a worse form of abstraction. It is global, not fully generic and doesn't allow for overloading. But it creates a user experience that is nicer. It lets a user print something and compare two variables and do type conversions without having to scratch their head, read a forum post and import a library.

Re: My thoughts on OCaml

#68
Knowing the virtually dead Standard ML is a curse when it comes to appreciating the aesthetics of OCaml. The two languages have similar syntax, but in just about every way they differ, OCaml syntax took the ugly road :(

Re: My thoughts on OCaml

#69
post #26

I don't the author really gave Ocaml a chance. He argues that every language needs to have interfaces. I agree somewhat with that statement, but I think the truer statement is to say that every language needs to have some way of defining composition at a structural level. An interface allows you to pass different "structures" to the same function so long as they adhere to the same spec. In Ocaml this is accomplished…

> Ocaml's module system means that you can describe the async runtime as a signature and make your entire library generic to the async runtime it runs on top of

Is this the program describing the interface it expects, and the compiler matching that with the implementations structure (e.g. Go interfaces, Python Protocols), or is it something someone declares and the libraries implement?

Re: My thoughts on OCaml

#70
post #3

Why would a company use ocaml? I’ve worked in software now for most of my life, from small to the biggest companies. I’ve watched teams with senior developers use non mainstream languages to build services and just about every time those devs get board again, leave the team, leaving them stuck with this system that’s hard to develop and different from the rest of the orgs, eventually resulting in a complete rewrite.…

I'm sure some companies out there might find a competitive advantage for using exotic languages and tech stacks. But I get the impression the more common scenario is that the engineers were bored and given the chance, wanted to play with something new and shiny. It also depends on the company's prestige. A company like Jane Street using OCaml? Considering both their prestige and the amount they pay, I'm sure they wil…

Jane Street wasn't all that prestigious when they started using OCaml. The way they put it is "it was easier to find great programmers in the empty set of people who know OCaml than in the huge set of other programmers" (roughly). So, on the contrary, I think it might help boring cludgy company find quality talent.

I think there is a fallacy being repeated in this thread, namely that the choice is between mainstream and weird, or between old-and-tested and new-and-shiny. No, that's not the choice. The choice is between tools and abstractions that are helpful and productive, and those that aren't. Some of the helpful and productive things are old, some are new, some are mainstream, some are niche.

I don't fully understand how someone wants to spend their career in programming and not actively seek out what is helpful and productive, rather than what currently gets the most questions on Stack Overflow or has a big pool of people who put it on their CV. It's not like all languages are equally good. It's a wasteful approach.

Post reply on HN