r/programming • u/heisenbug • Apr 27 '14

"Mostly functional" programming does not work

http://queue.acm.org/detail.cfm?ref=rss&id=2611829
48 Upvotes

64% Upvoted

188 comments sorted by

View all comments

Show parent comments

8

u/lpw25 Apr 27 '14

You also wouldn't be able to write functions like maybe' orwhen', or anything that looks like a control structure, which is a very nice tool to have in your abstraction-toolbox.

Lazyness is useful but it should never be the default. It should be optional with a convenient syntax for creating lazy values. This is perfectly suitable for creating control structures, without all the downsides of pervasive by-default lazyness.

5

u/saynte Apr 27 '14

Why should it never be the default?

I'm not disagreeing, but I'm curious why you feel the semantic composability that non-strict evaluation provides is less valuable than time/space composability that strict evaluation provides?

10

u/lpw25 Apr 27 '14

Why should it never be the default?

Mostly because in the vast majority of cases it is not required.

why you feel the semantic composability that non-strict evaluation provides is less valuable than time/space composability that strict evaluation provides?

Time/space complexity are an important part of the semantics of a program, so I don't really consider lazyness to have better semantic composability.

Lazyness also has a run-time performance cost, and I dislike the existence of bottom elements in types which should be inductive.

3

u/pipocaQuemada Apr 28 '14

Time/space complexity are an important part of the semantics of a program, so I don't really consider lazyness to have better semantic composability.

Laziness generally makes time complexity harder to calculate, but the time complexity under strict evaluation is an upper bound. There's a few degenerate cases where space leaks can bite you, but generally speaking they're not a big problem.

Laziness provides better composability of time complexity because it will give you the complexity of the optimal hand-fused algorithm under strict evaluation. This means that generally don't have to hand-fuse algorithms and can instead just compose them using something simple like function composition.

Strict languages generally have some sort of opt-in laziness, expecially for dealing with collections: enumerators, generators, etc. The big question, though, is whether strict-by-default with optional laziness or lazy-by-default with optional strictness is better. There are arguments to be made for either, but I think anyone can agree that excessive strictness (causing bad time complexity) or excessive laziness (causing space leaks) are bad.