[HN Gopher] 15-150: Principles of Functional Programming
___________________________________________________________________
15-150: Principles of Functional Programming
Author : brandonspark
Score : 273 points
Date : 2023-11-20 17:34 UTC (5 hours ago)
(HTM) web link (brandonspark.github.io)
(TXT) w3m dump (brandonspark.github.io)
| freedomben wrote:
| I do wish functional programming were more taught. we're getting
| to a point where I almost think OOP should be taught briefly and
| the rest of the focus on C/C++ for low level stuff (OS, data
| structures, some algorithms), and something functional or pseudo-
| functional for high level stuff. Most of the newer codebases in
| startups now require functional concepts to understand what's
| happening. For example, try writing modern JS without
| understanding .map, .reduce, et al, and function passing, etc.
|
| Regardless I think it's important that students get exposed to
| more than just Python, which seems to increasingly be the only
| thing students come out knowing.
| Mandelmus wrote:
| > I do wish functional programming were more taught
|
| My first CS bachelor's semester in Germany in 2017 taught
| functional programming using Haskell (as well as C and NASM
| assembly in another course on computer architecture).
|
| OOP using Java and Python was only introduced in the second
| semester.
|
| > Regardless I think it's important that students get exposed
| to more than just Python, which seems to increasingly be the
| only thing students come out knowing.
|
| In my B.Sc. studies I used C, C++, Haskel, Assembly, Java,
| Python, and Swift.
| freedomben wrote:
| There are definitely some good schools out there that expose
| students to a broad field. For anybody who is a student and
| looking, this is somethign I would strongly recommend
| considering.
| randmeerkat wrote:
| > My first CS bachelor's semester in Germany in 2017 taught
| functional programming using Haskell (as well as C and NASM
| assembly in another course on computer architecture).
|
| Also worth mentioning that since this was in Germany not only
| was it a great education, but there's no crippling student
| debt either.
| RamblingCTO wrote:
| Same here. Had Scala in my first year. Clojure and Racket
| later. On top of that I had C, ASM, Java, Python and R (had a
| focus on machine learning). So I got plenty of education in
| that department.
| PennRobotics wrote:
| Standard ML (sml / smlnj)
|
| The instructor is clear, energetic, has a decent flow in the
| first lecture e.g. emphasizes the important points with vigor and
| repetition, switches media every 10 or 15 minutes, has a
| conversation with students. Slides are relatively noise-free and
| are informative; terms to know are highlighted.
|
| I haven't watched a full functional programming lecture series
| yet, but I'd gladly audit this one.
|
| As a "new" instructor (as in, not a TA anymore) he's got a bit of
| teaching talent. I hope he keeps a tight feedback loop and
| improves every year and continues publishing material.
| andrewl wrote:
| This looks valuable. And it is from the summer of 2023, so quite
| current.
| ajbt200128 wrote:
| Of note, CMU produces a bunch of functional programming research,
| including a whole homotopy type theory department, so this is a
| quality source.
| frankbreetz wrote:
| Does this include exercises? I didn't see any and I always find
| that the most useful part of learning.
| fredgrott wrote:
| making up your exercises is part of that fun journey of
| creating your own toolbox of functional programming in your
| language of choice!
| PennRobotics wrote:
| Not exactly exercises, but there's
| https://smlhelp.github.io/book/docs/ which supports the course
| and explains each of the concepts as well as library
| documentation at the official class site,
| http://www.cs.cmu.edu/~15150/resources.html
|
| It looks like their current workflow keeps exams and homeworks
| off the internet effectively, but there's a 6-year-old codebase
| at https://github.com/zhengguan/15150-1 with 10-year-old
| homeworks and such.
| brandonspark wrote:
| Unfortunately, it does not. These lectures are "mine", in the
| sense that I developed all of them myself, but the homeworks
| and lab exercises are the combined efforts of generations of
| TAs and instructors from the past. It wouldn't be right for me
| to give them away. (they are also reused from time to time, so
| there are academic integrity concerns with that also)
| brandonspark wrote:
| (but I have thought of developing my own exercises
| independently to go with the lectures, to post on my website.
| This is generally a lot of work, though, so this might take
| some time, depending on how much people would benefit from
| it.)
| _a_a_a_ wrote:
| Congrats on the abuse of pointless images. All 49MB on the
| landing page.
|
| lecture02.png is 4.4MB, 3840 x 2160, FYI.
| epgui wrote:
| "Here is the fruit of my labour and love, which I give to
| you at no cost."
|
| "How dare you do it this way!"
| Sirizarry wrote:
| Being a cranky shithead and scrolling through HN. Name a
| more iconic duo. Seriously though, if your first reaction
| to a neat source of information is to shit on it with
| snark and thinly veiled assholerry, please leave the
| internet for a week. There are better ways to give
| constructive feedback
| _a_a_a_ wrote:
| In some ways I can only agree, having criticised others
| for apparently doing the same thing. I guess the
| difference is that it was completely bloody unnecessary
| to waste enormous amounts of bandwidth for the cost of
| just a little bit of basic checking. For me individually,
| bandwidth is virtually free, for others it is metered
| (not everywhere has Western-levels of Internetz). But
| bandwidth is _not_ free - multiply up 49.2 MB by a number
| of expected page visits.
|
| So, as a matter of principle we need to stop acting as if
| resources are free. Also if the author couldn't even get
| that simple HTML detail right then it potentially says
| something about the quality of his site's information.
| Perhaps.
| mbivert wrote:
| Rewriting standard list functions (map, fold, sum, etc.) is a
| good entry-level exercise.
|
| A l-calculus interpreter can be used as an intermediate level
| exercise. It is in particularly valuable in the context of
| solidifying one's understanding of functional programming.
|
| You can also use "standard" textbooks, such as the SICP [0],
| and perform the exercises using the language of your choice,
| instead of Scheme/LISP.
|
| [0]: https://mitp-content-
| server.mit.edu/books/content/sectbyfn/b...
| brandonspark wrote:
| If you get to around lecture 9, a classic example I always tell
| people to start with is a calculator!
|
| For instance, here's the SML code for it:
|
| ``` datatype exp = Num of int |
| Plus of exp * exp | Minus of exp * exp |
| Times of exp * exp | Div of exp * exp
|
| ```
|
| Implement the function `eval : exp -> int`, which evaluates the
| expression as best as it can. Assume no division by zero.
|
| Extra credit: Can you implement `eval' : exp -> int option`,
| that returns `SOME n` if the expression evaluates, and `NONE`
| if it divides by zero?
| c-c-c-c-c wrote:
| Wow, he went from taking his bachelor to lecturing.
|
| I always dreamt of that when going through my degree and
| encountering courses that needed a thorough rework.
| shortrounddev2 wrote:
| tbh if I were in a class taught by someone who had JUST
| finished their bachelor's degree, I'd take a lot of it with a
| grain of salt
| medstrom wrote:
| If you expect perfect factual accuracy from your teachers,
| yeah. On the flip side, they don't have the curse of
| knowledge yet i.e. it's still fresh in their mind what was
| difficult in the beginning, so they can probably explain very
| well. Just keep in mind who's teaching you, and it's just
| like if a co-student teaches you.
|
| And if you feel you have to take what you hear with a grain
| of salt, that's probably good for your learning too.
| shortrounddev2 wrote:
| I just mean in terms of experience. If you deviate from
| textbook accuracy and go into providing practical advice
| for real-life scenarios, someone with only a bachelor's and
| no work history is someone who can only give you canned
| anecdotes from others. Looking at his resume, it looks like
| he's had some internships so he has a bit of experience,
| and that's probably worth something
| gtchuang wrote:
| His main day job is as a SWE doing program analysis, so
| I'm pretty sure he's got the credentials to talk about
| real-life scenarios.
| shortrounddev2 wrote:
| Yeah idk anything about the guy
| elchananHaas wrote:
| I went to CMU and was in AEPI fraternity with Brandon Wu.
| Brandon Wu is exceptional when it comes to functional
| programming. He was head TA of 15150 for a year, I have 100%
| confidence in him.
|
| He took a break from TAing for some time, and when he
| returned he decided to have some fun with his application. He
| wrote a transpiler from a C like syntax to SML the day before
| his interview, and used it to joke that they should
| transition to teaching functional programming in C.
| shortrounddev2 wrote:
| Yeah idk anything about him in particular. I just mean
| that, on paper, someone who goes straight from bachelor's
| to teaching is someone who doesn't really have any
| experience. I notice that a lot of the people who extol the
| virtues of FP to me are a lot of people straight out of
| college and have little real-world reference for why FP is
| useful in a prod environment
| narinxas wrote:
| just in time for nobody to really care about programming because
| LLMs are so good at translation and all computer code and
| programing are a subfield of linguistics...
| interiorchurch wrote:
| As my mother used to say, we'll see...
| Verdex wrote:
| Programming runs along the back of mathematics. A field famous
| for spending centuries wasting time on silly games until those
| same silly games end up being the foundation on which modern
| society functions.
|
| Even if LLMs completely remove the need for programming (a
| rather big IF), this is not time wasted.
| shepherdjerred wrote:
| Functional programming is a perfect pairing with AI-generated
| code because the type systems are generally more expressive
| than non-functional languages, which means the compilers can
| catch all sorts of errors.
| agomez314 wrote:
| Great resource! Forgive my ignorance but why do so many modern
| functional programming courses use Standard ML instead of a Lisp
| dialect? Is it because of its built-in type-checking, or is it
| just how it's always been taught?
| f1shy wrote:
| My opinion: marketing. In my experience, if I tell someone
| ,,look here is Lisp" they turn off and roll the eyes with a
| ,,ohh that DEAD origramming language". If I instead say ,,look
| this new state of the art language called ML" I get full
| attention and respect.
| ajbt200128 wrote:
| No, it's definitely not because of marketing. SML is more of
| a dead language than most lisps. SML is used because it has a
| strong type checker, which is much more conducive to
| learning, and just having resilient programs in general.
| vmchale wrote:
| It is statically typed, there's a lot of depth to that side of
| things (Curry-Howard isomorphism)
| johnday wrote:
| The value of purely functional programming languages, as
| opposed to functional programming languages like lisps, is that
| you get referential transparency, which means that when you
| define `a = b`, you know that you can always replace any
| instance of `a` with `b` and get the same answer. This is a
| very natural property in mathematics (algebraic rewritings are
| basically just this property writ large) and so it helps to
| draw nice parallels between the familiar notation of functions
| from mathematics and the "new" and "confusing" notion of
| functions in functional programming and other declarative
| languages.
|
| As other posters have said, strong typing is also a nice
| property for lots of reasons, most notably it gives a platform
| to talk about ad-hoc and parametric polymorphism.
|
| (I lecture on Functional Programming at the University of
| Warwick, where we use Haskell.)
| albedoa wrote:
| For those of us who are unfamiliar with Lisps, can you expand
| on how they break referential transparency (and how Standard
| ML contrasts in that regard)?
| medo-bear wrote:
| He is probably talking about namespaces. In common lisp,
| for example, (a a)
|
| calls a function 'a' on a variable 'a'. Lisp knows this
| because the first thing that comes after the left paren is
| a function
| convolvatron wrote:
| more importantly there are functions (using scheme as an
| example) like set! and set-cdr! that mutate existing
| values and totally break referential transparency.
|
| this isn't just user facing - for example let* kind of
| depends on creating bindings up front so they work across
| clauses, and then mutating them afterwards
| epgui wrote:
| They don't.
|
| Or at least not inherently, if by "lisp" one is primarily
| referring to s-expressions.
| tmvphil wrote:
| I think SML isn't purely functional (although it naturally
| encourages a purely functional style).
| bmacho wrote:
| Why would they use a Lisp dialect instead of Standard ML? It
| looks ugly, it looks different from math, and different
| concepts have the same syntax. Standard ML looks nice, it looks
| like math, and different concepts have different syntax.
| SomeRndName11 wrote:
| No, SML is actually quite verbose ang generally ugly,
| compared to say OCaml or F#, or even Scheme or Closure. This
| is why it is dead.
| chriswarbo wrote:
| "Lisp" is pretty broad. Whilst it was inspired by Lambda
| Calculus (the core of most FP languages), a lot of Lisp code is
| quite imperative (loops, mutable variables, control flow
| separate from data flow (e.g. exceptions/errors), etc.).
|
| Scheme (and its dialects/descendants) tend to stick to a more
| functional style (although they also like to do stack-
| gymnastics with continuations, etc.). Many courses are based
| around Lisp.
|
| One of the main features of the ML family is static typing,
| with algebraic datatypes, pattern-matching, etc. (i.e. the
| stuff that new languages like to call "modern", because they
| first saw it in Swift or something). That gives a useful
| mathematical perspective on code ("denotational semantics",
| i.e. giving meaning to what's written; as opposed to the common
| "operational semantics" of what it made my laptop do), and
| having type checking and inference makes it easier to do
| generic and higher-order programming (dynamic languages make
| that trivial in-the-small, but can make large systems painful
| to implement/debug/maintain/understand). This course seems to
| take such abstraction seriously, since it covers modules and
| functors too (which are another big feature of the ML family).
|
| NOTE: In ML, the words "functor" and "applicative functor" tend
| to mean something very different (generic, interface-based
| programming) to their use in similar languages like Haskell
| (mapping functions over data, and sequencing actions together)
| systems wrote:
| on the choice of language to teach the course why sml
|
| i think there are a lot of nicer choice OCaml ,
| its basically sml only more popular and used more in real life
| Haskell , again more popular , and used more in real life
| Idris , newer and said to be more progressive F# , a more
| practical choice and similar to sml a lisp , well if you
| want to focus on the functional part and less on the types part
| brandonspark wrote:
| There's a few things which go into this (hi, I'm the
| instructor!).
|
| One such reason is historical. Standard ML is a research
| language, and a significant amount of work on it was done by
| professors at Carnegie Mellon, who developed the curriculum for
| this course.
|
| Even setting that aside though, I fully agree with the choice
| to teach it in SML. For transparency, I work professionally in
| OCaml, so I am not unfamiliar with it, and I enjoy it quite a
| bit. That being said, I think that the approach taken by CMU is
| best summarized as the fact that languages are ephemeral, and
| the concepts are what matters. We don't teach programming
| languages, we teach concepts -- so even if SML is not widely
| used, the tradeoff for having students have a simpler, less
| distracting, and better learning experience is well worth it.
|
| OCaml has its own intricacies that make things difficult. For
| instance, you can go down a lot of rabbit holes with `dune` and
| `utop` and `ocamlc` and `ocamlopt` and all of these things,
| versus SML/NJ's simple interactive REPL. Another thing is that
| the language is just generally more "bloated" -- you can teach
| modules, but then what if a student starts running into first-
| class modules, recursive modules, or even beyond that, GADTs
| and classes and objects?
|
| (as an aside, this is my primary reason for why I would not
| want to teach an introductory course in Haskell. To do
| anything, you suddenly need to understand the concept of type
| classes and lazy evaluation, and that's simply too much. I
| don't know much about the other languages.)
|
| I think teaching is as much enabling students to succeed as it
| is to prevent them from shooting themselves in the foot. For an
| anecdote, there is an `Option.valOf` function (of type `'a
| option -> 'a`), which essentially is just a bad function that
| should be avoided where possible. Every semester, without fail,
| even though we never tell students that function exists,
| students are smart enough to use Google, and will use it
| anyways, ultimately harming themselves.
|
| I think that same mentality applies to programming language
| choice, here. Keep it simple, keep it neat, and make sure that
| the students see what is necessary for their education, and not
| have to spend mental energy thinking about much more.
| munchler wrote:
| As a professional who uses F# every day, I appreciate this
| answer, even though it concerns me. Separating concepts from
| practical details is worthwhile, but can be taken too far. I
| think the FP community probably focuses a bit too much on
| theory. I would encourage you to consider teaching a more
| practical language, like F#, in the future.
| bfors wrote:
| I feel like F#'s commercial viability over other more
| computer sciencey FP languages is actually kind of a
| downside, from a "vibe" perspective. It seems like CS folks
| are not generally very interested in moving more towards
| the software engineering end of the discipline. Which is
| fair, because they are different things.
| zem wrote:
| i think someone with a good grounding in sml could get
| proficient ocaml or f# in under a month. sml is absolutely
| the right language to teach a course like this in.
| weatherlight wrote:
| because SML is awesome, isn't going to change and is simple.
| you can learn the syntax in an afternoon, and really focus on
| learning FP semantics.
| SomeRndName11 wrote:
| The problem that is extremely verbose though. OCaml is much
| more concise.
| weatherlight wrote:
| Both languages encourage a concise, functional programming
| style but with different flavors and toolsets. They are
| comparable, in terms of verbosity.
|
| I think these are correct implementations of the tower of
| Hanoi.
|
| OCaml let rec hanoi n source target
| auxiliary = if n > 0 then begin hanoi
| (n - 1) source auxiliary target; Printf.printf
| "Move disk from %s to %s\n" source target;
| hanoi (n - 1) auxiliary target source end
|
| SML fun hanoi n source target auxiliary =
| if n > 0 then ( hanoi (n - 1) source auxiliary
| target; print ("Move disk from " ^ source ^ "
| to " ^ target ^ "\n"); hanoi (n - 1) auxiliary
| target source )
|
| function definition, if expressions, recursion are more
| concise in SML, string interpolation is nicer in OCaml
| frozenlettuce wrote:
| My complaint with FP: Sometimes I just want to do something
| silly, like adding a log somewhere. If I choose to add said side
| effect, now all my functions are marked with an io signature (so
| there might be _other_, nastier side effects hiding there as well
| - mainly an issue if you have multiple people contributing to the
| same project). If I don't add the side effect, and choose to
| refactor multiple layers of code, I will need to make all my
| functions return multiple values and later fold over all the
| accumulated strings and... life is too short for that. The
| principles really resonate with me, but maybe we are limited by
| the current tooling, because the development experience is quite
| clunky in its current stage.
| brandonspark wrote:
| This is Haskell-specific, it sounds like. I agree, the IO monad
| is really quite inconvenient sometimes.
|
| I work in OCaml, which is also a functional language, but
| prints can be added in single lines. I address this point in
| Lecture 19 (Imperative Programming), actually, but my
| perspective is -- we invented immutability and purity to serve
| us, but we need not be fanatically beholden to it. In my
| opinion, I think Haskell goes in that direction, when every
| usage of IO now needs the IO monad to get involved.
|
| A little mutability is OK. Functional programming is about the
| avoidance of side effects, more than simply forbidding it.
| frozenlettuce wrote:
| yeah, I've been trying to get this mindset as well - even
| though sometimes I feel that I'm "cheating" :)
| mrkeen wrote:
| Just let all your functions live in IO then. You'll still come
| out ahead.
|
| Or do an unsafePerformIO.
|
| Or use trace (where someone else has done the unsafePerformIO
| for you).
|
| Or use a Writer.
|
| Or introduce some logging capability (Logger m =>) onto your
| code.
|
| Or take a look at all the man-hours that have been spent on
| trying to perfect logging:
| https://hackage.haskell.org/packages/tag/logging
| frozenlettuce wrote:
| yeah, biting the bullet seems to be the way to go. As you
| mention the lots of "man-hours that have been spent on trying
| to perfect logging", when doing research the usage of that
| time might be ok, but when building a product you might need
| to make concessions.
| tromp wrote:
| > Sometimes I just want to do something silly, like adding a
| log somewhere.
|
| In Haskell, you can use Debug.Trace for just that purpose, when
| you don't want to change the type of your function.
| frozenlettuce wrote:
| I've been playing with purescript and found out that they
| have a similar library, thanks!
| toast0 wrote:
| You might benefit from a more pragmatic functional language.
| Erlang is broadly functional, but you can output from anywhere
| if you want to. It's probably one of the least pure functional
| languages out there, but it's super handy.
| ElectricalUnion wrote:
| From my limited knowledge of FP languages it is expected that
| pure code in fact doesn't evaluate anything until a monad
| forces it to evaluate.
|
| You would then need a monad to evaluate the things you're
| attempting to log. And at that point you have a monad, so you
| can log as usual?
| squillion wrote:
| It's not about monads, it's about effectful code, which is
| represented by special types (e.g. IO in Haskell, Eff in
| PureScript). Effectful code can call pure code, but not vice-
| versa. Since a program will have to _do something_ , the main
| function is always effectful, i.e. it returns an effectful
| special type. So you're right that pure code isn't evaluated
| until some effectful code is ultimately returned by the main
| function and executed (by a runtime or equivalent). However,
| in purely functional languages most code is pure, even though
| it's ultimately called by effectful code.
|
| Monads and side-effects aren't intrinsically related.
| Simplifying, a monad is something with flatMap() - in
| JavaScript, Array and Promise are monads (kinda). What
| flatMap() gives you is the ability to _chain_ things, which
| is useful to _sequence_ side-effects so that they can be
| performed by a machine in a given order. That 's why IO and
| Eff are monads.
| poorlyknit wrote:
| In Haskell you have a lot of options to type your functions in
| a more granular way. Consider the type class MonadIO, which
| lets you specify that your function works on any monad that can
| do side effects, not just IO specifically: --
| Before captureAudioDuration :: DeviceID -> DiffTime ->
| IO WaveData -- After captureAudioDuration' ::
| MonadIO m => DeviceID -> DiffTime -> m WaveData
|
| You can build the same thing, but for logging!
| class Monad m => MonadLog m where log :: String ->
| m () -- In IO, just log to stdout. -- Other
| implementations might be a state/writer monad -- or a
| library/application-specific monad for business logic.
| instance MonadLog IO where log msg = putStrLn
| ("log: " ++ msg) -- Before: Bad, doesn't actually do
| any IO but logging findShortestPath :: Node -> Node ->
| Graph -> IO [Node] -- After: Better, type signature
| gives us more details on what's happening. -- We can
| still use this in an IO context because IO has a MonadLog
| instance. -- However, trying to capture audio in this
| function using either -- of the functions above will
| lead to a type error. findShortestPath' :: MonadLog m
| => Node -> Node -> Graph -> m [Node]
|
| As you can imagine this can get quite verbose and there's other
| patterns one can use. Feel free to ask any follow-up questions
| :)
| imslavko wrote:
| Slightly off-topic but what's a good forum to seek help on FP
| practices outside of the courses like this online?
|
| Every winter break I get back into trying to learn more FP (in
| Haskell) and in the past several years I have been practicing
| algo problems (codeforces, advent of code, leetcode).
|
| I always get stuck on more advanced graph algorithms where you
| traverse a and modify a graph, not a tree structure - it gets
| particularly tricky to work on circular data structures (I
| learned about "tying the knot" but it's incredibly challenging
| for me) and usually the runtime perf is sub-par both
| asymptotically and empirically.
| low_tech_punk wrote:
| My Scala friends heavily rely on discord, e.g. the one
| mentioned here: https://typelevel.org/blog/2021/05/05/discord-
| migration.html
|
| It is language based community but they do have vibrant
| discussion on learning and theories.
| kccqzy wrote:
| Many graph algorithms are designed for imperative programming.
| It's safe to say that functional graph programming is still in
| its infancy. Alga[0], a system for algebraic graphs only came
| out in 2017. And efficient algorithms for graphs may yet to be
| discovered (even something as simple as reversing a list that's
| both efficient and elegant only came out in 1986!)
|
| That said, as a beginner in functional programming, it would
| probably be good enough if you just focus on directly
| translating imperative graph algorithms to functional
| programming. You simply solve the problem by programming at a
| slightly lower level of abstraction.
|
| [0]: https://dl.acm.org/authorize?N46678 or preprint at
| https://github.com/snowleopard/alga-paper/releases/download/...
| philsnow wrote:
| I don't know if [0] would be any help, it doesn't talk about
| graphs in particular but does talk about functional-focused
| approaches to data structures. This note[1] on the wikipedia
| page for the book says it better than I could:
|
| > [...] consider a function that accepts a mutable list,
| removes the first element from the list, and returns that
| element. In a purely functional setting, removing an element
| from the list produces a new and shorter list, but does not
| update the original one. In order to be useful, therefore, a
| purely functional version of this function is likely to have
| to return the new list along with the removed element. In the
| most general case, a program converted in this way must
| return the "state" or "store" of the program as an additional
| result from every function call. Such a program is said to be
| written in store-passing style.
|
| [0] https://www.cs.cmu.edu/~rwh/students/okasaki.pdf
|
| [1] https://en.wikipedia.org/wiki/Purely_functional_data_stru
| ctu...
| zubairq wrote:
| Watching it now
| aroman wrote:
| 150 was one of my favorite courses at CMU; each homework really
| made me feel like I unlocked a new level of reasoning with code.
| louthy wrote:
| That's how I felt when I discovered FP after more than two
| decades writing procedural and OO code. It felt like I'd found
| a secret room where all the reasoning was kept.
| 3abiton wrote:
| Do you if any of the course material is available online or as
| a MOOC?
| low_tech_punk wrote:
| God send!! The FP learning resource is quite sparse on the
| internet. I've been looking for structured material like this for
| a while.
| Koshkin wrote:
| It seems that the fundamental problem with the functional
| paradigm (in its pure form) is that the real world - including
| the architecture of the computer that is used to run the programs
| on - is full of side effects, i.e. is essentially "imperative,"
| and with this impedance between them the idea creates more
| problems than it solves.
| whateveracct wrote:
| on the contrary, i think FP (Haskell at least) gives you more &
| better tools to represent and wrangle side effects
| kccqzy wrote:
| Exactly. These languages come up with more and more
| strategies and abstractions (from monads to modern effect
| systems) to help you manage your side effects well. It then
| raises the level of abstraction in your programs to become
| simpler and more concise.
| airstrike wrote:
| Hey Brandon, thanks for posting this. Off-topic but maybe
| consider serving up thumbnails on that page instead of the full-
| size pngs https://brandonspark.github.io/prologue/lecture01.png
| vermilingua wrote:
| Content aside, what gorgeous slides. I wish any of my lecturers
| had the same eye for presentation.
| gsuuon wrote:
| This looks cool! Just a note, it looks like the youtube playlist
| is in reverse order:
| https://www.youtube.com/watch?v=DSGXB9G5dxk&list=PLsydD1kw8j...
___________________________________________________________________
(page generated 2023-11-20 23:00 UTC)