Hacker News Reader

Comment by mpweiher | Hacker News Reader

To me, this is the most important part of the text (p2, bottom):

"The ways in which one can divide up the original problem dep end directly on the ways in which one can glue solutions together Therefore to increase ones ability to mo dularise a problem conceptually one must provide new kinds of glue in the programming language."

Functional programming is great because it provides two (new) kinds of glue: function composition and lazy evaluation.

Even if you accept that (I certainly do for function composition, less enthusiastic about lazy evaluation), I would say that it only provides two new kinds of glue.

We need lots of kinds of glue, in other words, lots of architectural connectors. And that means linguistic means of defining and varying architectural connectors. http://objective.st

View on HN

> Functional programming is great because it provides two (new) kinds of glue: function composition and lazy evaluation.

Certainly true for composition but laziness is more the exception than the rule in today's FP languages. And it's getting an increasingly bad reputation to the point that even Haskell is slowly (and reluctantly) being dragged in the strict direction (which it will never fully reach because so much of it would break).

> laziness is more the exception than the rule in today's FP languages

Exactly. I also wrote I am somewhat less enthusiastic about laziness.

So that leaves just one kind of glue as FP's contribution, which goes back to my point to the contribution being good but not sufficient.

There's one spot where I like laziness, and that's where it supports composition.

I'm gonna hop over to C# because that's where my favorite example lives: LINQ is a functional library that lets you describe queries on data that are executed lazily. The reason why the laziness is great in this scenario is that it lets you separate the tasks of constructing a data processing pipeline, and executing it.

The spot where it's tricky, though, is that it's a very leaky abstraction. It's easy to forget that these expressions might actually represent a lot of work, so if you get your lazy sequence object (IEnumerable<T> in C# terms) and then check if it has any values in one expression, and calculate its sum in another, then you might end up accidentally round-tripping a database twice.

Because of those sorts of stumbling blocks, I think laziness is a power that needs to be handled with care. I'm pretty sure that means you most certainly should not make it the default behavior.

I hope you will be interested in the C#/LINQ codes found in following pages:

  "Why Functional Programming Matters" solved with C#
  http://www.oki-osk.jp/esc/cs/whyfp.html
  http://www.oki-osk.jp/esc/cs/whyfp2.html
  http://www.oki-osk.jp/esc/cs/whyfp3.html

Laziness by default is only a property of the Miranda branch of FP languages, not a feature of all FP languages.

Reply on news.ycombinator.com