Hacker News Reader

Comment by miloshh | Hacker News Reader

languages that let you do short parlor tricks

Quite the opposite - functional programming is becoming very appealing as a practical alternative for building large, multi-threaded, correct systems.

True, it might be a bit more tedious to write a program that type-checks, but as many (including me) have been repeatedly amazed, it often works correctly right away, with minimal debugging.

But it also may be that almost no one has been thinking about problems like this

Mutable state is a fundamental issue that every functional programmer deals with every day. Indeed, it might be sometimes frustrating to pass around state that in C would be directly modifiable, but the benefits are huge.

Pure code has been called a "scarce resource", and that's exactly right - once it works, it will always work, no matter how huge is the system you build on top of it.

View on HN

OCaml is one of my favorite languages. I use it, despite its many warts, because it works. (I think there's a much smaller, cleaner language waiting to get out, though.) I wish more languages had decent module systems, for example. The ML family does this better than most, but I bet it's not a very glamorous area to experiment in, because it's hard to really show the benefits of a well-designed module system in small examples. That's what I'm complaining about.

BUT, pure functional programming is an intrinsically poor fit for some problems, and this is seldom addressed by hype. I think functional programming hype needs a reality check now, the same way C++-style OO hype could have used more way back when. I think we would all be better off if, instead of heralding it as the next technique that solves all problems, we work on getting a clearer idea of its strengths and weaknesses.

Oh, I agree with the strengths and weaknesses, and obviously I don't use FP for all my programming.

But I somehow cannot see any functional programming hype. Where are the people heralding it as solving all problems? Even in a place like HN with a highly non-average community of programmers, the FP links are quite rare and very intro-level. I would say FP is a high-hanging fruit that's only starting to find a few niches in real-world programming.

So I son't see anything close to an FP hype, nowhere near to the Java hype or Ruby hype.

Reddit has an ...ardent community, and I suspect regulars there may gain an unrealistic impression of the amount of FP hype there is out in the wider world.

I'm disappointed that I have yet to see a decent discussion on HN on comparing the ML-style module system with OOP. It's really worth talking about.

Also, OCaml is sometimes called a "higher-order imperative programming language" instead of a functional programming language. It does have strict evaluation and first-class mutation, after all. I would argue that there is NOTHING awkward about writing code in it, controlling for libraries and development tools.

I've wondered what the real difference is between a parametric module system that allows you to substitute along common interfaces, versus an object system that allows "duck" typing, mixins, or interface inheritance. In practice, the difference is that the former comes with type inference. :)

I think it'd help if there were more books on OCaml. The French O'Reilly one is pretty good (and free online, http://caml.inria.fr/pub/docs/oreilly-book/), but the Joshua Smith one is awful, and there aren't many others in English.

Also, the OCaml syntax scares some people, and its error messages are pretty unclear, particularly if you haven't learned how to work with the flow of H-M typing. These (and other similar issues) aren't fundamental problems with the language, though, just rough edges in the implementation.

> I've wondered what the real difference is between a parametric module system that allows you to substitute along common interfaces, versus an object system that allows "duck" typing, mixins, or interface inheritance. In practice, the difference is that the former comes with type inference. :)

In OCaml, I can create a module with multiple types, hide information about both of them, and write code sees both of their privates at the same time. In OOP, this can't be done as elegantly (only through the use of inheritance, friends, or inner classes). And this is just the tip of the iceberg; there's a lot more flexibility.

Books would help, as would improving the quality of the error messages (which are literal translations from French). However, neither of these are problems with the language itself... you can improve them without changing a single line of code or iota of the specification.

Type error messages will with HM always be hard (I think understanding an OCaml error message is a PSPACE-complete problem). But, Haskell has great type error messages, so again, this can be improved.

However, I still stand by my claim that the language itself doesn't force programs to be awkwardly structured, as is claimed throughout this discussion.

Indeed, it might be sometimes frustrating to pass around state that in C would be directly modifiable, but the benefits are huge.

Such as? Ok, so you get better multithreaded behaviour but now you're copying state all the time and having to thread it though all your functions. Sometimes just updating state is the right thing to do.

Personally, I think a good tradeoff is immutable data but mutable references.

The main benefit, as I mentioned above, is that if a pure function works once, it works all the time. This is captured by the saying "in Haskell, if it compiles, it works", which is surprisingly often true.

If you have a function that moves a player in a game such as movePlayer :: PlayerState -> PlayerState, you know that it only changes the state of this player, and nothing else. In an OO language you would do something like player.doUpdate(), which has absolutely no guarantees.

Plus there are many facilities available to deal with threading and hiding state.

> you know that it only changes the state of this player, and nothing else.

This gets ugly when the state of every actor can potentially affect the state of every other actor, though. This is pretty common in games.

That's the main point the linked article is making.

Yes, and it is a weak point.

My point, instead, was that FP does not break down when things get ugly; on the contrary, it gives much stronger guarantees on correctness. Of course, it takes effort to express the problem in the more restrictive functional paradigm.

Yeah. I fail to see how scads of global data is less ugly.

Reply on news.ycombinator.com