
In programming style, as in most things, moderation - bgray
http://www.cs.uni.edu/~wallingf/blog/archives/monthly/2010-01.html#e2010-01-05T15_25_06.htm
======
baguasquirrel
It's pretty difficult to have an intelligent conversation about programming
languages. Thus it's likewise difficult to advance the state of our art.

You try talking to most FPers about this stuff, and they get angry because
you're telling them that Haskell is not the most optimal language for building
a GUI. Go look at XMonad, they say. I'm sorry, but one damn example doesn't
quite cut it.

You try talking to mainstream folks, and they always default back to the
"where are the big, successful functional programs?" For christ's sake, when
did the size of your codebase become something to be proud about? Did you
become a goddamn excel-spreadsheet manager or something? The fact that all
current systems are done in OO/imperative is not a good thing because quite
frankly, most code SUCKS. And you know it.

For myself, personally, I've found the purity and laziness of Haskell too
useful to dispense with. It's just _that_ much better than other languages
like OCaml because of the lazy bit. So what do I advocate? Leave the UI code
to the imperative/OO languages, and do the backend in Haskell. This wins no
fans in either camp.

But the pure FP camp is the one that has something to prove, so we're the ones
at a loss here.

I think we should try to build _part_ of a good, stable system in something
our language is good at. In the real world, 80% is usually good enough, so
lets get the 80% we're really darn good at (yes, I think _pure_ FP is good at
80% of any task in any stack). Things that exploit parallelism and/or
correctness seem ripe for the picking. Things like databases, or any sort of
data processing.

Look at what the Erlang guys are doing with CouchDB. Even a full blown web
backend seems like fair game. The problems I've had doing one have not been
technical or related to Haskell. They're psychological (i.e. student
syndrome). Someone with more experience than me ought to just go and do a
better job.

------
dasil003
An interesting read, but I found this a bit bizarre:

 _No one seems to place a purity test on stateful programming: "Try writing
that without any functions!"._

It seems like the author is somehow placing imperative and functional
languages on opposite ends of the spectrum, but in reality imperative
programming is just a direct model of programming physical machines and
functional programming is a constraint layered on top of that to impose a much
more reasonable order.

State is an unavoidable consequence of machines operating in time and space.
Functional programming just lets you pretend the physical computation doesn't
exist to various degrees, but under the hood it's all imperative.

~~~
baguasquirrel
Imperative programming arises from the fact that modern architectures are
based on the Von Neumann model. FP programming arises from a lambda calculus
model, so I feel that his argument is accurate. Note that this is not placing
things on a spectrum, per se. One day we may not be using Von Neumann
architectures for everything, anymore, and then his analogy will become more
apparent.

~~~
dasil003
Pardon my shortsightedness, but how can a physical architecture be devised
that doesn't ultimately compute via a sequence of state modification (ie.
imperatively)? Von Neumann seems neither here nor there. Lambda calculus is a
mathematical model, it exists only as a concept, it can not physically be
excecuted in spacetime without an imperative implementation. Am I missing
something here?

~~~
baguasquirrel
There are people working on architectures that are mind-bogglingly different.
Google for Fleet.

------
mbrubeck
After linking to James Hague's article "Functional Programming Doesn't Work",
Wallingford argues that a practical compromise is to write programs that
contain about 90% pure and 10% stateful code. Interestingly, Hague came to the
same conclusion in a followup to his own article:

 _"My real position is this: 100% pure functional programing doesn't work.
Even 98% pure functional programming doesn't work. But if the slider between
functional purity and 1980s BASIC-style imperative messiness is kicked down a
few notches--say to 85%--then it really does work."_
<http://prog21.dadgum.com/55.html>

