Home > Archive > Scheme > December 2006 > Purely functional?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Purely functional?
|
|
|
| I attended the Haskell presentation at Oscon this year. Being "the only
purely functional language" is clearly very important to Haskellers, at
least that is what I came away with from the session.
While reading a fellows blog last night I read that he is focusing on
Haskell because his Scheme programs are more like Pascal programs with
functional features.
What is the big deal about writing programs that are purely functional?
Is that even possible in the sense of how we write calculus functions?
How can you write programs that involve events, threads, or anything
that requires
a specific order-of-execution if it is purely functional? (I know I
know, in Haskell use Monads)
| |
| Wolfram Fenske 2006-12-11, 7:18 pm |
| "Griff" <grettke@gmail.com> writes:
[...]
> What is the big deal about writing programs that are purely
> functional?
I thinks it's something like this: A lot of bugs in languages with
side-effects result from state changes (i. e. side-effects) not being
taken into account. This is (at least in part) why GOTO is considered
harmful, as are global variables, or manual memory management
("dangling pointers" etc.). So the logic is "no side-effects --> less
bugs". Two calls with the same arguments to a procedure in a language
with side-effects may not return the same results because some state
may have changed between those two calls. If this happens, it is
often not what you wanted. And if it is what you wanted, the
procedure tends to be hard to use because you have to keep its
dependencies in mind. OTOH in a purely functional language, when a
function is called with the same arguments as before you'll always get
the same result as before. Thus pure functions are easier to
understand and reason about--at least in theory. You might even be
able to prove in the mathematical sense that a program is correct.
That being said, I'm not a fan of purely functional languages. I
agree that side-effects should be avoided, but IMO removing them
altogether is wrong. Some algorithms just don't lend themselves very
well to a purely functional implementation.
--
Wolfram Fenske
A: Yes.[color=darkred]
>Q: Are you sure?
| |
| Mallor 2006-12-11, 7:18 pm |
| Griff wrote:
>
> What is the big deal about writing programs that are purely functional?
It is of academic interest. Nobody has demonstrated any major
industrial payoff from pursuing pure FP. Heck, it's hard to
demonstrate that even Lisp did anyone any good, and that's just a
"fancy language," not pure FP. Sure, Lisp may have helped a few
companies gain fame and fortune here and there, but these stories tend
to end with buyouts + all the Lisp code replaced, and they aren't being
widely repeated across the industry. I'm all for building better
mousetraps, and even taking risk to try some newfangled technology, in
the hopes of gaining a competitive advantage. But the reality is, most
people don't gain industrial advantages from any of this stuff. It is
completely fair to say, as compared to the legions of Java, C#, and C++
programmers being called for out there, that pure FP "is of academic
interest."
I don't know that in 20 years, anyone's going to prove that pure FP was
industrially important in any way at all. Whereas we can see in the
present day, automated memory management and garbage collection are big
industrial wins. Meanwhile, FP notions do influence current language
design, i.e. Java and C# take on more FP features as they evolve.
Study Haskell because you have an academic interest, or because a
specific job is paying you to use Haskell, or because you can get away
with using Haskell at your current job if you want to. Haskell, Clean,
and other pure FP languages have no industrial relevance in any big
picture sense.
Even Scheme has left me without any "buzzword compliant" resume skills,
frankly. I wish I had realized, 3 years ago, that when pursuing
advanced programming languages, I'd better keep an eye on whether there
are any $$$$$$$ attached to the language.
Cheers,
Brandon Van Every
| |
| Graham 2006-12-11, 7:18 pm |
| Mallor wrote:
> Even Scheme has left me without any "buzzword compliant" resume skills,
> frankly. I wish I had realized, 3 years ago, that when pursuing
> advanced programming languages, I'd better keep an eye on whether there
> are any $$$$$$$ attached to the language.
No, there's not a lot of cash in Scheme. But surely the chicks and fast
cars make up for it. ;-)
Graham
| |
| Mallor 2006-12-11, 7:18 pm |
|
Wolfram Fenske wrote:
> "Griff" <grettke@gmail.com> writes:
>
> [...]
>
>
> I thinks it's something like this: A lot of bugs in languages with
> side-effects result from state changes (i. e. side-effects) not being
> taken into account. This is (at least in part) why GOTO is considered
> harmful, as are global variables, or manual memory management
> ("dangling pointers" etc.). So the logic is "no side-effects --> less
> bugs".
When there is enough industrial software out there written in pure FP
languages such as Haskell, then we'll be in a position to pronounce
whether a lack of side effects really yields fewer bugs. It will still
be difficult to make apples-to-apples comparison between applications
and teams anyways. Who's using a better source control discipline?
Testing? Build tools? Attentiveness of the team members? What about
alternate programming paradigms like Extreme Programming? And last but
not least, those nasty variables called politics and funding?
Meanwhile, you should observe that it's difficult for a lot of people
to get Haskell compiled on their platforms. That should tell you
something about these kinds of industrial promises, i.e. they simply
ain't there.
I'm all for studying the consequences of different programming
paradigms. I don't confuse academic study with inflated claims about
industrial benefit.
> That being said, I'm not a fan of purely functional languages. I
> agree that side-effects should be avoided, but IMO removing them
> altogether is wrong. Some algorithms just don't lend themselves very
> well to a purely functional implementation.
Yes, and such contortions are a source of errors.
Cheers,
Brandon Van Every
| |
| Anton van Straaten 2006-12-11, 7:18 pm |
| Mallor wrote:
> When there is enough industrial software out there written in pure FP
> languages such as Haskell, then we'll be in a position to pronounce
> whether a lack of side effects really yields fewer bugs.
There's some evidence in the C/C++ vs. Erlang case, although Erlang's
relative purity isn't the only thing it has going for it.
Anton
| |
| Mallor 2006-12-11, 7:18 pm |
|
Graham wrote:
> Mallor wrote:
>
> No, there's not a lot of cash in Scheme. But surely the chicks and fast
> cars make up for it. ;-)
Care to give us a quick rundown on the do's and don'ts of Scheme job
hunting? It doesn't exist on the mainstream job boards, so I've been
trying to look elsewhere. I Google around for "Scheme job," or any of
my other buzzword non-compliant skills for that matter. Hoping to
stumble into some fishing hole that's actually compatible with what I
know how to do.
I have a fear / concern, that this is one of those job markets where
only people who know people make any money. And, the people who know
people, hoard their contacts. I certainly do this in signature
gathering. It's not a widely advertized job, and if I clued more
people in, then that's less signatures for me. There just ain't enough
to go around. So there's a handful of people who make lotsa money.
Everyone else strikes out, gets frustrated, and leaves the signature
gathering industry. That's better for the few top dogs who do stay.
Or, it could be one of these job markets where you already have to have
established yourself as some kind of uber-programmer using something
else. Then you had $$$$$$$$ capital, and you happened to succeed at
your newfangled Scheme venture, and so now you're self-sustaining. The
important point is that the startup conditions didn't come from Scheme.
People have to get rich on something else, then they can choose
Scheme.
I'm very cynical about what my last 3 years of investigating advanced
programming languages and open source has gotten me. I see no money in
either. I see only, free tools to build a business out of, if you
already have lotsa $$$$$$$ and a business model that can afford all
these "free" tools.
Cheers,
Brandon Van Every
| |
| Mallor 2006-12-11, 7:18 pm |
|
Anton van Straaten wrote:
> Mallor wrote:
>
> There's some evidence in the C/C++ vs. Erlang case, although Erlang's
> relative purity isn't the only thing it has going for it.
Erlang isn't pure FP, and the point is very narrowly about pure FP.
Also, as to Erlang's relative success, it was born (or raised?) in
industry and is targeted at the tangible needs of telcos.
Cheers,
Brandon Van Every
| |
| Mallor 2006-12-11, 7:18 pm |
|
Mallor wrote:
> Graham wrote:
>
> Care to give us a quick rundown on the do's and don'ts of Scheme job
> hunting?
Crap, I missed the word "not" in your reply. Thought you were telling
me there's gold in them thar hills.
Cheers,
Brandon Van Every
| |
| Ralf Mattes 2006-12-11, 7:18 pm |
| On Thu, 07 Dec 2006 12:43:54 -0800, Graham wrote:
> Mallor wrote:
>
> No, there's not a lot of cash in Scheme. But surely the chicks and fast
> cars make up for it. ;-)
Haj, you got that wrong! It's chick_en_ scheme, not chicks-scheme, and "T"
wasn't the fastest car Ford did build ....
Cheers, RalfD
> Graham
| |
| Wolfram Fenske 2006-12-11, 7:18 pm |
| "Mallor" <SeaFuncSpam@gmail.com> writes:
> Wolfram Fenske wrote:
>
> When there is enough industrial software out there written in pure FP
> languages such as Haskell, then we'll be in a position to pronounce
> whether a lack of side effects really yields fewer bugs.
I hope you realize I was only trying to explain what I think is the
typical argument for purely functional languages and against
side-effects. It's not my personal opinion. There is a report about
Erlang called [1] "Four-fold Increase in Productivity and Quality".
It says:
[...] it has been shown that programmer productivity in number of
error free lines of code per day is largely independent of the
programming language. [...]
*That* I am willing to believe. Lisp, with its first-class functions
and macros etc., should make you very productive then. Of course, in
real life, things like libraries etc. also matter, and other
alternatives may start to look much better. :-(
>
> Yes, and such contortions are a source of errors.
And contortions would lead to more lines of code and thus more bugs.
Footnotes:
[1] <http://www.erlang.se/publications/Ulf_Wiger.pdf>
--
Wolfram Fenske
A: Yes.[color=darkred]
>Q: Are you sure?
| |
| Anton van Straaten 2006-12-11, 7:18 pm |
| Mallor wrote:
> Anton van Straaten wrote:
>
>
>
> Erlang isn't pure FP, and the point is very narrowly about pure FP.
"ERLANG is a concurrent, dynamically typed, distributed, purely
functional programming language with non-purely functional libraries."[*]
The OP wrote:
> How can you write programs that involve events, threads, or anything
> that requires a specific order-of-execution if it is purely
> functional? (I know I know, in Haskell use Monads)
In a sense, Erlang is one answer to that question. Ultimately, to deal
with required effects in a pure system, you violate purity one way or
another. Haskell is no exception.
Anton
[*] Towards automatic verification of Erlang programs by π-calculus
translation, http://doi.acm.org/10.1145/1159789.1159798
| |
| Thant Tessman 2006-12-11, 7:18 pm |
| Brandon Van Every wrote:
[...]
> Even Scheme has left me without any "buzzword compliant" resume skills,
> frankly. I wish I had realized, 3 years ago, that when pursuing
> advanced programming languages, I'd better keep an eye on whether there
> are any $$$$$$$ attached to the language.
To the original poster: Potential employers are far more impressed with
honest descriptions of past accomplishments than they are with a laundry
list of programming languages and computer standards.
A working knowledge of functional programming techniques can make you a
better programmer in any language, and if you're lucky, you might even
occasionally have the opportunity to use a language like Haskell or
Scheme to do Real Work (TM), but you are a fool if you try to learn a
language solely so you can list it on your resume.
-thant
| |
| Joe Marshall 2006-12-11, 7:18 pm |
|
Graham wrote:
> Mallor wrote:
>
> No, there's not a lot of cash in Scheme. But surely the chicks and fast
> cars make up for it. ;-)
Don't forget the celebrities that want to hob-nob with Real Hackers!
I *love* this language!
| |
| Joe Marshall 2006-12-11, 7:18 pm |
|
Griff wrote:
>
> What is the big deal about writing programs that are purely functional?
Pure functional programs have a number of *really* useful properties.
First is referential transparency: you can substitute the value of a
function for the call to the function because the call always yields
the same value. This allows you to time-shift the computation: the
value never changes so you can evaluate the function any time you want.
If evaluation is expensive, simply evaluate the function at
compile-time and put the answer in the object code as an immediate
literal. Or delay the evalation even *after* it is called for in the
hope that the value isn't even used. A computation not done is
infinitely faster than one performed once.
Second, you can replicate the value at will. Cache a local copy across
several machines and speed up access to the value. Don't worry about
maintaining consistency because the value cannot change. Got a lot of
machines? Speculatively compute a function in the hopes that the value
will be used. With no side effects to worry about, you can simply
abort the computation at any point.
Third, you can share structure at will. If you know a library won't
muck around with your data structures, you don't need to copy the data
structures to protect them from modification. (Take a look at any
mid-size to large python program and look at all the copying that goes
on.) Use techniques such as `hash consing' to save significant time
and space during a computation.
But the most important thing of all: functional programs are *far*
easier to reason about and understand.
| |
| Ray Dillinger 2006-12-11, 7:18 pm |
| Anton van Straaten wrote:
> Mallor wrote:
>
> In a sense, Erlang is one answer to that question. Ultimately, to deal
> with required effects in a pure system, you violate purity one way or
> another. Haskell is no exception.
>
> Anton
I think that threading can be and properly should be abstracted
away from the programmer's primary attention. If the compiler
works out that sections of the program are pure-functional then
there is no problem with running those sections concurrently in
separate threads, along with a single thread of non-pure
functional work. If the compiler works out that several sections
of program each have no way of interfering with the other's state,
then there is no problem running those sections concurrently in
separate threads, along with as many pure-functional sections as
the compiler can find. But the compiler shouldn't be relying on
the programmer to be spotting and pointing out the parallizable
chunks of the code; a very smart compiler would be figuring that
out by itself.
One benefit of pure-functional programming is that it makes the
hazards of finding parallelizable code and avoiding thread
interference dead simple.
But as the OP pointed out, dealing with I/O and (other) items
with a required sequence is always annoying in pure FP languages;
I have always regarded monads as a bit of handwaving that
merely obfuscates I/O so that someone can *claim* it's pure
functional, while providing none of the real benefits of pure
functionality.
Anyway, I'm pretty firmly of the opinion that side effects are
at least sometimes necessary or beneficial. For example, a side
effect that (atomically) updates a memoization table when a
pure functional routine returns its result is utterly harmless
to your FP abstraction, and can yield huge benefits in terms
of making some programs run faster and in less memory.
Bear
| |
| JPWoodruff@gmail.com 2006-12-11, 7:18 pm |
|
Joe Marshall wrote:
> Griff wrote:
>
> Pure functional programs have a number of *really* useful properties.
<...>
> But the most important thing of all: functional programs are *far*
> easier to reason about and understand.
I'm stretching my recollections some decades to bring up data-flow
computers. This notion may be purely history now (or for all I know,
might be relevent) since I've been doing something else.
I wonder if this remark about FP and machine architecture is sound:
As I recall, dataflow computers executed a graph of operations. The
programs were functional. Execution proceded from function result to
the consumption of that operand. And the program executed with lots of
concurrency.
John
| |
| Mallor 2006-12-11, 7:18 pm |
|
Joe Marshall wrote:
> Griff wrote:
>
> Pure functional programs have a number of *really* useful properties.
> First is referential transparency: you can substitute the value of a
> function for the call to the function because the call always yields
> the same value. This allows you to time-shift the computation: the
> value never changes so you can evaluate the function any time you want.
> If evaluation is expensive, simply evaluate the function at
> compile-time and put the answer in the object code as an immediate
> literal.
Gee, but most things that are really expensive to evaluate depend upon
the state / environment that's being evaluated. Quite a runtime
technology if you're going to evaluate a function for a few hours, or
even a day, on the assumption that nothing shall change, then compile
it up for the next day's work. Although I suppose it's possible and
actually appropriate to some problem somewhere. Just not very
practical for most problems people tend to work on. Which gets back to
the theme of industrial relevance.
"If evaluation is somewhat expensive" might be a fairer billing of
utility. But now, you're placing a lot of faith in real world compiler
technology. I've seen no evidence that Haskell has anything to offer
in the performance dept. Maybe it's theoretically possible, but in
practice, it isn't industrialized, and it won't be for the next 20
years. Even C compilers aren't ever optimal, because the CPUs keep
changing out from under them.
Generally when someone tells you that FP is gonna buy you performance,
don't be quick to believe them. Look at whether the actual language
implementations and actual applications actually perform. A lot of it
is hand-waving theory about why certain tricks are going to be
beneficial. In practice, if those tricks complicate the
implementation, it doesn't get done in the real world.
Put another way, optimization is expensive and there isn't a magic
bullet for it.
> Or delay the evalation even *after* it is called for in the
> hope that the value isn't even used. A computation not done is
> infinitely faster than one performed once.
For some problems. You can shoot yourself in the foot with lazy
evaluation.
> Second, you can replicate the value at will. Cache a local copy across
> several machines and speed up access to the value. Don't worry about
> maintaining consistency because the value cannot change. Got a lot of
> machines? Speculatively compute a function in the hopes that the value
> will be used. With no side effects to worry about, you can simply
> abort the computation at any point.
Can you abort? Sounds like a denial of service attack.
Just throwing some cold water on how useful the pure FP is in practice.
If anyone wants to provide tangible demonstrations of performance
improvements that pure FP bought them, that's  .
> But the most important thing of all: functional programs are *far*
> easier to reason about and understand.
Sure, that's why the computer industry has so widely embraced the FP
paradigm. ;-) Only heavy duty CS g s find it easier to understand.
"Easier to reason about" is a fair cop, in the logician's sense.
That's why academia likes it so much; they're in the business of
reasoning about programs. The rest of industry is in the business of
writing and deploying programs, and FP, let alone pure FP, hasn't shown
any traction.
Cheers,
Brandon Van Every
| |
| Mallor 2006-12-11, 7:18 pm |
|
Thant Tessman wrote:
> Brandon Van Every wrote:
>
> [...]
>
>
> To the original poster: Potential employers are far more impressed with
> honest descriptions of past accomplishments than they are with a laundry
> list of programming languages and computer standards.
That's actually one of the traps of pursuing either CS esoterica or
certain corners of the open source universe. Like, the ones with too
many support burdens, where things are too broken and not enough people
are using them. If what you pursue is insufficiently tangible, you can
find yourself without any accomplishments to demonstrate. The industry
doesn't respect failure. It also doesn't understand certain
accomplishments, at least not well enough to offer you a job. There's
a sort of thankless, "Oh, that's nice" quality in how employers react
to certain things.
I think visual artists are better off in some ways, because they can
always say, "Here, look at my work." It's eye candy, it's accessible
at the touchy feely level, etc. Whereas when I say, "Here, look at my
Chicken CMake build," very few people see build engineering as an
important problem. And if they do, they want to see it in Ant or
something. I suppose I should be getting on with 3D graphics stuff so
that I have some eye candy advantages. You can get lost in 3D graphics
too: spend too much time on under-the-hood optimization stuff, and you
may not have anything to look at.
> A working knowledge of functional programming techniques can make you a
> better programmer in any language, and if you're lucky, you might even
> occasionally have the opportunity to use a language like Haskell or
> Scheme to do Real Work (TM), but you are a fool if you try to learn a
> language solely so you can list it on your resume.
Well I disagree. You're a fool to learn an avant garde / esoteric /
academic language. You wouldn't be a fool to learn Java, C#, or C++.
Nowadays, even Python might have resume cred.
Cheers,
Brandon Van Every
| |
| Thant Tessman 2006-12-11, 7:18 pm |
| Mallor wrote:
> Thant Tessman wrote:
[...]
>
> Well I disagree. You're a fool to learn an avant garde / esoteric /
> academic language. You wouldn't be a fool to learn Java, C#, or C++.
> Nowadays, even Python might have resume cred.
Good luck in your job search...
-thant
| |
| Bakul Shah 2006-12-11, 7:18 pm |
| Thant Tessman wrote:
> Brandon Van Every wrote:
>
> [...]
>
>
> To the original poster: Potential employers are far more impressed with
> honest descriptions of past accomplishments than they are with a laundry
> list of programming languages and computer standards.
>
> A working knowledge of functional programming techniques can make you a
> better programmer in any language, and if you're lucky, you might even
> occasionally have the opportunity to use a language like Haskell or
> Scheme to do Real Work (TM), but you are a fool if you try to learn a
> language solely so you can list it on your resume.
>
> -thant
I entirely agree with you. When I was hiring I gave more weight to
candidates who claimed experience with functional/esoteric languages in
addition to C/perl/python (even if the job entailed no use of functional
languages). What one wants are clear, quick, independent thinkers who
are open minded & *practical*. Such people tend to be naturally curious
about all sorts of things. And I did test them on their claimed
knowledge. Claiming something they didn't know counted against them
very heavily.
Some fraction of a programmer's time goes in writing/maintaining support
tools or one time use programs (e.g. a conversion script). These
provide opportunities to use your favorite languages!
Really good programmers can easily be 10 times as productive as an
average programmer and produce far superior code. So rather than worry
about buzzword compliance it is better to do *lots* of programming and
in languages where you can be most efficient. There are lots of open
source projects to hone your skills on! Also, it helps to work on
(sub)projects with well defined boundaries which are clearly your
responsibility.
| |
| Marcin 'Qrczak' Kowalczyk 2006-12-11, 7:18 pm |
| Ray Dillinger <bear@sonic.net> writes:
> I think that threading can be and properly should be abstracted
> away from the programmer's primary attention. If the compiler
> works out that sections of the program are pure-functional then
> there is no problem with running those sections concurrently in
> separate threads, along with a single thread of non-pure
> functional work.
Why isn't any compiler doing that then?
It's not as easy as it seems. There is an overhead associated with
scheduling the work into multiple threads, and with gathering their
results. It pays off only if the computation takes a significant time.
--
__("< Marcin Kowalczyk
\__/ qrczak@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
| |
| Ray Dillinger 2006-12-17, 7:07 pm |
| Marcin 'Qrczak' Kowalczyk wrote:
> Ray Dillinger <bear@sonic.net> writes:
>
>
>
>
> Why isn't any compiler doing that then?
It is because the art of crafting compilers has not yet advanced
so far.
> It's not as easy as it seems. There is an overhead associated with
> scheduling the work into multiple threads, and with gathering their
> results. It pays off only if the computation takes a significant time.
Indeed. Today's compilers spot relatively simple situations; I don't
know if it's really possible to go much further without some kind of
automatic adaptive mechanism that relies on profiler feedback. That
enables a "try this transformation: if it results in savings, keep it,
otherwise revert it" approach to optimization - but in turn that sort
of requires the compiler to continue optimization work - with all the
symbolic and meta-information still around - *while* the program is
running.
The compiler and environment for the language "Self" got up to such
things, and the papers are a fascinating read.
Bear
| |
| Rob Thorpe 2006-12-19, 7:13 pm |
| Ray Dillinger wrote:
> Marcin 'Qrczak' Kowalczyk wrote:
>
> It is because the art of crafting compilers has not yet advanced
> so far.
Also because the information to do it well is not forthcoming.
It actually depends on the program inputs. If a program is processing
arrays of size X in some part of the code it may benefit from
threading, but if it's processing smaller ones then producing the
threads will just consume time. Generally the benefit of threading is
dependant on the amount of data involved which isn't known at compile
time, though it can often be guessed.
>
> Indeed. Today's compilers spot relatively simple situations; I don't
> know if it's really possible to go much further without some kind of
> automatic adaptive mechanism that relies on profiler feedback. That
> enables a "try this transformation: if it results in savings, keep it,
> otherwise revert it" approach to optimization - but in turn that sort
> of requires the compiler to continue optimization work - with all the
> symbolic and meta-information still around - *while* the program is
> running.
>
> The compiler and environment for the language "Self" got up to such
> things, and the papers are a fascinating read.
The JITs inside JVMs do this. For some purposes it works quite well.
Other times the benchmarking code uses up so much runtime that it's not
worth it.
|
|
|
|
|