Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

15-150: Principles of Functional Programming

brandonspark.github.io

Post reply on HN
Print view View original

61–70 of 146 posts

Re: 15-150: Principles of Functional Programming

#61

Post by frozenlettuce »

tromp wrote: post #46
frozenlettuce wrote: post #31

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 w…

> 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.

I've been playing with purescript and found out that they have a similar library, thanks!

Re: 15-150: Principles of Functional Programming

#62

Post by bfors »

munchler wrote: post #34
brandonspark wrote: post #21

Earlier quoted context omitted.

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.

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.

Re: 15-150: Principles of Functional Programming

#63

Post by brandonspark »

frankbreetz wrote: post #8

Does this include exercises? I didn't see any and I always find that the most useful part of learning.

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?

Re: 15-150: Principles of Functional Programming

#64

Post by Koshkin »

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.

Re: 15-150: Principles of Functional Programming

#65

Post by bmacho »

agomez314 wrote: post #11

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?

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.

Re: 15-150: Principles of Functional Programming

#67

Post by [deleted] »

Koshkin wrote: post #64

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.

[deleted]

Re: 15-150: Principles of Functional Programming

#68

Post by tmvphil »

johnday wrote: post #28
agomez314 wrote: post #11

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?

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…

I think SML isn't purely functional (although it naturally encourages a purely functional style).
Post reply on HN