<div dir="ltr"><div>First off, immutability, laziness, and such are not strictly elements of functional programming. For example, Lisp (one of the first practical functional programming languages) has both mutation and strictness.</div><div><br></div>I think probably the better approach is to start with the fundamentals. In MIT and Berkeley, we used to teach using a now classic book called SICP (Structure and Interpretation of Computer Programs). The first chapter covers the core concepts of functional programming, and I highly recommend it. Doing the exercises is necessary to really get a grasp.<div><br></div><div>The book uses Lisp, but the syntax is so lightweight that it shouldn't be an issue.</div><div><br></div><div><a href="http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-4.html">http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-4.html</a><br></div><div><br></div><div><br></div><div>The class taught at Berkeley and MIT is the first class that computer science majors take. Most of the students who took the course were already familiar with imperative programming, and while it can be a little mind bending at first, everyone eventually gets a grasp of it after the homework.</div><div><br></div><div>If you are looking for the lectures, you can find them on youtube (or otherwise) by these course numbers. It always the first thing taught in the class.</div><div><br></div><div>Berkeley: CS61A</div><div><a href="http://www.youtube.com/watch?v=zmYqShvVDh4">http://www.youtube.com/watch?v=zmYqShvVDh4</a> (and the following ones)<br></div><div><br></div><div>MIT: 6.001</div><div><a href="http://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-001-structure-and-interpretation-of-computer-programs-spring-2005/video-lectures/">http://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-001-structure-and-interpretation-of-computer-programs-spring-2005/video-lectures/</a><br></div><div><br></div><div>James</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Oct 16, 2014 at 7:59 PM, John Wiegley <span dir="ltr"><<a href="mailto:johnw@newartisans.com" target="_blank">johnw@newartisans.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">>>>>> Birmjin In <<a href="mailto:yinbirmjin@gmail.com">yinbirmjin@gmail.com</a>> writes:<br>
<br>
> It seems more difficult than it looks - thinking in functional programming<br>
> way for the long time C, C++ and Java developers.<br>
<br>
</span>C/C++ and Java all have a functional component: their expression language.<br>
Since this is the only way to writie constexpr functions in C++, for example,<br>
such functions must be FP in nature.<br>
<br>
I think the thing to get across is how a functional programs mutate values<br>
through a composition of smaller components: each function takes in an<br>
argument, and returns a result which is derived from that argument.<br>
<br>
This, of course, can be terribly inefficient in languages like C++, which do<br>
not have full support for taking advantage of things persistence, the way<br>
Haskell does.  This is usually where a biggest disconnect happens: the<br>
functional "way" feels wrong, because it's not how you would ever write<br>
efficient C++.  Teaching them to think that way requires viewing the<br>
"progression of data" in a completely different way.<br>
<br>
I remember it took me months to become comfortable with folds rather than for<br>
loops, exactly because of this distinction.  Folds in C++ are a bit of a pain,<br>
and can be wasteful; while mutative iteration in Haskell is likewise a pain.<br>
<br>
I don't this gap can be bridged simply by taking one camp and showing them<br>
another language, and thinking that the insights will occur by themselves.<br>
You also have to talk about data structures, and how the whole concept of data<br>
flow through a program fundamentally changes when you have the facilities of a<br>
functional programming environment at your disposal.<br>
<br>
So, with an FP environment comes methodologies that are tuned for FP, and<br>
these methodologies do not always have direct analogues.  What is good for one<br>
is not necessarily good for the other and vice versa.  If you asked a C++<br>
programmer how he'd compute Fibonacci using only the expression sub-language<br>
of C++, he could do it -- and he'd end up with a functional-style solution by<br>
doing so.  But it would feel like tying his hands behind his back -- a feeling<br>
anyway who has done any template meta-programming has felt, since that is also<br>
a functional subset of C++, where most of the idioms are missing.<br>
<br>
I think that once the data flow model can be understood, and its benefits (in<br>
the scenarios where it does have benefits), then presenting how functional<br>
languages take advantage of these can make a lot more sense.<br>
<br>
John<br>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
</blockquote></div><br></div>