Live data from Hacker News

Functional Programming For The Rest of Us

defmacro.org

31–40 of 69 posts

Re: Functional Programming For The Rest of Us

#31

Good article , cleared a few things up for me. One thing I am still a bit hazy on though. He mentions that continuations could be used in the context of a web app to maintain state between HTTP requests. I'm not quite clear how this would actually work. Lets say you have something like this (in psuedocode): Let's say we have a counter we want to increment on each request. doHTTPRequest(requestVars) { renderPage(reque…

pg has a patent on this (I think). http://www.ptodirect.com/Results/Patents?query=PN/6205469

Re: Functional Programming For The Rest of Us

#32

Good article , cleared a few things up for me. One thing I am still a bit hazy on though. He mentions that continuations could be used in the context of a web app to maintain state between HTTP requests. I'm not quite clear how this would actually work. Lets say you have something like this (in psuedocode): Let's say we have a counter we want to increment on each request. doHTTPRequest(requestVars) { renderPage(reque…

Node.js is built around a lot of continuations, if I recall. It's very common in event driven computing. I believe the basic way to do it is that the function that processes the original request both returns the output and the continuation, then the next time the user connects it would use the continuation instead of the original function. function doHTTPRequest(requestVars, renderPage) { (content, renderNextPage) =…

Thankyou, that has made it at least slightly more clear to me I think :)

So what you need basically in the core of your server is some data structure (possibly keyed by the client's IP address and TCP port number?) that contains a bunch of functions with prepopulated arguments (curried functions?).

The prepopulated arguments are basically the state set by the previous request. When a new request comes in you somehow match it up with your data structure and execute?

I guess the continuation part is to force the I/O to happen at the right point, i.e make the next request depend on the execution of the first?

Of course Javascript is not really functional so that needn't be explicit.

Re: Functional Programming For The Rest of Us

#33
Is it me or that "A Walk in the Park" sounds like Sheldon Cooper from the Big Bang theory:

"Fire up the time machine. Our walk in the park took place more than two thousand years ago, on a beautiful sunny day of a long forgotten spring in 380 B.C. Outside the city walls of Athens, under the pleasant shade of olive trees Plato was walking towards the Academy with a beautiful slave boy. The weather was lovely, the dinner was filling, and the conversation turned to philosophy."

Big Bang: http://www.youtube.com/watch?v=lDxv9hSKdY4

Re: Functional Programming For The Rest of Us

#34
post #7

Earlier quoted context omitted.

I think the "if it compiles, it works" has to do with Haskell's type system being much more expressive than most static languages, and that most of your code will be declarative and pure. Purity helps because your program will necessarily be composed of small, self-contained modules (usually functions) that have no implicit dependencies. The type system helps because you can encode a lot of the code's intent in type…

Agreed; after getting used to working with Haskell's type system, I've found it kind of painful to use languages with weaker, less expressive type systems (which unfortunately, is basically every practical language other than Haskell). The ability to transform all manner of bugs into compile-time errors via the typechecker is indispensable. Once you start digging into GHC extensions like GADTs and type families, it g…

> which unfortunately, is basically every practical language other than Haskell

Is this also true of Ocaml? I have experience in neither, but my understanding from reading up on this says Ocaml and Haskell are roughly equivalent, and if anything - Ocaml is even more expressive.

Anyone with real world experience who can comment on this?

Re: Functional Programming For The Rest of Us

#35
post #34

Earlier quoted context omitted.

Agreed; after getting used to working with Haskell's type system, I've found it kind of painful to use languages with weaker, less expressive type systems (which unfortunately, is basically every practical language other than Haskell). The ability to transform all manner of bugs into compile-time errors via the typechecker is indispensable. Once you start digging into GHC extensions like GADTs and type families, it g…

> which unfortunately, is basically every practical language other than Haskell Is this also true of Ocaml? I have experience in neither, but my understanding from reading up on this says Ocaml and Haskell are roughly equivalent, and if anything - Ocaml is even more expressive. Anyone with real world experience who can comment on this?

I can't answer you with any real authority, since I haven't used OCaml. But from what I understand, it lacks type classes, which are absolutely central to the richness of Haskell's type system. Whether or not it makes up for this in other ways, I can't say.

OCaml is also strict by default, with optional laziness, whereas Haskell is the opposite. This could be seen as either an advantage or a disadvantage, but either way, it is a very fundamental difference.

If you are considering learning one or the other, I'd advocate for Haskell purely on the basis of it being the closest to mainstream of all the static functional languages. There is a huge variety of libraries available on Hackage, and the community is very active, welcoming, and friendly. Haskell (GHC in particular) is also the laboratory in which the majority of interesting FP research is currently being done, if you care about that at all.

Or just learn both languages, so you can compare the benefits and disadvantages for yourself. :)

Re: Functional Programming For The Rest of Us

#36
> Programmers are procrastinators. Get in, get some coffee, check the mailbox, read the RSS feeds, read the news, check out latest articles on techie websites, browse through political discussions on the designated sections of the programming forums. Rinse and repeat to make sure nothing is missed. Go to lunch. Come back, stare at the IDE for a few minutes. Check the mailbox. Get some coffee. Before you know it, the day is over.

You're fired.

Re: Functional Programming For The Rest of Us

#37
post #34

Earlier quoted context omitted.

> which unfortunately, is basically every practical language other than Haskell Is this also true of Ocaml? I have experience in neither, but my understanding from reading up on this says Ocaml and Haskell are roughly equivalent, and if anything - Ocaml is even more expressive. Anyone with real world experience who can comment on this?

I can't answer you with any real authority, since I haven't used OCaml. But from what I understand, it lacks type classes, which are absolutely central to the richness of Haskell's type system. Whether or not it makes up for this in other ways, I can't say. OCaml is also strict by default, with optional laziness, whereas Haskell is the opposite. This could be seen as either an advantage or a disadvantage, but either…

OCaml has a powerful module system which can be used in a way quite similar to typeclasses (https://ocaml.janestreet.com/?q=node/37).

The main difference is the lack of purity, which means that the side effects of a function aren't part of a function's type. It also doesn't have the wide variety of extensions which you can use to do really crazy stuff (like verifiably correct red-black trees, https://github.com/yairchu/red-black-tree/blob/master/RedBla...).

Re: Functional Programming For The Rest of Us

#38
Interesting, well written article.

However I was surprised to be made aware of the existence of a logician named Haskell Curry. The name struck me as the punchline to a joke only told and appreciated by the uber-nerds in the halls of elite university mathematics departments.

Re: Functional Programming For The Rest of Us

#40
post #9

Kudos to the piece for being well written, readable, and clear. But I'm worried about a "for the rest of us" that starts off with first Plato and then lambda calculus. The problem with "the rest of us" is that these concepts aren't inherently neat. Disclaimer: I'm not one of "rest of us". I'm learning Haskell, just because I enjoy having to think in a new way. A lot of FP explanations start off with immutability. Aft…

With that in mind, I recently wrote a series of posts about integrating functional programming concepts into everyday Javascript programming (and AS3, which is nearly identical). The last two, in particular, might be interesting even for programmers who already understand the basics.

http://www.alanmacdougall.com/functional-series/

I'd really like to see these techniques emerge into the spotlight, instead of just being voodoo magic hidden deep in the guts of frameworks.

Post reply on HN