Re: Lisp Ruby Scheme
- From: dvandeun@xxxxxxxxxxxxxxxxxxxxx (Dirk van Deun)
- Date: 31 Mar 2009 14:44:40 GMT
Pascal Costanza (pc@xxxxxxxxx) wrote:
: That's one side of the coin. The other side is that Lisp and Scheme
: allow you to explore new programming styles for which there are no
: dedicated languages available yet. Sticking to a strict "invented"
: programming style is then a matter of self-discipline, but at least you
: have the freedom to do so, whereas in other languages that try to impose
: their view of the world on you, you then constantly have to "fight"
: against the language.
You have a good point when you say that Lisps allow you to experiment
with styles for which there is no dedicated language yet.
But then I ask the question: do you reap the full rewards of a
programming paradigm if you use it as a discipline in a language that
was not designed especially to support it ?
Elena remarked earlier in this thread that you can also program in a
purely functional style in Scheme by just not doing destructive
operations. I will throw in another property of an important family
of functional programming languages: you can use
laziness/non-strictness perfectly in Scheme using delay and force.
But if you are doing so, are you reaping all the benefits ?
Now for a small example. Say we have a list of numbers, we want to do
operation foo on all of them, then operation bar, and then sum them.
The naive implementation is (sum (map bar (map foo our-list))). This
is not efficient, because we are building lists and throwing them
away again. So if we want to make this more efficient, we have to
rewrite, and combine the three operations foo, bar and +.
In Haskell however, where lists are lazily constructed by default, and
the compiler has the guarantee that no side-effects will happen
during sum, foo or bar, there is no reason for the compiler to actually
construct intermediate lists. It can produce efficient code from the
naive algorithm, code that never actually constructs a list, without
any risk of changing the semantics of the expression. (Because of the
non-strictness, the cells of the lists are even in the dumbest
interpreter only being constructed as they are being consumed and then
immediately thrown away: so why would a smart compiler make them ?)
No amount of discipline in not using destructive operations, no delays
or forces can effect this. Maybe a very very smart compiler could
analyze the code and do the same as the Haskell compiler, but for Scheme
this would be a masterpiece of optimization, whereas for Haskell this
is a trivial optimization, just a starting point.
I chose this example mainly because it is pretty cool and can be
explained in two paragraphs, not because it would be the main advantage
of using Haskell; but the point is that language designers are
probably not stupid, and that they will only restrict expressiveness of
their new languages where there is some kind of pay-off. Whether or
not you are interested in a specific pay-off is of course a completely
different matter; but programming in Scheme with lots of delay and force
and no destructive operations, does not pay off as much as it should.
And I am willing to bet that if you have never programmed in Haskell or
been immersed in "Haskell culture" by reading Haskell papers, you
did not even realize that.
Languages come with a culture, and learning about new cultures at the
very least broadens your mind.
Dirk van Deun
--
Ceterum censeo Redmond delendum
.
- Follow-Ups:
- Re: Lisp Ruby Scheme
- From: Grant Rettke
- Re: Lisp Ruby Scheme
- From: Didier Verna
- Re: Lisp Ruby Scheme
- From: Elena
- Re: Lisp Ruby Scheme
- References:
- Lisp Ruby Scheme
- From: kunjaan
- Re: Lisp Ruby Scheme
- From: kun
- Re: Lisp Ruby Scheme
- From: Elena
- Re: Lisp Ruby Scheme
- From: kun
- Re: Lisp Ruby Scheme
- From: Elena
- Re: Lisp Ruby Scheme
- From: Dirk van Deun
- Re: Lisp Ruby Scheme
- From: Ray Dillinger
- Re: Lisp Ruby Scheme
- From: Dirk van Deun
- Re: Lisp Ruby Scheme
- From: Pascal Costanza
- Lisp Ruby Scheme
- Prev by Date: Re: Lisp Ruby Scheme
- Next by Date: Re: Lisp Ruby Scheme
- Previous by thread: Re: Lisp Ruby Scheme
- Next by thread: Re: Lisp Ruby Scheme
- Index(es):
Relevant Pages
|