Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Programming and thinking the functional way

peteratt.com

Post reply on HN
Print view View original

41–50 of 86 posts

Re: Programming and thinking the functional way

#41

Post by tel »

platz wrote: post #33
tel wrote: post #14

Earlier quoted context omitted.

Eh, the list of operators is a weird artifact of the design of lens. The fundamental abstractions at the core are fairly simple, although they're exposed in a scary way. Most of that has to do with optimizing for reuse and proper type inference. It's a cheat to expose the Haskell subtyping relation for more leverage. A better way to understand lenses should be to consider a package like lens-family-core which keeps t…

Scala had/has an issue with user-defined operators; there was a proposal that all operators should also be able to be called with an english word i.e. provide a named function. I wouldn't mind if haskell library designers took that practice to heart.

To that end, the lens library exposes named verbs for most of the core operators and both the verbs and operators are chosen with great discretion toward consistency... if not great discretion toward not clobbering related libraries.

Re: Programming and thinking the functional way

#42

Post by Russell91 »

thinkpad20 wrote: post #18

Ah, the ole "quicksort in 3 lines" argument. There are a few things I take from this. The good: 1) The definition of the algorithm is clear. It shows "how quicksort works." 2) It's trivial to see (and prove) that the function will terminate, and almost as trivial to prove that it will result in a sorted list. So, it is easy to show correctness. 3) The polymorphism makes this an easily reusable function right out of t…

Not sure how you find this as O(n^2). It's clearly the divide and conquer version with O(n lg n) expected time. The only asymptotic complexity issue of the algorithm is that it doesn't randomly pick p, so it will get O(n^2) perf on an already sorted list. It would be expected that you randomly shuffle a list before using this quicksort alg. When the author says this is not the true quicksort, he's referring to the fact that it needs O(n) auxiliary memory, because it's not swapping values in place (the real cost here is worse caching performance). It's definitely not an O(n^2) algorithm though.

Re: Programming and thinking the functional way

#43

Post by collyw »

cousin_it wrote: post #26
samnardoni wrote: post #20

Earlier quoted context omitted.

> Maybe that just says something about my intelligence, or maybe the functional camp hasn't yet figured out how to write large programs in a readable way. You make it sound like we've figured out how to write imperative large programs in a readable way.

Well, it's not too bad. I work at Google and spend a significant part of every workday reading other people's code, written in imperative/OO languages. That's not too difficult, if the code uses few abstractions and if you have good tools for reading it, like cross-referencing, version control history and code review history. But the "few abstractions" part is actually important, I can't imagine reading typical Haske…

It really comes down to who's code you are reading.

Re: Programming and thinking the functional way

#44

Post by freyrs3 »

cousin_it wrote: post #22
dons wrote: post #16

Earlier quoted context omitted.

Lens is one guy's pathological abstraction. It's a library, and it's idiosyncratic. It isn't want large Haskell systems "look like". Cf http://ro-che.info/articles/2014-04-24-lens-unidiomatic.html

I agree that Lens is extreme, that's why I picked it as an example. However, most Haskell code I've seen also has line-noise problems, though not as extreme as Lens. Maybe I just haven't been lucky. Can you point to some good examples of readable Haskell code?

If you work with Java/C/C++ then the way you structure, compose, and think about programs is mostly entirely different from Haskell. Any of the examples I might point to as idiomatic Haskell are going to be "unreadable" ( if that words means anything ) within that worldview, because they come with an entirely different set of constraints and culture than the Java/C++ world.

Re: Programming and thinking the functional way

#45

Post by xxs »

ef4 wrote: post #37
thinkpad20 wrote: post #18

Ah, the ole "quicksort in 3 lines" argument. There are a few things I take from this. The good: 1) The definition of the algorithm is clear. It shows "how quicksort works." 2) It's trivial to see (and prove) that the function will terminate, and almost as trivial to prove that it will result in a sorted list. So, it is easy to show correctness. 3) The polymorphism makes this an easily reusable function right out of t…

> the actual instructions you're giving to the machine are very far removed from what the computer is doing. Who knows how much code is actually executed, how deep the rabbit hole goes... The same criticism can apply to Java. But it's not a particularly good criticism. Unless you're interested in quantum physics, you really don't want to know what the machine is "really doing". You want to have useful abstractions th…

quicksort is never O(1) memory but O(log N). On a flip note: Java's JITs are very mature to the point one may know what exactly the generated assembly would be (and display it as well -XX:+PrintAssembly)

Re: Programming and thinking the functional way

#46

Post by alkonaut »

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.

Re: Programming and thinking the functional way

#47

Post by AnimalMuppet »

chongli wrote: post #21
cousin_it wrote: post #10

It boils down to the choice between these two alternatives: 1) If it's simple to imagine the computer doing something, it should be easy to program. 2) If it's simple to analyze something mathematically, it should be easy to program. The first path leads to C-style programming with pointers and loops. The second path leads to lazy pure functional programming and beyond. Personally, I'm in the first camp. Small functi…

Maybe that just says something about my intelligence, or maybe the functional camp hasn't yet figured out how to write large programs in a readable way. Haskell programmers tend not to write large programs, period. Instead, we build lots of libraries until our problem is trivial to solve. Case in point, see the list of operators defined by the popular Lens library Not really a fair example. Lens is not a program (lar…

> Haskell programmers tend not to write large programs, period. Instead, we build lots of libraries until our problem is trivial to solve.

But if the libraries that you write, taken together, are large, then you are in fact writing a large program. Calling part of it "libraries" doesn't change that. (So far as I can see, that's no different than a C programmer writing lower-level functions, or an assembly language programmer writing subroutines. Everybody does that - at least, everybody sane.)

Re: Programming and thinking the functional way

#48

Post by AnimalMuppet »

eoconnell wrote: post #6

"Wow. i's and j's all the way, what is this? Why is it so long compared to the Haskell example? This looks like comparing C and assembly 30 years ago! And in some respects, it is the same leap." I don't think this is a fair comment considering the in-place Haskell implementation isn't incredibly readable either.

The criticism seems especially misplaced because of how fond Haskell coders are of one-letter names for values...

Re: Programming and thinking the functional way

#49

Post by dragonwriter »

chongli wrote: post #21
cousin_it wrote: post #10

It boils down to the choice between these two alternatives: 1) If it's simple to imagine the computer doing something, it should be easy to program. 2) If it's simple to analyze something mathematically, it should be easy to program. The first path leads to C-style programming with pointers and loops. The second path leads to lazy pure functional programming and beyond. Personally, I'm in the first camp. Small functi…

Maybe that just says something about my intelligence, or maybe the functional camp hasn't yet figured out how to write large programs in a readable way. Haskell programmers tend not to write large programs, period. Instead, we build lots of libraries until our problem is trivial to solve. Case in point, see the list of operators defined by the popular Lens library Not really a fair example. Lens is not a program (lar…

> Haskell programmers tend not to write large programs, period. Instead, we build lots of libraries until our problem is trivial to solve.

So, how is that different from any other language since the invention of functional/procedural decomposition? Programmers generally write libraries and then compose them, rather than writing large monolithic programs, irrespective of language.

Re: Programming and thinking the functional way

#50

Post by AnimalMuppet »

Rusky wrote: post #25
the_af wrote: post #17

Earlier quoted context omitted.

Why? In Java you must place your code within a class, and it's not like in this case it adds a lot of verbosity or overhead. I don't think the author's main argument was classes vs no classes. Java's verbosity is caused by something else...

You don't have to pass the arguments through the class's member variables.

Yeah. qsort should be a static function - it should use the class only for scoping, not for holding data.
Post reply on HN