
Professor Frisby's mostly adequate guide to functional programming (2018) - dsego
https://mostly-adequate.gitbooks.io/mostly-adequate-guide/
======
awinter-py
as 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

~~~
th0114nd
I worked as a Haskell developer for a year and a half. The best productivity
boost I had was switching to compiling on an EC2 instance. I saved battery,
sped up compiles with greater parallelism than my XPS had cores for, and
didn’t have to worry about cleaning up ~/.stack

~~~
tome
Could you give a short explanation or link to a write up? Which size of EC2
instance works well for compiling Haskell? Does the EC2 live only for the
duration of the compile, or permanently? If only for the duration, how do you
deal with persisting the installed libraries to disk? Thanks!

~~~
th0114nd
I can’t recall exactly, I want to say 16 vCPUs and 64GB. How well a project
can make use of the cores depends on how wide your dependency graph is vs how
tall, as the unit of parallelism is a package.

The EC2 instance was on continuously, and I would ssh+tmux in. You could
probably replace this with a server plugged in under your desk, depending on
how much you trade off operational costs and capital costs.

More often than not I wanted passing tests to send something for review. If I
needed an artifact, I would publish a docket image on an internal registry.

------
dang
Big 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.)

------
ethyreal
Related there is a related video series if your interested:

[https://egghead.io/courses/professor-frisby-introduces-
compo...](https://egghead.io/courses/professor-frisby-introduces-composable-
functional-javascript)

~~~
joshschreuder
And some more little videos on Brian's YT channel
[https://www.youtube.com/channel/UCKjVLbSDoM-8-eEM7A30igA/vid...](https://www.youtube.com/channel/UCKjVLbSDoM-8-eEM7A30igA/videos)

I hope he makes some more programming stuff at some point as he has a super
creative and interesting way of teaching.

------
gaze
There 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
I 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_Ru...](https://en.wikipedia.org/wiki/Why%27s_\(poignant\)_Guide_to_Ruby)

[1] [https://www.joelonsoftware.com/2000/10/15/painless-
functiona...](https://www.joelonsoftware.com/2000/10/15/painless-functional-
specifications-part-4-tips/)

~~~
lonelappde
Please 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.

------
jypepin
I 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!

------
barbarbar
About 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
It'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.

~~~
catalogia
> _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.

~~~
smabie
And the commonality between elisp and scheme: a lack of a module/namespacing
system.

~~~
catalogia
That's not true of racket though, and in racket long-identifiers are still
popular.

------
alexanderhorl
Link is broken.

