Simple Haskell == Worse is better? - Haskell

Welcome to the Functional Programming Zulip Chat Archive. You can join the chat here.

codygman

Thoughts? I've been thinking this lately.

I find the "simple haskell" vs "fancy haskell" debate mirrors "worse is better" vs "better is better" As a result I've recently been reading up on that debate.

If we revisit https://www.jwz.org/doc/worse-is-better.html then we see:

worse is better: Simplicity-the design must be simple, both in implementation and interface. It is more important for the implementation to be simple than the interface. Simplicity is the most important consideration in a design.

better is better Simplicity-the design must be simple, both in implementation and interface. It is more important for the interface to be simple than the implementation.

"Simple Haskell" advocates seem to advocate for things that result in simple implementations at the cost of the interface.

They might disagree with my characterization here, so one example is whether or not to use something like deriving-aeson[0] vs writing manual instances for aeson.

I think that simplicity of interface is ultimately what will make Haskell more approachable, but that requires sanding down all the rough edges of bad type errors.

Mainly here though, I'd like to focus on:

  • parallels of "Simple Haskell" and worse is better
  • parallels of "Fancy Haskell" and better is better
  • contradictions of "Simple Haskell == Worse is better"
  • contradictions of "Fancy Haskell == Better is better"
  • Are there good arguments from the worse is better debates in favor of or against simple Haskell?
  • Are there good arguments from the worse is better debates in favor of or against fancy Haskell?

0: https://hackage.haskell.org/package/deriving-aeson

Torsten Schmits

is there any research that concludes that simplicity of interface and implementation is inherently inversely proportional?

TheMatten

Maybe I'm misunderstanding, but I think of these two approaches based on what they create in composition - composing nice interfaces with bad implementations on top of each other should yield nice (library) interface, while composing bad interfaces with nice implementations will yield, well, bad interface?

Pedro Minicz

TheMatten said:

[...] while composing bad interfaces with nice implementations will yield, well, bad interface?

I don't believe that is necessarily the case.

Pedro Minicz

I find it interesting to see this discussion framed in terms of "simple code vs. simple interface." Wouldn't the classical dilemma be between "simple code vs. performance"?

codygman

@Torsten Schmits No, but I find it's usually the case in the area I'm trying to describe.

codygman

Maybe I'm misunderstanding, but I think of these two approaches based on what they create in composition - composing nice interfaces with bad implementations on top of each other should yield nice (library) interface, while composing bad interfaces with nice implementations will yield, well, bad interface?

Those can both be true. Simple Haskell like worse is better though follows:

Simplicity is the most important consideration in a design

In the 'simple Haskell' I've seen the interface and high level design is more of an afterthought.

Maybe that's just a seperate orthogonal problem though.

codygman

I guess the thing I keep coming back to is "simplicity is the most important consideration even at the cost of a complex interface".

Interface here being the code we programmers use to wrangle complexity they simple Haskell sacrifices for simplicity of implementation.

Torsten Schmits

my general reluctance to engage with questions like these is that what constitutes simplicity is entirely dependent on the consumer, in my view – and how complex the thing is you want to build when using this interface

Torsten Schmits

what's simplicity to one is just plain incompleteness to others

Torsten Schmits

I guess "simple" might just be code for "common" or "familiar"

codygman

To clarify I'm only referring to "simple Haskell", that doesn't mean I think it's simpler. Same for "worse is better", some people think it's better.

Torsten Schmits

well, the person saying

"simplicity is the most important consideration even at the cost of a complex interface".

probably has that notion

codygman

I don't want to discuss whether simpler Haskell is simple or simpler in this thread.

I was hoping to see if others see a parallel between simple Haskell and worse is better in terms of developer interface to using and maintaining that code

If it seems there is a link, the question is what lessons can be learned from worse is better vs better is better discussion if anything.

Torsten Schmits

I think it is pretty apparent that there is a parallel. my point was only that the listed criteria are informal and may be subjective, making the question hard to analyze

codygman

I think it is pretty apparent that there is a parallel.

I thought there would be as well, but everyone I've talked to about it didn't think the parallel was obvious.

my point was only that the listed criteria are informal and may be subjective, making the question hard to analyze

Ultimately I'd like to be able to formalize the criteria and the disagreement to tap into relevant research to come to a more objective conclusion about the tradeoffs involved.

I'm not there yet though... The point of this is for me to discuss this idea with others and see how it stands up and hopefully the discussion will help lead me to that desired result :smile:

Torsten Schmits

the story in the article sounds to me like a sort of vendor lock-in situation

Torsten Schmits

so a very concrete mechanism as a trade-off for generality, abstraction or compositionality

Torsten Schmits

with the benefit of higher performance

Torsten Schmits

and I guess you can generalize "performance" to revenue or turnaround times

TheMatten

BTW, not to be nitpicky, but that example in article doesn't sound very compelling to me - wouldn't it be easy to handle repeated attempts to retrieve result of some fallible operation in interface that provides bindings?

Pedro Minicz

codygman said:

If we revisit https://www.jwz.org/doc/worse-is-better.html then we see:

And revisit I did. The main point of the article seems to me not using the best solution available at the time. Points three and four of the "New Jersey approach" seem to be the bigger deal breaker (mainly point four):

  • Consistency-the design must not be overly inconsistent. Consistency can be sacrificed for simplicity in some cases, but it is better to drop those parts of the design that deal with less common circumstances than to introduce either implementational complexity or inconsistency.

  • Completeness-the design must cover as many important situations as is practical. All reasonably expected cases should be covered. Completeness can be sacrificed in favor of any other quality. In fact, completeness must sacrificed whenever implementation simplicity is jeopardized. Consistency can be sacrificed to achieve completeness if simplicity is retained; especially worthless is consistency of interface.

Pedro Minicz

Torsten Schmits said:

my general reluctance to engage with questions like these is that what constitutes simplicity is entirely dependent on the consumer, in my view – and how complex the thing is you want to build when using this interface

I believe the "consumer view" may be contextualized a bit going by the article. The "consumer" in the case of Unix and C are OS users and other programmers. The example the article brings about a given OS callback seems to make "OS users" a bit more clear: programmers interfacing with the OS.

codygman

I read something related this morning that distills the two camps well. It also states the debate isn't about simplicity at all.

I think this point about evolution carries over to the simple Haskell vs fancy Haskell debate.

Worse is better:

If evolution is in the center of your worldview, if you think about viability as more important than perfection in any area, then you'll tend to design in a Worse Is Better style.

Better is better:

If you think of evolutionary pressure as an obstacle, an ultimately unimportant, harmful distraction on the road to perfection, then you'll prefer designs in The Right Thing style.

http://yosefk.com/blog/what-worse-is-better-vs-the-right-thing-is-really-about.html

Sridhar Ratnakumar

Somebody used evolution as rationale? Just a reminder that evolution is all about survival (which can be grisly if history is anything to go by), and not a standard to live a good life by. The same should go with software.

Sridhar Ratnakumar

@codygman Interestingly, the same can be applied to somewhat conservative vs (classical) liberal thinking; not necessarily in political context, but specificaly in psychological context. ("I'll feel this way, because I'm human", "You can't change human nature", and such defeatist rationalizations).

Torsten Schmits

yes, worse is better is liberalism :sweat_smile:

Joel McCracken

I think "worse is better" is an observation that "there are multiple ways to evaluate the 'goodness' of something", and ultimately something might be "good" in some way but bad in another, and these are (often) in tension.

Joel McCracken

To me, "simple haskell" is just saying "these are the values that tend to work out better in industry"

Joel McCracken

So for example if you think systems that are staically proven correct are always better than ones that are not, you will be willing to try to solve every desired property in the type system, regardless of how often it works out that you aren't able to actually do it effectively. This is an extreme case, but im just trying to illustrate

Joel McCracken

similarly, if you value spending your evenigns with family and relaxing, the best programming language and techniques are the ones you already know