Programming and thinking the functional way • Hacker News Board

Re: Programming and thinking the functional way

#21

Post by chongli » Wed, May 07, 2014, 5:49 PM UTC

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 (large or otherwise), it is a new programming language embedded within Haskell. Viewed within that context, its bevy of operators is somewhat justified. The other thing to note about it is that lens was designed specifically to avoid clashing with variable and operator names defined in other popular libraries so that users could import it unqualified.

Re: Programming and thinking the functional way

#22

Post by cousin_it » Wed, May 07, 2014, 5:50 PM UTC

dons wrote: post #16

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…

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?

Re: Programming and thinking the functional way

#23

Post by ww520 » Wed, May 07, 2014, 5:58 PM UTC

the_af wrote: post #19

ExpiredLink wrote: post #5

The Java example builds up a straw man. Never underestimate your readers!

Why is it a straw man? It looks reasonable to me and I'm a Java programmer.

For one thing, the Haskell version is a non-inplace inefficient HelloWorld kind of qsort. For another, the Java version is rigged to add more unnecessary fluff.

Re: Programming and thinking the functional way

#24

Post by nnq » Wed, May 07, 2014, 6:00 PM UTC

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…

Is anyone not freaked out by Lens? Really, that "thing" is scarry... you realize you need something like `^.` from it because it can make life easier, but then you look at the whole jungle of what it really is and your mind explodes.

Re: Programming and thinking the functional way

#25

Post by Rusky » Wed, May 07, 2014, 6:04 PM UTC

the_af wrote: post #17

elwell wrote: post #11

Creating an entire class for the Java version is kind of a disingenuous comparison.

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.

Re: Programming and thinking the functional way

#26

Post by cousin_it » Wed, May 07, 2014, 6:04 PM UTC

samnardoni wrote: post #20

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. 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 Haskell code at the same speed. When you're tracking down a bug or trying to implement a feature that touches several projects, you really need to read fast.

Re: Programming and thinking the functional way

#27

Post by jerf » Wed, May 07, 2014, 6:05 PM UTC

rdtsc wrote: post #2

Another practical functional language is Erlang. It is at the core of many mobile to internet gateways out there. At the core of WhatsApp. Some databases (Riak, CouchDB) and message queues (RabbitMQ). Language-wise, besides concurrency constructs, you get pattern matching, immutable data structures (and bindings). Unlike Haskell, all types are dynamic (but strong). Also a counterpart to Learn You A Haskell For Great…

"But it is the large applications that ends up breaking my brain."

Really? Large Erlang applications can be understood as a collection of objects that happen to be running concurrently, and I explicitly mean that OO intuitions about responsibility, identity, and substitutability can be fairly directly used. In that sense, I don't think Erlang is actually a very functional language in practice. Erlang programs tend to look like one's initial, high-level overview of a how an OO program will look when you first draw a sketch, with each circle in the diagram becoming a process (or more accurately, type of process, e.g., a "connection" process that may be instantiated once per connection).

Re: Programming and thinking the functional way

#28

Post by [deleted] » Wed, May 07, 2014, 6:08 PM UTC

samnardoni wrote: post #20

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. You make it sound like we've figured out how to write imperative large programs in a readable way.

[deleted]

Re: Programming and thinking the functional way

#29

Post by ww520 » Wed, May 07, 2014, 6:09 PM UTC

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 3-liner qsort is kind of the marketing to lure in the newbies into the language. It becomes a problem when people start to believe the marketing as the real thing. People doing this kind of apple to orange comparison do a disservice to Haskell.

Re: Programming and thinking the functional way

#30

Post by [deleted] » Wed, May 07, 2014, 6:15 PM UTC

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?

[deleted]