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

131–140 of 146 posts

Re: 15-150: Principles of Functional Programming

#131

Post by doktrin »

brandonspark wrote: post #26
frankbreetz wrote: post #8

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

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)

TIL. Given that 15-213 has been widely available for years I naively assumed this would also hold true for other undergrad CS courses, but apparently not.

Re: 15-150: Principles of Functional Programming

#132

Post by amake »

tonyg wrote: post #130
convolvatron wrote: post #115

Earlier quoted context omitted.

let* permits expressions on the right refer to arbitrary other symbols bound by the let*. in particular it allows for construction of recursive lambdas that may not be linearlizable.

You're thinking of letrec.

Ah, that does look to be the case. I didn't know about that one.

    Signature
    (letrec BINDERS &rest BODY)
    
    Documentation
    Bind variables according to BINDERS then eval BODY.
    
    The value of the last form in BODY is returned.
    Each element of BINDERS is a list (SYMBOL VALUEFORM) that binds
    SYMBOL to the value of VALUEFORM.
    
    The main difference between this macro and let/let* is that
    all symbols are bound before any of the VALUEFORMs are evalled.

Re: 15-150: Principles of Functional Programming

#133

Post by _a_a_a_ »

zem wrote: post #108
_a_a_a_ wrote: post #101

Earlier quoted context omitted.

I'm a back-end dev (inc. FP) and RDBMS guy and even I'd know not to do this; instead to pre-shrink images presented as decorative thumbnails. But let's be constructive, what form should my critical thinking have taken, how should I have done better (edit: or criticised more carefully)? Serious question. Thanks.

https://news.ycombinator.com/item?id=38354130

I think I get the idea, thanks. I am a bit ratty these days so it comes out a bit harsh.

Re: 15-150: Principles of Functional Programming

#134

Post by PennRobotics »

vermilingua wrote: post #79

Content aside, what gorgeous slides. I wish any of my lecturers had the same eye for presentation.

Partial template source of the slides is available at https://github.com/jacobneu/150lectureNotes (For the uninitiated, it's a Beamer theme, compiled with LaTeX)

Some assembly required; use the instructions from https://github.com/jacobneu/alleycat as inspiration, use the scripts (e.g. startLecture) and Makefile in /crucible

Re: 15-150: Principles of Functional Programming

#135

Post by [deleted] »

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…

[deleted]

Re: 15-150: Principles of Functional Programming

#136

Post by SomeRndName11 »

weatherlight wrote: post #87
SomeRndName11 wrote: post #78

Earlier quoted context omitted.

The problem that is extremely verbose though. OCaml is much more concise.

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…

You SML code is incorrect, shows that you actually never coded anything in SML. SML requires that "if" always contains "else" clause (which is the norm for many functional languages). And this kind of stuff which makes SML unnecessarily verbose (OCaml has for operators, single line let definitions that do not require you to make use val and fun for different type definitions etc.).

Re: 15-150: Principles of Functional Programming

#137

Post by zelphirkalt »

jstrieb wrote: post #104

I loved 150 when I took it, and program in SML from time to time to this day. Bob Harper (a CMU professor with a focus on PL theory) also has a really good SML reference that is closer to a textbook than lecture notes. http://www.cs.cmu.edu/~rwh/isml/book.pdf

I found the regular expression package as a first thing to make in SML waaay too complex. You already need to have a good understanding of the elements of SML syntax to understand how it works. This is definitely not for SML beginners. I recommend "Elements of ML Programming" by Jeffrey D. Ullman for people starting to learn SML. It too has some corners, that are less great for not so mathematically inclined people, but you will definitely learn the language and have exercises.

Re: 15-150: Principles of Functional Programming

#138

Post by jstrieb »

zelphirkalt wrote: post #137
jstrieb wrote: post #104

I loved 150 when I took it, and program in SML from time to time to this day. Bob Harper (a CMU professor with a focus on PL theory) also has a really good SML reference that is closer to a textbook than lecture notes. http://www.cs.cmu.edu/~rwh/isml/book.pdf

I found the regular expression package as a first thing to make in SML waaay too complex. You already need to have a good understanding of the elements of SML syntax to understand how it works. This is definitely not for SML beginners. I recommend "Elements of ML Programming" by Jeffrey D. Ullman for people starting to learn SML. It too has some corners, that are less great for not so mathematically inclined people,…

This is valid criticism, and I agree. The regular expression example is not made easier by his use of non-standard regex syntax.

I have not read Dr. Harper's book cover to cover; I treat it as a reference. For that, it is quite useful.

The same criticism of his SML book could also be made of his Practical Foundations for Programming Languages book. It's a massive, dense tome that is probably great for other professors to use as the basis for a course, but (in my opinion) serves as a mediocre introduction if you have never seen the material before.

https://www.cs.cmu.edu/~rwh/pfpl.html

Re: 15-150: Principles of Functional Programming

#139

Post by weatherlight »

SomeRndName11 wrote: post #136
weatherlight wrote: post #87

Earlier quoted context omitted.

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…

You SML code is incorrect, shows that you actually never coded anything in SML. SML requires that "if" always contains "else" clause (which is the norm for many functional languages). And this kind of stuff which makes SML unnecessarily verbose (OCaml has for operators, single line let definitions that do not require you to make use val and fun for different type definitions etc.).

I did Programming Languages, Part A, (to learn FP semantics) many years ago. It doesn't show I never coded anything in SML, it shows I made a mistake :/ .I no longer have Standard ML on my machine.

I thought having the `let` keyword encompass `fun` and `val.` was needlessly confusing. It's not concise. if `let` can mean so many things why not just do what Haskell did.

Again.. it not "so much more verbose." which was the initial point.

but I concede, my SML code is in fact incorrect.

Re: 15-150: Principles of Functional Programming

#140

Post by SomeRndName11 »

weatherlight wrote: post #139
SomeRndName11 wrote: post #136

Earlier quoted context omitted.

You SML code is incorrect, shows that you actually never coded anything in SML. SML requires that "if" always contains "else" clause (which is the norm for many functional languages). And this kind of stuff which makes SML unnecessarily verbose (OCaml has for operators, single line let definitions that do not require you to make use val and fun for different type definitions etc.).

I did Programming Languages, Part A, (to learn FP semantics) many years ago. It doesn't show I never coded anything in SML, it shows I made a mistake :/ .I no longer have Standard ML on my machine. I thought having the `let` keyword encompass `fun` and `val.` was needlessly confusing. It's not concise. if `let` can mean so many things why not just do what Haskell did. Again.. it not "so much more verbose." which was…

No SML is more verbose, is pretty obvious. A simple "for" in ocaml could save lots boilerplate doing trivial recurison.
Post reply on HN