5 ms·

Can't comment on the comparison to Rust, but I recently spent quite some time learning OCaml, working through the excellent and freely available cs3110 course h

Can't comment on the comparison to Rust, but I recently spent quite some time learning OCaml, working through the excellent and freely available cs3110 course https://cs3110.github.io/textbook/cover.html https://cs3110.github.io/textbook/cover.html ; I really really wanted to like the language... I agree w/ the submitted article about the heavy reliance on linked lists and recursion, but what disillusioned me from it is that after many weeks of study I discovered competitive programming and on a whim started doing some easy problems. Since I was spending most of my time w/ OCaml at that point I thought it could also be a way to practice it further. So for a particularly easy problem it would go something like this: A straight forward, easy to read, performant C++ solution took me 10 minutes; an ugly unidiomatic OCaml version took me 30 minutes; and a beautiful idiomatic OCaml version using recursion that still no non-OCaml programmer could ever read took me something like an hour... It really dawned on me that after weeks of studying OCaml I barely knew how to write anything particularly useful in it from scratch. Dealing with user input/output still seemed cumbersome, given everything's immutability... from an intellectual perspective it feels interesting, and I had fun with it, but for now I decided I couldn't see myself becoming productive enough in it to justify further sinking time into it. There's so much to still learn for me (doing a network related project at the moment learning a ton about networking, sockets, etc), that trying to become an unproductive OCaml programmer probably shouldn't be high up my list of priorities... and that is not to say people aren't productive in it, that's to say that I don't see myself becoming productive in it any time soon, compared to being productive in C++ while being far away from being any expert in it. Maybe I'm too stupid for it, am not suited for it, need a few years of further programming to appreciate some things about it... but for now, sadly, I feel like I've wasted significant time I should have better spent on studying other topics and actually working on projects. And addendum: Never comment on downvotes, I know, but how I immediately got one for this comment... surprising.

yodsanklai 3y ago
Not all languages are equaly suitable to all tasks. If your leetcode easy problem is to write a quick sort, you wouldn't use linked list + recursion. That being said, the OCaml idiomatic solution is to declare a mutable array and write your for-loop, just like you would do in C++. > given everything's immutability OCaml has a lot of mutable datastructures. It's perfectly fine to use them. Even though with experience, you realize there's often a a better/safer way to do it. Also, I'm surprised that in 2023, functional programming still sounds like a mystery to some people. Python/Rust/C++ all have closures, immutable datastructures, their versions of the usual functional combinators, some form of variant types / pattern-matching (maybe not python?). C++23 even has monads. CppCon is full of talks of people realizing that they can write simpler code using this things. I believe all this FP tools should be in the bag of any proficient programmer.
- staunton 3y ago
  CppCon is a very niche audience in my experience. Most "C++ programmers" use a subset of C++11 with some UB sprinkled here and there. When you care about productivity I'm starting to suspect that's actually fine.
  - deleted 3y ago
    [deleted]
- aeonik 3y ago
  I'm not surprised people still don't know functional programming at all. It is really such a different way of programming, and if you don't try to write an entire project using the style, it's just too easy to fall back into mutable code, depriving your self of the greater benefits. Most of the code I used to write was just gluing libraries together, even heavily Object Oriented stuff was too complicated and becomes a spider web of dependencies, so I always hunted for better libraries, rather than try to extend existing ones. Now, I've been writing Clojure for about 3 or 4 years, and I still struggle with certain functional and immutable algorithms. But, now when I go back to Python I occasionally get bit very hard from the surprising mutability. So my brain is definitely adjusting to the safety. I'm still not fluent with a lot of higher order functional concepts. Though I think I'm finally understanding Monads and Transducers. It's hard to break 10+ years of imperative habit. What really helped me was diving down into the core of how parsers and code evaluation works. I didn't read SICP, but understanding the plumbing of these languages can help ease the transition, at least for me... Regardless, it's a lot of dedicated work that a lot of people don't want to invest.
- bmitc 3y ago
  > Not all languages are equaly suitable to all tasks. That is true. Although, I would make the argument that F# and OCaml are two of the best most general purpose languages available. They support the imperative, OOP, and functional paradigms effectively equally. About the only thing you wouldn't use them for is embedded real-time programming. Other than that, they're statically typed with great type inference and sane scoping and syntax (I find F# to be the "cleaner" language) and are performant.
ernst_klim 3y ago
> A straight forward, easy to read, performant C++ solution took me 10 minutes; an ugly unidiomatic OCaml version took me 30 minutes; and a beautiful idiomatic OCaml version using recursion that still no non-OCaml programmer could ever read took me something like an hour... Replace C++ with English and OCaml with Japanese or Estonian and you'll get the idea. OCaml is a vastly different language from what C++ is. Switching to OCaml from C++ is not at all like switching to Go or Java. If you switched to OCaml from SML or Haskell, you would write a completely different opinion. Paradigm shift takes huge mental effort, that's something you have to deal with, unless you want to confine yourself into the comfy world of familiar languages.
nazka 3y ago
What about back when you started to sturdy C++. Will that not have taken you more than an hour to do an performant and elegant C++ solution? I feel what is critical is to practice it more often and also to do a jump into how we think as a developer because OCaml is a functional language from the ML family. The way we have to design and think is not exactly the same as all the other mainstream languages.
tempodox 3y ago
You're not stupid. Functional programming requires its own way of thinking and it's different from procedural languages with mutable-state soup, like C++. It's less that OCaml is hard to learn, and more that you have to leave old habits of thinking and learn new ones. Don't give up just yet.
- MaxBarraclough 3y ago
  Right. Same goes for learning any radically unfamiliar style of programming. There are people who say once you've learned one programming language it's easy to learn any other programming language, but this just isn't true. The differences between languages aren't always skin deep. On the plus side these are the learning curves most worth climbing, as it broadens your understanding. That might be reason enough itself, but it might also make you a better programmer in your usual wheelhouse. Haskell, Forth, and assembly, are worth taking a look at for this reason. If you want to go further down the exotic language rabbit hole, there's Mercury [0] and Joy, [1] both of which I keep meaning to learn. (Hadn't realised until today that they're both from the University of Melbourne.) [0] https://en.wikipedia.org/wiki/Mercury_(programming_language) https://en.wikipedia.org/wiki/Mercury_(programming_language) [1] https://en.wikipedia.org/wiki/Joy_(programming_language) https://en.wikipedia.org/wiki/Joy_(programming_language)
misja111 3y ago
OCaml is not a very good fit for competitive programming, you're better off with a language like Python there. Writing code in a functional language like OCaml requires a mind switch. This can take quite a while. It took me years to really 'get it' after having programmed for 30 years in imperative languages. Now I prefer writing code in FP for a lot of things, but not for everything. E.g. for coding some algorithms you have a much easier time when you can use mutable arrays. A nice advantage of OCaml is, IMO, that it is not so strict about pure FP. E.g. unlike in Haskell, arrays are mutable by default.
- tromp 3y ago
  While Haskell's Array type indeed immutable, there is an incremental update function (//) :: (Ix a) => Array a b -> [(a,b)] -> Array a b that gives you a new updated array. As long as you no longer refer to the old instance, this is as efficient as a mutable array. But Haskell also offers the mutable STArray and STUArray, for boxed and unboxed types [1]. These preserve their purity by being monadic. [1] https://hackage.haskell.org/package/array-0.5.6.0/docs/Data-Array-ST.html https://hackage.haskell.org/package/array-0.5.6.0/docs/Data-...
  - misja111 3y ago
    > As long as you no longer refer to the old instance, this is as efficient as a mutable array. On paper this is true, in reality though it probably is not. Immutable Haskell arrays are implemented with pointers, mutable arrays are implemented as contiguous memory allocations, so they have great cache locality.
hurril 3y ago
After a few weeks, I am disappointed in not being an expert at $new_thing. $new_thing bad!
- hurril 3y ago
  Downvote it all you want. I've spent the last decade writing in this style and to me it's second nature. Starting Rust I've had to basically relearn solving problems with loops and iterators. Solving problems with loops is not the way I think. Never once thought negatively of Rust for this.
- serial_dev 3y ago
  After a few weeks (and I believe it was written many weeks, so to me, that sounds like a couple of months), it's not unreasonable for experienced programmer with already a couple of languages in their toolbelt to expect to get _some_ things done in a new programming language.
  - andrepd 3y ago
    I'd say one thing in your defense, it's absolutely true that the ocaml standard library is atrocious. Replace it with something like Base and you will at least stop struggling with basic stuff like simple IO.
  - ReleaseCandidat 3y ago
    But it isn't (just) a new programming language, it's a different way of solving problems.
    - toolslive 3y ago
      yes: paradigm shifts are not easy.
  - Lewton 3y ago
    After having learned French, German and Spanish, I spent three months learning Chinese and could not speak it fluently, what a shoddy language
ReleaseCandidat 3y ago
> Dealing with user input/output still seemed cumbersome, given everything's immutability... This sentence baffled mé, why would immutability be a problém with user input or output? But changing the way how you solve problems takes time.

yodsanklai 3y ago

Not all languages are equaly suitable to all tasks. If your leetcode easy problem is to write a quick sort, you wouldn't use linked list + recursion. That being said, the OCaml idiomatic solution is to declare a mutable array and write your for-loop, just like you would do in C++. > given everything's immutability OCaml has a lot of mutable datastructures. It's perfectly fine to use them. Even though with experience, you realize there's often a a better/safer way to do it. Also, I'm surprised that in 2023, functional programming still sounds like a mystery to some people. Python/Rust/C++ all have closures, immutable datastructures, their versions of the usual functional combinators, some form of variant types / pattern-matching (maybe not python?). C++23 even has monads. CppCon is full of talks of people realizing that they can write simpler code using this things. I believe all this FP tools should be in the bag of any proficient programmer.

staunton 3y ago
CppCon is a very niche audience in my experience. Most "C++ programmers" use a subset of C++11 with some UB sprinkled here and there. When you care about productivity I'm starting to suspect that's actually fine.
- deleted 3y ago
  [deleted]
aeonik 3y ago
I'm not surprised people still don't know functional programming at all. It is really such a different way of programming, and if you don't try to write an entire project using the style, it's just too easy to fall back into mutable code, depriving your self of the greater benefits. Most of the code I used to write was just gluing libraries together, even heavily Object Oriented stuff was too complicated and becomes a spider web of dependencies, so I always hunted for better libraries, rather than try to extend existing ones. Now, I've been writing Clojure for about 3 or 4 years, and I still struggle with certain functional and immutable algorithms. But, now when I go back to Python I occasionally get bit very hard from the surprising mutability. So my brain is definitely adjusting to the safety. I'm still not fluent with a lot of higher order functional concepts. Though I think I'm finally understanding Monads and Transducers. It's hard to break 10+ years of imperative habit. What really helped me was diving down into the core of how parsers and code evaluation works. I didn't read SICP, but understanding the plumbing of these languages can help ease the transition, at least for me... Regardless, it's a lot of dedicated work that a lot of people don't want to invest.
bmitc 3y ago
> Not all languages are equaly suitable to all tasks. That is true. Although, I would make the argument that F# and OCaml are two of the best most general purpose languages available. They support the imperative, OOP, and functional paradigms effectively equally. About the only thing you wouldn't use them for is embedded real-time programming. Other than that, they're statically typed with great type inference and sane scoping and syntax (I find F# to be the "cleaner" language) and are performant.

ernst_klim 3y ago

> A straight forward, easy to read, performant C++ solution took me 10 minutes; an ugly unidiomatic OCaml version took me 30 minutes; and a beautiful idiomatic OCaml version using recursion that still no non-OCaml programmer could ever read took me something like an hour... Replace C++ with English and OCaml with Japanese or Estonian and you'll get the idea. OCaml is a vastly different language from what C++ is. Switching to OCaml from C++ is not at all like switching to Go or Java. If you switched to OCaml from SML or Haskell, you would write a completely different opinion. Paradigm shift takes huge mental effort, that's something you have to deal with, unless you want to confine yourself into the comfy world of familiar languages.

nazka 3y ago

What about back when you started to sturdy C++. Will that not have taken you more than an hour to do an performant and elegant C++ solution? I feel what is critical is to practice it more often and also to do a jump into how we think as a developer because OCaml is a functional language from the ML family. The way we have to design and think is not exactly the same as all the other mainstream languages.

tempodox 3y ago

You're not stupid. Functional programming requires its own way of thinking and it's different from procedural languages with mutable-state soup, like C++. It's less that OCaml is hard to learn, and more that you have to leave old habits of thinking and learn new ones. Don't give up just yet.

MaxBarraclough 3y ago
Right. Same goes for learning any radically unfamiliar style of programming. There are people who say once you've learned one programming language it's easy to learn any other programming language, but this just isn't true. The differences between languages aren't always skin deep. On the plus side these are the learning curves most worth climbing, as it broadens your understanding. That might be reason enough itself, but it might also make you a better programmer in your usual wheelhouse. Haskell, Forth, and assembly, are worth taking a look at for this reason. If you want to go further down the exotic language rabbit hole, there's Mercury [0] and Joy, [1] both of which I keep meaning to learn. (Hadn't realised until today that they're both from the University of Melbourne.) [0] https://en.wikipedia.org/wiki/Mercury_(programming_language) https://en.wikipedia.org/wiki/Mercury_(programming_language) [1] https://en.wikipedia.org/wiki/Joy_(programming_language) https://en.wikipedia.org/wiki/Joy_(programming_language)

misja111 3y ago

OCaml is not a very good fit for competitive programming, you're better off with a language like Python there. Writing code in a functional language like OCaml requires a mind switch. This can take quite a while. It took me years to really 'get it' after having programmed for 30 years in imperative languages. Now I prefer writing code in FP for a lot of things, but not for everything. E.g. for coding some algorithms you have a much easier time when you can use mutable arrays. A nice advantage of OCaml is, IMO, that it is not so strict about pure FP. E.g. unlike in Haskell, arrays are mutable by default.

tromp 3y ago
While Haskell's Array type indeed immutable, there is an incremental update function (//) :: (Ix a) => Array a b -> [(a,b)] -> Array a b that gives you a new updated array. As long as you no longer refer to the old instance, this is as efficient as a mutable array. But Haskell also offers the mutable STArray and STUArray, for boxed and unboxed types [1]. These preserve their purity by being monadic. [1] https://hackage.haskell.org/package/array-0.5.6.0/docs/Data-Array-ST.html https://hackage.haskell.org/package/array-0.5.6.0/docs/Data-...
- misja111 3y ago
  > As long as you no longer refer to the old instance, this is as efficient as a mutable array. On paper this is true, in reality though it probably is not. Immutable Haskell arrays are implemented with pointers, mutable arrays are implemented as contiguous memory allocations, so they have great cache locality.

hurril 3y ago

After a few weeks, I am disappointed in not being an expert at $new_thing. $new_thing bad!

hurril 3y ago
Downvote it all you want. I've spent the last decade writing in this style and to me it's second nature. Starting Rust I've had to basically relearn solving problems with loops and iterators. Solving problems with loops is not the way I think. Never once thought negatively of Rust for this.
serial_dev 3y ago
After a few weeks (and I believe it was written many weeks, so to me, that sounds like a couple of months), it's not unreasonable for experienced programmer with already a couple of languages in their toolbelt to expect to get _some_ things done in a new programming language.
- andrepd 3y ago
  I'd say one thing in your defense, it's absolutely true that the ocaml standard library is atrocious. Replace it with something like Base and you will at least stop struggling with basic stuff like simple IO.
- ReleaseCandidat 3y ago
  But it isn't (just) a new programming language, it's a different way of solving problems.
  - toolslive 3y ago
    yes: paradigm shifts are not easy.
- Lewton 3y ago
  After having learned French, German and Spanish, I spent three months learning Chinese and could not speak it fluently, what a shoddy language

ReleaseCandidat 3y ago

> Dealing with user input/output still seemed cumbersome, given everything's immutability... This sentence baffled mé, why would immutability be a problém with user input or output? But changing the way how you solve problems takes time.