Hacker News Reader

Comment by mrkeen | Hacker News Reader

The hyperbole that Haskellers invoke around pure-functional vs impure is that you're never quite sure whether a function call you make will "fire the missiles".

It's colourful language, but it's just a stand-in for other properties you might care about. For instance, in head(sort(list)), will the whole list be sorted, or will the smallest element be returned? In atomically(doThis(); doThat()), will doThis be 100% reverted if doThat fails? If you stick to pure functions (and in the second example, STM) then you can unfire the missile!

AFAIK, Erlang just fires the missile "over there", not "over here". The author jumped from:

  (X = X + 1) is bad

  (mailbox = mailbox + message) is so simple!

I'm not bashing the BEAM, or the ease with which one can send messages (as an Actor language), but I am complaining about the lack of tooling to write non-missile-firing functions on a single node (as a Functional language).

View on HN

> (mailbox = mailbox + message) is so simple!

The author did not say this at all, they barely even touched on capabilities of erlang/OTP. Their focus was on the functional syntax of Erlang.

> For instance, in head(sort(list)), will the whole list be sorted, or will the smallest element be returned?

Your point isn’t clear. The functions have a clear nested call sequence, take a list, sort it, get the head.

Also how is it any different than Haskells `head (sort list)`?

In Haskell with `head (sort list)` the entire list does not have to be sorted, depending on the sort implementation. Everything is lazy, so sort can sort the list just enough to return the smallest element.

Going beyond laziness, a compiler that can understand and exploit equations, could use `head (sort list) = smallest (list)` to make the program more efficient, going from O(n * log n) to O(n) complexity.

I think the question is whether sort should return a new, sorted array or whether it should sort the array in place. In functional languages it is the former, in imperative the latter.

It can be quite useful to have nondestructive sorting in imperative languages as well. Hence python introducing 'sorted' even though '.sort()' preceded it.

> The author did not say this at all, they barely even touched on capabilities of erlang/OTP.

  Two separate Erlang nodes. On different machines, different networks, different continents if I wanted. And they could just… talk. No HTTP. No REST API. No serialization headaches. Just message passing. Just actors doing their thing.

> Their focus was on the functional syntax of Erlang.

They didn't write any Erlang until the ping/pong example, which doesn't have any functions. What does pong() equal? Is it equal to itself even? What's its domain and range? If I wrote a unit test for it, what test inputs would I give it and what outputs would I assert?

Right. The author barely touched on the capabilities of Erlang/OTP. That section was pretty much a demo of the syntax and an advertisement of the fact that the language syntax and runtime system makes it trivial to have a distributed program that runs on separate machines.

If the author actually talked about the capabilities of Erlang, they would -at minimum- answer the questions that you'd raised, that the return value of both 'ping/1' and 'pong/0' are irrelevant because they are ignored, and that the range of 'ping/1' is not only infinite, it can accept any type for which it's legal to '+ 1'. [0] They would have also mentioned why they call 'ping' and 'pong' at the end of the respective function, the reason for which is kinda strange if you're coming from a more-normal language.

One can add annotations to functions that indicate what their input and output types are, and if you do a little bit of work, you can also indicate valid ranges/values for those types. These annotations are not checked at runtime, but can be checked by tools such as dialyzer. But, because this blog post barely even touched on Erlang/OTP's capabilities, none of that was mentioned.

[0] I think the valid types are only integers and floats, but definitely don't bet your career on that information.

My point is, for an article about functional programming and Erlang, there wasn't any functional programming in Erlang.

The author pivoted from rejecting "change state of X" to advertising "change state of mailbox".

> the return value of both 'ping/1' and 'pong/0' are irrelevant because they are ignored If they were functional, they'd be optimised away by the compiler (for being irrelevant). They only exist for their side effects. Ping and pong are procedures. This is 100% imperative.

> [ping and pong] only exist for their side effects.

Yes, these are really obviously two functions that exist to mutate state by printing to a console somewhere then communicating with another process.

> If they were functional, they'd be optimised away by the compiler (for being irrelevant).

I'd expect -say- Haskell to not optimize away functions that exist just to print to a console.

So, is your complaint that Erlang is (like Prolog) not a purely functional language, and that the author has asserted that Erlang is a functional language (in the same way that Prolog is) [0] but provided example code that produces side effects?

[0] Be very careful when reading here. I'm fairly aware of just how much Prolog is a functional language.

> there wasn't any functional programming ...This is 100% imperative

What distinction are you drawing between functional and imperative programming? This is not a trick question. Simon Peyton Jones has described Haskell as "the world's finest imperative programming language", and one way of interpreting my Haskell effect system Bluefin[1] is "purely functional imperative programming". I don't think functional and imperative are are mutually exclusive, in fact, I don't think they're even at odds. I think they're both at their best when combined.

[1] https://hackage.haskell.org/package/bluefin

Reply on news.ycombinator.com