13 ms·
The Evolution of a Haskell Programmer (2001)
- Gratsby 11y agoPhase 1: There are no bugs because strong typing, no side effects, functional nature. Phase 2: OK, but those bugs are my own programmer errors. Phase 3: I admit it, I have no idea what I'm doing. Phase 4: OK, I can't even figure out what the Haskell I did two years ago was even trying to do. I was smarter then.
- jb1991 11y agoAs Rich Hickey says often, there are two truths that are true about all bugs: 1) They passed unit tests. 2) They passed a type checker.
- lmm 11y agoWell no, a lot of bugs didn't pass a type checker because a lot of languages don't have them. And some projects don't have unit tests.
- deleted 11y ago[deleted]
- GFK_of_xmaspast 11y ago> And some projects don't have unit tests. If a bug did not cause a unit test to fail, then it passed the unit test suite. (Less cryptically, an empty set is still a set)
- recursive 11y agoIf we're getting that pedantic, the quote was "they passed unit tests". If the bug passed a 0-size set of unit tests, then it didn't actually pass any unit tests.
- eru 11y agoThey didn't pass any, but they passed all. In any case, Rich Hickey probably had more context for his words.
- ank_the_elder 11y agoWe should take this discussion and publish it in the world-famous (and extremely popular) "Journal of the empty set." You will find most of my work published there, too. http://pic.blog.plover.com/math/major-screwups-4/emptyset.png http://pic.blog.plover.com/math/major-screwups-4/emptyset.pn...
- zachrose 11y agoStill though, 0% test coverage.
- deleted 11y ago[deleted]
- jacalata 11y agoI see you've never worked in vanilla JS.
- DonaldFisk 11y agoHe's assuming that the language the code was written in was strongly typed, and that unit tests were actually written. That is not always the case.
- ktRolster 11y agoHe's saying that a strongly typed language with unit tests is not enough to prevent bugs. And he's right.
- hellofunk 11y agoYes, this was the point of his quote. Strange how this point was missed in the other comments. Of course, Hickey is aware that not all languages are strongly typed.
- deleted 11y ago[deleted]
- eru 11y agoThere might still be far fewer bugs.
- DonaldFisk 11y agoStrongly typed languages, and unit testing, do prevent or detect many kinds of bugs less expensively than the alternatives. That is why they're worth using. Similarly, not all diseases are prevented by vaccination, but that's not considered a good argument to stop vaccinating people against those diseases that are prevented by vaccination.
- ktRolster 11y agoI agree with you, but you're being argumentative. No one here is saying that we should stop unit tests because they can't find all the bugs. Instead, the focus should be on what else we can do to improve the bug detection rate. This is an area that needs further research (and I would start with the observation that the quality of the unit test varies dramatically depending on who writes them).
- sordina 11y agoWell yeah, of course, but what conclusion are are you drawing from this?
- tel 11y agoMeh, that's an odd statement since it unifies the classes of bugs which pass varying qualities of (1) and (2). Certainly, "what's true of all bugs (seen in production) is that they passed the unit tests and type checkers levied against them" is nearly tautological, but leaving out those classifiers makes it into a much less meaningful statement.
- emergentcypher 11y agoWhich tells us something about the nature of the bugs we will find in our programs. The type-checker prevents certain classes of bugs, inconsistencies in types, lots of silly typos and mistakes. But it doesn't fix errors in our logic or algorithms. The type-checker doesn't know you should have added instead of multiplied, nor does it fix conversion errors at the borders of our programs where we, say, write a Haskell data structure into a JSON file.
- dllthomas 11y ago"The type-checker doesn't know you should have added instead of multiplied" Dimensional analysis is a type system that knows exactly that.
- bribri 11y agoGood thing type checkers stop many bugs from happening in the first place. I do agree with him that conceptually simple dynamic (Clojure) > complex typed (Java).
- marvel_boy 11y agoWon't product [1..n] lead to a space leak?
- RubenSandwich 11y agoIt could; depending on the size of n.
- pherq 11y agoWith a decent compiler (I think GHC is up to the job, but I've not checked), stream fusion should ensure that the intermediate list never actually exists.
- jfoutz 11y agothe prelude implementation is foldMap on list. as i understand it, a cons cell will be created with the head pointer pointing at 1, and the tail at a lazily evaluated thunk. + tries to evaluate, which creates a cons cell pointing at 2, and a thunk. 1 and 2 are added. so we've got two cells hanging around, but no references to the first one, so the gc can grab it whenever. it'll just kind of chug through the list. it's kinda wasteful to keep making the cells, but it's easy to read. shrug however ghc is very smart. it might be clever enough to optimize away the cells. it might also do immediate ints, rather than pointers to '1', i'm pretty hazy on when there's an int, and when there's a bigint.
- platz 11y agohere is the output of main = print $ product [1..100] ghc-core-html --ghc-option=-ddump-simpl --ghc-option=-dsuppress-all fact.hs https://rawgit.com/jonschoning/c4ad2129aa7d258e65f9/raw/f8edf61aaba6a7a28dc60bb935738d648e53335c/fact.html https://rawgit.com/jonschoning/c4ad2129aa7d258e65f9/raw/f8ed... you can see main_go (plusInteger x_a3Sq main4) (timesInteger eta_B1 x_a3Sq); where it compiles to a recursive loop with an accumulator typicall the [1..100] gets compiled to (enumFromTo 1 100) and it can be desugared further.. so, yeah, foldmap compiles to foldr which may compile down further
- 11y ago
- tromp 11y agoChurch of the No Fixed Point programmer: succChurch n f = n f . f facChurch n f = n g (const f) id where g f n = n (f (succChurch n)) toChurch 0 = const id toChurch k = succChurch (toChurch (k-1)) fromChurch n = n succ 0 fac = fromChurch . facChurch . toChurch
- agumonkey 11y agoAny updates since ? with FTP.
- infinity0 11y agoApparently this s f g x = f x (g x) k x y = x b f g x = f (g x) c f g x = f x g y f = f (y f) cond p f g x = if p x then f x else g x fac = y (b (cond ((==) 0) (k 1)) (b (s (*)) (c b pred))) is faster than this facAcc a 0 = a facAcc a n = facAcc (n*a) (n-1) fac = facAcc 1 and these are the first and second fastest. > Interestingly, this is the fastest of all of the implementations, perhaps reflecting the underlying graph reduction mechanisms used in the implementation. Could anyone elaborate on this a bit more?
- deleted 11y ago[deleted]
- tromp 11y agoThe former is equivalent to fac' f 0 = 1 fac' f n = n * f (n-1) fix f = f (fix f) fac = fix fac' so if the second is indeed faster then explicit fixpoints beat tail recursion
- protomyth 11y agoCan someone explain to the non-Haskell folks how that first example works?
- harveywi 11y agoThe author had (too much) fun using a combination of the SKI combinator calculus [1] and the "B, C, K, W" system [2]. [1] https://en.wikipedia.org/wiki/SKI_combinator_calculus https://en.wikipedia.org/wiki/SKI_combinator_calculus [2] https://en.wikipedia.org/wiki/B,_C,_K,_W_system https://en.wikipedia.org/wiki/B,_C,_K,_W_system
- maweki 11y agoIsn't Haskell internally using a variant of the SKI combinator calculus to represent that all functions are data? This would mean less reduction for an already reduced program.
- LifeQuestioner 11y agoAre there actually any use-cases where haskell would be recommended over other languages? There shear level of thinking and multiple different ways to do what seems like trivial tasks is mind bending...perhaps I never did it enough to a level this would not be the case.
- tdeck 11y agoEvery year since I've started to read about programming (maybe 10 years), Haskell (and pure functional programming in general) has been the Next Big Thing. I don't have anything in particular against Haskell, but its failure to "arrive" makes me think the answer to your question is no.
- tormeh 11y agoWell, functional programming has a lot of good ideas in it, it's just that people generally want the functional stuff in addition to, or at least only partially replacing, the imperative stuff. Laziness has gone out of style. Object orientation is going nowhere. Functional programming is arriving right now, but not as Haskell. As an aside, I think of Haskell as a sensei/guru saying, "Young grasshopper, if you want access to the glory that is my wisdom you will have to wash my dishes and scrape off my calluses for the next three years" to which my personal reply is "Hell no". It¨s unfriendly and it doesn't respect my time. Is there wisdom in Haskell? Probably, but I don't have the patience to deal with the bullshit.
- jfoutz 11y agoEvolution is slow. Java imho brought garbage collection to the mainstream. lisp had been doing that for 20 years or so. I don't think Haskell itself will ever be the language of choice, it'll probably fall into (remain in?) a smalltalk like life. That said, functional idioms seem to be creeping into lots of mainstream languages, so it's not like never. Rust seems pretty heavily influenced by ml, and somewhat by haskell.
- tdeck 11y agoOnly on Hacker News is Rust considered a mainstream language, but I see your point :).
- LesZedCB 11y agoEvery time I see this a get further down the list of examples that I understand. Unfortunately, I still don't make it very far before I'm lost.
- deleted 11y ago[deleted]
- unfamiliar 11y agoAnother post convincing me that writing versions of the factorial function is the primary focus of Haskell. I keep hearing about Haskell in production, I would like to see examples of the language actually doing something useful.
- MaxGabriel 11y agoHere's a screencast of me making a blog application with the Yesod web framework: https://www.youtube.com/watch?v=SadfV-qbVg8 https://www.youtube.com/watch?v=SadfV-qbVg8 While I would also like more production Haskell examples, I wouldn't read much into this webpage—it's basically just a 15 year old joke.
- pka 11y agoFirst google result: https://wiki.haskell.org/Haskell_in_industry https://wiki.haskell.org/Haskell_in_industry You'll probably recognize some companies, such as Facebook, Google, Microsoft.
- knucklesandwich 11y agoThis is such a trite criticism. This post isn't evangelizing the language, its describing coding styles of different haskell engineers using a simple toy problem (that happens to be a canonical algorithm for teaching recursion and FP) to make it somewhat comprehensible to a layman. Every time I read a comment like this it reminds me how much fashion and an unsubstantiated cult of "viable for production" publicity steers the industry instead of curiosity and experimentation. LMGHTFY: https://github.com/search?l=&o=desc&q=language%3AHaskell&ref=advsearch&s=stars&type=Repositories&utf8=%E2%9C%93 https://github.com/search?l=&o=desc&q=language%3AHaskell&ref...
- crdb 11y agoFor our last 2 clients (with both, offering a "data team as a service"): the reporting tools were written in Haskell, using Servant [1] which got started trying to do the same at Zalora to set up a customer service management tool. The motivation was that it made painful stuff much simpler and faster to write (performance was a bonus). It's also used for a bunch of tricky data manipulation problems that were harder to solve using pure SQL. Example: identify a unique customer based on attributes (email, phone, address, etc.) one or more of which can change when a customer tries to create a "new" profile to grab the $10 new customer signup voucher. This ran recursively on the entire customer dataset (12 countries, some customers had created as many as 250 profiles) in about 4 seconds on a m3.medium instance. We don't/didn't write blog posts or tweets about it though. I think the set of people who write blog posts (i.e. both have free time to do so, the talent, and the motivation) is relatively small, and the number of blog posts and other visible stuff being published is proportional to the size of the community, so you'll see many more Node.js/RoR posts than you will on using set theory to reduce a 5,000-table flawed data model systematically or the kind of everyday stuff Haskellers are doing everywhere. Also, personally at least, I don't feel like I know enough to have much to offer by writing a blog, so I stick to making these semi-anonymous HN comments. Interviewing Haskellers, I found a lot of examples of similar work - CRUD tasks, web services, etc. built in Haskell within a larger organisation and running quietly in the background. Something small and modular that can be tacked on quietly. One of the creators of Servant moved on to Tweag [2], a French big data company, where he's working on PB-size distributed machine learning projects for large corporate clients, which I think is where Haskell really shines today. I suspect NDAs will stop them from talking much about it... I've always wanted to do similar work for clients but so far, no dataset was "big" enough to justify moving away from well established R libraries. [1] https://github.com/haskell-servant/servant https://github.com/haskell-servant/servant [2] http://www.tweag.io/ http://www.tweag.io/
- dschiptsov 11y agoThe last 5 or 6 examples clearly captures what is wrong with programming in J^Hgeneral. Tendency to pile up useless crap^Wabstractions is the cause of suffering. Imagine that your doctor and financial adviser are doing this. Hey, wait a minute...
- begriffs 11y agoHaskell is a nice language and you can build regular stuff with it. I wish people shared more prosaic Haskell rather than shock-value postdoc thesis material. I know this article is a joke, but it plays into that stereotype. There's this helpful site that suggests libraries for various things: http://haskelliseasy.com http://haskelliseasy.com Someone should make a companion site listing snippets of code for common tasks showing plain ways of doing things.