Live data from Hacker News

Programming and thinking the functional way

peteratt.com

81–86 of 86 posts

Re: Programming and thinking the functional way

#81

So a divide-and-conquer algorithm on collections is more elegant functionally than imperatively? Also: water found wet. Haskell is elegant & Java isn't, but cherry picking examples always comes with a risk of making your argumentation straw-man-ish. Would be interesting to see some examples where imperative isn't so horrible, and how Haskell compares. The in-place sort the author mentions, for example.

So a divide-and-conquer algorithm on collections is more elegant functionally than imperatively? Also: water found wet.

Even that is only true if you consider the concise and readable nature of the Haskell code to be the most important factor in the elegance of the algorithm.

To me, the elegance of true quicksort is that its in-place nature is memory efficient, and consequently also cache-friendly on modern hardware, resulting in excellent real world performance.

If you consider the underlying nature of the algorithm to be more important to its elegance than superficial presentation details, then the typical 3-line functional implementation is clumsy by comparison, and equating the two is at best an appeal to having a sufficiently smart compiler.

In reality, of course, both the aesthetics and the underlying behaviour matter, so I'm not sure it's particularly helpful to promote any language as being superior on either basis without also considering or at least acknowledging the other.

Re: Programming and thinking the functional way

#82

Earlier quoted context omitted.

I had to audit a web app and the back end code was all written in Erlang. I had never seen the language in use before, so it took me a little while to get the hang of reading it. Now that I've spent some time playing around with it, I think I like Erlang better than I like Haskell; I used to think I disliked dynamic typing but it turns out I just don't like the way Ruby handles it. Erlang feels really good to write c…

There's no accounting for taste, but as "jerf" posted in a sibling comment Erlang's not really functional[0]. All that's really happening is that the mutable state is "hiding" in the message passing portion of the application. Just as an example: It's pretty simple to implement a mutable reference cell as an actor which contains only pure functional code. I'm not sure where I first saw it demonstrated, I think it was…

Of what use is this distinction, especially when zero languages fall within its definition? Honestly.

Re: Programming and thinking the functional way

#83

Earlier quoted context omitted.

There's no accounting for taste, but as "jerf" posted in a sibling comment Erlang's not really functional[0]. All that's really happening is that the mutable state is "hiding" in the message passing portion of the application. Just as an example: It's pretty simple to implement a mutable reference cell as an actor which contains only pure functional code. I'm not sure where I first saw it demonstrated, I think it was…

Of what use is this distinction, especially when zero languages fall within its definition? Honestly.

Hm? Haskell is purely functional. (Alright, you can theoretically use unsafeCoerce and unsafePerformIO, but in practice it doesn't actually happen.)

Re: Programming and thinking the functional way

#84
post #70

Earlier quoted context omitted.

Sounds like a good read, sold!

I'm kind of on the fence about it - I've hesitated buying it because the post also explains that it's a notoriously difficult book - some of the results of the "swizzling" can lead to some inscrutable final programs. But I'll probably pick it up at some point in the near future.

> it's a notoriously difficult book

Personally I don't find that to be true, it's perfectly logical mostly. It's definitely worth picking up imho.

Re: Programming and thinking the functional way

#85

Earlier quoted context omitted.

Of what use is this distinction, especially when zero languages fall within its definition? Honestly.

Hm? Haskell is purely functional. (Alright, you can theoretically use unsafeCoerce and unsafePerformIO, but in practice it doesn't actually happen.)

Can you please point me to any real-world Haskell program that is purely functional? I am interested in seeing what a program without I/O looks like.

Re: Programming and thinking the functional way

#86

Earlier quoted context omitted.

Hm? Haskell is purely functional. (Alright, you can theoretically use unsafeCoerce and unsafePerformIO, but in practice it doesn't actually happen.)

Can you please point me to any real-world Haskell program that is purely functional? I am interested in seeing what a program without I/O looks like.

All of them. Remember that "IO a" is just a value. :)

It's really the "interpreter" of the IO monadic values which causes all the side effects. I am aware that there are some issues with this interpretation, but if you want to get pragmatic it's really a question of X% pure/(100-X)% impure while keeping X as close to 100% as possible. Haskell can do that for X arbitrarily close to 100% (depending on how much abstraction/effort you're willing to go through).

Post reply on HN