Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Functional Programming Patterns

slideshare.net

Post reply on HN
Print view View original

41–50 of 70 posts

Re: Functional Programming Patterns

#41

Post by dschiptsov »

taeric wrote: post #34
jarcane wrote: post #24

Earlier quoted context omitted.

16 of 23 patterns have qualitatively simpler implementation in Lisp or Dylan than in C++ for at least some uses of each pattern Things like this are literally why I switched from Python to Racket almost immediately once I discovered the latter. So much time spent fighting an imperative language to do something that seemed like it should just be easier in the first place.

Racket is an imperative language, as well. Right? Don't get me wrong, I love Racket. Just I don't think of it as !imperative. I am also unconvinced that the imperative nature of many languages is the problem. Not sure what it is.

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

Re: Functional Programming Patterns

#42

Post by taeric »

dschiptsov wrote: post #41
taeric wrote: post #34

Earlier quoted context omitted.

Racket is an imperative language, as well. Right? Don't get me wrong, I love Racket. Just I don't think of it as !imperative. I am also unconvinced that the imperative nature of many languages is the problem. Not sure what it is.

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.

Re: Functional Programming Patterns

#43

Post by dschiptsov »

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.

let* is nothing but nested lets, which, in turn, are nested lamdas.

  (let* ((a 1) (b a))
     (+ a b))
is an abbreviation for

  (let ((a 1))
     (let ((b a))
        (+ a b))))
which, in turn, is a syntactic sugar for

  ((lambda (a)
     ((lambda (b)
         (+ a b)) a)) 1)
There is no "assignment", only lexicaly scooped bindings, which are "stateless" and "declarative".

Looping constructs in Racket are just syntactic sugar - layered macros, based on what they call "contracts", I suppose.

In CL looping constructs are micro-DSLs.

Re: Functional Programming Patterns

#44

Post by tel »

ejenk wrote: post #38
tel wrote: post #31

Earlier quoted context omitted.

Generally what we're talking about is the ability to say something like "for all types X which satisfy a predicate P, we have this code". The ability to quantify over "all" types is a key property of dependently typed languages. Likewise, a lot of Haskell's ability to simulate DT languages comes from its ability to reason about HKTs. In a DT language you have something called a Pi type which is a bit like a function…

Surely your monoid example should be a Sigma type (`exists`), not a Pi type (`forall`), since a monoid is a specification of data for a single type A, not for all types A. Indeed, the empty type has no monoid structure, so the Pi type you wrote down is necessarily empty.

Oh, yup. Surely indeed! I need my checker clearly

Re: Functional Programming Patterns

#45

Post by taeric »

dschiptsov wrote: post #43
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.

let* is nothing but nested lets, which, in turn, are nested lamdas. (let* ((a 1) (b a)) (+ a b)) is an abbreviation for (let ((a 1)) (let ((b a)) (+ a b)))) which, in turn, is a syntactic sugar for ((lambda (a) ((lambda (b) (+ a b)) a)) 1) There is no "assignment", only lexicaly scooped bindings, which are "stateless" and "declarative". Looping constructs in Racket are just syntactic sugar - layered macros, based on…

Yeah, I chose a somewhat poor example. My main point was that order matters, you have to do A before B. You can not do them at the same time, or something different happens. (Contrasted with a language like VHDL where everything typically happens at the same time.)

Simply put, functional is not necessarily the opposite of imperative.

I took to googling to see if someone had made my point better already. The best I found quickly is this[1]. It is a good read. As it points out that we are most likely both stuck on different numbers in the "opposite of imperative" definition world.

I will say that throwing out mutability with the bathwater is perhaps the single most frustrating thing with most functional advocacy.

[1] https://existentialtype.wordpress.com/2013/07/18/what-if-any...

Re: Functional Programming Patterns

#46

Post by skybrian »

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 something complicated: perhaps a bunch of monad transformers or some such?

Slide 104 is misleading. In an imperative language, you can write a decorator function that logs a function's inputs and outputs, and it will have the same API. In a pure language, you can't do that because a function that does I/O has a different type. The flexibility or sloppiness (depending on your point of view) that allows you to do I/O anywhere is really a feature of imperative languages rather than pure functional languages.

Re: Functional Programming Patterns

#47

Post by m0nastic »

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 not the OP, but I am also currently taking the FP101X Mooc with Erik Meijer. So far, I'm enjoying it tremendously. I've signed up for several moocs the past couple years, but have never been able to stick with any. This is the furthest I've been able to actually stay with it, which is probably indicative of something.

The lectures are basically laid out 1:1 with Hutton's Programming in Haskell book, so if you're familiar with that book, you're familiar with the way the course is structured. I find the actual experience of doing all the homework questions very helpful, even if so far nothing has been particularly difficult.

Re: Functional Programming Patterns

#48

Post by profquail »

jbeja wrote: post #27
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…

Loving learning #F for educational purpose on my spare time and I am loving it, any idea of which is the market for this language or for what you should be use it?

Besides the industries pjmlp mentioned (finance and insurance/banking), F# is also being used for data science/analytics/machine learning, distributed applications (on Azure and AWS) and bioinformatics. I also know there are at least a few companies building mobile apps and games with F# (e.g., in combination with the Xamarin toolchain).

Re: Functional Programming Patterns

#49

Post by mercurial »

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 somewhere (something needs to be able to reach the connection pool), so, yes, the comparison is unfair.

Re: Functional Programming Patterns

#50

Post by mercurial »

Interesting but not always correct.

Eg: slide 64 encourages the reader to "Using sum vs inheritance", and then goes on to show the "good" algebraic datatypes (no behaviour, just data) vs the "bad"... multiple class implementing the same interface (which I wouldn't call inheritance).

Post reply on HN