6 ms·

Is Ocaml actually good or is it a meme that people use it and become obsessed with it. How is the transition if you mostly code imperatively? Are there things t

Is Ocaml actually good or is it a meme that people use it and become obsessed with it. How is the transition if you mostly code imperatively? Are there things that are not ergonomic for it to do like GUIs or games?

moonchrome 3y ago
Disclaimer : I didn't try Ocaml (weird numeric operators turned me off of it a decade ago) but I did use F# which is supposedly similar. But I don't know what you mean by imperative - for loops and stuff ? Most languages these days support functional programming concepts. Unless you're coming from C it shouldn't be that groundbreaking. Note that Ocaml isn't lazy by default like Haskell - now that makes things... interesting I guess.
xixixao 3y ago
Nowadays my primary concern is readability and understandability. Thrown into a codebase, can I understand what's going on? OCaml (which at FB was used to write the Flow typechecker and Hack compiler afair) favored higher order functions. I enjoyed playing with these in my Haskel-based introduction course at university, and I even wrote a similar language that favored them. But I now heavily dislike if `a b c` means "call to a with functions b and c with unknown arguments". I need to read all three (a, b, c) to really get what's going on. This was my biggest gripe with OCaml as it was used at FB. (purely syntactically compare this to `a(parent => b(parent), child => c(child))`, for some verbosity I get a clearer syntax - a is the callee, and I got some information about what b and c possible do - this is a contrived example of course). I think the strength of ML and Haskell got eroded as more "mainstream"y languages got decent type systems (TS/Flow, Hack, Kotlin, even Rust, Python is getting there).
- hardwaregeek 3y ago
  Yeah I think it’s kind of like how pg wrote about how using lisp gave him a disproportionate advantage. Sure, when people used fewer dependencies and the alternatives were C++, Python v1, and Perl, but these days a lot of languages have Lisp features and the cost of using a niche language is worse dependencies and tooling.
  - robocat 3y ago
    PG’s disproportionate advantage was productivity - despite LISPs disadvantages - which he writes about in depth here: http://www.paulgraham.com/avg.html http://www.paulgraham.com/avg.html I suspect that productivity gap would still exist because the primary productivity feature is macros, which are still either uncommon or limited in other languages: The source code of the Viaweb editor was probably about 20-25% macros. Macros are harder to write than ordinary Lisp functions, and it's considered to be bad style to use them when they're not necessary. So every macro in that code is there because it has to be. What that means is that at least 20-25% of the code in this program is doing things that you can't easily do in any other language. So why doesn’t LISP rule the software universe? I presume it is because it takes exceptional skill and taste to use macros productively. I also suspect it requires a small team because everyone needs to deeply understand many macros which are unique to the system developed - deep customisation has its costs. Certainly I have worked with plenty of programmers where I was pleased they didn’t have access to macros! PG has created two other languages (ARC and Bel) which shows a high level of skill, and perhaps also shows that LISP is not his ideal language? He wrote this about designing a programming language: http://www.paulgraham.com/popular.html http://www.paulgraham.com/popular.html and he writes about the history of LISP here: http://www.paulgraham.com/icad.html http://www.paulgraham.com/icad.html which also talks about productivity: if you were to compete with ITA and chose to write your software in C, they would be able to develop software twenty times faster than you [by using LISP]. ITA's hackers seem to be unusually smart
- yawaramin 3y ago
  Readability is very subjective and also people get used to syntax. Elm is widely considered to be one of the most readable syntaxes by its users.
- still_grokking 3y ago
  I'm not sure your example makes sense. `a b c` means `a(b, c)`. MLs just leaves out the parens. You can't know just form looking at `a b c` what `b` and `c` are. They may be functions of course. But also any other value. This would be exactly the same in for example JS. Nobody in JS ever complained that you can pass functions as arguments to functions and "don't see the arguments". (If you would write arguments you would actually call the function, and not pass it as a value.) But in OCaml you have a static type-system that can tell you at any point what `a`, `b`, or `c` are! Just hover the symbol. > I think the strength of ML and Haskell got eroded as more "mainstream"y languages got decent type systems (TS/Flow, Hack, Kotlin, even Rust, Python is getting there). I don't think so. Especially given those examples. TS/Flow doesn't have a sound type system. It may "type-check" fine and than explode at runtime. That's imho worse than dynamic typing as with dynamic typing you know at least that such fuck-up will happen. But TS delivers a false feeling of security about type safety where there is none. Hack is "gradually typed" which is just another word for dynamically typed with some static checks. So not even close to MLs. Python is also still dynamically typed, and that won't change. The bolted on type-checkers are unsound. So same situation as with TS. Nothing can be said about Kotlin afaik, as there was no formal work on its type-system. And Rust? Rust is a ML (with ugly C syntax)! So Rust is a prime example of how MLs are still one of the most modern and influential language designs to this day on. With Rust and Scala you have even two MLs in the Top20 languages. If something than ML is slowly but finally approaching mainstream. Maybe not in its original form but still the tradition lives on.
  - xixixao 3y ago
    I agree with you on TS being unsound. Flow on the other hand strove for soundness, as does Hack. Unfortunately TS dominated thanks to good strategy and some better ergonomics for open source (which were not a focus for FB). Rust is more ML than Flow or Hack because of traits (type classes? Not sure what ML calls them or if it even has them, Haskell does). But it’s a vastly different language otherwise, so I think the “other languages have learned from ML” is more accurate description of what’s happened. Some people write JS/TS in the ML style (point-free), but it’s not by far the most popular way. TC-39 came around to Hack-style pipelines for the same reason. For me the stylistic difference is a crucial indicator of preferences and priorities. Haskell’s operator “overuse” lives in a similar world.
faitswulff 3y ago
I think it was Steve Klabnik who said that it's basically the version of Rust with a garbage collector that people ask for. Might have been this episode of Oxide and Friends: https://oxide.computer/podcasts/oxide-and-friends/1208089 https://oxide.computer/podcasts/oxide-and-friends/1208089
- steveklabnik 3y ago
  Rust was originally described to me as “Rust and C have a baby,” so yeah I’ve been a fan of this kind of thinking for a long time.
  - carlmr 3y ago
    Rust is its own father? I think the borrow checker will make this difficult.
    - riwsky 3y ago
      Just need support for recursive lifetimes
      - still_grokking 3y ago
        Serious question: How would that work?
        steveklabnik 3y ago
        What do you mean by “that,” specifically? A bit hard to know what exactly you’re asking.
        still_grokking 3y ago
        Recursive lifetimes. The idea of the gp.
yawaramin 3y ago
You could always try it out and see for yourself :-) Here's a pretty good article about the transition: https://roscidus.com/blog/blog/2014/06/06/python-to-ocaml-retrospective/ https://roscidus.com/blog/blog/2014/06/06/python-to-ocaml-re...

moonchrome 3y ago

Disclaimer : I didn't try Ocaml (weird numeric operators turned me off of it a decade ago) but I did use F# which is supposedly similar. But I don't know what you mean by imperative - for loops and stuff ? Most languages these days support functional programming concepts. Unless you're coming from C it shouldn't be that groundbreaking. Note that Ocaml isn't lazy by default like Haskell - now that makes things... interesting I guess.

xixixao 3y ago

Nowadays my primary concern is readability and understandability. Thrown into a codebase, can I understand what's going on? OCaml (which at FB was used to write the Flow typechecker and Hack compiler afair) favored higher order functions. I enjoyed playing with these in my Haskel-based introduction course at university, and I even wrote a similar language that favored them. But I now heavily dislike if `a b c` means "call to a with functions b and c with unknown arguments". I need to read all three (a, b, c) to really get what's going on. This was my biggest gripe with OCaml as it was used at FB. (purely syntactically compare this to `a(parent => b(parent), child => c(child))`, for some verbosity I get a clearer syntax - a is the callee, and I got some information about what b and c possible do - this is a contrived example of course). I think the strength of ML and Haskell got eroded as more "mainstream"y languages got decent type systems (TS/Flow, Hack, Kotlin, even Rust, Python is getting there).

hardwaregeek 3y ago
Yeah I think it’s kind of like how pg wrote about how using lisp gave him a disproportionate advantage. Sure, when people used fewer dependencies and the alternatives were C++, Python v1, and Perl, but these days a lot of languages have Lisp features and the cost of using a niche language is worse dependencies and tooling.
- robocat 3y ago
  PG’s disproportionate advantage was productivity - despite LISPs disadvantages - which he writes about in depth here: http://www.paulgraham.com/avg.html http://www.paulgraham.com/avg.html I suspect that productivity gap would still exist because the primary productivity feature is macros, which are still either uncommon or limited in other languages: The source code of the Viaweb editor was probably about 20-25% macros. Macros are harder to write than ordinary Lisp functions, and it's considered to be bad style to use them when they're not necessary. So every macro in that code is there because it has to be. What that means is that at least 20-25% of the code in this program is doing things that you can't easily do in any other language. So why doesn’t LISP rule the software universe? I presume it is because it takes exceptional skill and taste to use macros productively. I also suspect it requires a small team because everyone needs to deeply understand many macros which are unique to the system developed - deep customisation has its costs. Certainly I have worked with plenty of programmers where I was pleased they didn’t have access to macros! PG has created two other languages (ARC and Bel) which shows a high level of skill, and perhaps also shows that LISP is not his ideal language? He wrote this about designing a programming language: http://www.paulgraham.com/popular.html http://www.paulgraham.com/popular.html and he writes about the history of LISP here: http://www.paulgraham.com/icad.html http://www.paulgraham.com/icad.html which also talks about productivity: if you were to compete with ITA and chose to write your software in C, they would be able to develop software twenty times faster than you [by using LISP]. ITA's hackers seem to be unusually smart
yawaramin 3y ago
Readability is very subjective and also people get used to syntax. Elm is widely considered to be one of the most readable syntaxes by its users.
still_grokking 3y ago
I'm not sure your example makes sense. `a b c` means `a(b, c)`. MLs just leaves out the parens. You can't know just form looking at `a b c` what `b` and `c` are. They may be functions of course. But also any other value. This would be exactly the same in for example JS. Nobody in JS ever complained that you can pass functions as arguments to functions and "don't see the arguments". (If you would write arguments you would actually call the function, and not pass it as a value.) But in OCaml you have a static type-system that can tell you at any point what `a`, `b`, or `c` are! Just hover the symbol. > I think the strength of ML and Haskell got eroded as more "mainstream"y languages got decent type systems (TS/Flow, Hack, Kotlin, even Rust, Python is getting there). I don't think so. Especially given those examples. TS/Flow doesn't have a sound type system. It may "type-check" fine and than explode at runtime. That's imho worse than dynamic typing as with dynamic typing you know at least that such fuck-up will happen. But TS delivers a false feeling of security about type safety where there is none. Hack is "gradually typed" which is just another word for dynamically typed with some static checks. So not even close to MLs. Python is also still dynamically typed, and that won't change. The bolted on type-checkers are unsound. So same situation as with TS. Nothing can be said about Kotlin afaik, as there was no formal work on its type-system. And Rust? Rust is a ML (with ugly C syntax)! So Rust is a prime example of how MLs are still one of the most modern and influential language designs to this day on. With Rust and Scala you have even two MLs in the Top20 languages. If something than ML is slowly but finally approaching mainstream. Maybe not in its original form but still the tradition lives on.
- xixixao 3y ago
  I agree with you on TS being unsound. Flow on the other hand strove for soundness, as does Hack. Unfortunately TS dominated thanks to good strategy and some better ergonomics for open source (which were not a focus for FB). Rust is more ML than Flow or Hack because of traits (type classes? Not sure what ML calls them or if it even has them, Haskell does). But it’s a vastly different language otherwise, so I think the “other languages have learned from ML” is more accurate description of what’s happened. Some people write JS/TS in the ML style (point-free), but it’s not by far the most popular way. TC-39 came around to Hack-style pipelines for the same reason. For me the stylistic difference is a crucial indicator of preferences and priorities. Haskell’s operator “overuse” lives in a similar world.

faitswulff 3y ago

I think it was Steve Klabnik who said that it's basically the version of Rust with a garbage collector that people ask for. Might have been this episode of Oxide and Friends: https://oxide.computer/podcasts/oxide-and-friends/1208089 https://oxide.computer/podcasts/oxide-and-friends/1208089

steveklabnik 3y ago
Rust was originally described to me as “Rust and C have a baby,” so yeah I’ve been a fan of this kind of thinking for a long time.
- carlmr 3y ago
  Rust is its own father? I think the borrow checker will make this difficult.
  - riwsky 3y ago
    Just need support for recursive lifetimes
    - still_grokking 3y ago
      Serious question: How would that work?
      - steveklabnik 3y ago
        What do you mean by “that,” specifically? A bit hard to know what exactly you’re asking.
        still_grokking 3y ago
        Recursive lifetimes. The idea of the gp.

yawaramin 3y ago

You could always try it out and see for yourself :-) Here's a pretty good article about the transition: https://roscidus.com/blog/blog/2014/06/06/python-to-ocaml-retrospective/ https://roscidus.com/blog/blog/2014/06/06/python-to-ocaml-re...