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

Why I love OCaml (2023)

mccd.space

Post reply on HN
Print view View original

191–200 of 313 posts

Re: Why I love OCaml (2023)

#191

Post by le-mark »

timhh wrote: post #96

> why isn’t OCaml more popular I've used OCaml a bit and found various issues with it: * Terrible Windows support. With OCaml 5 it's upgraded to "pretty bad". * The syntax is hard to parse for humans. Often it turns into a word soup, without any helpful punctuation to tell you what things are. It's like reading a book with no paragraphs, capitalisation or punctuation. * The syntax isn't recoverable. Sometimes you can…

> The syntax is hard to parse for humans

This was my problem as well, the object oriented related syntax is just too much. ML of which caml is a version of, has really tight syntax. The “o” in ocaml ruins it imo.

Re: Why I love OCaml (2023)

#192

Post by int_19h »

m3at wrote: post #184
agentultra wrote: post #103

Why isn't it more popular? I think Richard Feldman [0] proposed some of the most reasonable theories as to why functional programming isn't the norm. Your language needs to be the platform-exclusive language for a widely used platform, have a killer application for a highly desired application domain, or be backed by a monster war-chest of marketing money to sway opinions. Since Feldman's talk, Python has grown much…

> mostly because it's the scripting language of choice for PyTorch and AI-adjacent libraries/tooling/frameworks I would politely disagree. Torch started in Lua, and switched to Python because of its already soaring popularity. Whatever drove Python's growth predates modern AI frameworks

Python was already big for scientists back in 2010. I remember working on Python tooling at the time, and DS/ML was one of our single largest user groups. It was already popular enough to have an IDE specifically for scientific Python use: https://en.wikipedia.org/wiki/Spyder_(software).

As far as I could tell, it had to do with two things. First, Python is notoriously dynamic and extensible, making it possible to implement "sloppy" syntax like advanced slicing or dataframes. But also, those guys had lots of pre-existing C and Fortran code, and Python had one of the easiest extensibility APIs to wrap it as high-level packages. And with IPython, you had a nice REPL with graphing to use all that from, and then of course notebooks happened.

Re: Why I love OCaml (2023)

#193

Post by int_19h »

karmakaze wrote: post #24

I've dabbled in F# (and aside from the rough setup with little coherent information at the time) had a pretty good time. Actor-based concurrency was easy to grok. The one gotcha was whenever those mutable Arrays entered the picture. I'd like to hear some practical reasons for preferring OCaml over F#. [Hoping I don't get a lot about MS & .NET which are valid concerns but not what I'm curious about.] I want to know mo…

OCaml is a much more powerful language. Take a look at functors, for example, or modules as first-class values, or GADTs, or its object system that can do type inference from use:

  # let foo x = x#frob;;
  val foo :  -> 'a =
F# is often called "OCaml for .NET", but it is a misrepresentation. It is an ML-family language for .NET, but aside from that ML core they don't have much in common.

Whether those features are more valuable to you than the ability to tap into .NET libraries depends largely on what you're doing.

Re: Why I love OCaml (2023)

#194

Post by int_19h »

vvpan wrote: post #150
zaphar wrote: post #72

Earlier quoted context omitted.

Having loops is not the defining feature that separates functional from imperative. Where did this idea come from? I'm suddenly seeing it in a lot of places.

It is not the defining feature but loss of the loop is one of the most obvious differences for people who look at a functional language Rust has immutability, pattern matching, etc, but it remains an imperative language with "some functional features". Or this is my subjective analysis.

But, again, loops aren't automatically imperative per se. Consider loop / recur in Clojure for an example. For someone coming from JavaScript, it's not really much different from writing a while loop where every branch has to terminate with an explicit break or continue.

Re: Why I love OCaml (2023)

#195

Post by Kwpolska »

timhh wrote: post #96

> why isn’t OCaml more popular I've used OCaml a bit and found various issues with it: * Terrible Windows support. With OCaml 5 it's upgraded to "pretty bad". * The syntax is hard to parse for humans. Often it turns into a word soup, without any helpful punctuation to tell you what things are. It's like reading a book with no paragraphs, capitalisation or punctuation. * The syntax isn't recoverable. Sometimes you can…

> * OPAM. In theory... I feel like it should be great. But in practice I find it to be incomprehensible, full of surprising behaviours, and also surprisingly buggy. I still can't believe the bug where it can't find `curl` if you're in more than 32 Unix groups.

I couldn’t believe this was an actual bug in opam, and I found it: https://github.com/ocaml/opam/issues/5373

I don’t think that’s an opam bug, it’s an issue with musl, and they just happened to build their binaries with it.

Re: Why I love OCaml (2023)

#196

Post by int_19h »

cyberpunk wrote: post #71
japhib wrote: post #51

Elixir is the closest thing to OCaml that has a chance at semi-mainstream usage IMO. It has basically all of the stuff about functional programming that makes it easier to reason about your code & get work done - immutability, pattern matching, actors, etc. But without monads or a complicated type system that would give it a higher barrier to entry. And of course it's built on top of the Erlang BEAM runtime, which ha…

immutability? Interactive Elixir (1.19.0) - press Ctrl+C to exit (type h() ENTER for help) iex(1)> x = 1 1 iex(2)> x = 2 2 iex(3)> What's immutable about elixir? It's one of the things which I MISS from Erlang -- immutability.

What you wrote is roughly equivalent to this in C:

  {
    const int x = 1;
    {
      const int x = 2;
    }
  }
which is to say, there are two different `x` in there, both immutable, one shadowing the other. You can observe this if you capture the one that is shadowed in a closure:

  iex(1)> x = 1
  1
  iex(2)> f = fn () -> x end
  #Function
  iex(3)> x = 2
  2
  iex(4)> f.()
  1

Re: Why I love OCaml (2023)

#197

Post by int_19h »

ModernMech wrote: post #33

>why isn’t OCaml more popular? OCaml did become popular, but via Rust, which took the best parts of OCaml and made the language more imperative feeling. That's what OCaml was missing!

Aside from ADTs, what else did Rust take from OCaml?

Re: Why I love OCaml (2023)

#198

Post by 999900000999 »

levzettelin wrote: post #132
ilaksh wrote: post #91

Why isn't it more popular if it's so good? Because popularity and merit are not the same thing. People confuse them all the time though. Check out the most popular music today. Like the top ten songs currently. Do you think those are really the best songs out there? Popularity is mostly driven by either trends or momentum.

Music being "good" is subjective. A programming language, however, can objectively be better if it allows a subset of programmers to better solve certain problems. The reason for why OCaml is not more popular, thus, is that this subset is small. The reason for this may be either (a) habit or (b) it's not that much better than other languages. I'm gravitating to (b). OCaml guys seem to be quite dogmatic for the wrong…

The popularity of a language usually translates into better support, tooling and learning materials.

Re: Why I love OCaml (2023)

#199

Post by jlouis »

creata wrote: post #180
jlouis wrote: post #163

Earlier quoted context omitted.

It's not isolation which hampers throughput. That's a red herring. In fact, isolation increases throughput, because it reduces synchronization. A group of isolated tasks are embarrassingly parallel by definition. The throughput loss stems from a design which require excessive communication. But such a design will always be slow, no matter your execution model. Modern CPUs simply don't cope well if cores need to send…

But the isolation is what necessitates (or at least encourages) a design that requires more communication, isn't it?

Not a priori.

The grand design of BEAM is that you are copying data rather than passing it by reference. A copy operation severs a data dependency by design. Once the copy is handed somewhere, that part can operate in isolation. And modern computers are far better at copying data around than what people think. The exception are big-blocks-of-data(tm), but binaries are read-only in BEAM and thus not copied.

Sure, if you set up a problem which requires a ton of communication, then this model suffers. But so does your GPU if you do the same thing.

As Joe Armstrong said: our webserver is a thousand small webservers, each serving one request.

Virtually none of them have to communicate with each other.

Re: Why I love OCaml (2023)

#200

Post by mrkeen »

neonsunset wrote: post #156
debugnik wrote: post #110

Earlier quoted context omitted.

It's a matter of trends: F# is losing compatibility with the overall CLR ecosystem due to the churn in C# features with poor F# interop, but F# has already mingled its design with the CLR's, too much to live on its own as a native language. Plus its compiler is slow and the tooling is getting increasingly unstable. Meanwhile, OCaml got rid of its global lock, got a really fast-compiling native toolchain with stable a…

> has an edge on some domains due to having unboxed types If a language makes "unboxed types" a feature, a specific distinction, and has to sell "removing global lock" as something that is a massive breakthrough and not table stakes from 1.0, it can't possibly be compared to F# in favourable light.

Where can I read more on F# unboxed types? My searches are only turning up examples of unboxed primitives.

Where's the equivalent to https://hackage-content.haskell.org/package/vector-0.13.2.0/... ?

Post reply on HN