7 ms·
Professor Frisby's mostly adequate guide to functional programming (2018)
- gaze 7y agoThere is this writing style that seems prevalent around certain programming circles, particularly the JavaScript, Python, and Ruby communities. It’s informal and somewhat hammy—- perhaps to seem friendly and more approachable. I imagine it’s pretty fun to write this way. Do people find it easier to read?
- MaxBarraclough 7y agoI think it's fair to say it was pioneered by why's (poignant) Guide to Ruby [0]. Spolsky is a fan of the style. He's made the case for deliberately writing documentation that's fun to read, rather than using a dry style. As he puts it, nobody read the spec, because it was so dang mind-numbing. [1] [0] https://en.wikipedia.org/wiki/Why%27s_(poignant)_Guide_to_Ruby https://en.wikipedia.org/wiki/Why%27s_(poignant)_Guide_to_Ru... [1] https://www.joelonsoftware.com/2000/10/15/painless-functional-specifications-part-4-tips/ https://www.joelonsoftware.com/2000/10/15/painless-functiona...
- microtherion 7y agoThere was writing like this considerably earlier, e.g, Leo Brodie’s Starting FORTH https://www.forth.com/starting-forth/ https://www.forth.com/starting-forth/ And Helmut Zwittlinger’s Comic Pascal https://balancedaction.files.wordpress.com/2016/03/img_0091.jpg https://balancedaction.files.wordpress.com/2016/03/img_0091....
- lonelappde 7y agoPlease don't follow Joel's advice. He's taking the wrong lesson. You can be conversational, you can lade your document with copious real world examples and justifications for rules, and illustrations, and explaining how different parts of the spec interact, and warn about common mistakes and included FAQs, but don't fill it with distracting unfunny garbage like Miss Piggy poking at a keyboard with eyeliner because her fingers are too fat.
- gaze 7y agoThe documentation can be enjoyable... the spec I think should be dry as a cracker. But if you want to write enjoyable docs, write like John Carlos Baez writes math/physics paper. The enjoyability should serve the clarity. Anything else is superfluous.
- pseudoramble 7y agoDepending on the circumstances, I often do. For a big topic like this, part of the reason I like it is that the pacing is better. It tends to be less densely packed, and lets me read through something carefully but not feel too strained. It also has a story, if you will, that helps me get back on track later on if I'm sticking with it. It's not to say a more formal style of writing couldn't achieve similar goals, but I just find they don't tend to. There are plenty of scenarios where it wouldn't fit (references, specifications, etc) of course. So I don't think it's great everywhere. But yeah, overall I find it easier to read when starting out on a big topic.
- ethyreal 7y agowe did this book for our work book club a year or so ago. most people in the club enjoyed reading it. there were issues getting the some of the examples to work at the time but that's another matter.
- Ididntdothis 7y agoPersonally I found that style funny for a while but now I feel it's becoming tedious and won't age well. In the long run I prefer a style like Kernighan & Ritchie which is concise, easy to read and timeless.
- a3n 7y agoYeah, it's like hearing a ukulele and a folksy male voice in a TV commercial. It's been done, move along. I too prefer barely more than "just the facts" that are relevant to the document's audience and purpose.
- jcelerier 7y ago> perhaps to seem friendly and more approachable. nothing makes me press ctrl-w faster that a web page that tries to be "friendly" (in an american pop-culture way) with me.
- lonelappde 7y agoDo you ctrl-w before or after the first animated gif meme?
- jcelerier 7y agoi also ctrl-w if something takes more than a couple seconds to load, which is most gifs, even on a gigabit fiber connection <_<
- ethyreal 7y agoRelated there is a related video series if your interested: https://egghead.io/courses/professor-frisby-introduces-composable-functional-javascript https://egghead.io/courses/professor-frisby-introduces-compo...
- joshschreuder 7y agoAnd some more little videos on Brian's YT channel https://www.youtube.com/channel/UCKjVLbSDoM-8-eEM7A30igA/videos https://www.youtube.com/channel/UCKjVLbSDoM-8-eEM7A30igA/vid... I hope he makes some more programming stuff at some point as he has a super creative and interesting way of teaching.
- barbarbar 7y agoAbout This: "We have to bind all over the place lest this change out from under us". I wonder if there are other languages with similar peculiar behaviour of this.
- namelosw 7y agoIt's dynamic scoping, as appose to lexical scoping. With the dynamic scoping, the environment of invocation becomes the caller's environment, while with the lexical scoping the environment was tied to the scope or original definition. JavaScript is kinda weird because it uses lexical scoping for most of the part, but uses dynamic scoping for 'this'. Lexical scoping looks sane, and it's adopted by most programming languages nowadays. Because it's much easier to reason about - it just worked as how the code was written, in the same file. While dynamic scoping would leak variables everywhere - when you need it it's not there, when you don't want it, it just sneakily replace many variables that you expect to be other things. But there are still quite some mostly dynamically scoped languages in use like Emacs Lisp, or shell languages like Bash and Powershell. Other than dynamically is debatable faster and easier to implement, it's also handy when you override the environment variables for short shell scripts. But for large codebases it's a nightmare, so traditionally Emacs Lisp scripts have super-long-variable-names-in-order-to-avoid-collisions just like writing CSS, and people had enough now so in newest version people can have a syntax that can enable lexical scoping.
- decentralised 7y agoI believe JS is lexically scoped... but it is in fact the most misunderstood language in the world. https://www.ecma-international.org/ecma-262/5.1/#sec-10.2 https://www.ecma-international.org/ecma-262/5.1/#sec-10.2 https://www.ecma-international.org/ecma-262/5.1/#sec-13.2 https://www.ecma-international.org/ecma-262/5.1/#sec-13.2 https://2ality.com/2011/04/ecmascript-5-spec-lexicalenvironment.html https://2ality.com/2011/04/ecmascript-5-spec-lexicalenvironm...
- catalogia 7y ago> so traditionally Emacs Lisp scripts have super-long-variable-names-in-order-to-avoid-collisions I don't think dynamic scoping is the only reason for this. Scheme has lexical scoping yet long-identifier-names are popular with scheme as well. Personally I prefer lexical scoping with long-identifier-names. I find it more pleasant to read. And with modern auto-completion systems, it's no longer inconvenient to write code like that.
- alexanderhorl 7y agoLink is broken.
- dang 7y agoBig thread from 2018: https://news.ycombinator.com/item?id=17072662 https://news.ycombinator.com/item?id=17072662 Little bits from 2016: https://news.ycombinator.com/item?id=11951823 https://news.ycombinator.com/item?id=11951823, https://news.ycombinator.com/item?id=11606453 https://news.ycombinator.com/item?id=11606453 Big from 2015, back when Professor Frisby was merely Dr Boolean: https://news.ycombinator.com/item?id=9884616 https://news.ycombinator.com/item?id=9884616 (I've put 2018 above but it's not clear when the bulk of it was written.)
- awinter-py 7y agoas a new haskell learner who started this month, I've really learned empathy from banging my head against the language the docs have a specific tone or pattern that's everywhere (and by docs I mean everything -- library readmes, examples, language intros, and stackoverflow posts) they all read like 'well, you probably haven't been introduced to monads yet. I can't answer your question directly in a short post (these posts are all like 6 paragraphs, nothing short about them), but I'll tell you why you can't do what you're trying to do and I'll also explain why I can't tell you what a monad is' also my laptop battery keeps dying because the builds are so expensive
- SirensOfTitan 7y agoI’d just recommend skimming over something like Haskell book to gain some vague familiarity with what concepts exist, then just write code and learn applicative/monad/monoid etc as you run into walls. Generalizations are notoriously hard to describe as they become more general. Better to understand where and when to use those patterns over being able to write a blog post about what a monad is.
- awinter-py 7y agoat this point I'm desperate for good docs / resources -- link to anything you particularly like spent hours figuring out how to debug-print a value from a pure function and still haven't gotten there
- unhammer 7y agoimport Debug.Trace myPureThing :: Bool -> Int myPureThing b = if b then traceShow "yay True" 42 else traceShow "oh noes False" 13 … λ> myPureThing True "yay True" 42 λ> myPureThing False "oh noes False" 13 I don't know if they're good for others, but I read Real World Haskell[1] and Learn You a Haskell[2]. There's also Graham Hutton's book which people like and which is free to read this month or something[3]. [1] http://book.realworldhaskell.org/ http://book.realworldhaskell.org/ – see also the in-progress updated version at https://github.com/tssm/up-to-date-real-world-haskell https://github.com/tssm/up-to-date-real-world-haskell [2] http://learnyouahaskell.com/ http://learnyouahaskell.com/ [3] https://www.cambridge.org/core/books/programming-in-haskell/8FED82E807EF12D390DE0D16FDE217E4 https://www.cambridge.org/core/books/programming-in-haskell/...
- jypepin 7y agoI learned FP through this book when it was first shared here on HN in 2018. It's very nicely written and clearly explain the concepts. I strongly recommend this book to anyone who wants to learn more about FP!