Functional Programming Patterns • Hacker News Board

Re: Functional Programming Patterns

#51

Post by skybrian » Sun, Nov 30, 2014, 10:27 PM UTC

mercurial wrote: post #49

skybrian wrote: post #46

These slides explain the usual functional patterns but it seems like a bit of a cheat, because it doesn't really explain how to do anything hard (dealing with time, persistence, logging, and so on). The comparison between Slides 81 and 82 is particularly unfair because the "object soup" actually does deal with the database, SMTP, and so on and the functional version doesn't. If you add those in, you're going to get s…

You're mixing up functional and pure. Plenty of "functional" languages let you do IO everywhere. > The comparison between Slides 81 and 82 is particularly unfair because the "object soup" actually does deal with the database, SMTP, and so on and the functional version doesn't. If you add those in, you're going to get something complicated: perhaps a bunch of monad transformers or some such? You clearly need state som…

I think it's the terminology that's mixed up, actually. Functions are first-class datatypes in many imperative languages, including Python, Go, or JavaScript, but they mostly aren't mathematical functions.

Re: Functional Programming Patterns

#52

Post by runT1ME » Sun, Nov 30, 2014, 10:29 PM UTC

virtualwhys wrote: post #22

Excellent presentation. Of the leading type safe functional languages (Haskell, F#, and OCaml) I find F# to be far and away the most accessible in terms of syntax and application. Writing Scala in my day job currently (which, for the most part, I quite enjoy) but can see jumping ship if Microsoft's move to Linux is successful. Being able to develop and deploy F# applications on Linux with full blown Type Providers an…

Scala's biggest advantage over other languages for me in terms of reducing bugs, complexity, and pleasantness have been higher kinded types. Given that F# is lacking in this, and they don't have plans to add it, I can't even see them as comparable.

Re: Functional Programming Patterns

#53

Post by tel » Sun, Nov 30, 2014, 10:29 PM UTC

skybrian wrote: post #46

These slides explain the usual functional patterns but it seems like a bit of a cheat, because it doesn't really explain how to do anything hard (dealing with time, persistence, logging, and so on). The comparison between Slides 81 and 82 is particularly unfair because the "object soup" actually does deal with the database, SMTP, and so on and the functional version doesn't. If you add those in, you're going to get s…

You can just turn that exact statement on its head and say that "the ability to recognize and differentiate between different kinds of effects in use is a feature of pure functional languages".

Re: Functional Programming Patterns

#54

Post by tel » Sun, Nov 30, 2014, 10:32 PM UTC

taeric wrote: post #42

dschiptsov wrote: post #41

Earlier quoted context omitted.

Racket is "mostly functional" which means that very few "impure" data structures (mcons, for example) and operations are marked explicitly (by convention).

That does nothing to talk about imperative versus not, though. Does it? The entire for* and let* class of bindings are imperative, in that the order matters. Same with (begin and friends.

Imperative requires order but they are not identical. Imperative tends to mean "sequence of instructions which operate on an exterior set of mutable state cells" versus functional which often means "set of expressions which reduce into values". Each can model the other, but let is clearly functional in this model since its meaning derives entirely from a reduction semantics.

Re: Functional Programming Patterns

#55

Post by mercurial » Sun, Nov 30, 2014, 10:34 PM UTC

skybrian wrote: post #51

mercurial wrote: post #49

Earlier quoted context omitted.

You're mixing up functional and pure. Plenty of "functional" languages let you do IO everywhere. > The comparison between Slides 81 and 82 is particularly unfair because the "object soup" actually does deal with the database, SMTP, and so on and the functional version doesn't. If you add those in, you're going to get something complicated: perhaps a bunch of monad transformers or some such? You clearly need state som…

I think it's the terminology that's mixed up, actually. Functions are first-class datatypes in many imperative languages, including Python, Go, or JavaScript, but they mostly aren't mathematical functions.

There is no clear-cut definition of what makes a language functional, but popular opinion says that F#, OCaml or Clojure are functional languages, none of which are pure.

Re: Functional Programming Patterns

#56

Post by 1971genocide » Sun, Nov 30, 2014, 10:37 PM UTC

I Really found the book "Learn you a haskell" to be an really fast way to get functional programming into production.

I did not however continue to use haskell since it doesnt have key libraries I need.

I instead adopted livescript,underscore into javascript and was good to go.

Re: Functional Programming Patterns

#57

Post by codygman » Sun, Nov 30, 2014, 11:13 PM UTC

1971genocide wrote: post #56

I Really found the book "Learn you a haskell" to be an really fast way to get functional programming into production. I did not however continue to use haskell since it doesnt have key libraries I need. I instead adopted livescript,underscore into javascript and was good to go.

Out of curiosity, what libraries did you need?

Re: Functional Programming Patterns

#58

Post by mitchty » Sun, Nov 30, 2014, 11:25 PM UTC

hexasquid wrote: post #35

KurtMueller wrote: post #16

I am currently taking EdX's Intro to Functional Programming mooc, taught by Erik Meijer (with his crazy shirts), which uses Haskell to teach functional programming concepts. I am wondering if there are any other good resources for teaching the functional programming paradigms. Anybody care to recommend me some resources? Also, I mainly work with Ruby and Javascript in my full time job. Currently, in school, I use Jav…

How are you finding the mooc? Can you recommend it?

I'm also taking it to help flesh out my Haskell learning. I rather like it.

Be aware it starts out really slow then 50% in ratchets up the fun into "scare away the freshman" territory with monads. I have to say preexisting knowledge has been quite helpful.

About my only complaint is the amount of "which of these 9 implementations are valid" exercises. Although i've been cheating and using hspec to tdd my way through them.

Re: Functional Programming Patterns

#59

Post by taeric » Sun, Nov 30, 2014, 11:47 PM UTC

tel wrote: post #54

taeric wrote: post #42

Earlier quoted context omitted.

That does nothing to talk about imperative versus not, though. Does it? The entire for* and let* class of bindings are imperative, in that the order matters. Same with (begin and friends.

Imperative requires order but they are not identical. Imperative tends to mean "sequence of instructions which operate on an exterior set of mutable state cells" versus functional which often means "set of expressions which reduce into values". Each can model the other, but let is clearly functional in this model since its meaning derives entirely from a reduction semantics.

See my link down thread. I think this really comes down to the murkiness in definitions of declarative and imperative. I did find a later definition that points out that these are no longer duals of each other.

I was actively avoiding the obviously imperative functions, though. Not sure why. That is, I could have simply said that the existence of all of the functions that end in exclamation points shows the language is imperative.

Re: Functional Programming Patterns

#60

Post by tel » Mon, Dec 01, 2014, 2:09 AM UTC

taeric wrote: post #59

tel wrote: post #54

Earlier quoted context omitted.

Imperative requires order but they are not identical. Imperative tends to mean "sequence of instructions which operate on an exterior set of mutable state cells" versus functional which often means "set of expressions which reduce into values". Each can model the other, but let is clearly functional in this model since its meaning derives entirely from a reduction semantics.

See my link down thread. I think this really comes down to the murkiness in definitions of declarative and imperative. I did find a later definition that points out that these are no longer duals of each other. I was actively avoiding the obviously imperative functions, though. Not sure why. That is, I could have simply said that the existence of all of the functions that end in exclamation points shows the language…

The imperativeness of Racket really doesn't come so much from the *! functions, but instead things like `begin` which explicitly sequence program statements in such a way that only allows them to interact via external mutable state.