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.
15-150: Principles of Functional Programming
51–60 of 146 posts
Re: 15-150: Principles of Functional Programming
#52My 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 w…
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.
Re: 15-150: Principles of Functional Programming
#53My 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 w…
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?
Re: 15-150: Principles of Functional Programming
#54Of note, CMU produces a bunch of functional programming research, including a whole homotopy type theory department, so this is a quality source.
[deleted]
Re: 15-150: Principles of Functional Programming
#55God send!! The FP learning resource is quite sparse on the internet. I’ve been looking for structured material like this for a while.
Re: 15-150: Principles of Functional Programming
#56Does this include exercises? I didn't see any and I always find that the most useful part of learning.
Rewriting standard list functions (map, fold, sum, etc.) is a good entry-level exercise.
A λ-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...
Re: 15-150: Principles of Functional Programming
#57Slightly 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 par…
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.
Re: 15-150: Principles of Functional Programming
#58Earlier quoted context omitted.
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…
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)?
He is probably talking about namespaces. In common lisp, for example,
(a a)
Re: 15-150: Principles of Functional Programming
#59My 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 w…
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
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.
Re: 15-150: Principles of Functional Programming
#60Great 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?
[deleted]