35 lines
1.7 KiB
Org Mode
35 lines
1.7 KiB
Org Mode
:PROPERTIES:
|
||
:ID: 6ce50155-471d-490a-baf0-865b75547611
|
||
:ROAM_REFS: @WillKurt2718
|
||
:END:
|
||
#+title: Notes on Will Kurt, Get Programming with Haskell
|
||
|
||
* [[id:68cedf67-0f59-4a06-9344-77d946129653][Functional Programming]]
|
||
#+begin_quote
|
||
John Backus, who led the team that created Fortran, asked in his Turing Award
|
||
lecture, “Can programming be liberated from the von Neumann style?”
|
||
|
||
This question leads to the second way to understand programming, which is the
|
||
subject of the first unit in this book. [[id:68cedf67-0f59-4a06-9344-77d946129653][Functional programming]] attempts to
|
||
liberate programming from the von Neumann style.
|
||
#+end_quote
|
||
* [[id:67dab4eb-231f-4af0-bf26-b3cf6d83f9a3][Algebraic Data Types]]
|
||
#+begin_quote
|
||
The big problem is that you want a single type that represents both vinyl
|
||
records and books so you can make a searchable inventory. Because you can
|
||
compose types only by /and/, you need to develop an abstraction that describes
|
||
everything that records and books have in common. You’ll then implement only the
|
||
differences in the separate classes. This is the fundamental idea behind
|
||
/inheritance/.
|
||
#+end_quote
|
||
|
||
#+begin_quote
|
||
In theory, creating object hierarchies is elegant and captures an abstraction
|
||
about how everything in the world is interrelated. In practice, creating even
|
||
trivial object hierar- chies is riddled with design challenges. The root of all
|
||
these challenges is that the only way to combine types in most languages is with
|
||
an /and/. This forces you to start from extreme abstraction and move downward.
|
||
Unfortunately, real life is full of strange edge cases that make this much more
|
||
complicated than you’d typically want.
|
||
#+end_quote
|
||
#+print_bibliography:
|