Hacker News Reader

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.

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.

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.

> 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.

> 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.

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.

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)

[1] https://en.wikipedia.org/wiki/Joy_(programming_language)

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.

> 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.

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

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.

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.

But it isn't (just) a new programming language, it's a different way of solving problems.

yes: paradigm shifts are not easy.

After having learned French, German and Spanish, I spent three months learning Chinese and could not speak it fluently, what a shoddy language

Many of today's popular programming languages are variations on the same theme, leading people to think that their experience is broader than it actually is.

"An NFL player found that he managed to be good at rugby after 2 months of practice, but when he tried to do gymnastics (or cycling or tennis or motorsports or ...) in the same time frame, the results were terrible."

What does that tell you the sports he tried to do? Not much. It's all about his previous experience and skills.

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.

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.

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-...

> 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.