27 Jan
2012
27 Jan
'12
6:12 a.m.
On 27/01/12 12:05 AM, Ethan Dicks wrote:
...
"In Haskell, we de-emphasise code that modifies data. Instead, we
focus on functions that take immutable values as input and produce new
values as output. Given the same inputs, these functions always return
the same results. This is a core idea behind functional programming."
This, to me, sounds like the model of connecting processes with pipes
via a shell (a 40-year-old technique, FWIW). I already do that,
Yes, it is very similar. Remember that FP is much older than shell...
dozens of times a day. I don't need to do that at
the code-block
level inside the same process.
Why not? If you keep reading, you'll discover that the same principles
that make it concise and effective in shell work at most levels of code
- and have other payoffs besides clarity.
Check out some of the references that have been posted, and also Jecel's
nice synopsis of closures. You'll find there is a lot of worthwhile, if
not essential, material in any introductory FP text. (Speaking as a
programmer who's used a variety of conventional languages between
assembler and Java for 25-odd years.)
If you don't care for Haskell then pick up Lisp, Scheme, or an ML family
language (the ML texts are particularly excellent and clear).
(Erlang, as a benefit of its functional design, has won the crown for
high concurrency applications over just about any other platform, but
its syntax is a little more idiosyncratic, so not exactly ideal for a
starter.)
These languages all used in serious commercial applications, as are
their increasingly popular derivatives Scala and Clojure, for example.
--Toby
I enjoyed the emergence of OOP into the world of
FORTRAN and vanilla
C....