Live data from Hacker News

15-150: Principles of Functional Programming

brandonspark.github.io

91–100 of 146 posts

Re: 15-150: Principles of Functional Programming

#91
post #84

Earlier quoted context omitted.

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)

[flagged]

“Here is the fruit of my labour and love, which I give to you at no cost.”

“How dare you do it this way!”

Re: 15-150: Principles of Functional Programming

#92
post #40
post #28

Earlier 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)?

They don’t.

Or at least not inherently, if by “lisp” one is primarily referring to s-expressions.

Re: 15-150: Principles of Functional Programming

#93
post #91
post #84

Earlier quoted context omitted.

[flagged]

“Here is the fruit of my labour and love, which I give to you at no cost.” “How dare you do it this way!”

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

Re: 15-150: Principles of Functional Programming

#94
post #91
post #84

Earlier quoted context omitted.

[flagged]

“Here is the fruit of my labour and love, which I give to you at no cost.” “How dare you do it this way!”

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.

Re: 15-150: Principles of Functional Programming

#96
post #94
post #91

Earlier quoted context omitted.

“Here is the fruit of my labour and love, which I give to you at no cost.” “How dare you do it this way!”

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…

As a matter of principle, those in bandwidth-constrained situations should be browsing via proxies or browsers that automatically compress, such as Opera Mobile back in the day, or Google’s more modern compression baked in to Android/Chrome. (If it still exists, it’s been awhile…) That said… yeah, it couldn’t hurt to put a free CloudFlare CDN in front with automatic image optimization, for example.

Re: 15-150: Principles of Functional Programming

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

That’s like saying the problem with rulers is that the real world doesn’t have straight lines.

Or the problem with cleaning your room is that in the real world entropy only ever increases.

Re: 15-150: Principles of Functional Programming

#98
post #94
post #91

Earlier quoted context omitted.

“Here is the fruit of my labour and love, which I give to you at no cost.” “How dare you do it this way!”

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…

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

Perhaps is doing some heavy lifting here. I take it from the fact that the lectures are on Functional Programming that OP might not be a front-end developer and might not have the level of care needed for front end to compress the images in a way that renders nicely. So,

Perhaps you ought not judge someone releasing their free teaching materials for a backend class on their front end development, when the site is a centered with purely static elements.

Perhaps you ought to slow down and do some critical thinking before being critical of others.

Re: 15-150: Principles of Functional Programming

#99
post #74

Earlier quoted context omitted.

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…

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

Oh yeah, a pure function that accepts previous state, and returns the new state is the pattern I use a lot.

The issue is that it is hard to do on complex graph structures in an algorithm where incremental changes happen to the graph O(n) times - it ends up creating complex code and complex execution that might be slow to pass the time limit on Codeforces, let's say.

In the OCaml world maybe this is the place where you say "screw it, this abstracted function does some stateful temporary business, but it looks pure from the outside" but in Haskell it's a lot harder to pull off without going deep into monads (and I forget how those work every time).

Re: 15-150: Principles of Functional Programming

#100
post #91
post #84

Earlier quoted context omitted.

[flagged]

“Here is the fruit of my labour and love, which I give to you at no cost.” “How dare you do it this way!”

Its not “How dare you do it this way!”. Its "Why do you fail in the end with the simplest and most obvious tasks?"
Post reply on HN