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

101–110 of 146 posts

Re: 15-150: Principles of Functional Programming

#101

Post by _a_a_a_ »

xerox13ster wrote: post #98
_a_a_a_ wrote: post #94

Earlier quoted context omitted.

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

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.

Re: 15-150: Principles of Functional Programming

#102

Post by Ringz »

lstamour wrote: post #96
_a_a_a_ wrote: post #94

Earlier quoted context omitted.

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.

> "it was completely bloody unnecessary to waste enormous amounts of bandwidth"

Thats not enough. It was completely bloody unnecessary to waste enormous amounts of co2.

And critical thinking should lead to the realization that not many people have to solve the - albeit small - mistake of an individual via Cloudflare or similar, but rather someone should do it correctly right away. And if he has no knowledge of frontend, he should not do things he has no knowledge of.

Re: 15-150: Principles of Functional Programming

#106

Post by kccqzy »

epgui wrote: post #97
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.

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.

Any time an HN comment uses the phrase "fundamental problem" chances are the problem is not only not fundamental, but also rather fun to solve for the right kind of people.

Re: 15-150: Principles of Functional Programming

#107

Post by agumonkey »

brandonspark wrote: post #21
systems wrote: post #15

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

having done the proglang course by dan grossman long ago, they use sml too, i knew lisps, ocaml, and others, but sml smallness was really really appealing

Re: 15-150: Principles of Functional Programming

#108

Post by zem »

_a_a_a_ wrote: post #101
xerox13ster wrote: post #98

Earlier quoted context omitted.

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

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

Re: 15-150: Principles of Functional Programming

#109

Post by kccqzy »

imslavko wrote: post #99
philsnow wrote: post #81

Earlier quoted context omitted.

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

Oh definitely go deep into monads. If you use the ST monad to do mutations, some people think Haskell provides nicer syntax to do imperative programming than traditional imperative languages like C. But of course such nicer syntax only comes from understanding and using important abstractions like monads, foldable, or traversable. Then there are niceties like automatic SoA/AoS transformation using type families.

Re: 15-150: Principles of Functional Programming

#110

Post by munchler »

zem wrote: post #75
munchler wrote: post #34

Earlier quoted context omitted.

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 think someone with a good grounding in sml could get proficient ocaml or f# in under a month. sml is absolutely the right language to teach a course like this in.

I agree with your first sentence, but the second one surprises me. If the practical language and the impractical one are that similar, why pick the impractical one?
Post reply on HN