Re: Functional Programming in the Larger or Functional Oriented Software Engineering

> The object school has developed a huge volume of literature to address the
> engineering issues involved with "Programming in the Large." It has given
> us not just languages, but processes, modeling languages, etc.
>
> It would seem that the functional school has been relatively mute on this
> topic.


    I think this is more a function (no pun intended) of scale, of the
popularity of "procedural OOP" and unpopularity of functional
programming in industry, and not reflective of the basic merits of FP.

    And to answer the follow-up question of why OOP was chosen over FP, I
think that traces to the historical reasons of the original popularity
of procedural languages in industry, and the fact that OOP was the
next big extension added to the procedural languages base, and not FP,
probably due to several reasons including the perception that FP was
more resource-intensive, and back in the 80's when this was happening
that was still a big issue (it hasn't gone away yet but it has
diminished, while programmer time has gotten relatively expensive
compared to machine resources).

    One could argue that what you are seeing now is exactly the extension
of procedural + OOP by adding functional programming, in bits and
pieces.  C#, Python, Perl, JavaScript, Ruby et al look more or less
like C syntactically, but are getting closer and closer to being LISP
in feature set.  Just give them a couple more decades to catch up. :-)

    I think in an industry dominated by FP languages you would see a
comparable body of literature and processes.

    Also to look at it from another angle, how necessary are all the "add
ons" that have been piled on top of Java & C++ the languages?  Clearly
they were invented to address perceived shortcomings in the substrate
development environments, to bridge the gap between merely writing
code and shipping quality code on time.  But, if FP has the advantages
many on this list believe they do, would FP code ship faster and with
fewer bugs, and with easier maintenance and less painful refactoring? 
If so, in that "FP world", would we need all the gurus and rigamarole
that has sprouted up around the industrial development process?

    For example, some have argued that the idea of patterns is inherently
misguided, and less or not necessary when programming in a better
language than the target audience for patterns does.

    A related point is, how much of this stuff works as advertised?  Has
anyone empirically measured the advantages of using UML to develop C++
apps versus, say, not using UML but developing in Common LISP?  How
much of this is overhyped and / or a fad?

    Remember when Object Oriented Programming was going to enable massive
industry-wide re-use of code (remember "componentware"?), radically
shorten development cycles, greatly reduce bugs, and whiten your teeth
while you sleep?  Where's my "OOP dividend"?

    Some of these promises are arguably in the process of coming true
today, but remember when they were originally made.  And perhaps it is
not a coincidence that, over the same span of time, the languages of
choice have been migrating towards FP capabilities.  Coincidence?  Or
was it always necessary to unlock the true potential of OOP?  Is OOP
even in danger of taking the credit for software advances that
properly belong to FP?