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.
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?
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?
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"?
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.
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 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.
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
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:
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?
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.
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.
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.
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.
@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).
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.
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
fwiw, I picked up Haskell while working a full-time, non-Haskell job and I have a small family with 2 kids that I spend a lot of time with. :big_smile:
I also value reliability and will often make the trade off for higher levels of complexity if it means fewer expensive errors in production and I like Haskell because it scales up to those kinds of challenges well.
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:
"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:
0: https://hackage.haskell.org/package/deriving-aeson
is there any research that concludes that simplicity of interface and implementation is inherently inversely proportional?
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?
TheMatten said:
I don't believe that is necessarily the case.
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"?
@Torsten Schmits No, but I find it's usually the case in the area I'm trying to describe.
Those can both be true. Simple Haskell like worse is better though follows:
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.
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.
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
what's simplicity to one is just plain incompleteness to others
I guess "simple" might just be code for "common" or "familiar"
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.
well, the person saying
probably has that notion
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.
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
I thought there would be as well, but everyone I've talked to about it didn't think the parallel was obvious.
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:
the story in the article sounds to me like a sort of vendor lock-in situation
so a very concrete mechanism as a trade-off for generality, abstraction or compositionality
with the benefit of higher performance
and I guess you can generalize "performance" to revenue or turnaround times
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?
codygman said:
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):
Torsten Schmits said:
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.
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:
Better is better:
http://yosefk.com/blog/what-worse-is-better-vs-the-right-thing-is-really-about.html
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.
@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).
yes, worse is better is liberalism :sweat_smile:
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.
To me, "simple haskell" is just saying "these are the values that tend to work out better in industry"
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
similarly, if you value spending your evenigns with family and relaxing, the best programming language and techniques are the ones you already know
fwiw, I picked up Haskell while working a full-time, non-Haskell job and I have a small family with 2 kids that I spend a lot of time with. :big_smile:
I also value reliability and will often make the trade off for higher levels of complexity if it means fewer expensive errors in production and I like Haskell because it scales up to those kinds of challenges well.