Hacker News Reader

Comment by tabtab | Hacker News Reader

"Stepwise refinement" is an intuitive and powerful concept, in part because it helps you grok and debug in a "fractal" kind of way, level by level. But it does have limits at a larger scale. (Event-driven architecture is often better for big.)

It's something Functional Programming either lacks or doesn't do as smoothly. The intermediate results and state are highly useful for debugging, and Functional doesn't "like" intermediate state. Yes, it can be emulated, but the emulation is rarely good as the real thing. For one, the emulated state lacks useful variable and token names, because it's machine-generated.

View on HN

Functional doesn’t like state. That’s the whole point. Functions that can be run in isolation with well defined input is much easier to debug.

In theory. Practice has proven messier to many. Maybe some have a "functional mind", but they shouldn't extrapolate their head to others. Functional has been around for 60+ years. If it were the magical productivity and Lego-modularity golden hammer, it would have mainstreamed already. (Long LINQ is also hard to debug for many of us.)

It is becoming mainstream. Not by pure functional languages taking over, but by developers adopting a functional style and by better and better support for functional programming in mainstream languages.

I'm not sure I'd agree. A lot of the use-cases are for niches or systems programming. I don't see it for business CRUD that often unless either the framework forces it on one, or they are using LINQ, which as I pointed out, can be tricky to debug if long. SQL is largely functional, but it's also hard to debug. The addition of the WITH clause to SQL greatly helped, as one can paste sections to test. Still, not as x-ray-able as imperative. Imperative still wins most x-ray contests. Maybe fast code readers don't need debugging as often? Could be, but I'm average at it.

> The intermediate results and state are highly useful for debugging, and Functional doesn't "like" intermediate state.

s/foldr/scanl

Only sort of kidding. Can you give aconcrete example of some task you'd like intermediate state around?

Also, do you know about the validate monad?

       x = foo01();
       y = foo02(x);
       z = foo03(x, y);

Contrast with:

       foo03(foo01(), foo02(foo01()) );

x, y, and z were named by humans, giving them domain meaning, whereas a debugger would give the second one no name or machine-made names for intermediate state. (Here, z, y, and z have no meaning because it's a foo-bar example, but in practice they'd have better names.)

The first is also often easier to read than the second, at least to my eyes. I know devs who can read the second quickly, but I don't think it's the norm. The LINQ "dot style" can be a little easier to read, but has similar problems.

Your first example is just as functional as your second. And, quite possibly, better style.

But your overall point is fair. A function, once composed, curried or having captured data, is very much like an object. Indeed its representation in memory is likely very similar to an object (mostly functional languages) or actually identical (Java). Your debugger won’t show the data in such a function but it’s happy to show the data in an object. That’s a big advantage of objects over functions. Hopefully debuggers will get better at this eventually.

I'd go with this, which I find the easiest to read:

  x = foo01();
  foo03(x, foo02(x));

In my head I tend to see code as a directed graph, and this one most closely matches that graph without creating too big a jumble on one line. The first one that also has y and z has additional nodes and edges, making the graph more complicated than it needs to be.

Your second one would have the simplest graph, except on one line like that it obscures that foo01() is called twice. If that second one was actually foo04(), then I'd prefer this as the simplest form (which I'd actually originally written before noticing foo01() was in there twice), because it has the simplest directed graph of all, and the code matches it very closely:

  foo03(
      foo01(),
      foo02(foo04())
  );

If the variables and function names were long enough, then I'd use that last format even with my first example, to avoid the whole "jumble of letters and numbers" while still keeping the directed graph simple:

  the_big_x = the_big_foo01()
  zimzamfoo03(
      the_big_x,
      bang_bar02(the_big_x)
  );

This example:

    x = foo01();
    y = foo02(x);
    z = foo03(x, y);

could easily be written in Haskell as:

    let x = foo01
        y = foo02 x
        z = foo03 x y
    in z

My thinking is that functional languages don't preclude you from having intermediate state, but I will agree that composition is used often.

Typically when working in a repl I don't really miss the intermediate state because my debugging consists of:

The lambdas must flow. λ> foo01 "expected result" λ> foo02 "UNexpected result"

Then I'll debug foo02 in isolation.

> foo03(foo01(), foo02(foo01()) );

I think I'd write this as the let example above with variables. Otherwise I guess I'd need to use something like:

    foo03 foo01 . foo02 $ foo01

Here's a Haskell playground link with these examples if you're curious or had something else in mind and want to modify the example: https://play.haskell.org/saved/MeRGyCjr

> Here, z, y, and z have no meaning because it's a foo-bar example, but in practice they'd have better names

As would foo0x.

I don't think many functional programmers would object to writing code as you did in your first example if you think it improves readability and if you don't change what the names refer to.

Reply on news.ycombinator.com