Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Rise of "Worse is Better"

jwz.org

Post reply on HN
Print view View original

31–37 of 37 posts

Re: The Rise of "Worse is Better"

#31

Post by masklinn »

baguasquirrel wrote: post #25
Peaker wrote: post #19

Earlier quoted context omitted.

Perhaps Haskell compromised on first-class modules. But ML compromised on: * Type-classes (which overlap but aren't really the same thing and are probably more important) * Typed-effects (a.k.a purity): This is a big one to lose. * Laziness/Strictness control I think ML is more of a compromise than Haskell.

Actually, I was originally of the same opinion, but then I read some lecture slides from Simon PJ. He has suggested that laziness was perhaps not the best default. It is hard to reason about space leaks with laziness. Likewise for typeclasses being inferior to ML functors. http://www.cs.nott.ac.uk/%7Egmh/appsem-slides/peytonjones.pp... I personally disagree. I'm pretty sure laziness has made it much easier for me to…

> He has suggested that laziness was perhaps not the best default. It is hard to reason about space leaks with laziness.

Aha, but it's perhaps not the best default for practical reasons, and it is the best default for theoretical reasons. Does that not make ML's eagerness an example of worse is better, because the worse theoretical solution is simpler the the rubber meets the road and you just want to find out where you're leaking memory>

Re: The Rise of "Worse is Better"

#32

Post by jlouis »

baguasquirrel wrote: post #7

You know, this almost reminds me of the ML vs. Haskell debate. I remember fondly, hearing the 15-312 kids talk about how ML is right and everything else is wrong. The CMU PL dept was kind of adorable that way. One of the classic examples is Haskell's typeclasses. Haskell's typeclasses are kinda kludgy because there's no way to provide more than one instance of a typeclass. ML's functors are way better. But as it turn…

It depends on what perspective you take I guess. From one view, ML is the worse language, but from other views it would be Haskell. Suppose you require a fully formal specification which has been verified in a mechanized way. You have that for Standard ML in Twelf and Haskell has nothing sort of that.

If you look at the concept of being a purely functional language however, it is the opposite with Standard ML being the "worse" animal.

Module system: Then SML got it right and Haskell got it Wrong.

Laziness/Strictness: This is a duality. There are advantages and disadvantages to both approaches so there is no worse/right choice IMO. If you look at the recent stuff on polarity in proof theory it becomes clear that when you latch onto a specific evaluation order, you make some things simple and other things hard.

Re: The Rise of "Worse is Better"

#33

Post by william42 »

justincormack wrote: post #23
william42 wrote: post #2

Richard Gabriel's thoughts on the whole thing: http://www.dreamsongs.com/WorseIsBetter.html

I think this is Richard Gabriel's thoughts, it is signed rpg@lucid.com at the bottom... which certainly isn't Jamie.

Well, yes, but what I linked is more recent.

Re: The Rise of "Worse is Better"

#34

Post by thesz »

tmp43522 wrote: post #30
thesz wrote: post #24

Earlier quoted context omitted.

As of importance, I boldly compare JS to Middle Ages' plague. It is very important but not the way it helps.

So one of the first languages with closures to get huge mainstream popularity hasn't helped? right...

Closures are too small an addition comparing to huge step back in semantics. Side effects in JS are irrepressible.

Re: The Rise of "Worse is Better"

#35

Post by nknight »

agentultra wrote: post #26

The funny thing is that Common Lisp can be used to deliver working systems just fine. In fact, there's nothing "perfect" about it. It has warts. But it is actually quite practical. "Worse is better," is thankfully a philosophy that is pretty unique (afaik) to software development. It is only really applicable to a sub-set of software development as well. I cannot imagine how "worse is better" would work in mission cr…

If you substitute "practicality" wherever you see "worse is better", you'll have a much clearer idea of what the "philosophy" really is, and realize it in no way conflicts with critical systems.

All software design and development is done to a set of requirements. The more disastrous a failure would be, the stricter the requirements will be, and the more rigorous the processes will be.

Like almost all other developers, my software does not run nuclear reactors, therefore I am not going to expend the resources to achieve the safety necessary for a nuclear reactor. It would be both unnecessary and economically infeasible.

Do I care if a client makes a call to my IPTV webservice and gets back corrupt data? Well, yeah, but I'm not going to step through the entire software stack to mathematically prove it's impossible, nor am I going to encase the servers in a lightyear of lead to protect them from cosmic rays. I'm going to follow general best practices, let some testers play with it for a few days (while thousands of other lines of code in the client and server get exercised at the exact same time) and ship it.

Why? Because the small risk of a user not being able to watch their favorite movie in some weird corner-case has less economic significance than me spending days making 100% sure everything is perfect in my new API call.

At the same time, I recognize components of my systems that can have serious economic consequences, and accordingly invest more time in getting them closer to "right" (or avoiding them entirely -- e.g. not so long ago I ripped out all the C-style string/buffer handling from what was ostensibly a C++ library (not mine, originally) and replaced it with std::string and std::vector, which I knew were right, because people smarter than me had made sure they were, because everyone knew they had to be, and time was invested accordingly).

This is a continuum, not a pigeonhole.

Re: The Rise of "Worse is Better"

#36

Post by jmelesky »

Peaker wrote: post #19
baguasquirrel wrote: post #7

You know, this almost reminds me of the ML vs. Haskell debate. I remember fondly, hearing the 15-312 kids talk about how ML is right and everything else is wrong. The CMU PL dept was kind of adorable that way. One of the classic examples is Haskell's typeclasses. Haskell's typeclasses are kinda kludgy because there's no way to provide more than one instance of a typeclass. ML's functors are way better. But as it turn…

Perhaps Haskell compromised on first-class modules. But ML compromised on: * Type-classes (which overlap but aren't really the same thing and are probably more important) * Typed-effects (a.k.a purity): This is a big one to lose. * Laziness/Strictness control I think ML is more of a compromise than Haskell.

> Laziness/Strictness control

I don't think there was any compromise here, just a different choice of default. Both offer a great deal of control over what evaluation method to use.

Haskell, for what it's worth, compromised on:

* Formal definition - this is an often-overlooked win for SML, and the sort of thing that lots of languages could use.

* Module system - type classes complicate this problem, but the lack of a decent module system hurts Haskell when building large systems.

Re: The Rise of "Worse is Better"

#37

Post by Peaker »

jmelesky wrote: post #36
Peaker wrote: post #19

Earlier quoted context omitted.

Perhaps Haskell compromised on first-class modules. But ML compromised on: * Type-classes (which overlap but aren't really the same thing and are probably more important) * Typed-effects (a.k.a purity): This is a big one to lose. * Laziness/Strictness control I think ML is more of a compromise than Haskell.

> Laziness/Strictness control I don't think there was any compromise here, just a different choice of default. Both offer a great deal of control over what evaluation method to use. Haskell, for what it's worth, compromised on: * Formal definition - this is an often-overlooked win for SML, and the sort of thing that lots of languages could use. * Module system - type classes complicate this problem, but the lack of a…

Well, I already mentioned the Module system part.

Good point on the Formal definition compromise.

But I think laziness-by-default has some fundamental advantages that SML pretty much loses: http://augustss.blogspot.com/2011/05/more-points-for-lazy-ev...

Post reply on HN