On Nov 22, 2005, at 5:42 PM, Kevin Toppenberg wrote:
Well, the syntax is a bit foreign to me as well.
Actually, it's not the syntax that I find difficult. It's at the
conceptual level that Haskell presents a greater challenge (to me,
anyway) than languages like MUMPS. The single concept I find most
frustrating is the monad. I can write code using monads, and I know
what the axioms for a monad are, but deep down, I know I don't quite
"get it". Monad provide a framework for dealing with interactions
(e.g., IO) without sacrificing referential integrity. You can't
legally write the Haskell equivalent of
READ X
SET Y=X
READ X
SET Y=Y-X
because, on the face of it, you should end up with Y=0, but with the
intervening READ it may not be. A nice feature of Haskell is that it
preserves equational reasoning like this, but that comes at the cost
of conceptual complexity. So-called "impure" languages (like Scheme
or ML) do allow reads with side effects, thereby sacrificing
referential transparency.
When I learned to
program, I worked with a guy that argued (and molded my opinion) that
code should be immediately readable by others if at all possible.
And I completely agree. But Haskell syntax often mirrors mathematical
notation. In fact, here's an interesting tidbit I just encountered
today: the quicksort example I gave you uses a notation referred to
as a list comprehension
[y | y <- xs, y > x]
That looks odd unless you think of <- as an ASCII approximation to
the mathematical symbol for "element of". Where did that name come
from? Well one of the axioms of set theory (known as the Zermelo-
Fraenkel axioms) is called the comprehension axiom, and it allows you
to write things lik
{ y | y <-XS and y > x }
So much for background: There's another functional language known as
Miranda that also supports list comprehensions, but there it's called
ZF notation!
So
we were as verbose as much as possible. So this would be "good" code:
"if IsPatientNew(Patient) then RegisterPatient(Patient)"
Yes, but this is imperative code. In functional languages, you don't
"do" things, you describe them. A line of a program is not a command
that "does" something, it's a definition of a relationship of some
sort. In the spreadsheet example, when you say that a cell should
contain the sum of the contents of the cells above it, you aren't
actually adding anything, you're declaring a relationship that must
hold between the cells in your spreadsheet.
and this would NOT be good code:
if ptNew(P) then reg(P)
I prefer the more verbose style, too.
Of course there are many ways to solve a problem. But that Haskell
code looks like greek to me. On the Haskell web site, there was a
humor section, and the joke showed about 20 ways to code problem...
many more complicated than they needed to be. But even the "easy" way
to do was a bit different than I was used to looking at.
No doubt!
But think about it for a moment: What does VistA actually "do"? We
have files containing all kinds of data and various rules describing
how the data all "fits together". In this sense, it seems to me that
VistA and functional programming make a good pair. An astounding
thing about functional programs is that they tend to much shorter
than their imperative counterparts, and they focus on what many
consider to be the important stuff. Code like
I +PID'>0 G ERROR
isn't terribly interesting, it's just an implementation detail. The
underlying design (or even algorithm) is often not even documented in
the code. You have to have to knowledge to be able to read the code
and (one hopes!) recognize what the programmer was trying to
accomplish. But going back to the sorting example, the code you saw
wasn't a low level implementation detail, it was a mathematical
expression of the underlying concept. To a large extent, that's what
appeals to me about functional programming.
===
Gregory Woodhouse
[EMAIL PROTECTED]
"One must act on what has not yet happened."
--Lao Tzu
-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc. Get Certified Today
Register for a JBoss Training Course. Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
_______________________________________________
Hardhats-members mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/hardhats-members
