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.
15-150: Principles of Functional Programming
31–40 of 146 posts
Re: 15-150: Principles of Functional Programming
#32My 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…
[deleted]
Re: 15-150: Principles of Functional Programming
#33My 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…
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.
Re: 15-150: Principles of Functional Programming
#34on 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
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 wit…
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.
Re: 15-150: Principles of Functional Programming
#35Slightly 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.
Re: 15-150: Principles of Functional Programming
#36just 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...
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.
Re: 15-150: Principles of Functional Programming
#37Great 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?
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.
[deleted]
Re: 15-150: Principles of Functional Programming
#38My 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
Re: 15-150: Principles of Functional Programming
#39Wow, 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.
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
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.
Re: 15-150: Principles of Functional Programming
#40Great 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?
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)?