from hell to paradise ; ; ; was: [plt-scheme] Prereqs for robotic programming

On Tue, Feb 17, 2009 at 3:25 PM, Marco Morazan <morazanm at gmail.com> wrote:

I am always shocked to hear stuff like this. Functional programming
> exacts a small intellectual price for a great deal of power that
> *most* when they discover it feel relieved and a sense of
> satisfaction. Yet the myth -- and let's be frank it is a myth -- that
> functional programming is hard persists.
>

Well - at the risk of appearing to be down on FP, I'll share my thoughts.
Let me first say that I've had a great ride so far learning FP and
developing in PLT, but it's certainly not without bumps and bruises.

Note - I am talking about the implementations of FP, not the concept of FP.

My view is completely from a practitioner perspective - my exposure to FP in
school is absolutely minimal - I had challenges matching parentheses back
then.


> Seriously, what is painful about it? Is it painful not to have a
> mangled syntax? Is it painful to encourage the use of recursion?
> Really, c'mon! Is it painful for functions to be first-class? Is it
> painful not to encourage the use of sequencing and
> mutation/assignment? Is it painful not to have "for" and "while" as
> keywords? Is it painful not to think of state all the time? Is it
> painful not to have to manipulate pointers? Is it painful for the
> language to properly implement tail calls? Is referential transparency
> painful -- most of my students are shocked when I point out to them
> that in, say, Java (pick any language that encurages assignment) that
> f(x) == f(x) is not always true, which suggest huge gaps in their
> education when they learned Java --? Is having macros or continuations
> painful?
>

The merits of FP are certainly there, but I don't believe they are well
articulated or positioned.

In general the message appears to be - you can write better, simpler, and
shorter program in FP, without having to pull your hairs out trying to find
the weird bugs.

These are good value propositions, but for mass practitioners they are
dubious at best.

The reason is because there are serious competitors.

FPs are no longer competing against C/C++ or even Java.  They are competing
against the newer wave of languages all vying for developers' attentions.

Perl, Python, PHP, Ruby also offer ways to write better, simpler and shorter
programs.  And they demand far lower learning curves.  Erann Gat
previously shared
his thought<http://groups.google.com/group/comp.lang.lisp/msg/6f75cfb5a289d3f6>and
alluded to Python being a serious competitor to his favorite, lisp.

These languages further lower the barrier to entry by providing massive
plumbings.   The amount of tutorials, books, references on them are
staggering.  Whether you consider them rubbish or not, their existences
simplified the adoption problem.

Besides being "battery included", the amount of 3rd party modules written in
these languages makes most developer's job fairly simple.  Most developers
simply have to find modules to plug and play.

The fastest way to develop is not having to develop.  No matter how fast you
can code in FP, you can't beat reusable code.  And no matter how well the FP
code are written, they also go through product lifecycle of maintenance.
Hence maintenance (and having a vibrant community to do maintenance) is
critical.

The most important thing for a practitioner is to be *productive*.  Contrast
the above with the state of FP language/platforms today.  Introduction
materials are hard(er) to find, and even when you find them, it might or
might not work with a given implementation.

And when you go through the hurdle to be proficient, you still have to
develop most code yourself, as there simply isn't a big enough community to
spread the burden and the maintenance.

That *is* pain.

The truth is, professional developers will put up with a lot of pain.  Just
look at their day jobs.  They are stuck using C, Java, Cobol or whatever at
work at most places in a dusty cubicle with little lights, working 60-80
hours a week, just so they can put some food on the table.  Why wouldn't
they want to simplify their lives?

But change is scary.  Peopleware talks about people hate change, period.
People more readily adapt change when there are prior examples of success.
Or when they really have to solve a problem that existing solutions just
don't cut it.  What they generally don't do is to jump through hoops for
qualitative and possibly dubious value propositions such as better or
simpler.

That's why I believe plumbings are the most important task for a FP to catch
on.  It's even better if there are such a well defined niche for the
language to solve a problem, so it can take the time to build up the
plumbings.  Even Perl's formiddable CPAN is built over time while Perl
prospers from solving text processing and web CGI niches.

Erlang now also appears to catch on as it solves massive concurrency
problems that's appearing to become important.  I am a lurker on erlang's
list and can attest to the increase of interest there.  If Erlang does "get
over the hump" it will cause more adoption for FP in general than other FP
languages.

I am not being cynical here. I know that many pick up bad habits that
> become part of muscle memory and then may feel lost at sea using a
> different programming language. Is that a short coming of functional
> programming? Would any of those lost at sea feel more comfortable
> coding in Prolog? Would a Cobol programmer feel more comfortable
> programming in Java? Perhaps, it is a shortcoming of our education and
> not of functional programming.
>

Education is certainly key, but education alone isn't going to influence the
industry, until the above issues are addressed.  And given most will stay in
industry longer than in school I would say it's more important to build up
the plumbings.  Wouldn't you want to hear your student say "why don't you
teach me scheme, I want to work at Google (or another hip company) and they
standardize on it"?  Surely that'll make your life as a professor easier
too.

My 2 cents and ramblings.  Cheers,
yc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20090217/d7f02872/attachment.html>