Coding katas/dojos and functional programming introduction

Gautier DI FOLCO

15 Apr 2015 15 Apr '15

6:34 a.m.

Hello, Some days ago I have participated to a coding dojo* which aimed to be an introduction to functional programming. I have also facilitate 3 of events like this and do several talks on this subject. But I'm kinda disappointed because each time there is a common pattern: 1. Unveil the problem which will be treated 2. Let the attendees solve it 3. Show the FP-ish solution (generally a bunch of map/fold) I think it's frustrating for the attendees (because they don't try to solve it) and gives a false illusion of knowledge. I don't consider myself as a "FP guru" or anything but for me FP is a matter of types and expressions, so when someone illustrate FP via map/fold, it's kind of irritating. Ironically, the best workshop I have done was on functional generalization (you begin by two hard coded functions, sum and product, and you extract Foldable and Monoid), but again, it's not satisfying. We can do better, we should do better. Have you got any feedback/subjet ideas/examples on how to introduce "real" FP to beginners in a short amount of time (like 1-3 hours)? Thanks in advance for your help. Regards. * Basically you have 2 to 3 hours, a problem and you try to solve with in iteration with different constraints

Attachments:

attachment.html (text/html — 1.3 KB)

Show replies by date

Mike Meyer

15 Apr 15 Apr

7:15 p.m.

...

Some days ago I have participated to a coding dojo* which aimed to be an introduction to functional programming. I have also facilitate 3 of events

On Wed, Apr 15, 2015 at 1:34 AM, Gautier DI FOLCO wrote: like this and do several talks on this subject. But I'm kinda disappointed because each time there is a common pattern:

...

1. Unveil the problem which will be treated 2. Let the attendees solve it 3. Show the FP-ish solution (generally a bunch of map/fold) I think it's frustrating for the attendees (because they don't try to solve it) and gives a false illusion of knowledge. I don't consider myself as a "FP guru" or anything but for me FP is a matter of types and expressions, so when someone illustrate FP via map/fold, it's kind of irritating. Ironically, the best workshop I have done was on functional generalization (you begin by two hard coded functions, sum and product, and you extract Foldable and Monoid), but again, it's not satisfying. We can do better, we should do better. Have you got any feedback/subjet ideas/examples on how to introduce "real" FP to beginners in a short amount of time (like 1-3 hours)?

Well, functional programming is very much like an elephant. I started with it doing Scheme, so while I appreciate what the HM type system brings to the table, to me it's not what functional programming is about. To me, functional programming is about thinking about functions as data, and designing them so you can compose and combine them like you would data, as opposed to simply being tools for encapsulating code. As such, maps and folds are simple, easy-to-understand higher order functions that you can plug other functions into. But such discussions tend to highlight map/fold, not how you build the functions that get plugged into them. To me, a better example would be one of the combinator-based parsing libraries. Say Text.XML.Cursor, as in the School of Haskell tutorial at https://www.fpcomplete.com/school/starting-with-haskell/libraries-and-framew... .

Alexander Solla

7:23 p.m.

The first exercise I did when I learned Haskell some 8 years ago was re-implement all of the list functions in the Prelude, based on the types and documentation. On Tue, Apr 14, 2015 at 11:34 PM, Gautier DI FOLCO < gautier.difolco@gmail.com> wrote:

...

Hello,

Some days ago I have participated to a coding dojo* which aimed to be an introduction to functional programming. I have also facilitate 3 of events like this and do several talks on this subject. But I'm kinda disappointed because each time there is a common pattern: 1. Unveil the problem which will be treated 2. Let the attendees solve it 3. Show the FP-ish solution (generally a bunch of map/fold) I think it's frustrating for the attendees (because they don't try to solve it) and gives a false illusion of knowledge. I don't consider myself as a "FP guru" or anything but for me FP is a matter of types and expressions, so when someone illustrate FP via map/fold, it's kind of irritating. Ironically, the best workshop I have done was on functional generalization (you begin by two hard coded functions, sum and product, and you extract Foldable and Monoid), but again, it's not satisfying. We can do better, we should do better. Have you got any feedback/subjet ideas/examples on how to introduce "real" FP to beginners in a short amount of time (like 1-3 hours)?

Thanks in advance for your help. Regards.

* Basically you have 2 to 3 hours, a problem and you try to solve with in iteration with different constraints

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

Gautier DI FOLCO

10:28 p.m.

2015-04-15 19:15 GMT+00:00 Mike Meyer :

...

Well, functional programming is very much like an elephant.

I have the same thought about OOP some years ago, them I discovered then first meaning of it and all was so clear and simple. My goal isn't to teach the full power of FP, my goal is to give them inspiration, to suggest that there is a wider world to explore.

...

As such, maps and folds are simple, easy-to-understand higher order functions that you can plug other functions into. But such discussions tend to highlight map/fold, not how you build the functions that get plugged into them.

That my main concern.

...

To me, a better example would be one of the combinator-based parsing libraries. Say Text.XML.Cursor, as in the School of Haskell tutorial at https://www.fpcomplete.com/school/starting-with-haskell/libraries-and-framew...

I'll have a look but parsing is a bit too "magic" I think. 2015-04-15 19:23 GMT+00:00 Alexander Solla :

...

The first exercise I did when I learned Haskell some 8 years ago was re-implement all of the list functions in the Prelude, based on the types and documentation.

Good idea, I have also done the NICTA repository and if was a nice training.

Mike Meyer

10:40 p.m.

On Wed, Apr 15, 2015 at 5:28 PM, Gautier DI FOLCO

...

wrote:

...

2015-04-15 19:15 GMT+00:00 Mike Meyer :

...
Well, functional programming is very much like an elephant.

I have the same thought about OOP some years ago, them I discovered then first meaning of it and all was so clear and simple. My goal isn't to teach the full power of FP, my goal is to give them inspiration, to suggest that there is a wider world to explore.

Just clarify, this is a reference to the fable of the blind men and the elephant. What you think it is like will depend on how you approach it.

Raphael Gaschignard

16 Apr 16 Apr

5:24 a.m.

Is this aimed for FP beginners who already know something like Java? I think the thing to do here would be to come up with some tasks that are genuinely tedious to write in a Java-esque (or Pascal-like) language, and then present how FP solutions are simpler. I'm of the opinion that FP succeeds not just because of the tenants of FP, but because most of the languages are terse and have code that is "pretty". Showing some quick things involving quick manipulation of tuples (basically a bunch of list processing) could show that things don't have to be complicated with a bunch of anonymous classes. Anyways, I think the essential thing is to present a problem that they, as programmers, have already experienced. The big one being "well these two functions are *almost* the same but the inner-part of the function has different logic" (basically, looking at things like map). Open up the world of possibilities. It's not things that are only possible in Haskell/Scheme (after all, all of these languages are turing complete so..), but they're so much easier to write in these languages. On Thu, Apr 16, 2015 at 7:41 AM Mike Meyer wrote:

...

On Wed, Apr 15, 2015 at 5:28 PM, Gautier DI FOLCO < gautier.difolco@gmail.com> wrote:

...
2015-04-15 19:15 GMT+00:00 Mike Meyer :

...
Well, functional programming is very much like an elephant.

I have the same thought about OOP some years ago, them I discovered then first meaning of it and all was so clear and simple. My goal isn't to teach the full power of FP, my goal is to give them inspiration, to suggest that there is a wider world to explore.

Just clarify, this is a reference to the fable of the blind men and the elephant. What you think it is like will depend on how you approach it. _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

Kyle Marek-Spartz

6:41 p.m.

A little out of date, and unsure what level it is aimed at, but there are a few sets ready to go: https://github.com/HaskVan/HaskellKoans https://wiki.haskell.org/H-99:_Ninety-Nine_Haskell_Problems -- Kyle Marek-Spartz

Gautier DI FOLCO

10:47 p.m.

2015-04-15 22:40 GMT+00:00 Mike Meyer :

...

Just clarify, this is a reference to the fable of the blind men and the elephant.

I obviously lack of culture, thanks for the precision. What you think it is like will depend on how you approach it.

...

Exactly, each paradigms I have learned (OOP, FP, Logic, Actor, Data-Flow) seemed to be a giant mess until I found a good approach and see a big and coherent unit. I miss a approach to broadcast it for FP. 2015-04-16 5:24 GMT+00:00 Raphael Gaschignard :

...

Is this aimed for FP beginners who already know something like Java? I think the thing to do here would be to come up with some tasks that are genuinely tedious to write in a Java-esque (or Pascal-like) language, and then present how FP solutions are simpler.

I'm of the opinion that FP succeeds not just because of the tenants of FP, but because most of the languages are terse and have code that is "pretty". Showing some quick things involving quick manipulation of tuples (basically a bunch of list processing) could show that things don't have to be complicated with a bunch of anonymous classes.

That's currently that we tend to do, but these are too "toy examples", they doesn't stick to the day-to-day problems.

...

Anyways, I think the essential thing is to present a problem that they, as programmers, have already experienced. The big one being "well these two functions are *almost* the same but the inner-part of the function has different logic" (basically, looking at things like map). Open up the world of possibilities. It's not things that are only possible in Haskell/Scheme (after all, all of these languages are turing complete so..), but they're so much easier to write in these languages.

Good hint. 2015-04-16 18:41 GMT+00:00 Kyle Marek-Spartz :

...

A little out of date, and unsure what level it is aimed at, but there are a few sets ready to go:

https://github.com/HaskVan/HaskellKoans

https://wiki.haskell.org/H-99:_Ninety-Nine_Haskell_Problems

I totally forgot the last one, but I think it doesn't emphasize enough on the type part.

Ernesto Rodriguez

17 Apr 17 Apr

7:47 a.m.

I agree with the approach. I have never done a intro to FP but I think parser combinators couod be a good start. U begin by showing the high level interface, I mean learning how to write simple parsers using for instance Parsec is.easy and one immediately sees the elegance and simplicity that approach has over say yacc. Then u guide them on implementimg a own basic parser combinator library which in my opinion is not out of this world with a good guideance. That way they see that such a powerful tool aint dark magic with FP. Anyways good luck with your workshop. Cheers, N. On Apr 16, 2015 7:25 AM, "Raphael Gaschignard" wrote:

...

Is this aimed for FP beginners who already know something like Java? I think the thing to do here would be to come up with some tasks that are genuinely tedious to write in a Java-esque (or Pascal-like) language, and then present how FP solutions are simpler.

I'm of the opinion that FP succeeds not just because of the tenants of FP, but because most of the languages are terse and have code that is "pretty". Showing some quick things involving quick manipulation of tuples (basically a bunch of list processing) could show that things don't have to be complicated with a bunch of anonymous classes.

Anyways, I think the essential thing is to present a problem that they, as programmers, have already experienced. The big one being "well these two functions are *almost* the same but the inner-part of the function has different logic" (basically, looking at things like map). Open up the world of possibilities. It's not things that are only possible in Haskell/Scheme (after all, all of these languages are turing complete so..), but they're so much easier to write in these languages.

On Thu, Apr 16, 2015 at 7:41 AM Mike Meyer wrote:

...
On Wed, Apr 15, 2015 at 5:28 PM, Gautier DI FOLCO < gautier.difolco@gmail.com> wrote:

...
2015-04-15 19:15 GMT+00:00 Mike Meyer :

...
Well, functional programming is very much like an elephant.

I have the same thought about OOP some years ago, them I discovered then first meaning of it and all was so clear and simple. My goal isn't to teach the full power of FP, my goal is to give them inspiration, to suggest that there is a wider world to explore.

Just clarify, this is a reference to the fable of the blind men and the elephant. What you think it is like will depend on how you approach it. _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

Alexey Shmalko

11:38 a.m.

When I was a Haskell beginner I was fascinated by writing even a simple CSV parser. It was so clear after flex/bison or parsing by hand in C++. The other cool thing in Haskell is writing JSON parsers with aeson. They also really short and expressive. Regards, Alexey On Fri, Apr 17, 2015 at 10:47 AM, Ernesto Rodriguez wrote:

...

I agree with the approach. I have never done a intro to FP but I think parser combinators couod be a good start. U begin by showing the high level interface, I mean learning how to write simple parsers using for instance Parsec is.easy and one immediately sees the elegance and simplicity that approach has over say yacc. Then u guide them on implementimg a own basic parser combinator library which in my opinion is not out of this world with a good guideance. That way they see that such a powerful tool aint dark magic with FP.

Anyways good luck with your workshop.

Cheers,

N. On Apr 16, 2015 7:25 AM, "Raphael Gaschignard" wrote:

...
Is this aimed for FP beginners who already know something like Java? I think the thing to do here would be to come up with some tasks that are genuinely tedious to write in a Java-esque (or Pascal-like) language, and then present how FP solutions are simpler.

I'm of the opinion that FP succeeds not just because of the tenants of FP, but because most of the languages are terse and have code that is "pretty". Showing some quick things involving quick manipulation of tuples (basically a bunch of list processing) could show that things don't have to be complicated with a bunch of anonymous classes.

Anyways, I think the essential thing is to present a problem that they, as programmers, have already experienced. The big one being "well these two functions are *almost* the same but the inner-part of the function has different logic" (basically, looking at things like map). Open up the world of possibilities. It's not things that are only possible in Haskell/Scheme (after all, all of these languages are turing complete so..), but they're so much easier to write in these languages.

On Thu, Apr 16, 2015 at 7:41 AM Mike Meyer wrote:

...
On Wed, Apr 15, 2015 at 5:28 PM, Gautier DI FOLCO < gautier.difolco@gmail.com> wrote:

...
2015-04-15 19:15 GMT+00:00 Mike Meyer :

...
Well, functional programming is very much like an elephant.

I have the same thought about OOP some years ago, them I discovered then first meaning of it and all was so clear and simple. My goal isn't to teach the full power of FP, my goal is to give them inspiration, to suggest that there is a wider world to explore.

Just clarify, this is a reference to the fable of the blind men and the elephant. What you think it is like will depend on how you approach it. _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

3734

Age (days ago)

3736

Last active (days ago)

List overview

Download

9 comments

7 participants

participants (7)

Alexander Solla
Alexey Shmalko
Ernesto Rodriguez
Gautier DI FOLCO
Kyle Marek-Spartz
Mike Meyer
Raphael Gaschignard