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

My thoughts on OCaml

osa1.net

Post reply on HN
Print view View original

81–90 of 230 posts

Re: My thoughts on OCaml

#81

Post by hardwaregeek »

ywei3410 wrote: post #76
hardwaregeek wrote: post #67

Earlier quoted context omitted.

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 doe…

> You gave a beautiful answer about programming language You do the same thing as in Rust, Scala or Haskell and derive the printer [1]. Then at the callsite, if you know the type then you do `T.show` to print it or `T.eq`. If you don't know the type, then you pass it in at the top level as a module and then do `T.show` or `T.eq`. > Or to convert one type into another type? If you want to convert a type, then you have…

Okay...so you have to add a third party library to print? Yes, recursive data structures are a pain in Rust (well, recursive multi-owner data structures). But that's like comparing changing your oil to opening your car door. We do one of these a lot more. And bear in mind, I had to find this answer by googling and reading a random forum post. That's some pretty poor documentation.

And that's not talking about aesthetics. `T.show foo` or `Foo.to_bar value` is a lot of syntactic overhead for a rather common task.

And again, these are the lesser concerns to the other ones I outlined. Reading the code, building the code, and understanding the compiler errors are the big ones.

Re: My thoughts on OCaml

#82

Post by pjmlp »

AlotOfReading wrote: post #66
pjmlp wrote: post #57

Earlier quoted context omitted.

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.

Nowadays most of those folks are no longer at MSR, Don Syme has moved into Github and I doubt they are into F#.

Re: My thoughts on OCaml

#83

Post by felixyz »

decafninja wrote: post #79
felixyz wrote: post #70

Earlier quoted context omitted.

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…

There's another aspect, which myself and a few others in this thread have mentioned - hireability. Both from the company's and employee's perspective. I'm pretty sure Jane Street would have paid well even when they were an obscure name. Will boring cludgy Fortune500 company or noname startup pay well for someone to come use an exotic tech stack that is used very rarely at any other companies? Likely not. Likewise, wo…

So are you saying that Jane Street more or less bribed people who didn't really care for OCaml to come work in a weird language, by offering a good salary? I find that far-fetched, and there are many other examples of companies attractive highly-competent people because they choose -- no, not exotic, weird, or niche tech, but good tech, that aid people thinking more clearly and abstracting better.

As in everything else, there is a trade-off involved here of course. And what is truly good and helpful is by no means obvious, and might take time to assess.

Re: My thoughts on OCaml

#84

Post by kthielen »

This piece focuses on complaints about ocaml, and the last half seems to just be syntax complaints (which I mostly ignore just because every language seems to have awkwardness in its syntax -- certainly Haskell, a language otherwise held up as an example, can be shown to accept some really weird text).

Good things about ocaml that I think should be mentioned are Hindley-Milner type inference (some might argue this, but it's a very effective system for inferring types), and also straightforward semantics (it's usually pretty easy to look at some code and make a reasonably accurate guess about what it will do on real hardware -- compare with Haskell).

I'm sympathetic toward the initial complaints here, which I also think are the most substantive. Type classes and qualified types, as in Haskell, would be very useful in ocaml/ML. The examples offered (show_of_int, show_of_double, ...) are valid, and also the related complaint that dishonestly broad types like structural equality (where runtime errors are raised for cases where the types are actually not supported) also make a compelling case for qualified types in ML.

I made this project ~10 years ago after making similar observations: https://github.com/morganstanley/hobbes

Things like structural equality and ordering are user functions here rather than magic internal definitions (e.g. equality is defined as a type class, and type class instances can deconstruct algebraic types at compile time to decide how to implement instances). But evaluation is eager by default, so it's pretty easy to reason about performance. And data structures can be persisted to files and/or shared transparently in memory with C/C++ programs without translation, also very convenient for the places where this was used. Actually we built some very big and complicated time series databases with it, used in both pre and post trade settings where ~15% of daily US equity trades happen. So I think these observations are useful and have passed through some pretty significant real tests.

Re: My thoughts on OCaml

#85

Post by decafninja »

felixyz wrote: post #83
decafninja wrote: post #79

Earlier quoted context omitted.

There's another aspect, which myself and a few others in this thread have mentioned - hireability. Both from the company's and employee's perspective. I'm pretty sure Jane Street would have paid well even when they were an obscure name. Will boring cludgy Fortune500 company or noname startup pay well for someone to come use an exotic tech stack that is used very rarely at any other companies? Likely not. Likewise, wo…

So are you saying that Jane Street more or less bribed people who didn't really care for OCaml to come work in a weird language, by offering a good salary? I find that far-fetched, and there are many other examples of companies attractive highly-competent people because they choose -- no, not exotic, weird, or niche tech, but good tech, that aid people thinking more clearly and abstracting better. As in everything el…

"Bribed" is a crude way to describe it, but in a manner of speaking, yes?

I think you might be a tad idealistic, and you might think I'm being a tad cynical. Maybe the truth is in the middle somewhere.

But throwing enough money at someone can talk. And not throwing enough money at someone can also talk. Short of being asked to do something unethical or illegal, what's wrong with that?

Can you honestly say all of the talented top engineers out there working for top paying companies are doing it for the pursuit of technological perfection, and aren't doing it at least partially for the good money?

I would say the same thing about doctors - people all love to say you should not get into medicine for money, but can we honestly say money isn't at least a factor in whether someone decides to pursue a MD?

Re: My thoughts on OCaml

#86

Post by yawaramin »

hardwaregeek wrote: post #81
ywei3410 wrote: post #76

Earlier quoted context omitted.

> You gave a beautiful answer about programming language You do the same thing as in Rust, Scala or Haskell and derive the printer [1]. Then at the callsite, if you know the type then you do `T.show` to print it or `T.eq`. If you don't know the type, then you pass it in at the top level as a module and then do `T.show` or `T.eq`. > Or to convert one type into another type? If you want to convert a type, then you have…

Okay...so you have to add a third party library to print? Yes, recursive data structures are a pain in Rust (well, recursive multi-owner data structures). But that's like comparing changing your oil to opening your car door. We do one of these a lot more. And bear in mind, I had to find this answer by googling and reading a random forum post. That's some pretty poor documentation. And that's not talking about aesthet…

You don't need a third-party library to derive a pretty-printer for your types, it just makes it simpler. OCaml takes the approach that the core compiler doesn't do any codegen, that is left to PPXs (basically, middlewares which transform code) which run before the compiler.

You can write a pretty-printer yourself using the conventions of the `Format` module. Is it manual and annoying? Yeah. That's why the PPX exists. It's a tradeoff.

Re: My thoughts on OCaml

#87

Post by yawaramin »

maleldil wrote: post #69
spqr233 wrote: 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?

Mostly the former. The compiler infers the type of the implementation and ensures it conforms to the interface. But, you can further restrict the interface's type to hide details from the outside world.

Re: My thoughts on OCaml

#89

Post by wk_end »

sgeisenh wrote: post #9
4ad wrote: post #8

[flagged]

Especially if modular implicits land, you get the best of both functions and typeclasses. Pretty weird way to start the post.

That's a big "if". The author themselves mentions modular implicits and points out that they haven't been updated in something like five years. I don't think modular implicits are going to happen in Ocaml in our lifetimes.

Re: My thoughts on OCaml

#90

Post by ywei3410 »

hardwaregeek wrote: post #81
ywei3410 wrote: post #76

Earlier quoted context omitted.

> You gave a beautiful answer about programming language You do the same thing as in Rust, Scala or Haskell and derive the printer [1]. Then at the callsite, if you know the type then you do `T.show` to print it or `T.eq`. If you don't know the type, then you pass it in at the top level as a module and then do `T.show` or `T.eq`. > Or to convert one type into another type? If you want to convert a type, then you have…

Okay...so you have to add a third party library to print? Yes, recursive data structures are a pain in Rust (well, recursive multi-owner data structures). But that's like comparing changing your oil to opening your car door. We do one of these a lot more. And bear in mind, I had to find this answer by googling and reading a random forum post. That's some pretty poor documentation. And that's not talking about aesthet…

Not really third-party; ocaml-ppx is something similar to `javax` in the Java space? But it is optional and doesn't come bundled with OCaml.

Recursive structures are only rare in Rust _because_ they suck to write and have terrible performance characteristics in the language. In languages like Haskell, OCaml and Scala using tagless initial encodings for eDSL's [2] are really, really common.

I don't write Rust like I write any semi-functional language with function composition because, well, it's _painful_ and not a good fit for the language.

> `T.show foo` or `Foo.to_bar value` is a lot of syntactic overhead

The `T.()` opens a scope so OCaml code generally looks like:

``` let foo = T.(if equal zero x then show x else "not here") ```

for,

``` fn foo(t: T) -> String { if(t == T::ZERO) { t.show() } else { "not here".into() } } ```

Even when talking about usage, each language community for better or worse has a predefined workflow in mind. Your questions and workflow are specific to a particular language; you don't, for example, ask about the REPL, the compile times, debugging macros, the cold-start of the compiler, whether hot-reloading is a thing, the debugger, how it interacts with perf, how to instrument an application. Presumably because the language you use or the programs that you make don't have those components as part of their main workflow.

[1] https://github.com/ocaml-ppx [2] https://peddie.github.io/encodings/encodings-text.html

Post reply on HN