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

71–80 of 230 posts

Re: My thoughts on OCaml

#71

Post by yodsanklai »

the_af wrote: post #47
yodsanklai wrote: post #19

1. To print values, nowadays you just derive pretty printers automatically. 2. Syntax? yes, it's not C-like... you'll get used to it in a few days. 3. Lack of interface? would be helpful to see a concrete example of what the author finds limiting. You have modules, functors, includes, objects, first-order modules... Personally, I find that plain modules are simple and go a long way. It's not perfect, but I find that…

> 2. Syntax? yes, it's not C-like... you'll get used to it in a few days Since the author mentions Haskell as a positive example multiple times, I don't think a lack of C-like syntax is the problem for them here. Also, the author claims: > Since 2013 I’ve had the chance to use OCaml a few times in different jobs, and I got frustrated and disappointed every time I had to use it. So it's safe to assume "in a few days"…

Incidentally, I find Haskell syntax more confusing, specifically the semantic indentation. But maybe I'm like the author, I don't use Haskell regularly enough so that the syntax sinks in.

Re: My thoughts on OCaml

#72

Post by yodsanklai »

hardwaregeek wrote: post #67
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…

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…

> How can you print a user defined data type?

Pretty much the same way you'd do in Haskell or Rust: you add a `[@@deriving show]` directive to your datatype.

Re: My thoughts on OCaml

#73

Post by hpstewed »

JaggerJo wrote: post #12

I think you should give F# a shot instead. 1. No standard and easy way of implementing interfaces No problem in F#, you have interfaces, abstract classed, ... 2. Bad standard library In F# you have access to the full .NET standard library and ecosystem. There are also quite a lot of libraries that are especially designed to take advantage of F# (SQL libs for example). 3. Syntax problems 3.1 OCaml doesn’t have a singl…

I use F# at work. Really love the language but the connection to the dotnet ecosystem is a curse as much as a blessing. Having to operate in a world of nulls and exceptions can reduce/nullify the amazing benefits of discriminated unions. Often you are back to relying on the due dilligence of other developers as a result.

I use a lot of rust in my spare time. The runtime guarantees it offers make other languages feel like a house of cards in comparison, including F#. I coincidentally picked up an ocaml book yesterday seeking a more 'robust' alternative to F#. Unfortunately it seems as though ocaml is even more niche than F# (I doubt I'll be working for jane street any time soon)

Re: My thoughts on OCaml

#74

Post by atbpaca »

I learned OCaml two decades ago. It was great to learning algorithmics but I already had the feeling the language was old and awkward. Today there is Scala, Haskell, Rust, F# etc.

Re: My thoughts on OCaml

#75

Post by octachron »

ywei3410 wrote: post #46
WastingMyTime89 wrote: post #43

Earlier quoted context omitted.

Ocaml has no ad-hoc polymorphism but you can use parametrised modules to write generic code which you will have to specialise at some point. That brings you ninety percents of the way in term of what ad-hoc polymorphism is used for. It's more cumbersome but I prefer it to the complexity involved by what Scala does for exemple.

Would you not consider the object system to be ad-hoc polymorphism?

The OCaml object system is still parametric polymorphism (trying to pass itself as subtyping polymorphism through row variables) rather than ad-hoc polymorphism: there are still no functions that only work on a finite subset of types. In other words, a function may work on any objects that has a method `m`, but you cannot have the same method that has different implementation for `int` and `float`.

Re: My thoughts on OCaml

#76

Post by ywei3410 »

hardwaregeek wrote: post #67
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…

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 a type that you want to convert from such as foo and bar, then you do `Foo.to_bar value`.

We can keep going, but you can get the point.

You _can't_ judge a language by doing what you want to do with one language in another. If I judge Rust by writing recursive data structures and complaining about performance and verbosity that's not particularly fair correct? I can't say that Dart is terrible for desktop because I can't use chrome developer tools on its canvas output and ignore it's hot-reloading server. I can't say Common Lisp code is unreadable because I don't have type annotations and ignore the REPL for introspection.

[1] https://github.com/ocaml-ppx/ppx_deriving

Re: My thoughts on OCaml

#77

Post by dimitrios1 »

JaggerJo wrote: post #14
nu11ptr wrote: post #5

I like OCaml, but if I were to start a new project with an ML I'd probably lean towards F# to take advantage of all the .NET libs

We use F# in prod. Could not be happier.

Completely ignorant here:

- I really want to do a project in an almost "pure" functional language. I tried with Elixir and Phoenix, and while they are certainly great, and I wouldn't mind using it again, Elixir, and subsequently Erlang didn't feel like FP a lot of times, it felt like the warty Elixir/Erlang way to do FP, so it didn't scratch that itch for me (but again, still a great experience overall)

- is there a way to do this openly? I.E. with dotnetcore, running on linux containers, no windows what so ever, etc? Guessing yes but wanted to make sure from people who have actually done it

- What exactly about the .NET libraries that has everyone so hyped up about? I remember from my C# .NET days, they always felt to be lacking.

Re: My thoughts on OCaml

#78

Post by ywei3410 »

Miltnoid wrote: post #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 completel…

They require `sexp_of_t` and `t_of_sexp` because of their workflow being based on them; such as expectation testing [1] and tools such as [2]. It's a less noisy alternative to json for many people.

[1] https://blog.janestreet.com/testing-with-expectations/ [2] https://github.com/janestreet/sexp

Re: My thoughts on OCaml

#79

Post by decafninja »

felixyz wrote: post #70
decafninja wrote: post #11

Earlier quoted context omitted.

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…

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, would an engineer well versed in some exotic language, and can land offers at top companies, come work for a boring cludgy Fortune500 company that is only willing to pay a fraction of what they can get elsewhere?

Maybe if you've already made your fortune elsewhere and well on the road to FIRE, and are really just looking for interesting work regardless of pay.

Re: My thoughts on OCaml

#80

Post by spqr233 »

boxed wrote: post #31
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…

To me it seems he gave it a lot of chance in order to find this many problems. It does sound to me like you stopped reading after the first point. Maybe you didn't give the post a chance?

It's more that only really strongly disagreed with that point. Frankly, there are some cons with using Ocaml. In practice, I think the library support for ocaml isn't completely there given the small community.
Post reply on HN