

Teaching FP to freshmen - JSig
http://existentialtype.wordpress.com/2011/03/15/teaching-fp-to-freshmen

======
Darmani
"Object-oriented programming [...] is both anti-modular and anti-parallel by
its very nature"

I'm sure this is going to get a lot of discussion, so I'd like to preemptively
elaborate on the anti-modular part.

Object inheritance is the moral equivalent of copy & paste.

Suppose you have a class, and you wish to reason about its behavior. You will
have to do so knowing that the function definitions therein will be ripped out
and replaced with different things. Thinking about the behavior of this will
essentially require people writing subclassses to look at the code for the
superclass, and vice versa. You've saved the clicking of copy & paste, but not
the need to share the code.

There is an exception where inheritance can be well-behaved, and that's where
there are a few methods intended to be overridden, with the rest of the class
providing meaningful behavior in terms of those few operations. A good example
is java.util.AbstractCollection, which provides all sorts of useful operations
in terms of the iterator() and size() functions. However, in this case you
might as well use an ML module, which makes this relation explicit.

~~~
stiff
Good OO design makes this relation very explicit in OO languages as well and
they are means in the language to achieve it - using interfaces,
public/private/protected, annotations like @Override in Java etc. Also, most
object oriented APIs provide different means for extending them than
subclassing of concrete base classes - that's what interfaces are mostly used
for.

The argument in the blog post is pretty much worthless as they are not backing
it up in any way or explain what they mean with very vague adjectives like
"anti-modular". I have been programming functionally in my spare time for the
last few years and there is certainly plenty to love about it, but the lack of
a clear set of principles and language tools for decomposing systems into
manageable modules I would actually view as one of it's main problems at the
moment.

Decades of writing large-scale OO software, produced a large set of such
principles, which applied thoughtfully produce software that really is
modular, in the sense that you can keep track in your head of a large program.
Things like law of Demeter, substitution principle, open-closed principle and
so on and so forth. This imposes a lot more structure upon the code and simply
makes it easier to remember things then just using functions grouped into
modules/namespaces like it often ends up looking in FP.

Now, I'm not saying that there are some inherent problems with modularity in
FP - I don't know the full spectrum of functional languages and how they
approach this problem of grouping large amounts of code into meaningful
pieces. But it doesn't seem that there is some form of a united and well-known
approach to this in the functional world, so such claims of "anti-modularity"
should be well-backed by arguments and examples of how does FP _help_
modularity. There are surely plenty of people wondering about how to write
modular applications in functional languages - just look at the popularity of
threads like this: [http://stackoverflow.com/questions/3077866/large-scale-
desig...](http://stackoverflow.com/questions/3077866/large-scale-design-in-
haskell)

Because of the above, I'm really looking forward to the development of
languages like Scala, which try to blend the benefits of functional
programming like parallelisation friendliness, with the main benefit of object
orientation - clear rules for program decomposition. Also, some of the issues
are probably orthogonal to what kind of language is used (in certain bounds at
least), for example look at this decades old paper:

[http://www.cs.umd.edu/class/spring2003/cmsc838p/Design/crite...](http://www.cs.umd.edu/class/spring2003/cmsc838p/Design/criteria.pdf)

------
goalieca
The real danger of OOP is that people mangle it and use far too much state. At
some point there is virtually no difference between a class with many
variables and global variables yet this is exactly what we teach freshmen.

~~~
sesqu
Is that a bad thing? Global variables keep cropping up in programming
languages, so large objects (context-globals; namespaces) might be just the
right compromise between encapsulation and coherence.

------
andjones
I think this a wonderful approach and I was taught at Indiana University.

Recursion helped me learn how to break problems apart. Working with lists and
the list primitives all the time gave me a leg up in data structures.
Anonymous functions taught me about abstraction. Macros taught me to write
programs for clarity and let the machine do the rewrite work. Many of the
analytical skills I learned from FP I carry over to programming in other
languages and problems solving in general.

The biggest complaint heard was "I don't see how this applies in the real
world". This is fair, the number of job listings out there that mention Lisp,
Scheme, or Haskell are far outweighted by other languages (i.e. java, C, C#,
PHP, etc).

I always responded that learning FP teaches you how to think about
programming. One of those "give a man a fish / teach a man to fish". That
response generally drew blank stares, but it's something I believe is true.

------
depoisfalamos
In the university where I attend, Universidade do Minho (Portugal), functional
programming it's the first programming class freshmen are given, computer
science and informatics engineering students alike. It is a very effective way
to teach programming, structures and a lot of math theory behind it. It also
helps students who didn't come from "professional schools" where they teach C
or Java to be in the same level as those who did. The language they teach here
is Haskell. We have 3 classes during our course where we work with Haskell. It
may seem a very academic language, geared to research, but the real world
usage has grown very much in the recent years. Not only Haskell but earlang
and lisp as well. So I think it's a great way to introduce the concepts to
first year students and "first comers" to 'our' (dark :p) side.

------
woan
I think its a good move but it isn't new. I think UC Berkeley moved the first
CS class for CS/EECS majors to functional concepts and Scheme in 1989 and MIT
even earlier, though the latter abandoned it later.

I remember my Berkeley compiler class implementing Scheme and APL subsets atop
the gcc backend as well which was again a doubly good learning experience in
learning other approaches to programming and their implications.

I have yet to see OO design taught well outside it's varying programming
constructs well. What is the right level of abstraction for "finding objects"
in the words of Bertand Meyer?

~~~
jallmann
> I think its a good move but it isn't new. I think UC Berkeley moved the
> first CS class for CS/EECS majors to functional concepts and Scheme in 1989
> and MIT even earlier, though the latter abandoned it later.

Yeah, but those aren't really the same reasons CMU is switching over. Scheme
was historically taught because it offers the opportunity to teach computer
science, as opposed to merely teaching programming. Most freshman "CS" courses
are oriented around the latter.

The shift into Java/Python/$OOP_LANGUAGE was precipitated by the demands of
the real world (eg, the job market). CMU is leading the pack in that respect
-- it just so happens that FP is a better fit for the type of work their
students will need to do, given the growth of multicore and distributed
systems.

OOP has its place, but it is far from a panacea. I'm glad to see at least one
school isn't hammering that into freshmen anymore.

~~~
woan
It's amazing how many of these so called CS topics that fell out of favor in
the 90s have come back in the web world in major ways.

Consistency, concurrency, parallelism, persistence. Yup we're back to basic
distributed systems over larger networks.

The vast majority of developers don't need to know all of those things of
course, i.e. forms enterprise or some level of RoR applications, but it is
kind of interesting to see the resurgence in systems level skills needed in
the industry. At one point OS and high transaction developers were down to a
negligible percentage of practicing developers and we thought everyone would
move to certification type education and high level abstractions.

