logoalt Hacker News

torginus • yesterday at 7:53 AM • 1 reply • view on HN

That is true, but on the flip-flip side, while procedural or FP programs are usually easy to run piecewise, with OOP, you have to run the entire app, and navigate to the statement in question to be even able to debug it.

Imho, most FP languages have very serious human-interface issues.

It's no accident that C likes statements (and not too complex ones at that). You can read and parse a statement atomically, which makes the code much easier to read.

In contrast, FP tends to be very, very dense, or even worse, have a density that's super inconsistent.

Replies

troad • yesterday at 11:45 PM

> In contrast, FP tends to be very, very dense, or even worse, have a density that's super inconsistent.

Depends on the FP. Pipes make things fairly legible. Example from Elixir:

    def some_function(thing, doodad, doohickey) do
      thing
      |> foo(doodad)
      |> bar()
      |> baz(doohickey)
      |> quux()
    end
Also easy to debug -- break on any of those lines, or insert `|> IO.inspect()` at any point for good old fashioned print debugging.

Conversely, the non-FP non-pipe version of this would:

(a) be monstrous and difficult to segment: `quux(baz(bar(foo(thing, doodad)), doohickey))`,

(b) needlessly require OOP: `thing.swizzle(doodad).razzle().blorple(doohickey).dazzle()`, where the functions are methods defined on the preceding construct (or some parent construct, to god-knows-what generation), or

(c) require a lot of throw away variables (you get the picture).

I wish more languages had a pipe construct. It's very handy.

Interestingly, D is one of the few languages to have uniform function call syntax,[0] which makes the dot syntax effectively act as a pipe operator, requiring no OOP coupling for its use. Very neat!

[0] https://en.wikipedia.org/wiki/Uniform_function_call_syntax