3 ms·
The next Haskell will be strict -Simon Peyton Jones http://www.cs.nott.ac.uk/%7Egmh/appsem-slides/peytonjones.ppt http://www.cs.nott.ac.uk/%7Egmh/appsem-slide
by codexon 16y ago
The next Haskell will be strict
-Simon Peyton Jones
http://www.cs.nott.ac.uk/%7Egmh/appsem-slides/peytonjones.ppt http://www.cs.nott.ac.uk/%7Egmh/appsem-slides/peytonjones.pp...
The latest research fads in CS aren't always beneficial.
- cageface 16y agoThis is why I think it makes sense to have research languages and production languages. The design constraints are totally different.
- plinkplonk 16y ago"The next Haskell will be strict -Simon Peyton Jones" True, he does say that but the slides you reference show a more nuanced position than implied by that isolated quote. Insisting on laziness forced the Haskell designers not to add side effects, eventually resulting in monads (slides 22 and 23), which ended up with Haskell programs having a "thin imperative shell over a fat pure core" internal structure. (slide 32). SPJ then concludes that (1)purity is more important than laziness, (2)the next ML will be pure with effectful programming only via monads and (3) the next Haskell will be strict, but still pure (slides 39 , 40). (the differences between "the next ML" and the "next Haskell" are worth pondering) It is through insisting on laziness as default and solving some of the problems encountered (via monads for e.g) that he arrived at the position that "the next Haskell will be strict". He also notes some open problems with adding laziness into a statically typed strict language (slide 40 "Still unclear exactly how to add laziness to a strict language. For example, do we want a type distinction between (say) a lazy Int and a strict Int?"). So yes, you are right that "The latest research fads in CS aren't always beneficial." but in this case it seems to have been (beneficial). As someone maintaining a 20 k+ line Haskell codebase on my "day job" ("20,000 lines of Haskell is enough to bootstrap SkyNet" - OH on Twitter), I would appreciate a "strict-by-default-Haskell" (with an ML like module system too, while you are at it, thanks in advance!), but really Haskell is certainly more "beneficial" than any other language I've seen to date for certain types of programs . Not contradicting your position,just qualifying it a bit.
- iamelgringo 16y agoHaskell is certainly more "beneficial" than any other language I've seen to date for certain types of programs Could you unpack that? I'd love to hear what types of programs Haskell phenomenal at, in comparison to others.
- plinkplonk 16y agoThis (http://news.ycombinator.com/item?id=1909331 http://news.ycombinator.com/item?id=1909331) is what I am doing - a "type of program" suited to Haskell, very algorithmic, lots of data munging, distribution, parts with proofs of correctness, compiler like pieces and so on.Can't be more specific in public - sorry about that . As for Haskell the language vs others in general, I personally like the combination of high abstraction, static typing and raw speed. Besides (like lisp?) it seems to be a productivity amplifier for very small teams of very sharp people, which is my situation.
- iamelgringo 16y agoNo worries, thanks.
- yena 16y agoThe slides are interesting, but I'd like them in context. Is a video of a seminar covering this material available somewhere?
- vegai 16y agoUhh, I don't see that in the Haskell 2011 standard, even as a suggestion. It would be great, though.