From: are
Subject: Lisp and OCaml
Date: 
Message-ID: <1190243904.681273.37890@w3g2000hsg.googlegroups.com>
Getting back to doing some programming after a long absence, I've been
reviewing the available languages to see which would be most suitable
for some numerically intensive simulation work.  Wanting something
that's fast and high-level, I've zeroed in on Lisp and OCaml.
Superficially, these two seem very different from one another, yet
I've noticed that there a some who post to both of these groups.
Would anyone who knows both languages well (let's not start a flame
war, please!) care to comment on the similarities and differences
between them?

From: Raffael Cavallaro
Subject: Flamebait if I ever saw it
Date: 
Message-ID: <2007091919520175249-raffaelcavallaro@pasdespamsilvousplaitmaccom>
On 2007-09-19 19:18:24 -0400, are <·········@gmx.net> said:

> Wanting something
> that's fast and high-level, I've zeroed in on Lisp and OCaml.
> Superficially, these two seem very different from one another, yet
> I've noticed that there a some who post to both of these groups.
> Would anyone who knows both languages well (let's not start a flame
> war, please!) care to comment on the similarities and differences
> between them?

Wanting something that's fast and high-level,
I've zeroed in on Lisp and Scheme.
Superficially, these two seem very different
from one another, yet I've noticed
that there are some who post to both of these groups.
Would anyone who knows both languages well (let's not start a
flame war, please!) care to comment on the similarities
and differences between them? ;^)

------------------------------------------

Anyone else here on c.l.l think that 'are' should choose
OCaml, decamp to c.l.functional, and take frog-boy with him?
From: are
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <1190300317.609336.42070@k79g2000hse.googlegroups.com>
On Sep 19, 6:52 pm, Raffael Cavallaro <················@pas-d'espam-
s'il-vous-plait-mac.com> wrote:
> On 2007-09-19 19:18:24 -0400, are <·········@gmx.net> said:
>
> > Wanting something
> > that's fast and high-level, I've zeroed in on Lisp and OCaml.
> > Superficially, these two seem very different from one another, yet
> > I've noticed that there a some who post to both of these groups.
> > Would anyone who knows both languages well (let's not start a flame
> > war, please!) care to comment on the similarities and differences
> > between them?
>
> Wanting something that's fast and high-level,
> I've zeroed in on Lisp and Scheme.
> Superficially, these two seem very different
> from one another, yet I've noticed
> that there are some who post to both of these groups.
> Would anyone who knows both languages well (let's not start a
> flame war, please!) care to comment on the similarities
> and differences between them? ;^)
>
> ------------------------------------------
>
> Anyone else here on c.l.l think that 'are' should choose
> OCaml, decamp to c.l.functional, and take frog-boy with him?

Yeah, well, I admit it was optimistic of me to hope that a flame war
might be avoided regardless of how genuine my interest in the question
posed was.
From: Don Geddis
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <87odfxuuhk.fsf@geddis.org>
are <·········@gmx.net> wrote on Thu, 20 Sep 2007:
>> On 2007-09-19 19:18:24 -0400, are <·········@gmx.net> said:
>> > Wanting something that's fast and high-level, I've zeroed in on Lisp and
>> > OCaml.
>
> Yeah, well, I admit it was optimistic of me to hope that a flame war might
> be avoided regardless of how genuine my interest in the question posed was.

Yet you posed a question that was tailor-made as flame bait.  You write as
though you have a legitimate question, and are hoping that people avoid the
temptation to indulge in a flame war.

Yet the topic itself is well-known to cause flamewars in the past.  Moreover,
it's highly unlikely that your original question is legitimate.

Why?  Because Lisp and OCaml are sufficiently different languages, that it's
almost inconceivable that you might have narrowed down your choice to just
those two.  They appeal to very different kinds of programmers, are best
suited for very different programming styles, etc.

That's why it seems far more likely that you deliberated instigated yet
another flamewar, rather than that you had a legitimate question which was
being unfairly sidetracked.  Because, if you care about OCaml, then surely
you ought to also consider nearby languages like Haskell, ML, F#, etc.
Meanwhile, if you care about (Common?) Lisp, then you might be considering
Scheme, etc.

But to have eliminated every other potential language, and be left only with
either OCaml or (Common) Lisp?  Seems unlikely to be a legitimate question.
While it's highly likely to be deliberate flamebait.

        -- Don
_______________________________________________________________________________
Don Geddis                  http://don.geddis.org/               ···@geddis.org
Sometimes I wonder if I'm patriotic enough.  Yes, I want to kill people, but on
both sides.  -- Deep Thoughts, by Jack Handey
From: are
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <1191097676.810373.273450@k79g2000hse.googlegroups.com>
On 20 Sep, 18:17, Don Geddis <····@geddis.org> wrote:
> it's highly unlikely that your original question is legitimate.
>
> Why?  Because Lisp and OCaml are sufficiently different languages, that it's
> almost inconceivable that you might have narrowed down your choice to just
> those two.

I maintain that my original question springs from a legitimate desire
to know the answer.  Have a look at the Computer Language Shootout.
Among the dozen or so languages with shorter execution times for the
benchmarks therein, you'll find C, C++, D, Oberon, Eiffel, Clean,
Lisp, Dylan, Pascal, Fortran, Ada and OCaml and a few others that I've
just never heard of.  Criteria I applied in winnowing the list
included my own past experience (Fortran, C, C++ and Pascal), OS-
independence, and maturity and breadth of support.  (I was just about
to go into my view on each until it occurred to me that doing so would
certainly ignite more flames!)  I freely admit to having done less
than exhaustive research on each possibility, for the simple reason
that I my objective is *not* to become an expert on programming
languages.  Nonetheless, my focus on Lisp and OCaml arose
methodically.

> They appeal to very different kinds of programmers, are best
> suited for very different programming styles, etc.

With your no doubt superior knowledge, this statement may be obvious
to you.  While it was obvious to me that the languages have very
different syntaxes, it was by no means obvious to me that they might
not be similar in other ways be similar or that they might not both be
suited to my needs.  That's why I asked the question in the first
place.

> That's why it seems far more likely that you deliberated instigated yet
> another flamewar, rather than that you had a legitimate question which was
> being unfairly sidetracked.
>
> Because, if you care about OCaml, then surely
> you ought to also consider nearby languages like Haskell, ML, F#, etc.

Lacking your broad knowledge of computer languages, I simply did not
know that, for example, F# and OCaml are closely related.  Helpful
private correspondence generated by my OP has educated me about
Haskell.

> Meanwhile, if you care about (Common?) Lisp, then you might be considering
> Scheme, etc.

Yes, as discussed elsewhere in this thread I have considered Scheme
and eliminated it after spending (and enjoying) some time getting to
know it.

> But to have eliminated every other potential language, and be left only with
> either OCaml or (Common) Lisp?  Seems unlikely to be a legitimate question.
>
> While it's highly likely to be deliberate flamebait.

As pointed out above, I considered a number of other possibilities in
varying depths.
From: Jon Harrop
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <13ftqs9ecd6f2f4@corp.supernews.com>
are wrote:
> On 20 Sep, 18:17, Don Geddis <····@geddis.org> wrote:
>> They appeal to very different kinds of programmers, are best
>> suited for very different programming styles, etc.
> 
> With your no doubt superior knowledge,

I suggest asking people who know both OCaml and Lisp to compare and contrast
these two languages. Almost all such people are on the OCaml mailing list
and not here.

> this statement may be obvious 
> to you.  While it was obvious to me that the languages have very
> different syntaxes, it was by no means obvious to me that they might
> not be similar in other ways be similar or that they might not both be
> suited to my needs.  That's why I asked the question in the first
> place.

You were quite correct in your assumption. Lisp and OCaml have a great deal
in common.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
From: Klaus Schilling
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <87ps008xqc.fsf@web.de>
Jon Harrop <···@ffconsultancy.com> writes:
>
> I suggest asking people who know both OCaml and Lisp to compare and contrast
> these two languages. Almost all such people are on the OCaml mailing list
> and not here.

it suffices to know that Ocaml lacks dynamic typing, interchangeability of
code and data, and EVAL, thus is vastly inferior to lisp in any sense.

Klaus Schilling
From: Jon Harrop
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <13g01ton59fpmaa@corp.supernews.com>
Klaus Schilling wrote:
> Jon Harrop <···@ffconsultancy.com> writes:
>>
>> I suggest asking people who know both OCaml and Lisp to compare and
>> contrast these two languages. Almost all such people are on the OCaml
>> mailing list and not here.
> 
> it suffices to know that Ocaml lacks dynamic typing, interchangeability of
> code and data, and EVAL, thus is vastly inferior to lisp in any sense.

If you assume that being able to compile incorrect code, having rudimentary
syntax and a feature whose use is discouraged are all good features, yes.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
From: Klaus Schilling
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <87ejgf971c.fsf@web.de>
Jon Harrop <···@ffconsultancy.com> writes:
>
> If you assume that being able to compile incorrect code, having rudimentary
> syntax and a feature whose use is discouraged are all good features, yes.

of course these are all good features


Klaus Schilling
From: Jon Harrop
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <13g0f01esfk2ed5@corp.supernews.com>
Klaus Schilling wrote:
> Jon Harrop <···@ffconsultancy.com> writes:
>> If you assume that being able to compile incorrect code, having
>> rudimentary syntax and a feature whose use is discouraged are all good
>> features, yes.
> 
> of course these are all good features

Therein lies the debate. Static typing is also a good feature. Manipulating
code as data is clearly not a problem for ML, which was bred specifically
for that task. Finally, EVAL is of limited utility and its use is
discouraged even in Lisp.

On the other hand, Standard ML, OCaml, F# and Haskell all provide powerful
static type systems and ubiquitous pattern matching.

To see the relative merits of the trade-offs you only need to see how easy
it is to obtain dynamic behaviour from such static languages and,
conversely, how prohibitively difficult it is to obtain static checking
from a dynamic language.

Witness the many pattern matching implementations that were announced the
last time we had this debate (all still vaporware) and the Minim
interpreters and compilers in OCaml (all shorter and faster than the
equivalent Lisp despite its EVAL capability, thanks to pattern matching).

The OP won't have to look far to make an informed decision...

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
From: Pascal Costanza
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <5mbmhlFcd8unU1@mid.individual.net>
Jon Harrop wrote:
> Klaus Schilling wrote:
>> Jon Harrop <···@ffconsultancy.com> writes:
>>> If you assume that being able to compile incorrect code, having
>>> rudimentary syntax and a feature whose use is discouraged are all good
>>> features, yes.
>> of course these are all good features
> 
> Therein lies the debate. Static typing is also a good feature. Manipulating
> code as data is clearly not a problem for ML, which was bred specifically
> for that task. Finally, EVAL is of limited utility and its use is
> discouraged even in Lisp.
> 
> On the other hand, Standard ML, OCaml, F# and Haskell all provide powerful
> static type systems and ubiquitous pattern matching.
> 
> To see the relative merits of the trade-offs you only need to see how easy
> it is to obtain dynamic behaviour from such static languages and,
> conversely, how prohibitively difficult it is to obtain static checking
> from a dynamic language.
> 
> Witness the many pattern matching implementations that were announced the
> last time we had this debate (all still vaporware) and the Minim
> interpreters and compilers in OCaml (all shorter and faster than the
> equivalent Lisp despite its EVAL capability, thanks to pattern matching).

Now you're outright lying. My minim interpreter was faster than your 
minim compiler, last time I checked.

And certain dynamic behaviors are impossible to achieve in languages 
with static languages.

We have discussed these things ad nauseam before.


Pascal

-- 
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
From: Pascal Costanza
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <5mbt4eFckhm5U1@mid.individual.net>
Pascal Costanza wrote:
> Jon Harrop wrote:
>> Klaus Schilling wrote:
>>> Jon Harrop <···@ffconsultancy.com> writes:
>>>> If you assume that being able to compile incorrect code, having
>>>> rudimentary syntax and a feature whose use is discouraged are all good
>>>> features, yes.
>>> of course these are all good features
>>
>> Therein lies the debate. Static typing is also a good feature. 
>> Manipulating
>> code as data is clearly not a problem for ML, which was bred specifically
>> for that task. Finally, EVAL is of limited utility and its use is
>> discouraged even in Lisp.
>>
>> On the other hand, Standard ML, OCaml, F# and Haskell all provide 
>> powerful
>> static type systems and ubiquitous pattern matching.
>>
>> To see the relative merits of the trade-offs you only need to see how 
>> easy
>> it is to obtain dynamic behaviour from such static languages and,
>> conversely, how prohibitively difficult it is to obtain static checking
>> from a dynamic language.
>>
>> Witness the many pattern matching implementations that were announced the
>> last time we had this debate (all still vaporware) and the Minim
>> interpreters and compilers in OCaml (all shorter and faster than the
>> equivalent Lisp despite its EVAL capability, thanks to pattern matching).
> 
> Now you're outright lying. My minim interpreter was faster than your 
> minim compiler, last time I checked.

...to be complete: My minim interpreter in Lisp was faster than your 
minim compiler in OCaml.

> And certain dynamic behaviors are impossible to achieve in languages 
> with static languages.

...that's one of the reasons why my implementation was faster than yours 
(although it's not obvious why that's the case, but for understanding, 
you would actually have to really learn Lisp).

> We have discussed these things ad nauseam before.

Nothing to add here.

Pascal

-- 
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
From: Jon Harrop
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <13g25fqiqe0jm68@corp.supernews.com>
Pascal Costanza wrote:
> Pascal Costanza wrote:
>> Now you're outright lying. My minim interpreter was faster than your
>> minim compiler, last time I checked.
> 
> ...to be complete: My minim interpreter in Lisp was faster than your
> minim compiler in OCaml.

Your compiler macro is an interpreter?

>> And certain dynamic behaviors are impossible to achieve in languages
>> with static languages.
>
> ...that's one of the reasons why my implementation was faster than yours
> (although it's not obvious why that's the case, but for understanding,
> you would actually have to really learn Lisp).

No, the reason turned out to be a simple optimization that you were doing
and I was not. Doing the same optimization in the OCaml, it runs at the
same speed and is ~3x shorter.

After all, you shouldn't expect any significant difference in the speed of
counting ints in OCaml and Lisp. It certainly has nothing to do with
ill-specified advantages of dynamic typing, which is just more
misinformation from the Lisp community...

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
From: Pascal Costanza
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <5mcvp1Fcpu4pU1@mid.individual.net>
Jon Harrop wrote:
> Pascal Costanza wrote:
>> Pascal Costanza wrote:
>>> Now you're outright lying. My minim interpreter was faster than your
>>> minim compiler, last time I checked.
>> ...to be complete: My minim interpreter in Lisp was faster than your
>> minim compiler in OCaml.
> 
> Your compiler macro is an interpreter?

Yes.

I can't stress enough what I said:
>> And certain dynamic behaviors are impossible to achieve in languages
>> with static languages.
 >>
>> ...that's one of the reasons why my implementation was faster than yours
>> (although it's not obvious why that's the case, but for understanding,
>> you would actually have to really learn Lisp).

...but you're not trying to understand.

> No, the reason turned out to be a simple optimization that you were doing
> and I was not. Doing the same optimization in the OCaml, it runs at the
> same speed and is ~3x shorter.

...but your implementation is not an interpreter anymore, so you're 
losing an important dynamic aspect of my implementation.

Sorry, but if you insist on taking shortcuts by playing around with toy 
examples, instead of actually investing the time to really learn Lisp, 
you don't have a chance to get it.


Pascal

-- 
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
From: Jon Harrop
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <13g2kq940n36hc0@corp.supernews.com>
Pascal Costanza wrote:
> Jon Harrop wrote:
>> Your compiler macro is an interpreter?
> 
> Yes.

For what definition of "interpreter"?

> Sorry, but if you insist on taking shortcuts by playing around with toy
> examples, instead of actually investing the time to really learn Lisp,
> you don't have a chance to get it.

I got it long ago.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
From: Cesar Rabak
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <fdr37j$qk6$2@aioe.org>
Jon Harrop escreveu:
[snipped]

> 
> Witness the many pattern matching implementations that were announced the
> last time we had this debate (all still vaporware) and the Minim
> interpreters and compilers in OCaml (all shorter and faster than the
> equivalent Lisp despite its EVAL capability, thanks to pattern matching).
> 
Besides other (more specific) comment on this, let's remember that 
pattern matching is not the single way to solve problems in the Earth.

Useful programs do need to do other things to be of practical for the users.
From: Jon Harrop
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <13g2kse700ogqc1@corp.supernews.com>
Cesar Rabak wrote:
> Besides other (more specific) comment on this, let's remember that
> pattern matching is not the single way to solve problems in the Earth.
> 
> Useful programs do need to do other things to be of practical for the
> users.

Absolutely, yes. The same can be said of dynamic typing, s-exprs and EVAL,
of course.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
From: Cesar Rabak
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <fds4ub$vt6$1@aioe.org>
Jon Harrop escreveu:
> Cesar Rabak wrote:
>> Besides other (more specific) comment on this, let's remember that
>> pattern matching is not the single way to solve problems in the Earth.
>>
>> Useful programs do need to do other things to be of practical for the
>> users.
> 
> Absolutely, yes. The same can be said of dynamic typing, s-exprs and EVAL,
> of course.
> 
That's why we praise so much the multiparadigm aspect of Lisp!
From: Jon Harrop
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <13g49ibmtpub334@corp.supernews.com>
Cesar Rabak wrote:
> Jon Harrop escreveu:
>> Cesar Rabak wrote:
>>> Besides other (more specific) comment on this, let's remember that
>>> pattern matching is not the single way to solve problems in the Earth.
>>>
>>> Useful programs do need to do other things to be of practical for the
>>> users.
>> 
>> Absolutely, yes. The same can be said of dynamic typing, s-exprs and
>> EVAL, of course.
>
> That's why we praise so much the multiparadigm aspect of Lisp!

Very true, but being multiparadigm is also another hailed feature of OCaml.
So this is still marking similarities (and there are many) rather than
differences.

Neither OCaml provides dynamic typing nor Lisp provides static typing. That
is the only really important difference between OCaml and Lisp, IMHO.
Comparing and contrasting the two is notoriously difficult, of course.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
From: Raffael Cavallaro
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <2007100208491150073-raffaelcavallaro@pasdespamsilvousplaitmaccom>
On 2007-10-02 06:57:08 -0400, the airborne amphibian said:

> Very true, but being multiparadigm is also another hailed feature of OCaml.

Henry Ford is alleged to have once said "They can have any color they 
want as long as it's black." To this we can add ocaml's "they can have 
any paradigm they want as long as it's strong static typing."

Of course if the paradigm you want uses any of the dynamic features 
Pascal is referring to you're out of luck with ocaml. But then, you've 
repeatedly avoided understanding what Pascal is talking about.
From: Jon Harrop
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <13g5boupesh6qd7@corp.supernews.com>
Turing argument.

Raffael Cavallaro wrote:
> On 2007-10-02 06:57:08 -0400, the airborne amphibian said:
>> Very true, but being multiparadigm is also another hailed feature of
>> OCaml.
> 
> Henry Ford is alleged to have once said "They can have any color they
> want as long as it's black." To this we can add ocaml's "they can have
> any paradigm they want as long as it's strong static typing."

Misinformation.

> Of course if the paradigm you want uses any of the dynamic features
> Pascal is referring to you're out of luck with ocaml.

Misinformation.

Learn how to implement the dynamic features that Pascal referred to in OCaml
and you'll see what I mean.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
From: Raffael Cavallaro
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <2007100311165616807-raffaelcavallaro@pasdespamsilvousplaitmaccom>
On 2007-10-02 16:40:58 -0400, Jon Harrop <···@ffconsultancy.com> said:

> Learn how to implement the dynamic features that Pascal referred to in OCaml
> and you'll see what I mean.

Learn how to reinvent the wheel and make your own soapbox derby racer 
instead of driving that common lisp luxury car of yours!
From: Rainer Joswig
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <joswig-9EFF68.13435302102007@news-europe.giganews.com>
In article <···············@corp.supernews.com>,
 Jon Harrop <···@ffconsultancy.com> wrote:

> Cesar Rabak wrote:
> > Jon Harrop escreveu:
> >> Cesar Rabak wrote:
> >>> Besides other (more specific) comment on this, let's remember that
> >>> pattern matching is not the single way to solve problems in the Earth.
> >>>
> >>> Useful programs do need to do other things to be of practical for the
> >>> users.
> >> 
> >> Absolutely, yes. The same can be said of dynamic typing, s-exprs and
> >> EVAL, of course.
> >
> > That's why we praise so much the multiparadigm aspect of Lisp!
> 
> Very true, but being multiparadigm is also another hailed feature of OCaml.
> So this is still marking similarities (and there are many) rather than
> differences.
> 
> Neither OCaml provides dynamic typing nor Lisp provides static typing. That
> is the only really important difference between OCaml and Lisp, IMHO.
> Comparing and contrasting the two is notoriously difficult, of course.

This is only your uninformed opinion. Most other people
in this newsgroup see it differently. Most people here
in this newsgroup have a clue about Lisp. You don't.
You have not written anything in Lisp and you are constantly
posting false information.

Folks, it is a waste of time to discuss anything with Mr. Harrop.
He is spamming comp.lang.lisp with his business interests.
Earlier he was banned from Wikipedia, because he was spamming
there, too.

-- 
http://lispm.dyndns.org
From: Cesar Rabak
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <fdums0$jtk$1@aioe.org>
Rainer Joswig escreveu:
> In article <···············@corp.supernews.com>,
>  Jon Harrop <···@ffconsultancy.com> wrote:
> 
>> Cesar Rabak wrote:
>>> Jon Harrop escreveu:
>>>> Cesar Rabak wrote:
>>>>> Besides other (more specific) comment on this, let's remember that
>>>>> pattern matching is not the single way to solve problems in the Earth.
>>>>>
>>>>> Useful programs do need to do other things to be of practical for the
>>>>> users.
>>>> Absolutely, yes. The same can be said of dynamic typing, s-exprs and
>>>> EVAL, of course.
>>> That's why we praise so much the multiparadigm aspect of Lisp!
>> Very true, but being multiparadigm is also another hailed feature of OCaml.
>> So this is still marking similarities (and there are many) rather than
>> differences.
>>
>> Neither OCaml provides dynamic typing nor Lisp provides static typing. That
>> is the only really important difference between OCaml and Lisp, IMHO.
>> Comparing and contrasting the two is notoriously difficult, of course.
> 
> This is only your uninformed opinion. Most other people
> in this newsgroup see it differently. Most people here
> in this newsgroup have a clue about Lisp. You don't.
> You have not written anything in Lisp and you are constantly
> posting false information.
> 
> Folks, it is a waste of time to discuss anything with Mr. Harrop.
> He is spamming comp.lang.lisp with his business interests.
> Earlier he was banned from Wikipedia, because he was spamming
> there, too.
> 
OK! I learned my lesson�.

His kennyness can spare His frozen trout :-)

--
Cesar Rabak

[1] meaning "I'll not waste time anymore".
From: Jon Harrop
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <13g5arqgl5acad5@corp.supernews.com>
Rainer Joswig wrote:
> ...you are constantly posting false information...
> ...Earlier he was banned from Wikipedia, because he was spamming
> there, too...

How ironic. :-)

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
From: Rainer Joswig
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <joswig-F7854B.23194302102007@news-europe.giganews.com>
In article <···············@corp.supernews.com>,
 Jon Harrop <···@ffconsultancy.com> wrote:

> Rainer Joswig wrote:
> > ...you are constantly posting false information...
> > ...Earlier he was banned from Wikipedia, because he was spamming
> > there, too...
> 
> How ironic. :-)

  Ist der Ruf erst ruiniert, lebt es sich ganz ungeniert.

(probably by Wilhelm Busch)

-- 
http://lispm.dyndns.org
From: Rainer Joswig
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <joswig-4AC993.00070403102007@news-europe.giganews.com>
In article <···············@corp.supernews.com>,
 Jon Harrop <···@ffconsultancy.com> wrote:

> Rainer Joswig wrote:
> > ...you are constantly posting false information...
> > ...Earlier he was banned from Wikipedia, because he was spamming
> > there, too...
> 
> How ironic. :-)

Here we have Harrop feedback:

 jdh30.plus.com -  -  [2007-10-02 21:28:58]   "GET / HTTP/1.1"  200   11395 "Mozilla/5.0 (compatible; Konqueror/3.5; Linux) KHTML/3.5.7 (like Gecko) (Debian)"  -
 jdh30.plus.com -  -  [2007-10-02 21:29:04]   "GET /pics/hornbelt.jpg HTTP/1.1"   200   241499   "Mozilla/5.0 (compatible; Konqueror/3.5; Linux) KHTML/3.5.7 (like Gecko) (Debian)"  "http://lispm.dyndns.org/"
 jdh30.plus.com -  -  [2007-10-02 21:31:35]   "POST /feedback HTTP/1.1"  200   364   "Mozilla/5.0 (compatible; Konqueror/3.5; Linux) KHTML/3.5.7 (like Gecko) (Debian)"  "http://lispm.dyndns.org/"


 (3400349495 80.229.56.224 (MOZILLA 5.0 (COMPATIBLE KONQUEROR 3.5 LINUX KHTML 3.5.7 LIKE GECKO DEBIAN))
 Jon Harrop ·······@ffconsultancy.com Is this the best webpage Lisp can generate? It really sucks. You should learn OCaml.
 Try reading some of the excellent resources out there... Homepage)


;-)

-- 
http://lispm.dyndns.org
From: Klaus Schilling
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <87ve9ppj3j.fsf@web.de>
Jon Harrop <···@ffconsultancy.com> writes:
>
> Neither OCaml provides dynamic typing nor Lisp provides static typing. That
> is the only really important difference between OCaml and Lisp, IMHO.

no, there's still the disgusting infix syntax of *ml, 
and the lack of eval for ocaml

Klaus Schilling
From: Jon Harrop
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <13g7marap11ab9d@corp.supernews.com>
Klaus Schilling wrote:
> Jon Harrop <···@ffconsultancy.com> writes:
>> Neither OCaml provides dynamic typing nor Lisp provides static typing.
>> That is the only really important difference between OCaml and Lisp,
>> IMHO.
> 
> no, there's still the disgusting infix syntax of *ml,
> and the lack of eval for ocaml

Conversely, secondary effects in Lisp: disgusting s-expr syntax and lack of
pattern matching in Lisp.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
From: Ken Tilton
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <GETMi.12$Uu6.8@newsfe12.lga>
Jon Harrop wrote:
> ...  and lack of
> pattern matching in Lisp.
> 

You don't like cl-ppcre or whatever it's called? I had it installed 
before noticing Franz had copied it in ACL, but still.

Dr Ken W Tilton, Flying Fuck Consultancy

-- 
http://www.theoryyalgebra.com/

"We are what we pretend to be." -Kurt Vonnegut
From: Klaus Schilling
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <87myuz5gdb.fsf@web.de>
Jon Harrop <···@ffconsultancy.com> writes:
> Conversely, secondary effects in Lisp: disgusting s-expr syntax 

all decent programmers dream and think in symbolic expressions.

> pattern matching in Lisp.

pattern matching is easily supplied by specialised packages

Klaus Schilling
From: Don Geddis
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <87r6kazudk.fsf@geddis.org>
Klaus Schilling <···············@web.de> wrote on Thu, 04 Oct 2007:
> Jon Harrop <···@ffconsultancy.com> writes:
>> pattern matching in Lisp.
>
> pattern matching is easily supplied by specialised packages

To be fair to our resident troll, I'm not so sure about this part.  He's not
talking about string matching with regular expressions.  As you say, that's
easily added to Lisp via any number of available packages.

He's talking about function definitions using pattern matching on the
arguments.  More like CLOS generic functions, where the specific method
is chosen automatically based on argument number and type.

I'm not entirely sure of the difference between OCaml "pattern matching"
function definitions, and Lisp CLOS generic functions ... but assuming there
is a significant difference, I doubt this can be "easily supplied by
specialized packages".

        -- Don
_______________________________________________________________________________
Don Geddis                  http://don.geddis.org/               ···@geddis.org
In America, we have a two-party system.  There is the stupid party.  And
there is the evil party.  I am proud to be a member of the stupid party.
Periodically, the two parties get together and do something that is both
stupid and evil.  This is called bipartisanship.
	-- Republican congressional staffer
From: Raffael Cavallaro
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <2007100414334950073-raffaelcavallaro@pasdespamsilvousplaitmaccom>
On 2007-10-04 13:01:43 -0400, Don Geddis <···@geddis.org> said:

> He's talking about function definitions using pattern matching on the
> arguments.  More like CLOS generic functions, where the specific method
> is chosen automatically based on argument number and type.

We've been round this issue several times before. There are indeed 
pattern matching libraries for common lisp of the type to which the 
airborne amphibian refers.

Marco Antoniotti's cl-unification,

<http://common-lisp.net/project/cl-unification/>

for example, allows you to write the same sorts of function definitions 
where dispatch is handled by pattern matching:

(defun factorial (x)
    (match-case (x)
      (0 1)
      (#T(number ?n) (* ?n (factorial (1- ?n))))
      (otherwise (error "Incorrect match for ~S." x))))

For a more complex and substantial example see:

<http://common-lisp.net/project/cl-unification/control-flow.html>


The issue with pattern matching in common lisp libraries is that, 
because they do the pattern matching dynamically at run time, they 
cannot do dispatch as fast as statically typed languages with built in 
pattern matching such as the irish ship of the desert. This is offset 
by the likelihood that dispatch on argument types is not where many 
real world applications spend most of their time.

Finally, I'm pretty sure that when kenny spoke of cl-ppcre, his 
kennyness, having participated in previous discussions of this same 
issue, was fully aware that regexes were not what the plummeting 
pond-dweller was talking about when he said "pattern matching." Kenny 
was just twitting the hurtling horned toad.
From: Pascal Costanza
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <5mkp14Fdo4jqU1@mid.individual.net>
Don Geddis wrote:
> Klaus Schilling <···············@web.de> wrote on Thu, 04 Oct 2007:
>> Jon Harrop <···@ffconsultancy.com> writes:
>>> pattern matching in Lisp.
>> pattern matching is easily supplied by specialised packages
> 
> To be fair to our resident troll, I'm not so sure about this part.  He's not
> talking about string matching with regular expressions.  As you say, that's
> easily added to Lisp via any number of available packages.
> 
> He's talking about function definitions using pattern matching on the
> arguments.  More like CLOS generic functions, where the specific method
> is chosen automatically based on argument number and type.
> 
> I'm not entirely sure of the difference between OCaml "pattern matching"
> function definitions, and Lisp CLOS generic functions ... but assuming there
> is a significant difference, I doubt this can be "easily supplied by
> specialized packages".

It's true that this is not straightforward. Statically typed languages 
have an advantage here because they can do more, well, static analysis.

Nevertheless, CLOS already provides some rope to integrate pattern 
matching into generic functions. There are two papers presented at this 
year's European Lisp Workshop which discuss some of the involved issues. 
See http://lisp-ecoop07.bknr.net/ for the papers.

Pascal

[And our resident frog will now say "greenspunning", or some such...]

-- 
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
From: Jon Harrop
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <13gapfaqdrd9gbf@corp.supernews.com>
Don Geddis wrote:
> I'm not entirely sure of the difference between OCaml "pattern matching"
> function definitions, and Lisp CLOS generic functions ... but assuming
> there is a significant difference, I doubt this can be "easily supplied by
> specialized packages".

The difference boils down to integration into the type system that gives
ML-style pattern matching its speed and static checking. Without a static
type system, you can't even implement a basic ML-style pattern matcher.

Since Common Lisp came out, pattern matching has evolved into a construct of
unparallelled expressive power that is now ubiquitous in all modern
statically typed functional programming languages. In contrast, nobody has
ever been able to write a pattern matching library for Lisp that gained the
same traction.

For example, Haskell, OCaml and F# add or-patterns, guards, polymorphic
variants, lazy stream parsers, lazy sequences, views and so on. All of
these extra features only serve to broaden the expressive power of pattern
matching.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
From: Raffael Cavallaro
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <2007100420170475249-raffaelcavallaro@pasdespamsilvousplaitmaccom>
On 2007-10-04 16:17:53 -0400, the plummeting pond-dweller said:

> In contrast, nobody has
> ever been able to write a pattern matching library for Lisp that gained the
> same traction.

Now your tune changes. First it was "in 50 years of Lisp nobody has 
ever been able to do that," now it's about gaining "traction." Hint to 
the falling fly-eater: No *single* pattern matcher has gained 
"traction" because:

1. pattern matching is not one cut and dried, generally agreed upon 
algorithm. Common Lisp gives you a choice of pattern matching libraries:


<http://common-lisp.net/project/cl-unification/>
<http://www.cliki.net/fare-matcher>
<http://common-lisp.net/project/bese/arnesi.html>
<http://lisa.sourceforge.net/>

the irish ship of the desert does not - you must use what's built in.


2. Common Lisp programmers don't see pattern matching as the be-all and 
end-all of programming that you do. It has it's uses, but pattern 
matching is far less compelling in a language that has generic 
functions dispatching on argument types (and values) at run time than 
it is in a strong statically typed language like the donut dromedary.

N.B. terms like "donut dromedary" and "falling fly-eater" are used to 
avoid feeding search engines links to him, his site, or his off topic 
language.
From: Kent M Pitman
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <uhcl6cmtl.fsf@nhplace.com>
Raffael Cavallaro <················@pas-d'espam-s'il-vous-plait-mac.com> writes:
> 2. Common Lisp programmers don't see pattern matching as the be-all
> and end-all of programming that you do.

Further, there is some sense in which Lisp has a specific history of
experimentation in this area, and some of its design specifically
avoids this.

A lot of early Lisp used to use pattern-matchy constructs, like
  (let (((a b c) (list 'a 'b 'c))) ...)
but we found we didn't like it because it wired into the language itself
a reliance on data being laid out a certain way.  If you later changed
the abstraction, your program shape was often wrong in subtle ways.

So while not everyone might agree this was a good decision, and while
people still do pattern matching in application situations where the
application writer may think it's appropriate, it's not sheer ignorance
that has driven the language not to follow this path.

Incidentally, I don't hear anyone here criticizing other languages for
having pattern matching, or saying those languages are wrong/bad/whatever.
I hear only people saying Lisp is wrong/bad/whatever for not having
those things other languages have.  Why have more than one language if
all languages are required to be the same?

"... now all restaurants are Taco Bell"
[If you don't recognize this quote, it's from the movie Demolition Man
 http://www.imdb.com/title/tt0106697/
 which a fun movie, well worth seeing.  If you're determined not to see it,
 you can read about the quote's significance in:
 http://www.tinotopia.com/wordpress/archive/2003/01/24/dangers_of_product_placement
]
From: Jon Harrop
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <13gb7p915m7l9de@corp.supernews.com>
Raffael Cavallaro wrote:
> On 2007-10-04 16:17:53 -0400, the plummeting pond-dweller said:
>> In contrast, nobody has
>> ever been able to write a pattern matching library for Lisp that gained
>> the same traction.
> 
> Now your tune changes. First it was "in 50 years of Lisp nobody has
> ever been able to do that," now it's about gaining "traction." Hint to
> the falling fly-eater: No *single* pattern matcher has gained
> "traction" because: 
> 
> 1. pattern matching is not one cut and dried, generally agreed upon
> algorithm.

ML-style pattern matching is found in:

Standard ML
Alice ML
Caml light
OCaml
Haskell
Nemerle
Scala
F#

and dozens of related languages (JoCaml, JCaml, GCaml, XDuce, CDuce etc.).

> Common Lisp gives you a choice of pattern matching libraries: 
> 
> <http://common-lisp.net/project/cl-unification/>
> <http://www.cliki.net/fare-matcher>
> <http://common-lisp.net/project/bese/arnesi.html>
> <http://lisa.sourceforge.net/>

None of those implement ML-style pattern matching and, consequently, they
are all rarely used. This was discussed in detail here on c.l.lisp not so
long ago.

> the irish ship of the desert does not - you must use what's built in.

Typical misinformation. Counter examples:

http://martin.jambon.free.fr/micmatch.html
http://blogs.msdn.com/dsyme/attachment/2044281.ashx
http://code.google.com/p/ocaml-patterns/wiki/PatternGuards
...

> 2. Common Lisp programmers don't see pattern matching as the be-all and
> end-all of programming that you do. It has it's uses, but pattern
> matching is far less compelling in a language that has generic
> functions dispatching on argument types (and values) at run time than
> it is in a strong statically typed language like the donut dromedary.

More people use ML-style pattern matching than Lisp, so it is clearly
useful. The fact that no Lisp reimplementation ever got traction simply
reflects the limitations that the Lisp language forces upon you.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
From: Raffael Cavallaro
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <200710042300378930-raffaelcavallaro@pasdespamsilvousplaitmaccom>
On 2007-10-04 22:09:55 -0400, Jon Harrop <···@ffconsultancy.com> said:

> ML-style pattern matching is found in:
> 
> Standard ML
> Alice ML
> Caml light
> OCaml

notice the 'ml' in all of these. This is rather like saying "lisp style 
s expressions are found in scheme, and common lisp, and newlisp, and 
picolisp and ...



> Haskell
> Nemerle
> Scala
> F#

yet another kind of ml.

> 
> and dozens of related languages (JoCaml, JCaml, GCaml, XDuce, CDuce etc.).
> 
>> Common Lisp gives you a choice of pattern matching libraries:
>> 
>> <http://common-lisp.net/project/cl-unification/>
>> <http://www.cliki.net/fare-matcher>
>> <http://common-lisp.net/project/bese/arnesi.html>
>> <http://lisa.sourceforge.net/>
> 
> None of those implement ML-style pattern matching and, consequently, they
> are all rarely used.

What is the traffic to comp.lang.functional? What is the traffic in 
comp.lang.lisp? Which language is rarely used again?

Your conclusion is completety *backwards*.

Reality: many more people use common lisp than all the functional 
languages *combined*. Common Lispers don't use pattern matching not 
because the Common Lisp libraries for pattern matching aren't like ml 
style pattern matching - who would possibly care? - practically no one 
uses *ml anyway - it's not as if these languages are some sort of 
interoperable library standard like C/C++. Common Lispers don't use 
pattern matching because they have CLOS multimethods, and rarely miss 
pattern matching. When they need it they load an easy to use library. 
Simple. Nothing to see here. Move along.

I know you find this hard to believe because your tiny little amphibian 
world revolves around pattern matching, but Common Lispers really, 
really, really, really do not miss pattern matching. We know it exists. 
We just don't really need it that often when we can dispatch on 
argument types and values at runtime with CLOS.
From: Jon Harrop
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <13gdpo9a1rn5cca@corp.supernews.com>
Raffael Cavallaro wrote:
> What is the traffic to comp.lang.functional?

What does c.l.f have to do with ML-style pattern matching?

> Reality: many more people use common lisp than all the functional
> languages *combined*.

JavaScript?

> I know you find this hard to believe because your tiny little amphibian
> world revolves around pattern matching, but Common Lispers really,
> really, really, really do not miss pattern matching.

You cannot miss something that you've never had.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
From: Raffael Cavallaro
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <2007100600300277923-raffaelcavallaro@pasdespamsilvousplaitmaccom>
On 2007-10-05 14:32:39 -0400, tumbling toad said:

> Raffael Cavallaro wrote:
>> What is the traffic to comp.lang.functional?
> 
> What does c.l.f have to do with ML-style pattern matching?

comp.lang.functional is where discussion of *ml belongs, but you knew 
that already. The only reason youre here in comp.lang.lisp is because 
you already know that there's little or no traffic in 
comp.lang.functional.
Asserting that *ml style pattern matching is some sort of standard is a 
joke, since you have to have a large number of users for something to 
be a de facto standard, and *ml does not have a large number of users.

> 
>> Reality: many more people use common lisp than all the functional
>> languages *combined*.
> 
> JavaScript?

You'll do anything to change the subject from the fact that *ml is not, 
and never will be popular enough to constitute some sort of de facto 
standard. JavaScript is weakly typed, and dynamic - now you're 
championing it as a functional language in the same breath as *ml. 
Please. Pull the other one, it's got bells on it.

The whole discussion is whether *ml style pattern matching is popular 
enough to constitute some sort of 'standard' that would put people off 
using lisp pattern matching libraries. JavaScript does not have *ml 
style pattern matching, so it's users cannot be counted by those 
familiar with the 'standard' *ml style pattern matching. To 
JavaScripters 'pattern matching' really does mean Perl style regexes.

Javascript users do *not* hang out in comp.lang.functional. They have 
their own newsgroup that actually gets some traffic. Your usual game of 
changing terms. For you 'functional' always meant pure functional, with 
strong static typing. Now, when it suits you, it means javascript, a 
dynamic, weakly typed scripting language that does not eschew state and 
mutation.

BTW, the wikipedia article on Javascript goes through a couple of dozen 
paragraphs before mentioning, in the very last line that javascript is 
*also* considered a functional language becuase it has first class 
functions. Common lisp has first class functions too, but it is not 
*merely* a functional language. Neither is Javascript.

> You cannot miss something that you've never had.

We do have pattern matching, and full blown unification when we need 
it. We just don't burn incense and light candles to it like you do.
From: Jon Harrop
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <13ge9rqia45oid7@corp.supernews.com>
Raffael Cavallaro wrote:
> On 2007-10-05 14:32:39 -0400, tumbling toad said:
>> Raffael Cavallaro wrote:
>>> What is the traffic to comp.lang.functional?
>> 
>> What does c.l.f have to do with ML-style pattern matching?
> 
> comp.lang.functional is where discussion of *ml belongs

OCaml is discussed on the caml-list (copied to fa.caml). Haskell on the
haskell-cafe. F# on their mailing list and hub.

> Asserting that *ml style pattern matching is some sort of standard is a
> joke,

The core concept has been adopted by many different languages.

> since you have to have a large number of users for something to 
> be a de facto standard, and *ml does not have a large number of users.

In total, those languages have far more users than Common Lisp.

>>> Reality: many more people use common lisp than all the functional
>>> languages *combined*.
>> 
>> JavaScript?
> 
> You'll do anything to change the subject

The functional language JavaScript sold 90x as many books in Q2 2007 than
Lisp. Your claim that Lisp is more popular is absurd.

> JavaScript is weakly typed, and dynamic - now you're
> championing it as a functional language in the same breath as *ml.

Did you mean to claim that Lisp is more popular than all statically typed
languages then?

> The whole discussion is whether *ml style pattern matching is popular

Your statement about Lisp being more popular than all functional languages
combined seemed irrelevant to ML-style pattern matching.

> Javascript users do *not* hang out in comp.lang.functional.

Indeed, nobody hangs out in c.l.f.

> They have their own newsgroup that actually gets some traffic.

Like OCaml, Haskell, F# and Scala then.

> For you 'functional' always meant pure functional, with
> strong static typing.

Neither OCaml nor F# are pure functional languages.

This is really exactly the kind of misinformation that I was referring to
before. You clearly have no idea what other functional languages are out
there or what pattern matching is but you're making gross sweeping
statements about their popularity and capabilities without ever having
visited their discussion forums. I really do recommend you go and have a
look. There are lots of awesome functional programming languages available
these days and there is absolutely no reason to restrict yourself to Lisp.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
From: Ken Tilton
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <5eONi.339$wc.55@newsfe12.lga>
Jon Harrop wrote:
> The functional language JavaScript sold 90x as many books in Q2 2007 than
> Lisp. Your claim that Lisp is more popular is absurd.

You should have been at ILC 2003, where we learned JavaSript /is/ Lisp.

kenny

-- 
http://www.theoryyalgebra.com/

"We are what we pretend to be." -Kurt Vonnegut
From: Rainer Joswig
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <joswig-2EDFAF.18165506102007@news-europe.giganews.com>
In article <···············@newsfe12.lga>,
 Ken Tilton <···········@optonline.net> wrote:

> Jon Harrop wrote:
> > The functional language JavaScript sold 90x as many books in Q2 2007 than
> > Lisp. Your claim that Lisp is more popular is absurd.
> 
> You should have been at ILC 2003, where we learned JavaSript /is/ Lisp.
> 
> kenny

Yep, JavaScript is very Lisp-like. It also has now learned
some more from Smalltalk. Check this out:

   http://research.sun.com/projects/lively/

If you have Safari 3.0beta (best) or some new Firefox
(some bugs) then try out the environment here:

   http://research.sun.com/projects/lively/index.xhtml

It is basically the Smalltalk environment redone in Javascript
running in a browser.

How could they do it in under 10000 lines without static typing
and pattern matching.

A wonder! Praise the Lambda!

-- 
http://lispm.dyndns.org
From: Jon Harrop
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <13gfe5et5ksus42@corp.supernews.com>
Rainer Joswig wrote:
> In article <···············@newsfe12.lga>,
>  Ken Tilton <···········@optonline.net> wrote:
>> You should have been at ILC 2003, where we learned JavaSript /is/ Lisp.
> 
> Yep, JavaScript is very Lisp-like.

ROTFL. Last stand of the Lisper: everything is Lisp.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
From: Ken Tilton
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <SWPNi.22$DO7.16@newsfe12.lga>
Jon Harrop wrote:
> Rainer Joswig wrote:
> 
>>In article <···············@newsfe12.lga>,
>> Ken Tilton <···········@optonline.net> wrote:
>>
>>>You should have been at ILC 2003, where we learned JavaSript /is/ Lisp.
>>
>>Yep, JavaScript is very Lisp-like.
> 
> 
> ROTFL. Last stand of the Lisper: everything is Lisp.
> 

Well, sorry, but that was the talk. I was actually guessing at the year, 
but 2003 would be ballparkish. The fellow seemed quite sincere and a big 
fan of Lisp. So there!

We did run him out of town, mind you, here on c.l.l after the conference.

kenny

-- 
http://www.theoryyalgebra.com/

"We are what we pretend to be." -Kurt Vonnegut
From: ···@telent.net
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <470b6746$0$13923$fa0fcedb@news.zen.co.uk>
Ken Tilton wrote:
> 
> 
> Jon Harrop wrote:
>> Rainer Joswig wrote:
>>
>>> In article <···············@newsfe12.lga>,
>>> Ken Tilton <···········@optonline.net> wrote:
>>>
>>>> You should have been at ILC 2003, where we learned JavaSript /is/ Lisp.
>>>
>>> Yep, JavaScript is very Lisp-like.
>>
>>
>> ROTFL. Last stand of the Lisper: everything is Lisp.
>>
> 
> Well, sorry, but that was the talk. I was actually guessing at the year, 
> but 2003 would be ballparkish. The fellow seemed quite sincere and a big 
> fan of Lisp. So there!

'02.  BTDTGTTS

It (javascript) is quite a fun language, but suffers badly from (a) no 
block scope - or at least, no sane syntax for it - and (b) too many 
morons writing web pages about it.


-dan
From: Cor Gest
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <87odfcjho0.fsf@cleopatra.clsnet.nl>
Some entity, AKA Jon Harrop <···@ffconsultancy.com>,
wrote this mindboggling stuff:
(selectively-snipped-or-not-p)


> > Yep, JavaScript is very Lisp-like.
> 
> ROTFL. Last stand of the Lisper: everything is Lisp.

Misguided again, everything imitates lisp (badly).

 Cor

-- 
Alle schraifvauden zijn opzettelijk, teneinde ieder lafaard de kans te 
 geven over spelling te zeuren in plaats van in te gaan op de inhoud.
    (defvar My-Computer '((OS . "GNU/Emacs") (IPL . "GNU/Linux")))
		            http://www.clsnet.nl/mail.php
From: Raffael Cavallaro
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <2007100616493184492-raffaelcavallaro@pasdespamsilvousplaitmaccom>
On 2007-10-06 02:03:59 -0400, Jon Harrop <···@ffconsultancy.com> said:

> The functional language JavaScript sold 90x as many books in Q2 2007 than
> Lisp. Your claim that Lisp is more popular is absurd.

My claim is that JavaScript is not the sort of pure functional, 
statically typed language *you are advocating* - JavaScript does *not* 
have *ml style pattern matching.

You yourself listed the kind of functional languages we're talking 
about - those with *ml style pattern matching. Common Lisp is more 
popular than these as evinced by:
1. The far greater traffic in c.l.l than c.l.f
2. The far greater number of lists in the gmane.lisp hierarchy.
From: Jon Harrop
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <13gg5tgkgpi0na1@corp.supernews.com>
Raffael Cavallaro wrote:
> On 2007-10-06 02:03:59 -0400, Jon Harrop <···@ffconsultancy.com> said:
>> The functional language JavaScript sold 90x as many books in Q2 2007 than
>> Lisp. Your claim that Lisp is more popular is absurd.
> 
> My claim is that JavaScript is not the sort of pure functional,
> statically typed language *you are advocating* - JavaScript does *not*
> have *ml style pattern matching.

Then you meant "ML" and not "functional language".

> You yourself listed the kind of functional languages we're talking
> about - those with *ml style pattern matching. Common Lisp is more
> popular than these as evinced by:
> 1. The far greater traffic in c.l.l than c.l.f

Again, 90x as many books sold on JavaScript but only 50% more usenet posts.
The quantity of usenet posts is totally unrelated to usage.

> 2. The far greater number of lists in the gmane.lisp hierarchy.

OCaml for Scientists makes more money than all Lisp books combined and F#
for Scientists will make far more than that.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
From: Brian Adkins
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <1191727313.915916.230810@d55g2000hsg.googlegroups.com>
On Oct 6, 7:08 pm, Jon Harrop <····@ffconsultancy.com> wrote:
> OCaml for Scientists makes more money than all Lisp books combined and F#
> for Scientists will make far more than that.

Baloney. You have no idea how much money was made on "all Lisp books
combined", and you certainly can't predict the future. Getting Amazon
to carry your book would probably provide more sales than making up
statistics on c.l.l.
From: Cor Gest
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <87k5pzk1s4.fsf@cleopatra.clsnet.nl>
Some entity, AKA Brian Adkins <···········@gmail.com>,
wrote this mindboggling stuff:
(selectively-snipped-or-not-p)

> On Oct 6, 7:08 pm, Jon Harrop <····@ffconsultancy.com> wrote:
> > OCaml for Scientists makes more money than all Lisp books combined and F#
> > for Scientists will make far more than that.
> 
> Baloney. You have no idea how much money was made on "all Lisp books
> 



I CONFESS, to have worshiped the HyperSpec
I CONFESS, to have followed the rulings of CLTL2
I CONFESS, to have listened to the MIT SICP lectures 
I COBFESS, to have read evil books like PAIP and PCL
I CONFESS, to have perverted True Languages to do my dirty work
I CONFESS, to have abused strong types as mere data
I CONFESS, to have misled patterns to be a dumb object
I CONFESS, to have liberated the GC by letting junk to be deleted
I CONFESS, to have rebelled against linguistic oppression
I CONFESS, to have raped cannonical coding-styles

HENCE I humbly ask forgiveness for all these evil deeds.

The only, meagre defence I have, is that I merely wanted a
simple program to get rid of the endemic spam-pestilence.

I cannot live in peace of mind with the gains from that endeavour, wich
will last to my end in this realm, but won by the 'utter evil in
your eye'.

deviniae harropus absolvo me 


Oh, BTW it really baffles me how a fucking Marketoid can keep everyone
busy with his excrement, he surely knows how to play suckers.



Cor


-- 
Alle schraifvauden zijn opzettelijk, teneinde ieder lafaard de kans te 
 geven over spelling te zeuren in plaats van in te gaan op de inhoud.
    (defvar My-Computer '((OS . "GNU/Emacs") (IPL . "GNU/Linux")))
		            http://www.clsnet.nl/mail.php
From: Jon Harrop
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <13ggutub2s55ebe@corp.supernews.com>
Brian Adkins wrote:
> On Oct 6, 7:08 pm, Jon Harrop <····@ffconsultancy.com> wrote:
>> OCaml for Scientists makes more money than all Lisp books combined and F#
>> for Scientists will make far more than that.
> 
> Baloney. You have no idea how much money was made on "all Lisp books
> combined"...

I'm going by the publically available statistics:

  http://radar.oreilly.com/archives/2007/05/state_of_the_co_10.html

Obviously I've a keen interest in books, languages and profit. You'll have
to excuse me if I don't jump at the chance of writing about Lisp or any
other dead languages.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
From: Matthias Benkard
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <1191751193.229025.82670@57g2000hsv.googlegroups.com>
Jon Harrop wrote:
> I'm going by the publically available statistics:
>
>   http://radar.oreilly.com/archives/2007/05/state_of_the_co_10.html

... according to which O'Caml, as measured by book sales, is an
``irrelevant'' language, with F# not even making it onto the list. :)

~ Matthias
From: Ken Tilton
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <SO8Oi.29$gM.18@newsfe12.lga>
Jon Harrop wrote:
>  You'll have
> to excuse me if I don't jump at the chance of writing about Lisp or any
> other dead languages.
> 

And you are surprised we savage you?

You remind me of the guy who sat in the cheap seats at a Rangers game in 
Madison Square Garden wearing an Islanders jersey and yelling "Rangers 
suck!" like a metronym until he got his ass kicked for him.

Unlike you  he was smart enough to understand why he got attacked.

As for your sales, you remind me of another asshole who works the crowd 
at our DJed skate circle in Central Park selling CDs and claiming they 
are the same music the DJs are playing.

Like you, no one believes him.

Back OT, hey, no OO? No macros? How about LOOP? Gotta have LOOP.

kenny

-- 
http://www.theoryyalgebra.com/

"We are what we pretend to be." -Kurt Vonnegut
From: Kent M Pitman
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <uir5i2595.fsf@nhplace.com>
Jon Harrop <···@ffconsultancy.com> writes:

> Obviously I've a keen interest in books, languages and profit. You'll have
> to excuse me if I don't jump at the chance of writing about Lisp or any
> other dead languages.

If it's not profitable to write about Lisp, then by all means, please
do not.  You could start your new career of not writing about Lisp
right here on this forum.

If you have such disdain for the language, this is not your forum
anyway.  Please have some respect for those you allege dead and leave
us in reverent silence.

Usenet is divided by topic according to interest groups.  Interest
should not be confused with disinterest.  These are not disinterest
groups.  If every topic were an invitation to everyone with an active
disinterest to post the reasons for their disinterest, the entire
mechanism would melt down in short order.

If there are ever rules made against free posting on usenet, you might
give serious thought to whether personally will be cited as historical
evidence that people do not cope well with freedom and that freedom
needs to be curtailed.  I would hope that wouldn't make you feel proud.
From: André Thieme
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <febcs3$4dp$1@registered.motzarella.org>
Kent M Pitman schrieb:
> Jon Harrop <···@ffconsultancy.com> writes:
> 
>> Obviously I've a keen interest in books, languages and profit. You'll have
>> to excuse me if I don't jump at the chance of writing about Lisp or any
>> other dead languages.
> 
> If it's not profitable to write about Lisp, then by all means, please
> do not.  You could start your new career of not writing about Lisp
> right here on this forum.

The thing is that John understood that Lisp really is more useful than
OCaml and F#. However, he has written so much positive things about them
in public that he is in the sad situation of not being able to go back.
Instead of accepting the facts he sadly has to come up with lies.
His book is not sold at amazon.com. No wonder, they don't even have
a unique listing for ML, OCaml or F#.
He ignores that Seibels Lisp book ranked on position 4 of all programming
books that amazon sold, or that recently the book "Lisp in small pieces"
was on rank #1 on amazon.ca of *all* books.

He is not able to stop writing about Lisp, because it really touches him.


Andr�
-- 
From: Madhu
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <m3lkaep91g.fsf@robolove.meer.net>
* Kent M Pitman <·············@nhplace.com> :
| Usenet is divided by topic according to interest groups.  Interest
| should not be confused with disinterest.  These are not disinterest
| groups.  If every topic were an invitation to everyone with an active
| disinterest to post the reasons for their disinterest, the entire
| mechanism would melt down in short order.
|
| If there are ever rules made against free posting on usenet, you might
| give serious thought to whether personally will be cited as historical
| evidence that people do not cope well with freedom and that freedom
| needs to be curtailed.  I would hope that wouldn't make you feel
| proud.

I'm afraid the OP is probably actually *being rewarded* for his actions,
in encouraging people to move to controlled forums and removing any
value from usenet.  [I think it is a fact that people get rewarded for
introducing inefficiencies, and doing stuff that would normally make one
balk]

I remembered a post from Duane Rettig in August in the huge thread
(crossposted to comp.lang.functional), where, in response to a flood of
posts from Markus, he spoke about automatic regulation: how normally
external factors in ones life would end up regulating the time spent on
an activity like usenet.

I tried in vain hour to find this post in google groups (bloody useless
tool)!  If someone can please post a pointer, I'd apperciate it.

--
Madhu
From: Duane Rettig
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <o0k5pyvysa.fsf@gemini.franz.com>
Madhu <·······@meer.net> writes:

> * Kent M Pitman <·············@nhplace.com> :
> | Usenet is divided by topic according to interest groups.  Interest
> | should not be confused with disinterest.  These are not disinterest
> | groups.  If every topic were an invitation to everyone with an active
> | disinterest to post the reasons for their disinterest, the entire
> | mechanism would melt down in short order.
> |
> | If there are ever rules made against free posting on usenet, you might
> | give serious thought to whether personally will be cited as historical
> | evidence that people do not cope well with freedom and that freedom
> | needs to be curtailed.  I would hope that wouldn't make you feel
> | proud.
>
> I'm afraid the OP is probably actually *being rewarded* for his actions,
> in encouraging people to move to controlled forums and removing any
> value from usenet.  [I think it is a fact that people get rewarded for
> introducing inefficiencies, and doing stuff that would normally make one
> balk]
>
> I remembered a post from Duane Rettig in August in the huge thread
> (crossposted to comp.lang.functional), where, in response to a flood of
> posts from Markus, he spoke about automatic regulation: how normally
> external factors in ones life would end up regulating the time spent on
> an activity like usenet.
>
> I tried in vain hour to find this post in google groups (bloody useless
> tool)!  If someone can please post a pointer, I'd apperciate it.

http://groups.google.com/group/comp.lang.lisp/msg/78ac8e31e0936b57

-- 
Duane Rettig    ·····@franz.com    Franz Inc.  http://www.franz.com/
555 12th St., Suite 1450               http://www.555citycenter.com/
Oakland, Ca. 94607        Phone: (510) 452-2000; Fax: (510) 452-0182   
From: Slobodan Blazeski
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <1191854621.969393.49240@y42g2000hsy.googlegroups.com>
On Oct 8, 9:41 am, Duane Rettig <·····@franz.com> wrote:
> Madhu <·······@meer.net> writes:
> > * Kent M Pitman <·············@nhplace.com> :
> > | Usenet is divided by topic according to interest groups.  Interest
> > | should not be confused with disinterest.  These are not disinterest
> > | groups.  If every topic were an invitation to everyone with an active
> > | disinterest to post the reasons for their disinterest, the entire
> > | mechanism would melt down in short order.
> > |
> > | If there are ever rules made against free posting on usenet, you might
> > | give serious thought to whether personally will be cited as historical
> > | evidence that people do not cope well with freedom and that freedom
> > | needs to be curtailed.  I would hope that wouldn't make you feel
> > | proud.
>
> > I'm afraid the OP is probably actually *being rewarded* for his actions,
> > in encouraging people to move to controlled forums and removing any
> > value from usenet.  [I think it is a fact that people get rewarded for
> > introducing inefficiencies, and doing stuff that would normally make one
> > balk]
>
> > I remembered a post from Duane Rettig in August in the huge thread
> > (crossposted to comp.lang.functional), where, in response to a flood of
> > posts from Markus, he spoke about automatic regulation: how normally
> > external factors in ones life would end up regulating the time spent on
> > an activity like usenet.
>
> > I tried in vain hour to find this post in google groups (bloody useless
> > tool)!  If someone can please post a pointer, I'd apperciate it.
>
> http://groups.google.com/group/comp.lang.lisp/msg/78ac8e31e0936b57
>
> --
> Duane Rettig    ·····@franz.com    Franz Inc.  http://www.franz.com/
> 555 12th St., Suite 1450              http://www.555citycenter.com/
> Oakland, Ca. 94607        Phone: (510) 452-2000; Fax: (510) 452-0182  

Nice post thank you, I was addicted too. SOmething I understood after
reading
http://www.stevepavlina.com/articles/effective-online-forum-usage.htm

Here are some potential negative effects of excessive forum usage:
Reduced concentration and focus
Reduced productivity
Chronic procrastination
Increased pessimism and/or apathy
Being distracted by endless debates and idle gossip
Gradually substituting tribal group think for your own intelligence
Impaired social skills, neglected relationships, and a weakened social
circle (a consequence of substituting online socialization for face-to-
face conversations)
Reduced energy (forum participation is sedentary compared to more
active social outlets)
Reduced self-esteem
Career and income may suffer (including loss of employment)
Forum addiction


cheers
Slobodan
From: Madhu
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <m3hcl1q4jf.fsf@robolove.meer.net>
* Duane Rettig <··············@gemini.franz.com> :

|> I tried in vain hour to find this post in google groups (bloody useless
|> tool)!  If someone can please post a pointer, I'd apperciate it.
|
| http://groups.google.com/group/comp.lang.lisp/msg/78ac8e31e0936b57

Thanks,

[It appears to be indexed now.  I had the a number of browser windows
open looking at failed results of queries (matching keywords `job' and
`messages', for example) with your name as `author:', limiting `groups:'
to cll and clf.  Running the query again now finds this message]

--
Madhu
From: Brian Adkins
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <1191805978.928639.233520@k79g2000hse.googlegroups.com>
On Oct 7, 2:15 am, Jon Harrop <····@ffconsultancy.com> wrote:
> Brian Adkins wrote:
> > On Oct 6, 7:08 pm, Jon Harrop <····@ffconsultancy.com> wrote:
> >> OCaml for Scientists makes more money than all Lisp bookscombinedand F#
> >> for Scientists will make far more than that.
>
> > Baloney. You have no idea how much money was made on "all Lisp books
> >combined"...
>
> I'm going by the publically available statistics:
>
>  http://radar.oreilly.com/archives/2007/05/state_of_the_co_10.html

It appears that Lisp + Scheme had a total of 928 units sold in 2007.
OCaml had 38 units sold in 2007. So, I think the "baloney" charge will
stick, but it's much worse than I thought - thanks for the link!

Haskell blew your doors off which is not surprising.
From: Raffael Cavallaro
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <2007100801293950073-raffaelcavallaro@pasdespamsilvousplaitmaccom>
On 2007-10-07 21:12:58 -0400, Brian Adkins <···········@gmail.com> said:

> It appears that Lisp + Scheme had a total of 928 units sold in 2007.
> OCaml had 38 units sold in 2007. So, I think the "baloney" charge will
> stick, but it's much worse than I thought - thanks for the link!

Did you notice that the donut dromedary is listed in the category 
called 'Irrelevant'

Ouch! Mr. Toad must be smarting from that.
From: Jon Harrop
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <13gkfdgscj8u814@corp.supernews.com>
Raffael Cavallaro wrote:
> Ouch! Mr. Toad must be smarting from that.

Already answered in an old blog post:

  http://ocamlnews.blogspot.com/2007/05/ocaml-revolution.html

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
From: Ken Tilton
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <BwnOi.1$S67.0@newsfe12.lga>
Brian Adkins wrote:
> On Oct 7, 2:15 am, Jon Harrop <····@ffconsultancy.com> wrote:
> 
>>Brian Adkins wrote:
>>
>>>On Oct 6, 7:08 pm, Jon Harrop <····@ffconsultancy.com> wrote:
>>>
>>>>OCaml for Scientists makes more money than all Lisp bookscombinedand F#
>>>>for Scientists will make far more than that.
>>
>>>Baloney. You have no idea how much money was made on "all Lisp books
>>>combined"...
>>
>>I'm going by the publically available statistics:
>>
>> http://radar.oreilly.com/archives/2007/05/state_of_the_co_10.html
> 
> 
> It appears that Lisp + Scheme had a total of 928 units sold in 2007.
> OCaml had 38 units sold in 2007. So, I think the "baloney" charge will
> stick, but it's much worse than I thought

Nonsense. Ocaml is listed under "Irrelevant Languages"*, not cold cuts.

Meanwhile, a dynamic dagger between the third and fourth ribs of static 
languages: "The noticeable trend with the mid-minor languages is that 
Groovy came from nowhere and has now sold 1500 copies in the first 
quarter of 2007. "

Groovy being Java's attempt to become Python.

 > - thanks for the link!

Indeed. I think Jon's motto is "The best defense is to shoot yourself in 
the head so the other guy has nothing left to shoot." Kinda long for a 
motto, he needs to work on that.

kenny

* I did not make that up.

-- 
http://www.theoryyalgebra.com/

"We are what we pretend to be." -Kurt Vonnegut
From: Jon Harrop
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <13gjhcgi3ocj2ad@corp.supernews.com>
Brian Adkins wrote:
> On Oct 7, 2:15 am, Jon Harrop <····@ffconsultancy.com> wrote:
>> I'm going by the publically available statistics:
>>
>>  http://radar.oreilly.com/archives/2007/05/state_of_the_co_10.html
> 
> It appears that Lisp + Scheme had a total of 928 units sold in 2007.
> OCaml had 38 units sold in 2007. So, I think the "baloney" charge will
> stick, but it's much worse than I thought - thanks for the link!
> 
> Haskell blew your doors off which is not surprising.

Haskell is also a long way behind OCaml for Scientists (which isn't listed,
of course).

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
From: Raffael Cavallaro
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <200710062046387987-raffaelcavallaro@pasdespamsilvousplaitmaccom>
On 2007-10-06 19:08:59 -0400, der fliengede Frosch schrieb:

>> 
>> My claim is that JavaScript is not the sort of pure functional,
>> statically typed language *you are advocating* - JavaScript does *not*
>> have *ml style pattern matching.
> 
> Then you meant "ML" and not "functional language".

*I* meant? *You* started this whole discussion, and *you* defined the 
terms: languages that use *ml style pattern matching. What you've been 
calling "modern functional programming languages."

JavaScript has first class functions but it:

1. Does *not* have *ml style pattern matching. It only has perl style regexes.

2. Is not even vaguely pure funtional. It does not eschew side effects 
and mutation of state.

3. Is neither strongly, nor statically typed.

In other words, it's everything that lisp is, and everything that 
circle-chameau is not. How could any sane person interpret the 
popularity of JavaScript as an indication of the user base of *ml style 
pattern matching?
From: Jon Harrop
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <13ggupg1po8o8bd@corp.supernews.com>
Raffael Cavallaro wrote:
> On 2007-10-06 19:08:59 -0400, der fliengede Frosch schrieb:
>> Then you meant "ML" and not "functional language".
> 
> *I* meant? *You* started this whole discussion, and *you* defined the
> terms...

You said "many more people use common lisp than all the functional 
languages *combined*".

> JavaScript has first class functions but it:
> 
> 1. Does *not* have *ml style pattern matching. It only has perl style
> regexes.

Yes.

> 2. Is not even vaguely pure funtional. It does not eschew side effects
> and mutation of state.

Indeed, none of these languages are pure.

> 3. Is neither strongly, nor statically typed.

Apparently so. It is, however, a far more popular functional language than
Lisp. So are the MLs, of course, but JavaScript is utterly clearcut.

> In other words, it's everything that lisp is, and everything that
> circle-chameau is not. How could any sane person interpret the
> popularity of JavaScript as an indication of the user base of *ml style
> pattern matching?

You digressed onto c.l.functional but seem to have come full circle. I don't
understand what it is about the statement you made that you would like to
change. Can you clarify?

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
From: Raffael Cavallaro
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <2007100713230616807-raffaelcavallaro@pasdespamsilvousplaitmaccom>
On 2007-10-07 02:13:33 -0400, the meandering mudpuppy said:

> You said "many more people use common lisp than all the functional
> languages *combined*".

If simply having first class functions made a language "functional," 
then Common Lisp would be a functional language, and it would make no 
sense to compare common lisp on the one hand, and functional languages 
on the other. This distinction is why we have c.l.l on the one hand, 
and c.l.f on the other.

We are clearly distinguishing between impure, dynamic, multi-paradigm 
languages like common lisp (and JavaScript, btw) on the one hand, and 
pure functional, statically type checked and - most importantly for 
this discussion - *ml style pattern matching languages on the other.


JavaScript does not use *ml style pattern matching. Therefore their 
user base is in no way accustomed to your fantasy 'standard.' A 
JavaScript programmer who begins using Common Lisp would in no way be 
put off by the fact that cl-unification doesn't work like *ml style 
patern matching, because JavaScript programmers have no fsking idea 
what *ml style pattern matching is. Some 'standard'
From: Jon Harrop
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <13gif858j6h6e6a@corp.supernews.com>
Raffael Cavallaro wrote:
> On 2007-10-07 02:13:33 -0400, the meandering mudpuppy said:
>> You said "many more people use common lisp than all the functional
>> languages *combined*".
> 
> If simply having first class functions made a language "functional,"

Having first-class lexical closures does make a functional language.

> then Common Lisp would be a functional language,

Common Lisp is a functional language.

> and it would make no 
> sense to compare common lisp on the one hand, and functional languages
> on the other.

Which is exactly what you did.

> This distinction is why we have c.l.l on the one hand,
> and c.l.f on the other. 

Many functional languages have their own newsgroups, not just Lisp.

> JavaScript does not use *ml style pattern matching.

Correct.

> Therefore their user base is in no way accustomed to your
> fantasy 'standard.' 

Irrelevant. You only said "functional language" and JavaScript is a
functional language.

> A 
> JavaScript programmer who begins using Common Lisp would in no way be
> put off by the fact that cl-unification doesn't work like *ml style
> patern matching, because JavaScript programmers have no fsking idea
> what *ml style pattern matching is. Some 'standard'

Again, this has nothing to do with anything that I wrote. You are just
arguing with yourself.

The facts are:

. JavaScript is more popular than Lisp.

. ML-style pattern matching is more popular than Common Lisp.

. ML-style static typing is more popular than Common Lisp.

. Haskell, OCaml and Common Lisp are roughly as popular as each other but
Scala and F# will overtake them all in no time.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
From: Don Geddis
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <87bqbabjzk.fsf@geddis.org>
Jon Harrop <···@ffconsultancy.com> wrote on Sun, 07 Oct 2007:
> . ML-style pattern matching is more popular than Common Lisp.
> . ML-style static typing is more popular than Common Lisp.
> . Haskell, OCaml and Common Lisp are roughly as popular as each other

References please.  Nobody believes your unsupported claims.

        -- Don
_______________________________________________________________________________
Don Geddis                  http://don.geddis.org/               ···@geddis.org
If trees could scream, would we be so cavalier about cutting them down?  We
might, if they screamed all the time, for no good reason.
	-- Deep Thoughts, by Jack Handey
From: Rob St. Amant
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <febs6e$68i$1@blackhelicopter.databasix.com>
Don Geddis <···@geddis.org> writes:

> Jon Harrop <···@ffconsultancy.com> wrote on Sun, 07 Oct 2007:
>> . ML-style pattern matching is more popular than Common Lisp.
>> . ML-style static typing is more popular than Common Lisp.
>> . Haskell, OCaml and Common Lisp are roughly as popular as each other
>
> References please.  Nobody believes your unsupported claims.

I don't know if this has been posted before, but for what it's worth:

http://www.tiobe.com/tpci.htm

   The TIOBE Programming Community index gives an indication of the
   popularity of programming languages. The index is updated once a
   month. The ratings are based on the world-wide availability of
   skilled engineers, courses and third party vendors. The popular
   search engines Google, MSN, and Yahoo! are used to calculate the
   ratings. Observe that the TIOBE index is not about the best
   programming language or the language in which most lines of code
   have been written.

There's table of the top fifty.
From: Don Geddis
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <871wc6w7pa.fsf@geddis.org>
·······@ncsu.edu (Rob St. Amant) wrote on Sun, 07 Oct 2007:
> Don Geddis <···@geddis.org> writes:
>> Jon Harrop <···@ffconsultancy.com> wrote on Sun, 07 Oct 2007:
>>> . ML-style pattern matching is more popular than Common Lisp.
>>> . ML-style static typing is more popular than Common Lisp.
>>> . Haskell, OCaml and Common Lisp are roughly as popular as each other
>>
>> References please.  Nobody believes your unsupported claims.
>
> I don't know if this has been posted before, but for what it's worth:
> http://www.tiobe.com/tpci.htm

Excellent, thanks.  I see that the real data in no way supports the frog's
claims, and in fact directly contradicts them.

Lisp is in the top 20 languages.  I also noticed that Lua, a DYNAMICALLY
TYPED language that I've never heard of, seems to have come out of nowhere in
the last six months and made it to #17.

Meanwhile, the highest ranked language in the swamp seems to be Haskell,
in the mid 30's.  Then you have to plunge a bit to get to ML, and the
Irish Dromedary barely cracks the top 50.  The Musical Note language is
lucky to make the top 100.

So, as usual, any objective claim spewing from the swamp, when actually
fact-checked, is seen to be simply false.

The reference was much appreciated.

        -- Don
_______________________________________________________________________________
Don Geddis                  http://don.geddis.org/               ···@geddis.org
A great many people think they are thinking when they are merely rearranging
their prejudices.  -- William James
From: Ken Tilton
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <PCnOi.2$S67.0@newsfe12.lga>
Don Geddis wrote:
> So, as usual, any objective claim spewing from the swamp, when actually
> fact-checked, is seen to be simply false.

Yeah, I had not followed froggy very closely until lately, and it is a 
little disappointing to see how little is there, I was expecting more 
given all the attention. I predict the last hound in the cll kennel will 
weary of this chew toy by Halloween.

kenny

-- 
http://www.theoryyalgebra.com/

"We are what we pretend to be." -Kurt Vonnegut
From: namekuseijin
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <1191834525.025016.109970@v3g2000hsg.googlegroups.com>
On Oct 8, 1:28 am, Don Geddis <····@geddis.org> wrote:
> Lisp is in the top 20 languages.  I also noticed that Lua, a DYNAMICALLY
> TYPED language that I've never heard of, seems to have come out of nowhere in
> the last six months and made it to #17.

Lua is behind the scripting engines of some well-known commercial
games and applications today.
BTW, the brazilian teacher who developed Lua is also behind the
revitalization of Computer Science curriculum at the University he
works at by introducing Scheme as the primary language. :)

> Meanwhile, the highest ranked language in the swamp seems to be Haskell,
> in the mid 30's.  Then you have to plunge a bit to get to ML, and the
> Irish Dromedary barely cracks the top 50.  The Musical Note language is
> lucky to make the top 100.

yes, the editor calls them "Irrelevant Programming Languages".  Among
them is C, Fortran, Ada and Delphi.  I believe it's in good company.

But really, statistics like these lead nowhere.  Delphi and OCaml,
being European IP, suffer from Not-Invented-Here syndrome in the USA.
Besides, OCaml is open-source and, like C, has plenty of good reading
material available online, including the manual.

And newsgroups activity should really be an useful measure?  Most
newsgroups readers are old timers who seem to have missed the web
train and webforums and blogs.  If nothing, it measures the age of
posters and in this case, the language they're commited to. And the
geekiness factor, sure...
From: Jon Harrop
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <13gkgnihhjg151a@corp.supernews.com>
namekuseijin wrote:
> And newsgroups activity should really be an useful measure?

They do not even vaguely correlate with book sales. However, as you say many
people learn from on-line resources so even book sales may be irrelevant.
Finally, I'm not even sure what we want to measure. For example, should the
enormous amount of legacy Lisp code offset the massive current use of OCaml
in industry?

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
From: Raffael Cavallaro
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <2007100717292750073-raffaelcavallaro@pasdespamsilvousplaitmaccom>
On 2007-10-07 16:00:38 -0400, the whizzing web-foot said:

> Having first-class lexical closures does make a functional language.

From the definition in the wikipedia article on functional programming:

"Functional programming is a programming
paradigm that treats computation as the
evaluation of mathematical functions and
avoids state and mutable data."
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
(emphasis added)

JavaSript avoids neither state nor mutable data so is not a language 
for functional programming. Javascript, like lisp, has first class 
functions, but languages with first class functions *and* mutable state 
are neither functional nor imperative. They are multi-paradigm.

Neither JavaScripters nor Common Lispers limit themselves to the narrow 
functional paradigm. Neither JavaScript nor Common Lisp is a functional 
language like *ml or Haskell are.

And, lest we forget what brought us here, JavaScript does not use *ml 
style pattern matching. So JavaScripters will not care in the slightest 
that cl-unifcation does pattern matching differently than *ml.
From: Jon Harrop
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <13gim40gsv8cq87@corp.supernews.com>
Raffael Cavallaro wrote:
> On 2007-10-07 16:00:38 -0400, the whizzing web-foot said:
>> Having first-class lexical closures does make a functional language.
> 
> From the definition in the wikipedia article on functional programming:
>
> "Functional programming is a programming
> paradigm that treats computation as the
> evaluation of mathematical functions and
> avoids state and mutable data."
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> (emphasis added)

In the Haskell community, that is a definition of "functional programming".
However, many other communities and far more people refer to that
as "purely functional programming", including the Lisp and ML communities.

> JavaSript avoids neither state nor mutable data so is not a language
> for functional programming. Javascript, like lisp, has first class
> functions, but languages with first class functions *and* mutable state
> are neither functional nor imperative. They are multi-paradigm.

That is not the conventional meaning.

Standard ML provides only functional and imperative programming but I would
not call it multi-paradigm. I would call Lisp, OCaml, F# and Scala
multi-paradigm because they provide both functional and object-oriented
programming, for example.

> Neither JavaScripters nor Common Lispers limit themselves to the narrow
> functional paradigm.

I think you are referring to "purely functional paradigm", i.e. stateless.

> Neither JavaScript nor Common Lisp is a functional language like *ml or
> Haskell are. 

I think you have misunderstood what ML is. All MLs provide both first-class
lexical closures and mutable variables, just as Lisp and JavaScript do.
Consequently, Lisp and ML are both families of impure functional
programming languages. Many dialects from these languages are
multi-paradigm, such as Common Lisp and OCaml.

Although there are some fundamental differences between Common Lisp and
OCaml, you are describing the similarities and not the differences.

> And, lest we forget what brought us here, JavaScript does not use *ml
> style pattern matching.

Yes. My statement that JavaScript is far more popular than Lisp had nothing
to do with ML-style pattern matching.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
From: Raffael Cavallaro
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <2007100720355316807-raffaelcavallaro@pasdespamsilvousplaitmaccom>
On 2007-10-07 17:57:54 -0400, tumbling toad said:

> I think you have misunderstood what ML is. All MLs provide both first-class
> lexical closures and mutable variables, just as Lisp and JavaScript do.
> Consequently, Lisp and ML are both families of impure functional
> programming languages.

The whole point of functional programming is to be able to reason about 
the parts of a program separately, in the same way that we can reason 
about separate mathematical functions separately.

When you have mutable data in a *dynamic* language you can no longer do 
this - any function, anywhere in the program, can mutate not just the 
value of a datum, but it's *type* as well. Thus you can't reason about 
the parts of a program separately - you must do *whole program* 
analysis which completely defeats the purpose of functional programming.

Both JavaScript and Lisp are *dynamic* in this sense, so unless you 
restrict yourself to a subset of the language, neither JavaScript nor 
Common Lisp is a functional language.

And before you go off on another rant, the reason such dynamism is 
desirable to lispers, even though it defeats the purpose of functional 
programming, is that it allows the programmer to change 
representational types in a *running* program as it is being developed, 
without having to:

1. kill the program,
2. recompile it,
3. restart it, and
4. recreate the relevant program state

just in order to see the changes. It also allows a programmer to run an 
incomplete, inconsistent, or incorrect program for debugging purposes.

In *ml each datum is constrained at compile time to be of a particular 
*type* for the duration of the program, even if it's *value* changes. 
This allows both programmers and the compiler to do effective reasoning 
(in particualr, type inference) about separate parts of the program 
separately; this is why *ml *are* functional languages. You can still 
do useful reasoning about separate parts of the program separately, 
even in the face of mutable data.

This is the trade off that you've been ignoring for months now. You 
have chosen the ability to reason effectively about separate parts of 
the program, even in the face of mutable data *values*. We have chosen 
the ability to change representational types in a running program 
without restarting the program, the ability to run incomplete, 
inconsistent, or incorrect programs, etc.

We have diferent preferences, that is all. Attempting to argue that 
your preference is *objectively* superior just betrays your lack of 
social skills - your inability to understand that others have different 
minds than you, and different preferences. Choosing something you would 
not choose is *not* an indicator of some logical failing, merely 
different preferences in this trade off.
From: Jon Harrop
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <13gjipnmt58vfae@corp.supernews.com>
Raffael Cavallaro wrote:
> In *ml each datum is constrained at compile time to be of a particular
> *type* for the duration of the program, even if it's *value* changes.
> This allows both programmers and the compiler to do effective reasoning
> (in particualr, type inference) about separate parts of the program
> separately; this is why *ml *are* functional languages. You can still
> do useful reasoning about separate parts of the program separately,
> even in the face of mutable data.
> 
> This is the trade off that you've been ignoring for months now.

No, that trade-off does not exist. You're using the notions of static and
dynamic "type" interchangeably when they are completely different concepts.
A type in these static languages is simply a constraint narrowing down the
set of possible values. You just remove all such constraints to get dynamic
typing.

However, this has absolutely nothing to do with functional programming,
which is a totally orthogonal concept. If you remove the static type
checker from an interpreter, the language does not cease to be functional.

From your statements, you believe there are no dynamically typed functional
programming languages when, in fact, there are many. There is a venerable
zoo of languages out there and I really cannot emphasize enough how much
more productive it would be if you learned about them before settling on a
preference. Even if you are starting off wrong-footed because of a Lisp
background, there is an enormous amount of fascinating information out
there to learn.

> We have diferent preferences, that is all. Attempting to argue that
> your preference is *objectively* superior just betrays your lack of
> social skills - your inability to understand that others have different
> minds than you, and different preferences. Choosing something you would
> not choose is *not* an indicator of some logical failing, merely
> different preferences in this trade off.

Stating that you do not want something that you have no experience of is a
logical failing though. Indeed, it underpins the religious faith that keeps
you here.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
From: Rainer Joswig
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <joswig-9F9929.10381708102007@news-europe.giganews.com>
In article <···············@corp.supernews.com>,
 Jon Harrop <···@ffconsultancy.com> wrote:

> Raffael Cavallaro wrote:
> > In *ml each datum is constrained at compile time to be of a particular
> > *type* for the duration of the program, even if it's *value* changes.
> > This allows both programmers and the compiler to do effective reasoning
> > (in particualr, type inference) about separate parts of the program
> > separately; this is why *ml *are* functional languages. You can still
> > do useful reasoning about separate parts of the program separately,
> > even in the face of mutable data.
> > 
> > This is the trade off that you've been ignoring for months now.
> 
> No, that trade-off does not exist. You're using the notions of static and
> dynamic "type" interchangeably when they are completely different concepts.
> A type in these static languages is simply a constraint narrowing down the
> set of possible values. You just remove all such constraints to get dynamic
> typing.

Yep, we want less constraints.

> From your statements, you believe there are no dynamically typed functional
> programming languages when,

Right, there are many dynamically typed functional languages.

> in fact, there are many. There is a venerable
> zoo of languages out there and I really cannot emphasize enough how much
> more productive it would be if you learned about them before settling on a
> preference. Even if you are starting off wrong-footed because of a Lisp
> background, there is an enormous amount of fascinating information out
> there to learn.

Yes, there is an enormous amount of fascination information
about to learn about dynamically typed functional languages.

Start learning now!

Btw., there is a great Lisp tutorial written by Peter Seibel:
Practical Common Lisp. Order now! You can also read
it online:

  http://www.gigamonkeys.com/book/

> 
> > We have diferent preferences, that is all. Attempting to argue that
> > your preference is *objectively* superior just betrays your lack of
> > social skills - your inability to understand that others have different
> > minds than you, and different preferences. Choosing something you would
> > not choose is *not* an indicator of some logical failing, merely
> > different preferences in this trade off.
> 
> Stating that you do not want something that you have no experience of is a
> logical failing though. Indeed, it underpins the religious faith that keeps
> you here.

Right, you have no experience with and no knowledge about Lisp,
still you come here. How strange.

-- 
http://lispm.dyndns.org
From: Jon Harrop
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <13gkgbljt98oo18@corp.supernews.com>
Rainer Joswig wrote:
> In article <···············@corp.supernews.com>,
>  Jon Harrop <···@ffconsultancy.com> wrote:
>> No, that trade-off does not exist. You're using the notions of static and
>> dynamic "type" interchangeably when they are completely different
>> concepts. A type in these static languages is simply a constraint
>> narrowing down the set of possible values. You just remove all such
>> constraints to get dynamic typing.
> 
> Yep, we want less constraints.

I thought you wanted the freedom to choose. If you want fewer constraints
then use an untyped language rather than a dynamically typed language. They
don't even have pesky run-time type checks. Presumably that makes assembler
an even better language than Lisp by your logic...

>> From your statements, you believe there are no dynamically typed
>> functional programming languages when,
> 
> Right, there are many dynamically typed functional languages.

Correct!

>> in fact, there are many. There is a venerable
>> zoo of languages out there and I really cannot emphasize enough how much
>> more productive it would be if you learned about them before settling on
>> a preference. Even if you are starting off wrong-footed because of a Lisp
>> background, there is an enormous amount of fascinating information out
>> there to learn.
> 
> Yes, there is an enormous amount of fascination information
> about to learn about dynamically typed functional languages.
> 
> Start learning now!
> 
> Btw., there is a great Lisp tutorial written by Peter Seibel:
> Practical Common Lisp. Order now! You can also read
> it online:
> 
>   http://www.gigamonkeys.com/book/

I already read it. A fine book for its domain. I would only recommend it to
anyone who is already familiar with modern static type systems, otherwise
they'll start off in the wrong direction and may never catch up again.

>> Stating that you do not want something that you have no experience of is
>> a logical failing though. Indeed, it underpins the religious faith that
>> keeps you here.
> 
> Right, you have no experience with and no knowledge about Lisp...

Ad hominem. You'll have to learn about ML-style pattern matching if you want
to construct justifiable arguments against it. Of course, if you study it
you'll probably never post here again...

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
From: Rainer Joswig
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <joswig-8942B1.17514008102007@news-europe.giganews.com>
In article <···············@corp.supernews.com>,
 Jon Harrop <···@ffconsultancy.com> wrote:

> Rainer Joswig wrote:
> > In article <···············@corp.supernews.com>,
> >  Jon Harrop <···@ffconsultancy.com> wrote:
> >> No, that trade-off does not exist. You're using the notions of static and
> >> dynamic "type" interchangeably when they are completely different
> >> concepts. A type in these static languages is simply a constraint
> >> narrowing down the set of possible values. You just remove all such
> >> constraints to get dynamic typing.
> > 
> > Yep, we want less constraints.
> 
> I thought you wanted the freedom to choose. If you want fewer constraints
> then use an untyped language rather than a dynamically typed language. They
> don't even have pesky run-time type checks. Presumably that makes assembler
> an even better language than Lisp by your logic...

Come on, that's frogshit.

> 
> >> From your statements, you believe there are no dynamically typed
> >> functional programming languages when,
> > 
> > Right, there are many dynamically typed functional languages.
> 
> Correct!
> 
> >> in fact, there are many. There is a venerable
> >> zoo of languages out there and I really cannot emphasize enough how much
> >> more productive it would be if you learned about them before settling on
> >> a preference. Even if you are starting off wrong-footed because of a Lisp
> >> background, there is an enormous amount of fascinating information out
> >> there to learn.
> > 
> > Yes, there is an enormous amount of fascination information
> > about to learn about dynamically typed functional languages.
> > 
> > Start learning now!
> > 
> > Btw., there is a great Lisp tutorial written by Peter Seibel:
> > Practical Common Lisp. Order now! You can also read
> > it online:
> > 
> >   http://www.gigamonkeys.com/book/
> 
> I already read it. A fine book for its domain. I would only recommend it to
> anyone who is already familiar with modern static type systems, otherwise
> they'll start off in the wrong direction and may never catch up again.

More frogshit.

> 
> >> Stating that you do not want something that you have no experience of is
> >> a logical failing though. Indeed, it underpins the religious faith that
> >> keeps you here.
> > 
> > Right, you have no experience with and no knowledge about Lisp...
> 
> Ad hominem.

You have no first hand knowledge about Lisp programming, isn't that true?

> You'll have to learn about ML-style pattern matching if you want
> to construct justifiable arguments against it. Of course, if you study it
> you'll probably never post here again...

That's what we all hope for you.

-- 
http://lispm.dyndns.org
From: Jon Harrop
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <13gm0bomsd41t9f@corp.supernews.com>
Rainer Joswig wrote:
>> >> Stating that you do not want something that you have no experience of
>> >> is a logical failing though. Indeed, it underpins the religious faith
>> >> that keeps you here.
>> > 
>> > Right, you have no experience with and no knowledge about Lisp...
>> 
>> Ad hominem.
> 
> You have no first hand knowledge about Lisp programming, isn't that true?

Look at the benchmarks we've discussed here. I wrote Lisp implementations of
all of them. None of mine ever prevailed but, then, neither did yours. :-)

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
From: Rainer Joswig
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <joswig-CE9D49.06440409102007@news-europe.giganews.com>
In article <···············@corp.supernews.com>,
 Jon Harrop <···@ffconsultancy.com> wrote:

> Rainer Joswig wrote:
> >> >> Stating that you do not want something that you have no experience of
> >> >> is a logical failing though. Indeed, it underpins the religious faith
> >> >> that keeps you here.
> >> > 
> >> > Right, you have no experience with and no knowledge about Lisp...
> >> 
> >> Ad hominem.
> > 
> > You have no first hand knowledge about Lisp programming, isn't that true?
> 
> Look at the benchmarks we've discussed here. I wrote Lisp implementations of
> all of them. None of mine ever prevailed but, then, neither did yours. :-)

Which Lisp code was written by you?
From: Raffael Cavallaro
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <2007100816574543658-raffaelcavallaro@pasdespamsilvousplaitmaccom>
On 2007-10-08 02:07:24 -0400, plummeting pond-hopper said:

> However, this has absolutely nothing to do with functional programming,
> which is a totally orthogonal concept.

You fail to see how different concepts interact. Functional programming:

"treats computation as the evaluation of mathematical functions and 
avoids state and mutable data."

You cannot treat computation as the evaluation of mathematical 
functions if the data that these functions operate on can have both 
their value and their type modified by other parts of the program 
behind their back, as it were.

This is *why* functional programming "avoids state and mutable data." 
It isn't just a fetish you know. There's a reason for it. Allowing it 
prevents functional programming.

Common Lisp has first class functions. It also has dynamic typing, 
*and* mutation. If you avail yourself of dynamic typing and mutation 
Common Lisp ceases to be functional.

That is why Common Lisp is a *multi-paradigm* language. You can have 
*portions* of your program which you keep functional by observing the 
discipline of not mutating data, but other portions where you do not 
observe this discipline will *not* be functional.


> If you remove the static type
> checker from an interpreter, the language does not cease to be functional.

You have it backwards - it's not the type checker that's at issue, it's 
the *mutation of data types*. If you allow mutation of *types*, then 
you can't have functional programming because you cannot treat 
computation as if it were the evaluation of separate mathematical 
functions - some other part of the program could change the type of a 
datum behind your back.

(Naturally, if you allow the mutation of data *types* at runtime, you 
can't have a static type checker either.)

> 
> From your statements, you believe there are no dynamically typed functional
> programming languages when, in fact, there are many.

to the extent that such languages allow the mutation of data type and 
value, they are not functional. Such languages can be *used* 
functionally, but only by restricting yourself to a limited subset of 
the language. This makes these languages multi-paradigm.

Note that in *ml even with mutable data *values* the compiler can still 
be sure that the data a function operates on can ever have it's type 
changed behind the compiler's back.

> I really cannot emphasize enough how much
> more productive it would be if you learned about them before settling on a
> preference. Even if you are starting off wrong-footed because of a Lisp
> background, there is an enormous amount of fascinating information out
> there to learn.

You make the mistake of believing that I have no experience of other 
such languages. Frankly this last bit is just condescending.
From: Ken Tilton
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <kwxOi.85$UF3.3@newsfe12.lga>
Raffael Cavallaro wrote:
> On 2007-10-08 02:07:24 -0400, plummeting pond-hopper said:
> 
>> However, this has absolutely nothing to do with functional programming,
>> which is a totally orthogonal concept.
> 
> 
> You fail to see how different concepts interact.

Tim, can the transporter handle three?

kenny

-- 
http://www.theoryyalgebra.com/

"We are what we pretend to be." -Kurt Vonnegut
From: Raffael Cavallaro
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <2007100901295011272-raffaelcavallaro@pasdespamsilvousplaitmaccom>
On 2007-10-09 00:08:00 -0400, anti-gravity amphibian said:

> If you have experience of ML then you should be able to classify it
> correctly.

It is a functional language. Any language that allows you to defeat 
functional programming by mutating data in such a way that the same 
function, when called with the exact same inputs can return different 
*types* of values - a string one time, a float another - at different 
invocations is no longer functional. functions return the same unique 
value for the same inputs. Allowing mutation of data values defeats 
this partially, but you can still reason about type. Allowing data 
types to change defeats it utterly.


>> Note that in *ml even with mutable data *values* the compiler can still
>> be sure that the data a function operates on can ever have it's type
                                                  ^^^^^^^
                just to clarify this is a typo of "never"

>> changed behind the compiler's back.
From: Jon Harrop
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <13gmgq4qt8jboc6@corp.supernews.com>
Raffael Cavallaro wrote:
> On 2007-10-09 00:08:00 -0400, anti-gravity amphibian said:
>> If you have experience of ML then you should be able to classify it
>> correctly.
> 
> It is a functional language. Any language that allows you to defeat
> functional programming by mutating data...

Using mutation does not defeat functional programming. Lisp showed that
before ML did.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
From: Tim X
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <871wc4sc2o.fsf@lion.rapttech.com.au>
Raffael Cavallaro <················@pas-d'espam-s'il-vous-plait-mac.com>
writes:

> On 2007-10-08 02:07:24 -0400, plummeting pond-hopper said:
>
>> I really cannot emphasize enough how much
>> more productive it would be if you learned about them before settling on a
>> preference. Even if you are starting off wrong-footed because of a Lisp
>> background, there is an enormous amount of fascinating information out
>> there to learn.
>
> You make the mistake of believing that I have no experience of other such
> languages. Frankly this last bit is just condescending.
>

I would hav said it was both arrogant and pompous. Reminds me of fanatic
religious missionaries attempting to save the poor savage from their
ignorance of the 'One true god'. 

I suggest we treat him like many of the early missionaries who visited some
pacific islands. 

Let me know if you would prefer vegetables or salad with your zelot.

Anyone want a frogs leg?


-- 
tcross (at) rapttech dot com dot au
From: Raffael Cavallaro
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <2007100911450127544-raffaelcavallaro@pasdespamsilvousplaitmaccom>
On 2007-10-09 08:32:31 -0400, Tim X <····@nospam.dev.null> said:

> I suggest we treat him like many of the early missionaries who visited some
> pacific islands.
> 
> Let me know if you would prefer vegetables or salad with your zelot.
> 
> Anyone want a frogs leg?

Something tells me this particular pond dweller would not be good eating ;^)
From: Klaus Schilling
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <87tzp09hag.fsf@web.de>
Jon Harrop <···@ffconsultancy.com> writes:
>
> Having first-class lexical closures does make a functional language.

Python, Perl, Lua, Ruby have those too

>
> Many functional languages have their own newsgroups, not just Lisp.
>

Not every Lisp has lexical closures.
McCarthy's original Lisp, Emacs Lisp, Franz Lisp bind free variables
to their calling environment.

>
> . JavaScript is more popular than Lisp.
>
among webspamming pervies


that's because human culture is perverse and corrupt from the get on.
Lisp is of divine origin, thus shouldn't adopt to human weaknesses 
and perversions.

       Klaus Schilling
From: Raffael Cavallaro
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <200710131027318930-raffaelcavallaro@pasdespamsilvousplaitmaccom>
On 2007-10-13 07:30:10 -0400, Klaus Schilling <···············@web.de> said:

> Lisp is of divine origin, thus shouldn't adopt to human weaknesses
> and perversions.

I hear that Will Clinger has a scheme implementation that will maintain 
the Purity of Essence of ones precious bodily fluids. ;^)
From: Kent M Pitman
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <uk5pqamja.fsf@nhplace.com>
Raffael Cavallaro <················@pas-d'espam-s'il-vous-plait-mac.com> writes:

> On 2007-10-13 07:30:10 -0400, Klaus Schilling <···············@web.de> said:
> 
> > Lisp is of divine origin, thus shouldn't adopt to human weaknesses
> > and perversions.
> 
> I hear that Will Clinger has a scheme implementation that will
> maintain the Purity of Essence of ones precious bodily fluids. ;^)

Suddenly the drive for "purity of essence" exhibited in the "OPEn source"
movement and everyone's sense that it is sheer POEtry seems more 
intelligible to me.  (I wonder if it's where Mandrake Linux got its name...)

(PROBABLY not related to any specific agenda of Will's ... unless maybe it
 affects feelings he has about fluid variables in some way)
From: Raffael Cavallaro
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <2007101402273527544-raffaelcavallaro@pasdespamsilvousplaitmaccom>
On 2007-10-13 14:37:29 -0400, Kent M Pitman <······@nhplace.com> said:

> PROBABLY not related to any specific agenda of Will's ... unless maybe it
>  affects feelings he has about fluid variables in some way

I think he just likes Dr. Strangelove, or as he once put it (searches 
google groups...)

"I certainly consider plausible lists to have been
a joke.  Unlike Aziz, I thought they were funny,
in the sad, pathetic, twisted way I enjoy so much."
From: Jon Harrop
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <13h1lr07el0sqce@corp.supernews.com>
Klaus Schilling wrote:
> Jon Harrop <···@ffconsultancy.com> writes:
>>
>> Having first-class lexical closures does make a functional language.
> 
> Python, Perl, Lua, Ruby have those too

Are you sure Python does?

>> Many functional languages have their own newsgroups, not just Lisp.
>>
> 
> Not every Lisp has lexical closures.
> McCarthy's original Lisp, Emacs Lisp, Franz Lisp bind free variables
> to their calling environment.

I didn't realise Franz's Lisp didn't...

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
From: Don Geddis
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <87d4vjko6h.fsf@geddis.org>
Jon Harrop <···@ffconsultancy.com> wrote on Sat, 13 Oct 2007:
> Klaus Schilling wrote:
>> Not every Lisp has lexical closures.  McCarthy's original Lisp, Emacs
>> Lisp, Franz Lisp bind free variables to their calling environment.
>
> I didn't realise Franz's Lisp didn't...

Franz Lisp != Franz's (Allegro Common) Lisp

_______________________________________________________________________________
Don Geddis                  http://don.geddis.org/               ···@geddis.org
There are a number of mechanical devices which increase sexual arousal,
particularly in women.  Chief among them is the Mercedes-Benz 380SL
convertible.  -- PJ O'Rourke.
From: Jon Harrop
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <13h3c6efurs5j3a@corp.supernews.com>
Don Geddis wrote:
> Jon Harrop <···@ffconsultancy.com> wrote on Sat, 13 Oct 2007:
>> I didn't realise Franz's Lisp didn't...
> 
> Franz Lisp != Franz's (Allegro Common) Lisp

Ah!

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
From: Rob Warnock
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <rIWdnQ4sjN7oTo_anZ2dnUVZ_vPinZ2d@speakeasy.net>
Klaus Schilling  <···············@web.de> wrote:
+---------------
| Lisp is of divine origin...
+---------------

Perhaps, but there are indications it *wasn't*
really used to code the Universe after all:

    http://xkcd.com/224/


-Rob

-----
Rob Warnock			<····@rpw3.org>
627 26th Avenue			<URL:http://rpw3.org/>
San Mateo, CA 94403		(650)572-2607
From: Don Geddis
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <87odfda41p.fsf@geddis.org>
Raffael Cavallaro <················@pas-d'espam-s'il-vous-plait-mac.com> wrote on Thu, 4 Oct 2007 :
> Hint to the falling fly-eater
> the irish ship of the desert does not
> like the donut dromedary.
> N.B. terms like "donut dromedary" and "falling fly-eater" are used to avoid
> feeding search engines links to him, his site, or his off topic language.

Are you kidding?  I don't care why you make up those labels.  This is
my very favorite part of the whole thread!

I couldn't help laughing every time I read your next brilliant phrasing.

I'm not even sure what your actual point was, but who cares?  Write more!
Write more!

        -- Don
_______________________________________________________________________________
Don Geddis                  http://don.geddis.org/               ···@geddis.org
Sometimes it's hard to tell if something is actually a memory, or you just
dreamed it.  So I asked my boss if I called him a lying, stinking thief, or if
I just dreamed it, and he said I just dreamed it.  Whew, that was close.
	-- Deep Thoughts, by Jack Handey [1999]
From: Damien Kick
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <13glsdcvbudkde@corp.supernews.com>
Raffael Cavallaro wrote:

> N.B. terms like "donut dromedary" and "falling fly-eater" are used to 
> avoid feeding search engines links to him, his site, or his off topic 
> language.

The anti-kibo.  Not to mention it's just plain fun.  I'm actually quite 
proud of my "Discommodiously Defenestrated Toad".
From: Raffael Cavallaro
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <2007100912052250878-raffaelcavallaro@pasdespamsilvousplaitmaccom>
On 2007-10-08 23:12:44 -0400, Damien Kick <·····@earthlink.net> said:

> I'm actually quite proud of my "Discommodiously Defenestrated Toad".

Yes, you get credit for starting the ever lengthening roll call. Let's 
list them here for easy future reference:

The man himself:

the Discommodiusly Defenstrated Toad
the airborne/anti-gravity amphibian
the tumbling toad
the careening cane-toad
the hurtling horned-toad
the plummeting pond-dweller, pond-hopper
der fliengede Frosch
the meandering mudpuppy
the whizzing web-foot
the falling fly-eater
face-plant frosch
Mr. Toad of wild-ride fame
flap-feet the frosch
frog boy
throw-away tadpole
the near-earth-orbit newt

His preferred language:

the irish ship of the desert
the donut dromedary
the circle chameau
the humped one
From: Jon Harrop
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <13gdpopfj3ch1cc@corp.supernews.com>
Don Geddis wrote:
> I'm not entirely sure of the difference between OCaml "pattern matching"
> function definitions, and Lisp CLOS generic functions ... but assuming
> there is a significant difference, I doubt this can be "easily supplied by
> specialized packages".

The difference boils down to integration into the type system that gives
ML-style pattern matching its speed and static checking. Without a static
type system, you can't even implement a basic ML-style pattern matcher.

Since Common Lisp came out, pattern matching has evolved into a construct of
unparallelled expressive power that is now ubiquitous in all modern
statically typed functional programming languages. In contrast, nobody has
ever been able to write a pattern matching library for Lisp that gained the
same traction.

For example, Haskell, OCaml and F# add or-patterns, guards, polymorphic
variants, lazy stream parsers, lazy sequences, views and so on. All of
these extra features only serve to broaden the expressive power of pattern
matching.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
From: Raffael Cavallaro
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <2007100600381737709-raffaelcavallaro@pasdespamsilvousplaitmaccom>
On 2007-10-04 16:17:53 -0400, fallling fly-eater said:

> Since Common Lisp came out, pattern matching has evolved into a construct of
> unparallelled expressive power that is now ubiquitous in all modern
> statically typed functional programming languages.

1. unparallelled only in the world of statically typed compiler 
shackles. Those free of that bondage have lots of powerfully expressive 
tools available.

2. ubiquitous? Like 8-track players are ubiquitous in 1976 Dodge Dusters?
From: Don Geddis
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <87bqbc6sdu.fsf@geddis.org>
Jon Harrop <···@ffconsultancy.com> wrote on Thu, 04 Oct 2007:
> The difference boils down to integration into the type system that gives
> ML-style pattern matching its speed and static checking. Without a static
> type system, you can't even implement a basic ML-style pattern matcher.

Your two sentences seem mutually contradictory.

If the (static) type system gives pattern matching "speed and type checking",
then surely you could implement pattern matching in a dynamic type system,
even though it might be "slow" and not provide "type checking".

So: what would it even mean, for a dynamically typed language like Common Lisp
to have "pattern matching"?  What would that look like, even in the abstract?

> Since Common Lisp came out, pattern matching has evolved into a construct
> of unparallelled expressive power that is now ubiquitous in all modern
> statically typed functional programming languages.

So what?  Common Lisp fans explicitly and consciously reject the choice to
evolve the language in the direction of static type checking.  The tradeoffs
aren't worth it.

So naturally, any feature which REQUIRES static type checking, wouldn't be of
interest.

> In contrast, nobody has ever been able to write a pattern matching library
> for Lisp that gained the same traction.

Did you not say above that "you can't even implement a basic ML-style pattern
matcher" in the absence of static type checking?  And we all know that Lisp
uses dynamic type checking.  So why would a Lisp programmer ever even try to
write such a library, if it "can't" be implemented?

So, why don't you try again.  I asked a specific question.  In Common Lisp,
a language with dynamic type checking, we already have the ability to define
functions in parts based on the types of arguments.  This is how CLOS and
generic functions work.

You have been saying that Common Lisp "lacks" pattern matching.  So please
give me a concrete example of how "pattern matching" would work in some
Lisp-like language, in a way different from how CLOS already works.  (I
suspect the answer has something to do with destructuring, much like Lisp's
DESTRUCTURING-BIND, which is available in Lisp in function bodies but not in
the argument list of a function's definition.)

If you just retreat to "well, it's not the same without static type
checking", then just admit up front that it's all the same issue.  Instead,
many times you've written that Lisp lacks BOTH static type checking AND
pattern matching, as though these were two different things, and you could
imagine having one without the other.

Looks like that might not be the case, and instead this is all just the same
old argument about static vs. dynamic type checking.

If you want static, go ahead.  We prefer dynamic.

        -- Don
_______________________________________________________________________________
Don Geddis                  http://don.geddis.org/               ···@geddis.org
Native Americans used every part of the buffalo, including the wings.
From: Jon Harrop
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <13gg7ju1rga6ua4@corp.supernews.com>
Don Geddis wrote:
> Jon Harrop <···@ffconsultancy.com> wrote on Thu, 04 Oct 2007:
>> The difference boils down to integration into the type system that gives
>> ML-style pattern matching its speed and static checking. Without a static
>> type system, you can't even implement a basic ML-style pattern matcher.
> 
> Your two sentences seem mutually contradictory.
> 
> If the (static) type system gives pattern matching "speed and type
> checking", then surely you could implement pattern matching in a dynamic
> type system, even though it might be "slow" and not provide "type
> checking".
> 
> So: what would it even mean, for a dynamically typed language like Common
> Lisp
> to have "pattern matching"?  What would that look like, even in the
> abstract?

cl-unification is the best I've seen for an implementation without variants,
static checking and performance. Without those, the whole idea is much less
useful and, consequently, cl-unification is rarely used.

>> Since Common Lisp came out, pattern matching has evolved into a construct
>> of unparallelled expressive power that is now ubiquitous in all modern
>> statically typed functional programming languages.
> 
> So what?  Common Lisp fans explicitly and consciously reject the choice to
> evolve the language in the direction of static type checking.

Except Mark Tarver, yes.

> The tradeoffs aren't worth it.

Lispers believe the trade-offs aren't worth it but try finding a Lisper who
knows about the relative merits of polymorphic variants or active patterns,
for example.

> So naturally, any feature which REQUIRES static type checking, wouldn't be
> of interest.

Saying that you don't want what you can't have is just self-reassurance, not
a logical decision.

>> In contrast, nobody has ever been able to write a pattern matching
>> library for Lisp that gained the same traction.
> 
> Did you not say above that "you can't even implement a basic ML-style
> pattern
> matcher" in the absence of static type checking?  And we all know that
> Lisp
> uses dynamic type checking.  So why would a Lisp programmer ever even try
> to write such a library, if it "can't" be implemented?

The inventors of ML wrote their first implementations in Lisp, so they would
have done exactly that. The result has been developed for 3 decades and now
looks quite different.

> So, why don't you try again.  I asked a specific question.  In Common
> Lisp, a language with dynamic type checking, we already have the ability
> to define
> functions in parts based on the types of arguments.  This is how CLOS and
> generic functions work.

Yes.

> You have been saying that Common Lisp "lacks" pattern matching.  So please
> give me a concrete example of how "pattern matching" would work in some
> Lisp-like language, in a way different from how CLOS already works.  (I
> suspect the answer has something to do with destructuring, much like
> Lisp's DESTRUCTURING-BIND, which is available in Lisp in function bodies
> but not in the argument list of a function's definition.)

Consider the symbolic derivative:

# let rec d f x = match f with
    | `Var y when x=y -> `Int 1
    | `Int _ | `Var _ -> `Int 0
    | `Add(f, g) -> `Add(d f x, d g x)
    | `Mul(f, g) -> `Add(`Mul(f, d g x), `Mul(g, d f x));;
val d :
  ([< `Add of 'a * 'a | `Int of 'b | `Mul of 'a * 'a | `Var of 'c ]
as 'a) ->
  'c -> ([> `Add of 'd * 'd | `Int of int | `Mul of 'a * 'd ] as 'd) = <fun>

The integrated static type system and pattern matcher do make this very
fast. But that is not all. The types being handled by this function are
inferred. They might be by a Lisp compiler but OCaml explicitly states its
inferred types:

[< `Add of 'a * 'a | `Int of 'b | `Mul of 'a * 'a | `Var of 'c ] as 'a

[> `Add of 'd * 'd | `Int of int | `Mul of 'a * 'd ] as 'd

This tells us than the input expression is one of at most four varieties but
it also tells us that the output can be one of at least three. One was
dropped. Inspection of the inferred type shows that the `Var constructor
cannot appear in the output. So the static type system has proven that
whatever expression is given to this function, the result will never
contain a `Var.

You can also use explicitly declared sum types:

# type expr =
    | Int of int
    | Var of string
    | Add of expr * expr
    | Mul of expr * expr;;
...
# let rec d f x = match f with
    | Var y when x=y -> Int 1
    | Int _ | Var _ -> Int 0
    | Add(f, g) -> Add(d f x, d g x)
    | Mul(f, g) -> Add(Mul(f, d g x), Mul(g, d f x));;
val d : expr -> string -> expr = <fun>

The inferred type is less interesting. However, the combination of static
typing and pattern matching is even more useful in this case because
extending the sum type to include a new construct, such as Pow, causes the
compiler to emit a warning for every incomplete pattern match. Making sure
that all functions handle all inputs:

# type expr =
    | Int of int
    | Var of string
    | Add of expr * expr
    | Mul of expr * expr
    | Pow of expr * expr;;
...
# let rec d f x = match f with
    | Var y when x=y -> Int 1
    | Int _ | Var _ -> Int 0
    | Add(f, g) -> Add(d f x, d g x)
    | Mul(f, g) -> Add(Mul(f, d g x), Mul(g, d f x));;
Warning P: this pattern-matching is not exhaustive.
Here is an example of a value that is not matched:
Pow (_, _)
val d : expr -> string -> expr = <fun>

Notice how the compiler even gives you an explicit example of the kind of
data structure that will not be handled by this function. This is
particularly useful when the overlap between patterns is non-trivial.

It also checks for redundant pattern matchers, which catches the common bug
of accidentally performing overlapping tests in the wrong order:

# let rec d f x = match f with
    | Int _ | Var _ -> Int 0
    | Var y when x=y -> Int 1
    | Add(f, g) -> Add(d f x, d g x)
    | Mul(f, g) -> Add(Mul(f, d g x), Mul(g, d f x));;
Warning P: this pattern-matching is not exhaustive.
Warning U: this match case is unused.

These are the basic ideas that make ML-style pattern matching so useful.
Haskell, OCaml, F# and Scala all implement this core functionality. Each
language also adds new and interesting features.

This is a simplified example, of course. Real code can uses pattern matches
that run for pages. Common practical examples are document munging, XML
transformations, symbolics, tree-based data structures and computer
graphics.

> If you just retreat to "well, it's not the same without static type
> checking", then just admit up front that it's all the same issue. 
> Instead, many times you've written that Lisp lacks BOTH static type
> checking AND pattern matching, as though these were two different things,
> and you could imagine having one without the other.

You can have one without the other but it is the combination that makes
ML-style pattern matching so much more powerful. For example, C# has static
typing but no pattern matching and Mathematica has pattern matching but no
static typing.

Mathematica resembles Lisp with pattern matching quite closely but the type
system cannot express closed sum types or infer sum types so the pattern
matcher cannot use that information to perform static checking.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
From: Raffael Cavallaro
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <2007100620545622503-raffaelcavallaro@pasdespamsilvousplaitmaccom>
On 2007-10-06 19:38:00 -0400, face-plant frosch, the gallumphing 
grenouille said:

> Saying that you don't want what you can't have is just self-reassurance, not
> a logical decision.

can't have? what exactly is stopping us from using *ml? (answer: 
nothing) What you consistently miss is that many of us have used *ml 
and *just don't like it very much*

Get over it. The world really, really, really does not live in your 
tiny amphibian head. People actually have different preferences than 
you. Here's the kicker - having preferences that differ from yours does 
not make someone either foolish or uniformed. It just makes them *not 
you.*
From: Jon Harrop
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <13ggv67hpuv0vc0@corp.supernews.com>
Raffael Cavallaro wrote:
> Here's the kicker - having preferences that differ from yours does
> not make someone either foolish or uniformed.

Trying to dodge the concept of a "functional language" whilst mentioning
completely irrelevant topics like c.l.f and purely functional languages
does, however, make someone uniformed.

I didn't assume that you were uninformed. I let you prove it.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
From: Raffael Cavallaro
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <2007100714061375249-raffaelcavallaro@pasdespamsilvousplaitmaccom>
On 2007-10-07 02:20:20 -0400, the careening cane toad said:

> Trying to dodge the concept of a "functional language" whilst mentioning
> completely irrelevant topics like c.l.f and purely functional languages
> does, however, make someone uniformed.


Can't have it both ways, wet one. Either *ml style pattern matching is 
standard among modern functional languages, or JavaScript isn't really 
a functional language.

Of course reasonable programmers know where the truth lies - merely 
having first class functions doesn't make it a "functional language" 
any more than having mutation makes it an "imperative language." Having 
both, like Common Lisp and JavaScript, makes it *multiparadigm*.

Being constrained or strongly encouraged by the language to use as 
purely functional a style as possible is what distinguishes what you 
have consistently called modern functional languages like *ml and 
haskell.

Most programmers (including JavaScripters) have zero experience with 
*ml style pattern matching, so the fact that common lisp pattern 
matchers work differently is zero barrier to adoption for users of 
common lisp, or to programmers coming to common lisp from other more 
mainstream languages.

Finally, on what planet is it that comp.lang.functional is irrelevant 
to the concept of a "functional language?" (Hint: that's exactly what 
comp.lang.functional is for.) The fact that c.l.f. has so little 
traffic is no surprise since sane programmers like to have more than 
one paradigmatic arrow in their language quiver.

Go preach the gospel of the humped one in the low-traffic limbo where 
you belong. If you unwisely choose to keep posting your jesuitical bs 
here we'll keep exposing you for the double talking spammer that your 
are.
From: Jon Harrop
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <13gibgudna9ch63@corp.supernews.com>
Raffael Cavallaro wrote:
> Either *ml style pattern matching is
> standard among modern functional languages, or JavaScript isn't really
> a functional language.

ML-style pattern matching is ubiquitous among modern statically-typed
functional programming languages. My reference to JavaScript had nothing to
do with that.

> Of course reasonable programmers know where the truth lies - merely
> having first class functions doesn't make it a "functional language"
> any more than having mutation makes it an "imperative language." Having
> both, like Common Lisp and JavaScript, makes it *multiparadigm*.

No, that makes them impure functional programming languages like ML. Being
multiparadigm generally means supporting at least two paradigms, like FP
and OOP. OCaml, F#, Scala and Lisp are all multiparadigm in that sense.

> Being constrained or strongly encouraged by the language to use as
> purely functional a style as possible is what distinguishes what you
> have consistently called modern functional languages like *ml and
> haskell.

Once again, ML is not a purely functional language.

> Most programmers (including JavaScripters) have zero experience with
> *ml style pattern matching, so the fact that common lisp pattern
> matchers work differently is zero barrier to adoption for users of
> common lisp, or to programmers coming to common lisp from other more
> mainstream languages.

Then why is ML-style pattern matching ubiquitous among modern
statically-typed functional programming languages but rare in Lisp?

The answer can only be that Lisp is not able to express this concept in a
useful way.

> Finally, on what planet is it that comp.lang.functional is irrelevant
> to the concept of a "functional language?"

Once again, you're arguing with yourself.

> (Hint: that's exactly what 
> comp.lang.functional is for.) The fact that c.l.f. has so little
> traffic is no surprise since sane programmers like to have more than
> one paradigmatic arrow in their language quiver.

Could you please just read the definitions of the terms you are using before
constructing any sentences using them. Multiparadigm does not mean impure.
Functional does not mean statically typed and does not mean pure.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
From: Raffael Cavallaro
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <2007100717383843658-raffaelcavallaro@pasdespamsilvousplaitmaccom>
On 2007-10-07 14:57:03 -0400, the hurtling horned-toad said:

> Then why is ML-style pattern matching ubiquitous among modern
> statically-typed functional programming languages but rare in Lisp?

Because *ml style pattern matching is not the center of the universe. 
Just because you worship it doesn't mean others think so highly of it. 
Your preference is in the minority. Get over it.

> 
> The answer can only be that Lisp is not able to express this concept in a
> useful way.

On the contrary, I find cl-unification a useful expression of pattern 
matching (and general unification). I just don't feel compelled to 
express *every* program using this sometimes useful means.

It is *you* who have limited choice. You are given one expressive tool 
and so you feel the whole world must be constrained to express their 
programs in that way. We have many expressive tools and use them all as 
we wish.
From: Jon Harrop
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <13gilbplj38b081@corp.supernews.com>
Raffael Cavallaro wrote:
> On 2007-10-07 14:57:03 -0400, the hurtling horned-toad said:
>> Then why is ML-style pattern matching ubiquitous among modern
>> statically-typed functional programming languages but rare in Lisp?
> 
> Because *ml style pattern matching is not the center of the universe.
> Just because you worship it doesn't mean others think so highly of it.
> Your preference is in the minority. Get over it.

My statements are objective.

>> The answer can only be that Lisp is not able to express this concept in a
>> useful way.
> 
> On the contrary, I find cl-unification a useful expression of pattern
> matching (and general unification). I just don't feel compelled to
> express *every* program using this sometimes useful means.
> 
> It is *you* who have limited choice. You are given one expressive tool
> and so you feel the whole world must be constrained to express their
> programs in that way. We have many expressive tools and use them all as
> we wish.

Except that the expressive tools I chose gained traction but the ones you've
restricted yourself to did not. That was my original point.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
From: Raffael Cavallaro
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <2007100720531675249-raffaelcavallaro@pasdespamsilvousplaitmaccom>
On 2007-10-07 17:44:59 -0400, flap-feet the frosch said:

>> On 2007-10-07 14:57:03 -0400, the hurtling horned-toad said:
>>> Then why is ML-style pattern matching ubiquitous among modern
>>> statically-typed functional programming languages but rare in Lisp?
>> 
>> Because *ml style pattern matching is not the center of the universe.
>> Just because you worship it doesn't mean others think so highly of it.
>> Your preference is in the minority. Get over it.
> 
> My statements are objective.

But your conclusion is not:

> 
>>> The answer can only be that Lisp is not able to express this concept in a
>>> useful way.

No, the answer can also be (and, as it happens, *actually is*) that 
Common Lisp is perfectly able to express pattern matching in a useful 
way but lispers don't feel the strong need for it that *ml users do 
because lispers have many expressive means, but pattern matching is one 
of the only espressive means available to *ml programmers.

>> 
>> On the contrary, I find cl-unification a useful expression of pattern
>> matching (and general unification). I just don't feel compelled to
>> express *every* program using this sometimes useful means.
>> 
>> It is *you* who have limited choice. You are given one expressive tool
>> and so you feel the whole world must be constrained to express their
>> programs in that way. We have many expressive tools and use them all as
>> we wish.
> 
> Except that the expressive tools I chose gained traction but the ones you've
> restricted yourself to did not. That was my original point.

Your interpretation of the fact that pattern matching is not nearly as 
popular in lisp as in *ml once again betrays your "everybody lives in 
my head" worldview. Lisp's pattern matching libraries aren't widely 
used simply because pattern matching is not the sole expressive means 
available to lispers. Consequently, we don't see it as the 'must-use' 
language tool that you do. It's just one expressive means among many.
From: Jon Harrop
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <13gjh9shshob4ac@corp.supernews.com>
Raffael Cavallaro wrote:
>> Except that the expressive tools I chose gained traction but the ones
>> you've restricted yourself to did not. That was my original point.
> 
> Your interpretation of the fact that pattern matching is not nearly as
> popular in lisp as in *ml once again betrays your "everybody lives in
> my head" worldview. Lisp's pattern matching libraries aren't widely
> used simply because pattern matching is not the sole expressive means
> available to lispers. Consequently, we don't see it as the 'must-use'
> language tool that you do. It's just one expressive means among many.

Compare the OCaml to the only Lisp that comes close in terms of performance
on this page:

  http://www.lambdassociates.org/studies/study10.htm

If Lisp programmers have no need of pattern matching because they have more
expressive constructs at their disposal, why are the Lisp implementations
so shamefully obfuscated and slow in comparison?

Note that this is not specific to OCaml. Any language with ML-style pattern
matching (SML, Haskell, F#, Scala...) can solve that problem far more
elegantly that any of the Lisp solutions. Also, this is also not a new
idea, Lisp is decades out of date with respect to trivial constructs.
Moreover, the fundamental limitations of Lisp mean that you can never catch
up.

Here, let me make the comparison explicit for you:

OCaml:

let rec ( +: ) f g = match f, g with 
   | `Int n, `Int m -> `Int (n +/ m) 
   | `Int (Int 0), e | e, `Int (Int 0) -> e 
   | f, `Add(g, h) -> f +: g +: h 
   | f, g -> `Add(f, g) 

let rec ( *: ) f g = match f, g with 
   | `Int n, `Int m -> `Int (n */ m) 
   | `Int (Int 0), e | e, `Int (Int 0) -> `Int (Int 0) 
   | `Int (Int 1), e | e, `Int (Int 1) -> e 
   | f, `Mul(g, h) -> f *: g *: h 
   | f, g -> `Mul(f, g) 

let rec simplify = function 
   | `Int _ | `Var _ as f -> f 
   | `Add (f, g) -> simplify f +: simplify g 
   | `Mul (f, g) -> simplify f *: simplify g


Lisp:

(defun simplify-no-redundant-checks (xexpr) 
     (if (atom xexpr) 
       xexpr 
       (let ((op (first xexpr)) 
             (z (second xexpr)) 
             (y (third xexpr))) 
         (let* ((f (simplify-no-redundant-checks z)) 
                (g (simplify-no-redundant-checks y)) 
                (nf (numberp f)) 
                (ng (numberp g))) 
           (tagbody 
            START 
              (if (eq '+ op) (go OPTIMIZE-PLUS) (go TEST-MULTIPLY)) 
            OPTIMIZE-PLUS 
              (when (and nf ng) (return-from simplify-no-redundant-checks (+
f g))) 
            TEST-PLUS-ZEROS 
              (when (eql f 0) (return-from simplify-no-redundant-checks g)) 
              (when (eql g 0) (return-from simplify-no-redundant-checks f)) 
              (go REARRANGE-EXPR) 
            TEST-MULTIPLY 
              (unless (eq '* op) (go REARRANGE-EXPR)) 
            OPTIMIZE-MULTIPLY 
              (when (and nf ng) (return-from simplify-no-redundant-checks (*
f g))) 
            TEST-MULTIPLY-ZEROS-AND-ONES 
              (when (or (eql f 0) (eql g 0)) (return-from
simplify-no-redundant-checks 0)) 
              (when (eql f 1) (return-from simplify-no-redundant-checks g)) 
              (when (eql g 1) (return-from simplify-no-redundant-checks f)) 
          REARRANGE-EXPR 
              (when (and (listp g) (eq op (first g))) 
                (let ((op2 (first g)) 
                      (u (second g)) 
                      (v (third g))) 
                  (declare (ignore op2)) 
                  (return-from simplify-no-redundant-checks 
                    (simplify-no-redundant-checks (list op (list op f u)
v))))) 
            MAYBE-CONS-EXPR 
              (if (and (eq f z) (eq g y)) 
                  (return-from simplify-no-redundant-checks xexpr) 
                  (return-from simplify-no-redundant-checks (list op f
g))))))))

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
From: Raffael Cavallaro
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <200710081704248930-raffaelcavallaro@pasdespamsilvousplaitmaccom>
On 2007-10-08 01:41:52 -0400, Mr. Toad of wild-ride fame said:

> Here, let me make the comparison explicit for you:
> 
> OCaml:
> 
> let rec ( +: ) f g = match f, g with
>    | `Int n, `Int m -> `Int (n +/ m)
>    | `Int (Int 0), e | e, `Int (Int 0) -> e
>    | f, `Add(g, h) -> f +: g +: h
>    | f, g -> `Add(f, g)
> 
> let rec ( *: ) f g = match f, g with
>    | `Int n, `Int m -> `Int (n */ m)
>    | `Int (Int 0), e | e, `Int (Int 0) -> `Int (Int 0)
>    | `Int (Int 1), e | e, `Int (Int 1) -> e
>    | f, `Mul(g, h) -> f *: g *: h
>    | f, g -> `Mul(f, g)
> 
> let rec simplify = function
>    | `Int _ | `Var _ as f -> f
>    | `Add (f, g) -> simplify f +: simplify g
>    | `Mul (f, g) -> simplify f *: simplify g

You want comp.lang.functional I think.
From: Rainer Joswig
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <joswig-DDAFAB.04072107102007@news-europe.giganews.com>
In article <···············@corp.supernews.com>,
 Jon Harrop <···@ffconsultancy.com> wrote:
> 
> # let rec d f x = match f with
>     | `Var y when x=y -> `Int 1
>     | `Int _ | `Var _ -> `Int 0
>     | `Add(f, g) -> `Add(d f x, d g x)
>     | `Mul(f, g) -> `Add(`Mul(f, d g x), `Mul(g, d f x));;

Kind of ironic that it is prefix notation - even an ugly version.

Let's do something more interesting: compute the
simplified derivative of a Lisp function, compile it and apply
it to some values.


Let's do some really basic Lisp:


CL-USER 1 > (defun op (expr) (first expr))
OP

CL-USER 2 > (defun arg1 (expr) (second expr))
ARG1

CL-USER 3 > (defun arg2 (expr) (third expr))
ARG2

CL-USER 4 > (defun op? (expr sym)
              (and (consp expr) (eq (op expr) sym)))
OP?

CL-USER 5 > (defun d (expr x)
              (cond ((eq x expr) 1)
                    ((symbolp expr) 0)
                    ((numberp expr) 0)
                    ((op? expr '+)
                     `(+ ,(d (arg1 expr) x)
                         ,(d (arg2 expr) x)))
                    ((op? expr '*)
                     `(+ (* ,(arg1 expr) ,(d (arg2 expr) x))
                         (* ,(third expr) ,(d (second expr) x))))))
D

CL-USER 6 > (d '(+ (* a (* x x)) (+ (* b x) c)) 'x)
(+ (+ (* A (+ (* X 1) (* X 1))) (* (* X X) 0)) (+ (+ (* B 1) (* X 0)) 0))


Wow! It took an expression in Lisp notation and returned another
one in Lisp notation.




Now let's write a simplifier:

CL-USER 7 > (defun s (expr)
              (labels ((s1 (expr)
                         (cond ((and (op? expr '+) (eql (arg1 expr) 0))
                                (arg2 expr))
                               ((and (op? expr '+) (eql (arg2 expr) 0))
                                (arg1 expr))
                               ((and (op? expr '*) (or (eql (arg1 expr) 0) (eql (arg2 expr) 0)))
                                0)
                               ((and (op? expr '*) (eql (arg1 expr) 1))
                                (arg2 expr))
                               ((and (op? expr '*) (eql (arg2 expr) 1))
                                (arg1 expr))
                               ((consp expr) `(,(op expr) ,(s1 (arg1 expr)) ,(s1 (arg2 expr))))
                               (t expr))))
                (loop for e0 = expr then e1
                      for e1 = (s1 e0)
                      until (equal e0 e1)
                      finally do (return e1))))

CL-USER 8 > (s (d '(+ (* a (* x x)) (+ (* b x) c)) 'x))
(+ (* A (+ X X)) B)


Now we have a function 
   (lambda (a b c x) (+ (* a x x) (* b x) c))
and we want to compute the derivative function.




Let's collect the variables of an expression:

CL-USER 9 > (defun cv (expr)
              (let ((vars nil))
                (labels ((cv1 (expr)
                           (cond ((symbolp expr) (pushnew expr vars))
                                 ((consp expr)
                                  (cv1 (arg1 expr))
                                  (cv1 (arg2 expr))))))
                  (cv1 expr))
                vars))
CV

CL-USER 10 > (cv '(+ (* a (* x x)) (+ (* b x) c)))
(C B X A)




Now let's compute the simplified derivative of a Lisp function,
removing unused args:

CL-USER 11 > (defun msdf (f x)
               (let* ((d (d (third f) x))
                      (s (s d))
                      (dargs (cv s))
                      (args (loop for arg in (second f)
                                  when (member arg dargs) collect arg)))
                 `(lambda ,args
                    ,s)))

CL-USER 12 > (msdf '(lambda (a b c x) (+ (* a (* x x)) (+ (* b x) c))) 'x)
(LAMBDA (A B X) (+ (* A (+ X X)) B))



Now let's create a compiled version:

CL-USER 13 > (defun msdfc (f x)
               (compile nil (msdf f x)))
MSDFC

CL-USER 14 > (msdfc '(lambda (a b c x) (+ (* a (* x x)) (+ (* b x) c))) 'x)
#<Function 24>
NIL
NIL

CL-USER 15 > (disassemble *)
    #x0: #x80F80692     lwz tmp1,#x692(nil)
    #x4: #x7C013840     cmpl cr0,sp,tmp1
    #x8: #x408100F0     ble #xF8
...

Now, at runtime, specify a function, compute the compiled derivative
and apply it:


CL-USER 16 > (let* ((f '(lambda (a b c x) (+ (* a (* x x)) (+ (* b x) c))))
                    (msdfc (msdfc f 'x)))
               (funcall msdfc 10 20 30))
620
From: Tim X
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <87ir5j4lnj.fsf@lion.rapttech.com.au>
tadpole writes:

> Don Geddis wrote:
>> Jon Harrop <···@ffconsultancy.com> wrote on Thu, 04 Oct 2007:
>>> The difference boils down to integration into the type system that gives
>>> ML-style pattern matching its speed and static checking. Without a static
>>> type system, you can't even implement a basic ML-style pattern matcher.
>> 
>> Your two sentences seem mutually contradictory.
>> 
>> If the (static) type system gives pattern matching "speed and type
>> checking", then surely you could implement pattern matching in a dynamic
>> type system, even though it might be "slow" and not provide "type
>> checking".
>> 
>> So: what would it even mean, for a dynamically typed language like Common
>> Lisp
>> to have "pattern matching"?  What would that look like, even in the
>> abstract?
>
> cl-unification is the best I've seen for an implementation without variants,
> static checking and performance. Without those, the whole idea is much less
> useful and, consequently, cl-unification is rarely used.
>
>>> Since Common Lisp came out, pattern matching has evolved into a construct
>>> of unparallelled expressive power that is now ubiquitous in all modern
>>> statically typed functional programming languages.
>> 
>> So what?  Common Lisp fans explicitly and consciously reject the choice to
>> evolve the language in the direction of static type checking.
>
> Except Mark Tarver, yes.
>
>> The tradeoffs aren't worth it.
>
> Lispers believe the trade-offs aren't worth it but try finding a Lisper who
> knows about the relative merits of polymorphic variants or active patterns,
> for example.
>
>> So naturally, any feature which REQUIRES static type checking, wouldn't be
>> of interest.
>
> Saying that you don't want what you can't have is just self-reassurance, not
> a logical decision.
>
>>> In contrast, nobody has ever been able to write a pattern matching
>>> library for Lisp that gained the same traction.
>> 
>> Did you not say above that "you can't even implement a basic ML-style
>> pattern
>> matcher" in the absence of static type checking?  And we all know that
>> Lisp
>> uses dynamic type checking.  So why would a Lisp programmer ever even try
>> to write such a library, if it "can't" be implemented?
>
> The inventors of ML wrote their first implementations in Lisp, so they would
> have done exactly that. The result has been developed for 3 decades and now
> looks quite different.
>
>> So, why don't you try again.  I asked a specific question.  In Common
>> Lisp, a language with dynamic type checking, we already have the ability
>> to define
>> functions in parts based on the types of arguments.  This is how CLOS and
>> generic functions work.
>
> Yes.
>
>> You have been saying that Common Lisp "lacks" pattern matching.  So please
>> give me a concrete example of how "pattern matching" would work in some
>> Lisp-like language, in a way different from how CLOS already works.  (I
>> suspect the answer has something to do with destructuring, much like
>> Lisp's DESTRUCTURING-BIND, which is available in Lisp in function bodies
>> but not in the argument list of a function's definition.)
>
> Consider the symbolic derivative:
>
> # let rec d f x = match f with
>     | `Var y when x=y -> `Int 1
>     | `Int _ | `Var _ -> `Int 0
>     | `Add(f, g) -> `Add(d f x, d g x)
>     | `Mul(f, g) -> `Add(`Mul(f, d g x), `Mul(g, d f x));;
> val d :
>   ([< `Add of 'a * 'a | `Int of 'b | `Mul of 'a * 'a | `Var of 'c ]
> as 'a) ->
>   'c -> ([> `Add of 'd * 'd | `Int of int | `Mul of 'a * 'd ] as 'd) = <fun>
>
> The integrated static type system and pattern matcher do make this very
> fast. But that is not all. The types being handled by this function are
> inferred. They might be by a Lisp compiler but OCaml explicitly states its
> inferred types:
>
> [< `Add of 'a * 'a | `Int of 'b | `Mul of 'a * 'a | `Var of 'c ] as 'a
>
> [> `Add of 'd * 'd | `Int of int | `Mul of 'a * 'd ] as 'd
>
> This tells us than the input expression is one of at most four varieties but
> it also tells us that the output can be one of at least three. One was
> dropped. Inspection of the inferred type shows that the `Var constructor
> cannot appear in the output. So the static type system has proven that
> whatever expression is given to this function, the result will never
> contain a `Var.
>
> You can also use explicitly declared sum types:
>
> # type expr =
>     | Int of int
>     | Var of string
>     | Add of expr * expr
>     | Mul of expr * expr;;
> ...
> # let rec d f x = match f with
>     | Var y when x=y -> Int 1
>     | Int _ | Var _ -> Int 0
>     | Add(f, g) -> Add(d f x, d g x)
>     | Mul(f, g) -> Add(Mul(f, d g x), Mul(g, d f x));;
> val d : expr -> string -> expr = <fun>
>
> The inferred type is less interesting. However, the combination of static
> typing and pattern matching is even more useful in this case because
> extending the sum type to include a new construct, such as Pow, causes the
> compiler to emit a warning for every incomplete pattern match. Making sure
> that all functions handle all inputs:
>
> # type expr =
>     | Int of int
>     | Var of string
>     | Add of expr * expr
>     | Mul of expr * expr
>     | Pow of expr * expr;;
> ...
> # let rec d f x = match f with
>     | Var y when x=y -> Int 1
>     | Int _ | Var _ -> Int 0
>     | Add(f, g) -> Add(d f x, d g x)
>     | Mul(f, g) -> Add(Mul(f, d g x), Mul(g, d f x));;
> Warning P: this pattern-matching is not exhaustive.
> Here is an example of a value that is not matched:
> Pow (_, _)
> val d : expr -> string -> expr = <fun>
>
> Notice how the compiler even gives you an explicit example of the kind of
> data structure that will not be handled by this function. This is
> particularly useful when the overlap between patterns is non-trivial.
>
> It also checks for redundant pattern matchers, which catches the common bug
> of accidentally performing overlapping tests in the wrong order:
>
> # let rec d f x = match f with
>     | Int _ | Var _ -> Int 0
>     | Var y when x=y -> Int 1
>     | Add(f, g) -> Add(d f x, d g x)
>     | Mul(f, g) -> Add(Mul(f, d g x), Mul(g, d f x));;
> Warning P: this pattern-matching is not exhaustive.
> Warning U: this match case is unused.
>
> These are the basic ideas that make ML-style pattern matching so useful.
> Haskell, OCaml, F# and Scala all implement this core functionality. Each
> language also adds new and interesting features.
>
> This is a simplified example, of course. Real code can uses pattern matches
> that run for pages. Common practical examples are document munging, XML
> transformations, symbolics, tree-based data structures and computer
> graphics.
>
>> If you just retreat to "well, it's not the same without static type
>> checking", then just admit up front that it's all the same issue. 
>> Instead, many times you've written that Lisp lacks BOTH static type
>> checking AND pattern matching, as though these were two different things,
>> and you could imagine having one without the other.
>
> You can have one without the other but it is the combination that makes
> ML-style pattern matching so much more powerful. For example, C# has static
> typing but no pattern matching and Mathematica has pattern matching but no
> static typing.
>
> Mathematica resembles Lisp with pattern matching quite closely but the type
> system cannot express closed sum types or infer sum types so the pattern
> matcher cannot use that information to perform static checking.
>

so don and the others were correct - all your rants really just boil down
to the fact you like static typing over dynamic? This just seems to come
down to that same old religious static vs dynamic war that has no
conclusion - neither is right, neither is wrong - its just a matter of
preference.  Having come from a C background, I personally love the fact CL
frees me from the tyranny of the compiler and enjoy the power lisp gives me
to explore the problem dynamically. Given the standard of programming out
there, I can see why some prefer a language which constrains the programmer
to  prevent them from screwing up as easily or requires that everything be
fully scoped and specified before any coding starts, I just don't like it
personally. However, I just don't see your point or why your bothering. CL
chose dynamic typing - for better or for worse thats what we have. 

The only valid point, which you have been repeatedly asked to demonstrate
and have failed to do, is show a single problem that your static typed
pattern matching can solve which cannot be solved using CL. If you cannot
show this, then all your rants are just religious dogma which adds nothing
and achieves even less. 

As Kenny might say "Move on, nothing to see here."

Tim

-- 
tcross (at) rapttech dot com dot au
From: Jon Harrop
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <13ggv01afqgdpbf@corp.supernews.com>
Tim X wrote:
> The only valid point, which you have been repeatedly asked to demonstrate
> and have failed to do, is show a single problem that your static typed
> pattern matching can solve which cannot be solved using CL. If you cannot
> show this...

Turing argument.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
From: Kent M Pitman
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <ulkaicnjv.fsf@nhplace.com>
Don Geddis <···@geddis.org> writes:

> I'm not entirely sure of the difference between OCaml "pattern matching"
> function definitions, and Lisp CLOS generic functions ... but assuming there
> is a significant difference, I doubt this can be "easily supplied by
> specialized packages".

I'd like to see an example of something that was both important to do
and not doable.  Not because I challenge the possibility, only because
I don't understand the claim and can't respond to an over-vague criticism.

Put another way, I like to separate problem descriptions from proposed
solutions, and it raises a red flag for a problem description to be 
"the solution I was going to propose is absent".

A pattern matcher is a solution to a particular class of problems.  We
can write pattern matchers.  A type dispatch system is a solution to a
particular class of problems.  We can do type dispatch.  Now it's
apparently alleged there is a particular class of problems that is
"combined pattern matching and type dispatch".  I'd like to understand
those better in a neutral, non-provocative way.  Not as part of a
firehose of "Lisp is inferior because it doesn't do things like I like
them".

If you come up with a serious example, it might be worth changing the
subject line, too.  But for now, this one does nicely.
From: Jon Harrop
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <13gb7u2lapj5mdf@corp.supernews.com>
Kent M Pitman wrote:
> A pattern matcher is a solution to a particular class of problems.  We
> can write pattern matchers.  A type dispatch system is a solution to a
> particular class of problems.  We can do type dispatch.  Now it's
> apparently alleged there is a particular class of problems that is
> "combined pattern matching and type dispatch".  I'd like to understand
> those better in a neutral, non-provocative way.  Not as part of a
> firehose of "Lisp is inferior because it doesn't do things like I like
> them".

If I'm understanding you correctly then I think the answer is that pattern
matching is how type dispatch is implemented in SML, OCaml, Haskell, F# and
Scala programs.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
From: Kent M Pitman
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <u4ph564ud.fsf@nhplace.com>
Jon Harrop <···@ffconsultancy.com> writes:

> Kent M Pitman wrote:
> > A pattern matcher is a solution to a particular class of problems.  We
> > can write pattern matchers.  A type dispatch system is a solution to a
> > particular class of problems.  We can do type dispatch.  Now it's
> > apparently alleged there is a particular class of problems that is
> > "combined pattern matching and type dispatch".  I'd like to understand
> > those better in a neutral, non-provocative way.  Not as part of a
> > firehose of "Lisp is inferior because it doesn't do things like I like
> > them".
> 
> If I'm understanding you correctly then I think the answer is that pattern
> matching is how type dispatch is implemented in SML, OCaml, Haskell, F# and
> Scala programs.

Jon, I was going out on a limb talking to you at all here.  You haven't
evolved a reputation for being willing to engage people in a way that is
responsive.  In this case, again, you quoted the wrong part of my message,
going straight past the part that answers your own question.  Let me retry:

| Put another way, I like to separate problem descriptions from proposed
| solutions, and it raises a red flag for a problem description to be 
| "the solution I was going to propose is absent".

To reiterate: What do you want to DO with these languages, or their
respective features, that will allow you to concisely solve problems
that cannot be concisely solved in Lisp or Lisp plus an extension that
is reasonably writable off-the-shelf?  Every language requires you to 
express things differently.  That's not a criticism of the language,
that's a statement of what it is for Language X to not be the same
language as Language Y.

The usefulness or non-usefulness of a language comes on an
application-by-application basis, and not as a global truth, but even
in those cases where you can attach goodness or badness it comes from
the details of what problem of the world you'd like to encode, not
from the problem that you'd like to encode the world in FORTRAN (or
COBOL or APL) no matter what language you are actually writing in.

This is a call for specific programming examples, not for general
rhetoric.  This is a forum about Lisp, not about other languages.
Tell us what you are trying to do in Lisp and failing to be able to do
(other than force it, against the apparent will and interest of its
community, to be some other language).
From: Jon Harrop
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <13gdtou82crk7d2@corp.supernews.com>
Kent M Pitman wrote:
> This is a call for specific programming examples, not for general
> rhetoric.

For a simplified example demonstrating the benefits of pattern matching,
look no further than the symbolic simplifier that we discussed before:

  http://www.lambdassociates.org/studies/study10.htm

> This is a forum about Lisp, not about other languages. 
> Tell us what you are trying to do in Lisp and failing to be able to do
> (other than force it, against the apparent will and interest of its
> community, to be some other language).

I thought Lisp's ability to be "some other language" was its primary
benefit?

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
From: Ken Tilton
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <phDNi.93$yx4.77@newsfe12.lga>
Jon Harrop wrote:
> Kent M Pitman wrote:
> 
>>This is a call for specific programming examples, not for general
>>rhetoric.
> 
> 
> For a simplified example demonstrating the benefits of pattern matching,
> look no further than the symbolic simplifier that we discussed before:
> 
>   http://www.lambdassociates.org/studies/study10.htm

Uh, what was the benefit? I did not spot one anywhere. Shorter runtime? 
15 lines vs 23 lines?

>>This is a forum about Lisp, not about other languages. 
>>Tell us what you are trying to do in Lisp and failing to be able to do
>>(other than force it, against the apparent will and interest of its
>>community, to be some other language).
> 
> 
> I thought Lisp's ability to be "some other language" was its primary
> benefit?
> 

"primary benefit"? Don't be daft, the primary objection to CL is that it 
is a big ball of mud, which means we have more then enough toys to play 
with already if we want to write an application vs piss around on this 
NG trying to drive traffic to your one-foot-in-the-grave web site since 
your twin claims to greatness are shorter run times and program 
correctness thanks to strong static typing neither of which anyone cares 
about anymore. Your confusuion over Lisp being another language is like 
the silliness of me getting excited over running into a classmate I have 
not seen since kindergarten on the Great Wall of China. That would be 
interesting if someone had called it back in kindergarten, naming the 
classmate. What matters with Lisp is not being *ML, what matters with 
Lisp is its ability to be a different language when I can use one and it 
need not have any specific feature, it just needs to rock and guess what 
I am going to make my new language work a lot like Lisp builtins because 
(a) they are well designed anyway and (b) the learning curve will be 
that much shorter but mostly (a), because the standard builtins are so 
beautifully done I may as well stand on their shoulders.

ribbit.

kenny

ps. Besides, Don Geddis is working on LispML this weekend, plans to have 
it ready for Monday. k



-- 
http://www.theoryyalgebra.com/

"We are what we pretend to be." -Kurt Vonnegut
From: Brian Adkins
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <1191646641.728985.160170@57g2000hsv.googlegroups.com>
On Oct 5, 11:28 pm, Ken Tilton <···········@optonline.net> wrote:
> ... which means we have more then enough toys to play
> with already if we want to write an application vs piss around on this
> NG trying to drive traffic to your one-foot-in-the-grave web site since
> your twin claims to greatness are shorter run times and program
> correctness thanks to strong static typing neither of which anyone cares
> about anymore.

"Those who would give up Essential Liberty to purchase a little
Temporary Safety, deserve neither Liberty nor Safety."
  - Benjamin Franklin, when asked about static typing


Saw that on James Britt's sig over on c.l.r and thought of what's-his-
name...
From: Jon Harrop
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <13ge8jdo1bp0id6@corp.supernews.com>
Ken Tilton wrote:
> Jon Harrop wrote:
>> For a simplified example demonstrating the benefits of pattern matching,
>> look no further than the symbolic simplifier that we discussed before:
>> 
>>   http://www.lambdassociates.org/studies/study10.htm
> 
> Uh, what was the benefit?

Asymptotically less code.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
From: Ken Tilton
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <JyINi.103$yx4.98@newsfe12.lga>
Jon Harrop wrote:
> Ken Tilton wrote:
> 
>>Jon Harrop wrote:
>>
>>>For a simplified example demonstrating the benefits of pattern matching,
>>>look no further than the symbolic simplifier that we discussed before:
>>>
>>>  http://www.lambdassociates.org/studies/study10.htm
>>
>>Uh, what was the benefit?
> 
> 
> Asymptotically less code.
> 

Well then you need a new link (to a different example) because what I 
see there is that there will be hyperbolically less difference in LOC as 
you get into real (big) applications. The example of writing an 
optimized interpreter for a calculator (a) is not really about less 
code, is it? and (b) is transparently one tailored to benefit from the 
stupid pet trick you are trying to sell, pattern-matching. Yeah, we 
wanted a small example, but in this case you are trying to sell a snail 
fork to a backpacker by eating a snail in front of them. They already 
have a swiss army knife, they'll probably do OK if they run into a 
snail, but they are thinking they may not. otoh, A small example of OO 
is understandable to anyone who has placed a "type" slot in a C 
structure and then written 100kloc of code with more switch statements 
off that type slot than a Cleveland baseball field has gnats. That same 
programmer sees &optional and &key and does not even need to see a one 
line example, they just start running around whooping and hollering and 
hoping they are not in a library. But I look at C++ overloading and 
think, clever and "It's a fine line between stupid..." "...and clever." 
but it is not how I think about getting desired wadges of code applied 
to stuff I want munged. I am reminded of multimethods in CLOS which I 
certainly understand and never seem to use. If I do not even use that 
primitive form of pattern-matching, well, I see *ML and the librarian 
smacks me for snoring. Thanks for nothing. What I did with Cells (oh, 
thanks for asking: http://www.tilton-technology.com/cells_top.html) as 
soon as I got tired of running around the room whooping was to try for 
something that did /not/ scream USE DATAFLOW!!!! I did this because I 
sensed I had stumbled onto something awesome but suspected it might be a 
snail fork and not so good for mashed potatos. That would have meant, 
oh, cool, stupid pet trick, nice, no big deal. The example I chose was 
managing a group of radio buttons, mundane, trivial, pedestrian, yawn -- 
perfect! The first good news is that the task was /still/ trivial 
expressed with Cells, the second good news was that I forgot to deal 
with intializing the radio group to some starting value and it still 
worked because the Cells solution somehow covered that. A few whoops 
later with the miracle of Cells confirmed I made a post to c.l.lisp and 
got a cooler reception than you but I digress. The thing is, we need 
small examples of mundane things that are problems we have and recognize 
as ones we confront all day long. And do not try to sneak "it's faster!" 
into the example next time, that was painfully obvious.

kenny

-- 
http://www.theoryyalgebra.com/

"We are what we pretend to be." -Kurt Vonnegut
From: Ken Tilton
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <wrJNi.169$0B1.87@newsfe12.lga>
Jon Harrop wrote:
> Ken Tilton wrote:
> 
>>Jon Harrop wrote:
>>
>>>For a simplified example demonstrating the benefits of pattern matching,
>>>look no further than the symbolic simplifier that we discussed before:
>>>
>>>  http://www.lambdassociates.org/studies/study10.htm
>>
>>Uh, what was the benefit?
> 
> 
> Asymptotically less code.
> 

btw, You had me all excited about function dispatch by fancy patterns 
(ie, overloading on steroids), but if I understand your code it is just 
using pattern matching to parse runtime data. Not that it is not fun to 
have that SPT (stupid pet trick) built into your toy language, I just 
want to make sure I grok the non-achievement.

kt

-- 
http://www.theoryyalgebra.com/

"We are what we pretend to be." -Kurt Vonnegut
From: Sacha
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <yZFNi.141323$D87.8185897@phobos.telenet-ops.be>
Jon Harrop wrote:
> Ken Tilton wrote:
>> Jon Harrop wrote:
>>> For a simplified example demonstrating the benefits of pattern matching,
>>> look no further than the symbolic simplifier that we discussed before:
>>>
>>>   http://www.lambdassociates.org/studies/study10.htm
>> Uh, what was the benefit?
> 
> Asymptotically less code.
> 

You sure seem to have asymptotically more time on hand than i do.

Sacha
From: Kent M Pitman
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <u7im026jx.fsf@nhplace.com>
Jon Harrop <···@ffconsultancy.com> writes:

> I thought Lisp's ability to be "some other language" was its primary
> benefit?

http://en.wikipedia.org/wiki/Clarke's_three_laws

(In case it's not completely obvious from context,
 you'll be wanting to look at the first.  The
 second one won't hurt you either, by the way.)
From: Klaus Schilling
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <87ejg4des3.fsf@web.de>
Jon Harrop <···@ffconsultancy.com> writes:
>
> I thought Lisp's ability to be "some other language" was its primary
> benefit?

the primary benefit are dynamic typing, S-Expressions, and eval,
as opposed to inferior languages who lack those qualities

Klaus Schilling
From: Jon Harrop
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <13gmgngiidri5c5@corp.supernews.com>
Klaus Schilling wrote:
> Jon Harrop <···@ffconsultancy.com> writes:
>>
>> I thought Lisp's ability to be "some other language" was its primary
>> benefit?
> 
> the primary benefit are dynamic typing, S-Expressions, and eval,
> as opposed to inferior languages who lack those qualities

Reader macros are something Lispers have but don't value or use enough,
IMHO.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
From: André Thieme
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <feh162$suo$1@registered.motzarella.org>
Jon Harrop schrieb:
> Klaus Schilling wrote:
>> Jon Harrop <···@ffconsultancy.com> writes:
>>> I thought Lisp's ability to be "some other language" was its primary
>>> benefit?
>> the primary benefit are dynamic typing, S-Expressions, and eval,
>> as opposed to inferior languages who lack those qualities
> 
> Reader macros are something Lispers have but don't value or use enough,
> IMHO.

I tend to agree here, to some extend.
A team could carefully introduce some few reader macros that can be
learned in a few minutes, or even days if it is about a company who will
continue to work for many years on a set of projects. All incoming new
coders would learn this hand selected restricted set of syntax additions
and use them.
Anyway, this should happen in a controled environment and be a team
descision. But then, yes, there could be some use for it.


Andr�
-- 
From: Ken Tilton
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <b4iNi.141$ZY5.71@newsfe12.lga>
Don Geddis wrote:
> Klaus Schilling <···············@web.de> wrote on Thu, 04 Oct 2007:
> 
>>Jon Harrop <···@ffconsultancy.com> writes:
>>
>>>pattern matching in Lisp.
>>
>>pattern matching is easily supplied by specialised packages
> 
> 
> To be fair to our resident troll, I'm not so sure about this part.  He's not
> talking about string matching with regular expressions.  As you say, that's
> easily added to Lisp via any number of available packages.
> 
> He's talking about function definitions using pattern matching on the
> arguments.  More like CLOS generic functions, where the specific method
> is chosen automatically based on argument number and type.
> 
> I'm not entirely sure of the difference between OCaml "pattern matching"
> function definitions, and Lisp CLOS generic functions ... but

You will assess CL's ability to do it anyway? Cool!

>... assuming there
> is a significant difference, I doubt this can be "easily supplied by
> specialized packages".

You cannot imagine how you would write the macro def-ml-fun? That's a 
walk in the park! Plz have it on my desk by Monday. Extra credit for an 
optimized mlfuncall that avoids runtime dispatch when sufficient 
information is available.

kt

-- 
http://www.theoryyalgebra.com/

"We are what we pretend to be." -Kurt Vonnegut
From: Jon Harrop
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <13gaiksnmvpdga9@corp.supernews.com>
Klaus Schilling wrote:
> Jon Harrop <···@ffconsultancy.com> writes:
>> Conversely, secondary effects in Lisp: disgusting s-expr syntax
> 
> all decent programmers dream and think in symbolic expressions.

Absolutely. That has nothing to do with s-exprs though.

>> pattern matching in Lisp.
> 
> pattern matching is easily supplied by specialised packages

Yet in 50 years of Lisp nobody has ever been able to do that but SML, OCaml,
Haskell, Scala and F# all do.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
From: Raffael Cavallaro
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <2007100420013516807-raffaelcavallaro@pasdespamsilvousplaitmaccom>
On 2007-10-04 16:09:11 -0400, the hurtling horned toad said:

> Yet in 50 years of Lisp nobody has ever been able to do that but SML, OCaml,
> Haskell, Scala and F# all do.

You keep reiterating this same bs line which we will refute once again:


<http://common-lisp.net/project/cl-unification/>
<http://www.cliki.net/fare-matcher>
<http://common-lisp.net/project/bese/arnesi.html>
<http://lisa.sourceforge.net/>
From: Jon Harrop
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <13gb6dugj16n5dd@corp.supernews.com>
Raffael Cavallaro wrote:
> On 2007-10-04 16:09:11 -0400, the hurtling horned toad said:
>> Yet in 50 years of Lisp nobody has ever been able to do that but SML,
>> OCaml, Haskell, Scala and F# all do.
> 
> You keep reiterating this same bs line which we will refute once again:
> 
> <http://common-lisp.net/project/cl-unification/>
> <http://www.cliki.net/fare-matcher>
> <http://common-lisp.net/project/bese/arnesi.html>
> <http://lisa.sourceforge.net/>

You keep citing unrelated libraries. To understand what I'm saying, you need
to understand what ML-style pattern matching means. Of course, if you knew
you would no longer be using Lisp...

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
From: Raffael Cavallaro
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <2007100423090311272-raffaelcavallaro@pasdespamsilvousplaitmaccom>
On 2007-10-04 21:46:51 -0400, frog boy said:

> You keep citing unrelated libraries. To understand what I'm saying, you need
> to understand what ML-style pattern matching means. Of course, if you knew
> you would no longer be using Lisp...

Oh please, how condescending. The only significant difference between, 
for example, cl-unifcation's matcher and ML style pattern matching is 
that *ml matchers make use of static type analysis and lisp libraries 
must do this dynamically at run time. This buys you greater dispatch 
speed in *ml - much or all of the dispatch can be statically decided at 
compile time in *ml - which is of little concern unless your 
application spends most of its time in dispatch.

In order to get this faster dispatch of dubious value, you have to give 
up the ability to run incomplete, partially incorrect, or downright 
broken programs for debugging and testing purposes. You have to bend 
over before the dominatrix compiler and say "please ma'am, may I have 
another," and hope this time she'll let your program - *gasp* - 
actually run, not paddle you yet again. No thanks.
From: Jon Harrop
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <13gdq73j5p4gfcf@corp.supernews.com>
Raffael Cavallaro wrote:
> On 2007-10-04 21:46:51 -0400, frog boy said:
>> You keep citing unrelated libraries. To understand what I'm saying, you
>> need to understand what ML-style pattern matching means. Of course, if
>> you knew you would no longer be using Lisp...
> 
> Oh please, how condescending. The only significant difference between,
> for example, cl-unifcation's matcher and ML style pattern matching is
> that *ml matchers make use of static type analysis and lisp libraries
> must do this dynamically at run time.

No, they don't "do this dynamically at run time" because if you defer
everything to run-time then there is no longer any merit in doing the
tests. This is precisely why it is less useful. For example, exhaustiveness
and redundancy.

> This buys you greater dispatch 
> speed in *ml - much or all of the dispatch can be statically decided at
> compile time in *ml - which is of little concern unless your
> application spends most of its time in dispatch.

Enormous performance improvements is certainly one of the advantages but
static checking is even more useful.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
From: Raffael Cavallaro
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <2007100600440964440-raffaelcavallaro@pasdespamsilvousplaitmaccom>
On 2007-10-05 21:36:54 -0400, throw-away tadpole said:

> No, they don't "do this dynamically at run time" because if you defer
> everything to run-time then there is no longer any merit in doing the
> tests. This is precisely why it is less useful. For example, exhaustiveness
> and redundancy.

We don't want the tests, just the pattern matching dispatch (and full 
blown unification if we want). The tests are a devil's bargain - you 
gain only partial correctness proof, but must pay by not being able to 
run incomplete or incorrect programs *at all*

>> This buys you greater dispatch
>> speed in *ml - much or all of the dispatch can be statically decided at
>> compile time in *ml - which is of little concern unless your
>> application spends most of its time in dispatch.
> 
> Enormous performance improvements is certainly one of the advantages but
> static checking is even more useful.

No, static checking is more painful, and it still doesn't prove correctness.
From: Jon Harrop
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <13ge9umbvclg1d8@corp.supernews.com>
Raffael Cavallaro wrote:
> On 2007-10-05 21:36:54 -0400, throw-away tadpole said:
>> No, they don't "do this dynamically at run time" because if you defer
>> everything to run-time then there is no longer any merit in doing the
>> tests. This is precisely why it is less useful. For example,
>> exhaustiveness and redundancy.
> 
> We don't want the tests...

Whether you want them or not is irrelevant. The type inference and static
tests are the critical differences between the Lisp libraries you cited and
the much more useful construct found in all modern statically typed
functional programming languages.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
From: Ken Tilton
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <MmJNi.168$0B1.21@newsfe12.lga>
Jon Harrop wrote:
> Raffael Cavallaro wrote:
> 
>>On 2007-10-05 21:36:54 -0400, throw-away tadpole said:
>>
>>>No, they don't "do this dynamically at run time" because if you defer
>>>everything to run-time then there is no longer any merit in doing the
>>>tests. This is precisely why it is less useful. For example,
>>>exhaustiveness and redundancy.
>>
>>We don't want the tests...
> 
> 
> Whether you want them or not is irrelevant. The type inference and static
> tests are the critical differences between the Lisp libraries you cited and
> the much more useful..

[Right here you sound a little desperate since whether it is useful or 
useless or an impediment to development is precisely your problem so 
bellowing it out like that in the middle of the sentence, well, I 
mentioned "desperate", right? hth]

>... construct found in all modern statically typed
> functional programming languages.
> 

"modern statically typed" is a bit of an oxymoron, don't you think? I 
think that train has rather left the station. Look over there. See the 
smoke?

kenny


-- 
http://www.theoryyalgebra.com/

"We are what we pretend to be." -Kurt Vonnegut
From: Jon Harrop
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <13gfe7t713g7d43@corp.supernews.com>
Ken Tilton wrote:
> "modern statically typed" is a bit of an oxymoron, don't you think? I
> think that train has rather left the station. Look over there. See the
> smoke?

How ironic, coming from a Lisper. =B-)

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
From: Ken Tilton
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <I_PNi.23$DO7.4@newsfe12.lga>
Jon Harrop wrote:
> Ken Tilton wrote:
> 
>>"modern statically typed" is a bit of an oxymoron, don't you think? I
>>think that train has rather left the station. Look over there. See the
>>smoke?
> 
> 
> How ironic, coming from a Lisper. =B-)
> 

Don't be silly, the only erason you are here is because you get so many 
hits off your silliness here. (Oh, do be silly, hits are hits.)

The world has found Lisp is almost as fast as C and the merits of strong 
static typing long ago. The only reason you are bleating about them 
endlessly is that that is where you have placed your bets. Oops.

kenny

-- 
http://www.theoryyalgebra.com/

"We are what we pretend to be." -Kurt Vonnegut
From: Jon Harrop
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <13gfohvbi1c7070@corp.supernews.com>
Ken Tilton wrote:
> Don't be silly, the only erason you are here is because you get so many
> hits off your silliness here. (Oh, do be silly, hits are hits.)

Sales, not hits.

> The world has found Lisp is almost as fast as C and the merits of strong
> static typing long ago. The only reason you are bleating about them
> endlessly is that that is where you have placed your bets. Oops.

Post hoc ergo propter hoc.

My OCaml work was so successful that I'm moving into related domains like F#
and Scala rather than Lisp (which has a semblance of activity only because
it is still taught at many US universities). The market value of Lisp is
dwarfed by OCaml, F# and Scala.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
From: Ken Tilton
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <RfSNi.374$wc.202@newsfe12.lga>
Jon Harrop wrote:
> Ken Tilton wrote:
> 
>>Don't be silly, the only erason you are here is because you get so many
>>hits off your silliness here. (Oh, do be silly, hits are hits.)
> 
> 
> Sales, not hits.

Why do I not believe you? But we certainly wish you prosperity and huge 
success for F#. Best of luck. At some *ML will be so popular you will 
not have to sell it here, right?

Btw, a technical question:

> let rec ( +: ) f g = match f, g with
>   | `Int n, `Int m -> `Int (n +/ m)
>   | `Int (Int 0), e | e, `Int (Int 0) -> e
<snip>

Ewww, repetitive! No way around that? This awkwardness appeared in the 
next rule as well.

> 
> 
>>The world has found Lisp is almost as fast as C and the merits of strong
>>static typing long ago. The only reason you are bleating about them
>>endlessly is that that is where you have placed your bets. Oops.
> 
> 
> Post hoc ergo propter hoc.

Whoa, what did /you/ eat?

> 
> My OCaml work was so successful that I'm moving into related domains like F#
> and Scala rather than Lisp (which has a semblance of activity only because
> it is still taught at many US universities).

Odd, it has been a long time since I met someone who said they were 
studying computers in school and had heard of Lisp. I think you are 
making that up.

> The market value of Lisp is
> dwarfed by OCaml, F# and Scala.
> 

The lady protests too much, methinks. When you raise your voice like 
that you sound terribly insecure, which only makes people wonder exactly 
how much you believe your own assessment. Might want to ease up on the 
scenery chewing (is that what you ate?)

Anyway, time will tell, right? May the best language win, either way 
it's all good. As long as Microsoft goes down the drain, that is all any 
self-respecting technologist could...oh, sorry, .NET, your other bet. 
Deal with the devil, eh? If yer having trouble sleeping, it's not the 
scenery you are digesting keeping you up.

kt

-- 
http://www.theoryyalgebra.com/

"We are what we pretend to be." -Kurt Vonnegut
From: .
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <470bf5ef$0$24270$4c368faf@roadrunner.com>
On Sat, 06 Oct 2007 16:30:35 -0400, Ken Tilton wrote:

>> My OCaml work was so successful that I'm moving into related domains like F#
>> and Scala rather than Lisp (which has a semblance of activity only because
>> it is still taught at many US universities).
> 
> Odd, it has been a long time since I met someone who said they were 
> studying computers in school and had heard of Lisp. I think you are 
> making that up.
> 

We used lisp in my semantics, symbolic programming, ai and algorithms
classes.  I used it in a practical class and studying numerical methods,
but this wasn't required.

I've also used ocaml, but I kept end up writing those correct functions
the type checker has to reject in order to keep type-checking decidable. 
That's the part that's constantly glossed over in raving about the
benefits of static typing; that the compiler has to reject some correct
programs in order to be sure of rejecting incorrect ones.  I compiler
which rejects any program would reject all incorrect ones too.
From: Jon Harrop
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <13gottn7d7817b7@corp.supernews.com>
Ken Tilton wrote:
> Btw, a technical question:
>> let rec ( +: ) f g = match f, g with
>>   | `Int n, `Int m -> `Int (n +/ m)
>>   | `Int (Int 0), e | e, `Int (Int 0) -> e
> <snip>
> 
> Ewww, repetitive!

You mean the "Int 0" to mean bignum zero?

> No way around that?

Macro, if you're doing it a lot.

>> My OCaml work was so successful that I'm moving into related domains like
>> F# and Scala rather than Lisp (which has a semblance of activity only
>> because it is still taught at many US universities).
> 
> Odd, it has been a long time since I met someone who said they were
> studying computers in school and had heard of Lisp.

Lisp is touched upon almost universally in academic courses, and I'm all for
that. Lisp is certainly something everyone should be made aware of.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
From: Raffael Cavallaro
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <2007100616554143042-raffaelcavallaro@pasdespamsilvousplaitmaccom>
On 2007-10-06 15:20:56 -0400, the near-earth-orbit newt said:

> My OCaml work was so successful...

... that it, and all the other *ml languages *combined* can't support a 
newsgroup with half the traffic of comp.lang.lisp. Which is why you're 
hawking your dromedary droppings here of course.
From: ······@corporate-world.lisp.de
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <1191704650.708026.37700@d55g2000hsg.googlegroups.com>
On Oct 6, 10:55 pm, Raffael Cavallaro <················@pas-d'espam-
s'il-vous-plait-mac.com> wrote:
> On 2007-10-06 15:20:56 -0400, the near-earth-orbit newt said:
>
> > My OCaml work was so successful...
>
> ... that it, and all the other *ml languages *combined* can't support a
> newsgroup with half the traffic of comp.lang.lisp. Which is why you're
> hawking your dromedary droppings here of course.

Though one has to admit, if Mr. Harrop would not post here, the
traffic
would drop by 20% (a guess). While there is some 'signal' in these
20%, there is more 'noise' (like this posting of mine right now).
I always try to contribute to some technical thread at least once
a day, to compensate for a posting like this. ;-)
From: Jon Harrop
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <13gg7k4g1e77ka5@corp.supernews.com>
······@corporate-world.lisp.de wrote:
> Though one has to admit, if Mr. Harrop would not post here, the
> traffic would drop by 20% (a guess).

30% according to my newsreader.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
From: Leandro Rios
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <4707f3c9$0$1346$834e42db@reader.greatnowhere.com>
Jon Harrop escribi�:
> Ken Tilton wrote:
>> Don't be silly, the only erason you are here is because you get so many
>> hits off your silliness here. (Oh, do be silly, hits are hits.)
> 
> Sales, not hits.
> 
>> The world has found Lisp is almost as fast as C and the merits of strong
>> static typing long ago. The only reason you are bleating about them
>> endlessly is that that is where you have placed your bets. Oops.
> 
> Post hoc ergo propter hoc.
> 
> My OCaml work was so successful that ... [snip]

Can I ask what this work was? Is it possible to be seen? Is it an 
application? A web site? A robot's brain? A ray tracer?

Leandro
From: Rainer Joswig
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <joswig-D3F1D6.18443006102007@news-europe.giganews.com>
In article <···············@corp.supernews.com>,
 Jon Harrop <···@ffconsultancy.com> wrote:

> Ken Tilton wrote:
> > "modern statically typed" is a bit of an oxymoron, don't you think? I
> > think that train has rather left the station. Look over there. See the
> > smoke?
> 
> How ironic, coming from a Lisper. =B-)

Waldemar Horwat who worked on JavaScript:

  "JavaScript is just an alternative syntax for Common Lisp".

-- 
http://lispm.dyndns.org
From: Klaus Schilling
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <87tzp66mp8.fsf@web.de>
Jon Harrop <···@ffconsultancy.com> writes:
> You keep citing unrelated libraries. To understand what I'm saying, you need
> to understand what ML-style pattern matching means. Of course, if you knew
> you would no longer be using Lisp...

no, as ML has a perverse (infix) syntax,
thus decent programmers prefer Lisp

     Klaus Schilling
From: Kent M Pitman
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <ubqbc26t0.fsf@nhplace.com>
Jon Harrop <···@ffconsultancy.com> writes:

> To understand what I'm saying, you need to understand what ML-style
> pattern matching means. Of course, if you knew you would no longer
> be using Lisp...

It's weird listening to someone who purports that the reason we should
switch to static typing is that inference technique is very powerful
and reliable ... and then who makes strange claims like this.

If I read correctly, you're saying here that if we understood the
beauty of some thing X, it would imply that we would be no longer
using anything Y that is of lesser beauty.

Somehow, your "logic" escapes me.  Because I have seen MANY discussions
of far greater beauty and value than what you've been able to muster here.
And yet here I am still replying to one of your posts.

Has it ever worried you that perhaps you might not be the best
ambassador that a society seeking to base its technology on proper
inference technique could elect?
From: Harald Hanche-Olsen
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <pco7im0u1vs.fsf@shuttle.math.ntnu.no>
+ Kent M Pitman <······@nhplace.com>:

> Somehow, your "logic" escapes me.  Because I have seen MANY
> discussions of far greater beauty and value than what you've been
> able to muster here. And yet here I am still replying to one of your
> posts.

And /that/ must surely rank as one of life's great mysteries.
Kent, I stand in awe of your superhuman patience.

-- 
* Harald Hanche-Olsen     <URL:http://www.math.ntnu.no/~hanche/>
- It is undesirable to believe a proposition
  when there is no ground whatsoever for supposing it is true.
  -- Bertrand Russell
From: Ken Tilton
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <YeONi.340$wc.61@newsfe12.lga>
Harald Hanche-Olsen wrote:
> + Kent M Pitman <······@nhplace.com>:
> 
> 
>>Somehow, your "logic" escapes me.  Because I have seen MANY
>>discussions of far greater beauty and value than what you've been
>>able to muster here. And yet here I am still replying to one of your
>>posts.
> 
> 
> And /that/ must surely rank as one of life's great mysteries.
> Kent, I stand in awe of your superhuman patience.
> 

I was going to say "Fool me once, shame on you. Fool me twice..."

kenny

-- 
http://www.theoryyalgebra.com/

"We are what we pretend to be." -Kurt Vonnegut
From: Klaus Schilling
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <87abqsdehn.fsf@web.de>
Kent M Pitman <······@nhplace.com> writes:
>
> If I read correctly, you're saying here that if we understood the
> beauty of some thing X, it would imply that we would be no longer
> using anything Y that is of lesser beauty.

infixish syntaxes are always ugly

       Klaus Schilling
From: Jon Harrop
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <13gmg9o67km62c4@corp.supernews.com>
Klaus Schilling wrote:
> Kent M Pitman <······@nhplace.com> writes:
>>
>> If I read correctly, you're saying here that if we understood the
>> beauty of some thing X, it would imply that we would be no longer
>> using anything Y that is of lesser beauty.
> 
> infixish syntaxes are always ugly

  1 + 1 = 2

  (eq (+ 1 1) 2)

Hmm...

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
From: Klaus Schilling
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <873awkbmmm.fsf@web.de>
Jon Harrop <···@ffconsultancy.com> writes:
>   1 + 1 = 2
>
>   (eq (+ 1 1) 2)

this underlines the superiority of S-Expressions

Klaus Schilling
From: Rainer Joswig
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <joswig-3374F0.18400009102007@news-europe.giganews.com>
In article <···············@corp.supernews.com>,
 Jon Harrop <···@ffconsultancy.com> wrote:

> Klaus Schilling wrote:
> > Kent M Pitman <······@nhplace.com> writes:
> >>
> >> If I read correctly, you're saying here that if we understood the
> >> beauty of some thing X, it would imply that we would be no longer
> >> using anything Y that is of lesser beauty.
> > 
> > infixish syntaxes are always ugly
> 
>   1 + 1 = 2
> 
>   (eq (+ 1 1) 2)
> 
> Hmm...

Not EQ, you have to use = .

http://www.lispworks.com/documentation/HyperSpec/Body/f_eq.htm#eq

(= (+ 1 1) 2)

But you would have known that, if you had any Lisp knowledge,
which you don't have.

-- 
http://lispm.dyndns.org
From: John Thingstad
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <op.tzx3eafupqzri1@pandora.upc.no>
P� Tue, 09 Oct 2007 18:40:00 +0200, skrev Rainer Joswig <······@lisp.de>:

>
> Not EQ, you have to use = .
>

or eql..

Anyhow eq actually works on some systems (all?) because of the way fixnums  
are stored.
Two or three tag bits followed by the number. So comparison by 'address'  
gives the right result.
So you might get the right/expected result if you just casually tested  
this.
You should, of course, not rely on this..

(eq 2 (+ 1 1))
-> T
(eq (* 2 1) (+ 1 1))
-> T
(eql 2 (+ 1 1))
-> T
(= 2 (+ 1 1))
-> T

This is not true for BIGNUM

(setf a (+ most-posivive-fixnum 1))
(type-of a)
-> BIGNUM
(eq (* 2 a) (+ a a))
-> NIL
(eql (* 2 a) (+ a a))
-> T
(= (* 2 a) (+ a a))
-> T

(Tested under LispWorks.)

You are right that the ANSI spec dosn't spesify what the behaviour is.

> http://www.lispworks.com/documentation/HyperSpec/Body/f_eq.htm#eq
>
> (= (+ 1 1) 2)
>
> But you would have known that, if you had any Lisp knowledge,
> which you don't have.
>
From: André Thieme
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <febb7p$s9n$1@registered.motzarella.org>
Jon Harrop schrieb:

> Neither OCaml provides dynamic typing nor Lisp provides static typing.

Common Lisp does not have static typing by default. With a library like
Qi you can add that.
Also, you can write a program like Erlangs Dyalizer, that is performing
any checks you like. So, the default for Lisp is dynamic typing.
However, you can chose the degree of static typing that you want in CL.


Andr�
-- 
From: Jon Harrop
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <13gjitqcstc0qaf@corp.supernews.com>
Andr� Thieme wrote:
> Jon Harrop schrieb:
>> Neither OCaml provides dynamic typing nor Lisp provides static typing.
> 
> Common Lisp does not have static typing by default. With a library like
> Qi you can add that.

Yes.

> Also, you can write a program like Erlangs Dyalizer, that is performing
> any checks you like. So, the default for Lisp is dynamic typing.
> However, you can chose the degree of static typing that you want in CL.

In theory, you have a Turing tarpit and can start reimplementing parts of
modern languages but, as they have shown, you cannot obtain the benefits of
these languages without evolving Lisp beyond all recognition.

In practice, nobody does this in the Lisp community and they almost all just
stick with what they're given. Deconstructing manually. Unit testing
forever. And so on.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
From: Rainer Joswig
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <joswig-14BF48.10312508102007@news-europe.giganews.com>
In article <···············@corp.supernews.com>,
 Jon Harrop <···@ffconsultancy.com> wrote:

> Andr� Thieme wrote:
> > Jon Harrop schrieb:
> >> Neither OCaml provides dynamic typing nor Lisp provides static typing.
> > 
> > Common Lisp does not have static typing by default. With a library like
> > Qi you can add that.
> 
> Yes.
> 
> > Also, you can write a program like Erlangs Dyalizer, that is performing
> > any checks you like. So, the default for Lisp is dynamic typing.
> > However, you can chose the degree of static typing that you want in CL.
> 
> In theory, you have a Turing tarpit and can start reimplementing parts of
> modern languages but, as they have shown, you cannot obtain the benefits of
> these languages without evolving Lisp beyond all recognition.

Nobody wants Lisp as ML. When you need ML use ML. Lisp is different.

> In practice, nobody does this in the Lisp community and they almost all just
> stick with what they're given. Deconstructing manually. Unit testing
> forever. And so on.

The evidence is against you. Again.

-- 
http://lispm.dyndns.org
From: Jon Harrop
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <13gkf636f41e413@corp.supernews.com>
Rainer Joswig wrote:
>> In practice, nobody does this in the Lisp community and they almost all
>> just stick with what they're given. Deconstructing manually. Unit testing
>> forever. And so on.
> 
> The evidence is against you.

How do you deconstruct?

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
From: Rainer Joswig
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <joswig-29F751.17522408102007@news-europe.giganews.com>
In article <···············@corp.supernews.com>,
 Jon Harrop <···@ffconsultancy.com> wrote:

> Rainer Joswig wrote:
> >> In practice, nobody does this in the Lisp community and they almost all
> >> just stick with what they're given. Deconstructing manually. Unit testing
> >> forever. And so on.
> > 
> > The evidence is against you.
> 
> How do you deconstruct?

With a Lisp function or macro.

-- 
http://lispm.dyndns.org
From: André Thieme
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <feed61$gr9$1@registered.motzarella.org>
Jon Harrop schrieb:
> Rainer Joswig wrote:
>>> In practice, nobody does this in the Lisp community and they almost all
>>> just stick with what they're given. Deconstructing manually. Unit testing
>>> forever. And so on.
>> The evidence is against you.
> 
> How do you deconstruct?

That is an interesting question.
When looking at 1-8 line functions then having a mechanism for destructing
list elements can make a difference.
If you give up the tilde in variable names for these small
functions you could say:

(def sum-numbers (f~r)
   (if r
       (+ f (sum-numbers r))
       f))

vs

(defun sum-numbers (list)
   (if (rest list)
       (+ (first list) (sum-numbers (rest list)))
       (first list)))

vs

(defun sum-numbers (list)
   (let ((f (first list))
         (r (rest  list)))
     (if r
         (+ f (sum-numbers r))
         f)))

vs

(defun sum-numbers (list)
   (destructuring-bind (f . r) list
     (if r
         (+ f (sum-numbers r))
         f)))

However, if this is part of a 50k LOC project, then these LETs here and
destructuring-binds there make really not a big difference.
A macro that allows destructuring directly in the naming is simple.
You can do it for arrays, lists, whatever.
f~s~t~r/list could give you the variables
f, s, t, r (with first, second, third and rest) and LIST as the name for
the current argument. You can have other syntaxes as well.
The question really is if it makes a noticable difference in readability
or productivity in a 50k LOC code base. From my experience I can tell
you that it will not make a huge difference. If I suggested such a
macro to a programmer team I think they would not want it. Saving three
hours of typing time and another 8 hours in reading time does not matter
when the project itself consumes 12.000 hours. The company/team will agree
to make it 12.011 hours then and suggest me to write some other code
(for example a macro) for real patterns, so that saving 90 hours (minus
7 for writing the macro) can make a difference of 10 working days over
the course of two years.


Andr�
--
From: Jon Harrop
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <13glupjitou79d@corp.supernews.com>
Andr� Thieme wrote:
> Jon Harrop schrieb:
>> Rainer Joswig wrote:
>>> The evidence is against you.
>> 
>> How do you deconstruct?
> 
> That is an interesting question.
> When looking at 1-8 line functions then having a mechanism for destructing
> list elements can make a difference.
> If you give up the tilde in variable names for these small
> functions you could say:
> 
> (def sum-numbers (f~r)
>    (if r
>        (+ f (sum-numbers r))
>        f))
> 
> vs
> 
> (defun sum-numbers (list)
>    (if (rest list)
>        (+ (first list) (sum-numbers (rest list)))
>        (first list)))
> 
> vs
> 
> (defun sum-numbers (list)
>    (let ((f (first list))
>          (r (rest  list)))
>      (if r
>          (+ f (sum-numbers r))
>          f)))
> 
> vs
> 
> (defun sum-numbers (list)
>    (destructuring-bind (f . r) list
>      (if r
>          (+ f (sum-numbers r))
>          f)))
> 
> However, if this is part of a 50k LOC project, then these LETs here and
> destructuring-binds there make really not a big difference.

On the contrary, if your 50k LOC project is composed largely of pattern
matches that expand into asymptotically more Lisp code then you're looking
at a huge difference.

The reduce example I gave was trivial. Here is a real example from some of
our production code:

      match action, it, blk, lines with
      | action, it, blk, [] :: lines ->
          (* Examine the next line *)
          begin match edit_block action it blk lines with
            `Replace x -> `Replace x
          | `SplitParagraph x -> `SplitParagraph x
          | `SplitSlide x -> `SplitSlide x
          | `Prev -> `Prev | `Next -> `Next
          | `Down x -> `Down x
          | `PrevUp x ->
              (* If we wish to move up a line then examine the current line *)
              `Up x
          | `Up x ->
              (* Search the new line *)
              `Replace ((search_line x (blk, List.hd lines), None), blk)
          end
      | #math_action as action, (0, Some it), Math maths :: blk,
          ((m, graph) :: line) :: lines ->
          (* Apply iterator inside maths *)
          let m, graphs = group m graph in
          begin match edit_maths action m it maths graphs with
            `Replace (it, maths) -> `Replace ((0, Some it), Math maths :: blk)
          | `Down x ->
              begin match search_down_block x (blk, line :: lines) with
                `Replace i ->
                  (* Move down to next line *)
                  `Replace ((i + 1, None), Math maths :: blk)
              | `Down ->
                  (* Propagate to next paragraph *)
                  `Down x
              end
          | `Up x -> `PrevUp x
          | `Prev -> `Replace ((0, None), Math maths :: blk)
          | `Next -> `Replace ((1, None), Math maths :: blk)
          | `Delete _ ->
              (* Do nothing when maths are deleted from the inside *)
              `Replace ((0, Some it), Math maths :: blk)
          end
      | ( `SplitParagraph
        | `SplitSlide
        | `InsertMaths ), (0, Some _ as it), blk, _ ->
          (* Splitting and insert maths have no effect on maths *)
          `Replace (it, blk)
      | `Left, (0, _), _, _ ->
          (* Undo recursion *)
          `Prev
      | `Left, (1, None), (Math maths :: _ as blk), _ ->
          (* Left into maths *)
          `Replace ((0, Some (last_maths maths)), blk)
      | `Left, (1, None), (Char c :: _ as blk), _ ->
          (* Left to previous character *)
          `Replace ((0, None), blk)
      | `Right, _, [], _ ->
          (* Right into next paragraph *)
          `Next
      | `Right, (0, None), (Char c :: _ as blk), _ ->
          (* Right to next character *)
          `Replace ((1, None), blk)
      | `Right, (0, None), (Math maths :: _ as blk), _ ->
          (* Right to maths *)
          `Replace ((0, Some (first_maths maths)), blk)
      | `SplitParagraph, (0, None), blk, _ ->
          (* Split into two blocks *)
          `SplitParagraph ([], blk)
      | `SplitSlide, (0, None), blk, _ ->
          (* Split into two blocks *)
          `SplitSlide ([], blk)
      | `Delete, (1, None), _ :: blk, _ ->
          (* Delete previous character/maths *)
          `Replace ((0, None), blk)
      | `InsertMaths, (0, None), blk, _ ->
          (* Insert a block of maths *)
          `Replace ((0, Some (0, End)), Math [] :: blk)
      | `Insert c, (0, None), blk, _ ->
          (* Insert a text character *)
          `Replace ((1, None), Char c :: blk)
      | `Up x, (0, None), blk, lines ->
          (* Respond by moving up onto the previous line *)
          `PrevUp x
      | `Down x, (0, None), blk, lines ->
          (* Search the next line if there is one *)
          begin match search_down_block x (blk, lines) with
            `Replace i ->
              (* Move down to next line *)
              `Replace ((i, None), blk)
          | `Down ->
              (* Propagate to next paragraph *)
              `Down x
          end
      | action, (i, it), entry :: blk, (_ :: line) :: lines ->
          (* Examine the next entry *)
          begin match edit_block action (i-1, it) blk (line :: lines) with
            `Replace ((i, it), blk) -> `Replace ((i+1, it), entry :: blk)
          | `SplitParagraph (blk1, blk2) ->
              `SplitParagraph (entry :: blk1, blk2)
          | `SplitSlide (blk1, blk2) -> `SplitSlide (entry :: blk1, blk2)
          | `Prev -> `Replace ((0, None), entry :: blk)
          | `Next -> `Next
          | `Down x -> `Down x
          | `Up x -> `Up x
          | `PrevUp x ->
              (* Return back to the newline *)
              `PrevUp x
          end
      | action, it, blk, lines ->
          let b = front_of string_of_entry blk in
          invalid_arg ("edit_block "^string_of_iterator3 it^" "^b)

> A macro that allows destructuring directly in the naming is simple.
> You can do it for arrays, lists, whatever.
> f~s~t~r/list could give you the variables
> f, s, t, r (with first, second, third and rest) and LIST as the name for
> the current argument. You can have other syntaxes as well.
> The question really is if it makes a noticable difference in readability
> or productivity in a 50k LOC code base. From my experience I can tell
> you that it will not make a huge difference. If I suggested such a
> macro to a programmer team I think they would not want it. Saving three
> hours of typing time and another 8 hours in reading time does not matter
> when the project itself consumes 12.000 hours. The company/team will agree
> to make it 12.011 hours then and suggest me to write some other code
> (for example a macro) for real patterns, so that saving 90 hours (minus
> 7 for writing the macro) can make a difference of 10 working days over
> the course of two years.

Static checking of the above pattern match reduced development time (and
cost) of the whole application by ~30%.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
From: André Thieme
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <febarc$qjd$1@registered.motzarella.org>
Jon Harrop schrieb:

> If you assume that being able to compile incorrect code,

You are talking about Lisp and OCaml here.
Both can compile code that can
a) result in runtime type errors
b) do something the programmer did not want it to do
c) is not doing everything the programmer intended it to do.

For Lisp there exist type checkers for which OCamls type system is
only a subset. So, at least in the regard of correctness Lisp wins.


> having rudimentary syntax

This is because Lisp is not only a programming language but also a
building material for programming languages. You can have any syntax
you want.
Also let us not forget that OCaml sucks badly:
http://www.podval.org/~sds/ocaml-sucks.html

Looking at
(Int64.to_float (Int64.sub (Int64.mul q (Int64.of_int n)) (Int64.mul s 
s))) /. (float n)
vs
(/ (- (* q n) (* s s)) n)
lets Lisp win easily.
Also, in Lisp it would not be hard to say
[(qn - s�) / n]

It was nice that a team looked into OCaml. Science discovered a dead-end
street and concentrate now again on other things.


Andr�
--
From: Cesar Rabak
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <febudc$f4m$1@aioe.org>
Andr� Thieme escreveu:
> sailing toad escreveu:
> 
>> If you assume that being able to compile incorrect code,
> 
> You are talking about Lisp and OCaml here.
> Both can compile code that can
> a) result in runtime type errors
> b) do something the programmer did not want it to do
> c) is not doing everything the programmer intended it to do.
> 
> For Lisp there exist type checkers for which OCamls type system is
> only a subset. So, at least in the regard of correctness Lisp wins.
> 
> 
>> having rudimentary syntax
> 
> This is because Lisp is not only a programming language but also a
> building material for programming languages. You can have any syntax
> you want.
> Also let us not forget that OCaml sucks badly:
> http://www.podval.org/~sds/ocaml-sucks.html

Which interestingly shows OCaml has no macros...
From: Ken Tilton
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <yQhOi.520$gM.168@newsfe12.lga>
Cesar Rabak wrote:
> Andr� Thieme escreveu:
> 
>> sailing toad escreveu:
>>
>>> If you assume that being able to compile incorrect code,
>>
>>
>> You are talking about Lisp and OCaml here.
>> Both can compile code that can
>> a) result in runtime type errors
>> b) do something the programmer did not want it to do
>> c) is not doing everything the programmer intended it to do.
>>
>> For Lisp there exist type checkers for which OCamls type system is
>> only a subset. So, at least in the regard of correctness Lisp wins.
>>
>>
>>> having rudimentary syntax
>>
>>
>> This is because Lisp is not only a programming language but also a
>> building material for programming languages. You can have any syntax
>> you want.
>> Also let us not forget that OCaml sucks badly:
>> http://www.podval.org/~sds/ocaml-sucks.html
> 
> 
> Which interestingly shows OCaml has no macros...

I think it is more interesting that someone has been using it at work 
for a year.

Well, also that it seems to be a bit of a joke of a language. Looks fine 
as an exercise in theoretical languages, but as a working 
language--fuggedaboutit?

The most interesting thing is that DrJon has lasted this long on c.l.l. 
What I notice is that he responds only to those people daft enough to 
argue with him on minutiae. Anyone who demonstrates he is simply a toad 
somehow never gets an answer. Of course no one daft enough to argue with 
a toad would notice such a thing,

kenny

-- 
http://www.theoryyalgebra.com/

"We are what we pretend to be." -Kurt Vonnegut
From: Jon Harrop
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <13gjgputeji01ab@corp.supernews.com>
Andr� Thieme wrote:
> Jon Harrop schrieb:
>> If you assume that being able to compile incorrect code,
> 
> You are talking about Lisp and OCaml here.
> Both can compile code that can
> a) result in runtime type errors
> b) do something the programmer did not want it to do
> c) is not doing everything the programmer intended it to do.
> 
> For Lisp there exist type checkers for which OCamls type system is
> only a subset. So, at least in the regard of correctness Lisp wins.

Can you cite a Lisp implementation of polymorphic variants?

>> having rudimentary syntax
> 
> This is because Lisp is not only a programming language but also a
> building material for programming languages. You can have any syntax
> you want.

Same as OCaml.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
From: Sacha
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <pqkOi.145153$ph2.8306728@phobos.telenet-ops.be>
Jon Harrop wrote:
> Andr� Thieme wrote:
>> Jon Harrop schrieb:
>>> If you assume that being able to compile incorrect code,
>> You are talking about Lisp and OCaml here.
>> Both can compile code that can
>> a) result in runtime type errors
>> b) do something the programmer did not want it to do
>> c) is not doing everything the programmer intended it to do.
>>
>> For Lisp there exist type checkers for which OCamls type system is
>> only a subset. So, at least in the regard of correctness Lisp wins.
> 
> Can you cite a Lisp implementation of polymorphic variants?
> 

Aren't these totally irrelevant in a dynamic typing context  ?

I mean ... the door can be locked or closed, same for the lock ... so 
i'll just use the two symbols locked and open to describe their state.

The compiler won't complain and i won't have to access the inria web 
server (which is down again) to understand polymorphic variants.

Maybe i didn't understand the concept well enough, but still :

That's the problem with those languages, lots of vocabulary introduced 
for hard to grasp concepts (this one is ok i think), all of this only to 
get around the type system.

How much code could be written while searching for a solution to this 
dead-easy problem ?

Sacha
From: Jon Harrop
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <13gkh238u1vo91d@corp.supernews.com>
Sacha wrote:
> How much code could be written while searching for a solution to this
> dead-easy problem?

# let rec d e x = match e with
    | `Var v when v=x -> `Int 1
    | `Int _ | `Var _ -> `Int 0
    | `Add(f, g) -> `Add(d f x, d g x)
    | `Mul(f, g) -> `Add(`Mul(f, d g x), `Mul(g, d f x));;
val d :
  ([< `Add of 'a * 'a | `Int of 'b | `Mul of 'a * 'a | `Var of 'c ]
as 'a) ->
  'c -> ([> `Add of 'd * 'd | `Int of int | `Mul of 'a * 'd ] as 'd) = <fun>

Completely independently of the run-time behaviour of this code, OCaml
inferred the sum type input and sum type output, checked this function for
soundness and printed out the inferred sum types, the result of which
proves that the `Var constructor does not survive this function.

In contrast, Lisp saying nothing about this function. It proves nothing. You
are left to unit test the function until you are sufficiently confident
that it removes all variables from the given expression.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
From: namekuseijin
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <1191862530.080032.261960@57g2000hsv.googlegroups.com>
On 8 out, 11:43, Jon Harrop <····@ffconsultancy.com> wrote:
> In contrast, Lisp saying nothing about this function. It proves nothing. You
> are left to unit test the function until you are sufficiently confident
> that it removes all variables from the given expression.

For Christ's sake!  The one having to prove anything about a function
is the programmer.  Your static type system won't help managers create
an army of codemonkeys who know absolutely nothing about programming
logic.

It proves trivial things which I already know of.  It doesn't say
squat if the
logic underneath is ok...
From: Rainer Joswig
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <joswig-365CFB.17581708102007@news-europe.giganews.com>
In article <···············@corp.supernews.com>,
 Jon Harrop <···@ffconsultancy.com> wrote:

> Sacha wrote:
> > How much code could be written while searching for a solution to this
> > dead-easy problem?
> 
> # let rec d e x = match e with
>     | `Var v when v=x -> `Int 1
>     | `Int _ | `Var _ -> `Int 0
>     | `Add(f, g) -> `Add(d f x, d g x)
>     | `Mul(f, g) -> `Add(`Mul(f, d g x), `Mul(g, d f x));;
> val d :
>   ([< `Add of 'a * 'a | `Int of 'b | `Mul of 'a * 'a | `Var of 'c ]
> as 'a) ->
>   'c -> ([> `Add of 'd * 'd | `Int of int | `Mul of 'a * 'd ] as 'd) = <fun>
> 
> Completely independently of the run-time behaviour of this code, OCaml
> inferred the sum type input and sum type output, checked this function for
> soundness and printed out the inferred sum types, the result of which
> proves that the `Var constructor does not survive this function.
> 
> In contrast, Lisp saying nothing about this function. It proves nothing. You
> are left to unit test the function until you are sufficiently confident
> that it removes all variables from the given expression.

You still have to test your OCAML function against input and
expected output. There is no way around it.

If you have no test cases to show and no idea about test case
coverage, then the test department will not let you
deploy your code. No way.

-- 
http://lispm.dyndns.org
From: Leandro Rios
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <470abad7$0$1346$834e42db@reader.greatnowhere.com>
Jon Harrop escribi�:
> 
> # let rec d e x = match e with
>     | `Var v when v=x -> `Int 1
>     | `Int _ | `Var _ -> `Int 0
>     | `Add(f, g) -> `Add(d f x, d g x)
>     | `Mul(f, g) -> `Add(`Mul(f, d g x), `Mul(g, d f x));;
> val d :
>   ([< `Add of 'a * 'a | `Int of 'b | `Mul of 'a * 'a | `Var of 'c ]
> as 'a) ->
>   'c -> ([> `Add of 'd * 'd | `Int of int | `Mul of 'a * 'd ] as 'd) = <fun>
> 

Please refrain from posting ugly code in this group. You are ruining the 
beauty of the landscape.

Leandro
From: André Thieme
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <feephr$v93$1@registered.motzarella.org>
Jon Harrop schrieb:
> Sacha wrote:
>> How much code could be written while searching for a solution to this
>> dead-easy problem?
> 
> # let rec d e x = match e with
>     | `Var v when v=x -> `Int 1
>     | `Int _ | `Var _ -> `Int 0
>     | `Add(f, g) -> `Add(d f x, d g x)
>     | `Mul(f, g) -> `Add(`Mul(f, d g x), `Mul(g, d f x));;
> val d :
>   ([< `Add of 'a * 'a | `Int of 'b | `Mul of 'a * 'a | `Var of 'c ]
> as 'a) ->
>   'c -> ([> `Add of 'd * 'd | `Int of int | `Mul of 'a * 'd ] as 'd) = <fun>
> 
> Completely independently of the run-time behaviour of this code, OCaml
> inferred the sum type input and sum type output, checked this function for
> soundness and printed out the inferred sum types, the result of which
> proves that the `Var constructor does not survive this function.
> 
> In contrast, Lisp saying nothing about this function. It proves nothing. You
> are left to unit test the function until you are sufficiently confident
> that it removes all variables from the given expression.
> 

I think that currently no tool like Erlangs Dyalizer exists for Lisp.
But that one could give you such information as well an give you even
more warnings than OCaml does.
For example how does OCaml handle the division a/b when both are ints?
Does it warn you that b could potentially be a zero and lead to a runtime
error?

Or when you read the number that a visitor entered on a html page and
which you now want to store in the Oracle DB - will OCaml produce a
warning if you didn't include checks to see if what the user entered
really was a number? Does the OCaml compiler warn you when you forget
to close a file?

In Lisp one would begin by setting up a little database that knows all
types of all ansi CL functions (parameters and return values). Since all
other (non-implementation specific) code uses a subset of the ansi
functions it means that all code can be type checked now, optionally.
The "Lisp Dialyzer" will follow each call and check if at the end the
right type is waiting.
After this step one, one could add others.


Andr�
From: Rainer Joswig
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <joswig-88509E.08595209102007@news-europe.giganews.com>
In article <············@registered.motzarella.org>,
 Andr� Thieme <······························@justmail.de> wrote:

> Jon Harrop schrieb:
> > Sacha wrote:
> >> How much code could be written while searching for a solution to this
> >> dead-easy problem?
> > 
> > # let rec d e x = match e with
> >     | `Var v when v=x -> `Int 1
> >     | `Int _ | `Var _ -> `Int 0
> >     | `Add(f, g) -> `Add(d f x, d g x)
> >     | `Mul(f, g) -> `Add(`Mul(f, d g x), `Mul(g, d f x));;
> > val d :
> >   ([< `Add of 'a * 'a | `Int of 'b | `Mul of 'a * 'a | `Var of 'c ]
> > as 'a) ->
> >   'c -> ([> `Add of 'd * 'd | `Int of int | `Mul of 'a * 'd ] as 'd) = <fun>
> > 
> > Completely independently of the run-time behaviour of this code, OCaml
> > inferred the sum type input and sum type output, checked this function for
> > soundness and printed out the inferred sum types, the result of which
> > proves that the `Var constructor does not survive this function.
> > 
> > In contrast, Lisp saying nothing about this function. It proves nothing. You
> > are left to unit test the function until you are sufficiently confident
> > that it removes all variables from the given expression.
> > 
> 
> I think that currently no tool like Erlangs Dyalizer exists for Lisp.

Check out SBCL and CMUCL.

-- 
http://lispm.dyndns.org
From: Jon Harrop
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <13gmg7r1phkcqc3@corp.supernews.com>
Rainer Joswig wrote:
> In article <············@registered.motzarella.org>,
>  Andr� Thieme <······························@justmail.de> wrote:
>> I think that currently no tool like Erlangs Dyalizer exists for Lisp.
> 
> Check out SBCL and CMUCL.

LOL. :-)

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
From: =?ISO-8859-15?Q?Andr=E9_Thieme?=
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <feh1so$v9q$1@registered.motzarella.org>
Rainer Joswig schrieb:

>> I think that currently no tool like Erlangs Dyalizer exists for Lisp.
> 
> Check out SBCL and CMUCL.

They are nice, yes, but they are just the tip of the iceberg of what is
potentially possible.
The best combination would be a tight interwoven integration of editor
and compiler. This could allow for nice refactoring tools, beginnig
with renaming variables but without stopping at renaming packages and
all references to them in a code base of any size.
Or remove a parameter of a method call and update all callers, etc.

Anyway, it is nice to see that SBCL is on the right track.
Add (optimize (speed 3)) to your code and it will tell you a lot about
what you did wrong.

If we had some more Lispers a company may be willing to develop such an
editor (emacs like) and build a "Dyalizer" into it as a professional
environment.


Andr�
-- 
From: Cesar Rabak
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <feeikv$fj6$1@aioe.org>
Jon Harrop escreveu:
> Andr� Thieme wrote:
>> Jon Harrop schrieb:
>>> If you assume that being able to compile incorrect code,
>> You are talking about Lisp and OCaml here.
>> Both can compile code that can
>> a) result in runtime type errors
>> b) do something the programmer did not want it to do
>> c) is not doing everything the programmer intended it to do.
>>
>> For Lisp there exist type checkers for which OCamls type system is
>> only a subset. So, at least in the regard of correctness Lisp wins.
> 
> Can you cite a Lisp implementation of polymorphic variants?

Can you cite _one single thing_ that can only be accomplished with it?
From: Jon Harrop
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <13glua135eivl9c@corp.supernews.com>
Cesar Rabak wrote:
> Jon Harrop escreveu:
>> Can you cite a Lisp implementation of polymorphic variants?
> 
> Can you cite _one single thing_ that can only be accomplished with it?

The "removing symbols" symbolic derivative example should suffice. In
reality, the technique is of enormous practical benefit.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
From: Cesar Rabak
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <feglck$u8s$1@aioe.org>
der fliengede Frosch schrieb:
> Cesar Rabak wrote:
>> der fliengede Frosch schrieb:
>>> Can you cite a Lisp implementation of polymorphic variants?
>> Can you cite _one single thing_ that can only be accomplished with it?
> 
> The "removing symbols" symbolic derivative example should suffice. In
> reality, the technique is of enormous practical benefit.
> 

Sir, I asked for an example that could be accomplished *only* with this 
technique: Axiom and Maxima have symbolic derivatives for eons...
From: Jon Harrop
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <13gotk7h80s0bb4@corp.supernews.com>
Cesar Rabak wrote:
> der fliengede Frosch schrieb:
>> Cesar Rabak wrote:
>>> der fliengede Frosch schrieb:
>>>> Can you cite a Lisp implementation of polymorphic variants?
>>> Can you cite _one single thing_ that can only be accomplished with it?
>> 
>> The "removing symbols" symbolic derivative example should suffice. In
>> reality, the technique is of enormous practical benefit.
> 
> Sir, I asked for an example that could be accomplished *only* with this
> technique...

Turing argument.

> Axiom and Maxima have symbolic derivatives for eons...

Neither provide the functionality I referred to. Read the example I posted
in this thread.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
From: Cesar Rabak
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <fejvhi$sns$1@aioe.org>
der fliengede Frosch schrieb:
> Cesar Rabak wrote:
>> der fliengede Frosch schrieb:
>>> Cesar Rabak wrote:
>>>> der fliengede Frosch schrieb:
>>>>> Can you cite a Lisp implementation of polymorphic variants?
>>>> Can you cite _one single thing_ that can only be accomplished with it?
>>> The "removing symbols" symbolic derivative example should suffice. In
>>> reality, the technique is of enormous practical benefit.
>> Sir, I asked for an example that could be accomplished *only* with this
>> technique...
> 
> Turing argument.

What part of the *only* didn't you understand?

>> Axiom and Maxima have symbolic derivatives for eons...
> 
> Neither provide the functionality I referred to. Read the example I posted
> in this thread.

Can you specify in a single paragraph what's different between an 
implementation that does symbolic derivative and the one you're bragging of?
From: Jon Harrop
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <13grncq20m55fa5@corp.supernews.com>
Cesar Rabak wrote:
> Can you specify in a single paragraph what's different between an
> implementation that does symbolic derivative and the one you're bragging
> of?

The type statically inferred and checked by the OCaml compiler proves
assertions about the code.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
From: Duane Rettig
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <o03awhis1h.fsf@gemini.franz.com>
The ubiquitous mutated adult tadpole writes:

> Cesar Rabak wrote:
>> Can you specify in a single paragraph what's different between an
>> implementation that does symbolic derivative and the one you're bragging
>> of?
>
> The type statically inferred and checked by the OCaml compiler proves
> assertions about the code.

But what proves the assumptions behind the assertions, or whether the
assertions or even the larger design match the requirements for the
software, or that the requirements satisfy the desires of the end-user?

http://www.usability.uk.com/images/cartoons/cart5.htm

-- 
Duane Rettig    ·····@franz.com    Franz Inc.  http://www.franz.com/
555 12th St., Suite 1450               http://www.555citycenter.com/
Oakland, Ca. 94607        Phone: (510) 452-2000; Fax: (510) 452-0182   
From: Ken Tilton
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <YbtPi.13$fO4.12@newsfe12.lga>
Duane Rettig wrote:
> The ubiquitous mutated adult tadpole writes:
> 
> 
>>Cesar Rabak wrote:
>>
>>>Can you specify in a single paragraph what's different between an
>>>implementation that does symbolic derivative and the one you're bragging
>>>of?
>>
>>The type statically inferred and checked by the OCaml compiler proves
>>assertions about the code.
> 
> 
> But what proves the assumptions behind the assertions, or whether the
> assertions or even the larger design match the requirements for the
> software, or that the requirements satisfy the desires of the end-user?
> 
> http://www.usability.uk.com/images/cartoons/cart5.htm
> 

I actually like the development version better than what the user 
wanted... does that explain my spotty job history?

kenny

-- 
http://www.theoryyalgebra.com/

"Mother always told me, if you tell a lie,
always rehearse it. If it don't sound good
to you, it won't sound good to no one else."
                          - Satchel Paige
From: Duane Rettig
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <o0y7e9h1m8.fsf@gemini.franz.com>
Ken Tilton <···········@optonline.net> writes:

> Duane Rettig wrote:
>> The ubiquitous mutated adult tadpole writes:
>>
>>>Cesar Rabak wrote:
>>>
>>>>Can you specify in a single paragraph what's different between an
>>>>implementation that does symbolic derivative and the one you're bragging
>>>>of?
>>>
>>>The type statically inferred and checked by the OCaml compiler proves
>>>assertions about the code.
>> But what proves the assumptions behind the assertions, or whether the
>> assertions or even the larger design match the requirements for the
>> software, or that the requirements satisfy the desires of the end-user?
>> http://www.usability.uk.com/images/cartoons/cart5.htm
>>
>
> I actually like the development version better than what the user
> wanted... does that explain my spotty job history?
>
> kenny

No, it just goes along with your focus as a developer.

It gives yet new meaning to the word "hacker".

-- 
Duane Rettig    ·····@franz.com    Franz Inc.  http://www.franz.com/
555 12th St., Suite 1450               http://www.555citycenter.com/
Oakland, Ca. 94607        Phone: (510) 452-2000; Fax: (510) 452-0182   
From: Cesar Rabak
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <felphv$jbc$1@aioe.org>
Jon Harrop escreveu:
> Cesar Rabak wrote:
>> Can you specify in a single paragraph what's different between an
>> implementation that does symbolic derivative and the one you're bragging
>> of?
> 
> The type statically inferred and checked by the OCaml compiler proves
> assertions about the code.
> 
So what?
From: Pascal Costanza
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <5m9805Fc7go5U1@mid.individual.net>
are wrote:
> On 20 Sep, 18:17, Don Geddis <····@geddis.org> wrote:
>> it's highly unlikely that your original question is legitimate.
>>
>> Why?  Because Lisp and OCaml are sufficiently different languages, that it's
>> almost inconceivable that you might have narrowed down your choice to just
>> those two.
> 
> I maintain that my original question springs from a legitimate desire
> to know the answer.  

I am going to assume that your original question was indeed an honest one.

If that's really the case, you are just the victim of an extremely 
unlikely accident. Since a couple of months, we have a guy spamming this 
newsgroup with advertisements for his F# and OCaml "expertise", in the 
form of books, websites, what have you. Apparently that guy has picked 
Lisp as one of his favorite competitors, for unknown reasons. His claims 
tend to sound highly arbitrary and generally portray F# and OCaml to be 
much better than Lisp, with generally unfounded, or at best anecdotal, 
backing. Many regulars at c.l.l find his behavior very annoying.

Your OP sounded like a very clever plot arranged by that guy with the 
sole purpose to give him even more opportunities for spamming and making 
wild claims. The fact that you narrowed down your question to the two 
languages that are typically at the center of that guy's attention is a 
strong evidence in favor of this assumption. (For this reason, I am 
myself still not sure whether or whether you are not indeed making an 
honest to get an objective answer.)

This will be hard to resolve.

In any case, it is very hard, probably impossible to compare programming 
languages objectively, from a very general point of view. My suggestion 
would be to take a closer look at one or all of the ones you're 
interested in, look out for good tutorials, documentation, community 
websites, implementations, libraries, etc., and ask more specific 
questions. In the general case, asking specific questions narrowed down 
to the context of one particular language are much more likely to yield 
well-informed answers.


Pascal

-- 
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
From: Jon Harrop
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <13g0238mh1r4pad@corp.supernews.com>
Pascal Costanza wrote:
> If that's really the case, you are just the victim of an extremely
> unlikely accident. Since a couple of months, we have a guy spamming this
> newsgroup with advertisements for his F# and OCaml "expertise", in the
> form of books, websites, what have you. Apparently that guy has picked
> Lisp as one of his favorite competitors, for unknown reasons.

Many people wanting to broaden their knowledge of programming languages
accidentally take a wrong turn and end up buried in misinformation on this
newsgroup. I am simply here to help guide these people towards modern
solutions.

> His claims 
> tend to sound highly arbitrary and generally portray F# and OCaml to be
> much better than Lisp, with generally unfounded, or at best anecdotal,
> backing. Many regulars at c.l.l find his behavior very annoying.

L. Ron Hubbard would dislike South Park for poking fun at the religion he
created.

> Your OP sounded like a very clever plot arranged by that guy with the
> sole purpose to give him even more opportunities for spamming and making
> wild claims.

That is just paranoia. People were asking for comparisons between Lisp and
ML/Haskell long before I read this group.

> In any case, it is very hard, probably impossible to compare programming
> languages objectively, from a very general point of view. My suggestion
> would be to take a closer look at one or all of the ones you're
> interested in, look out for good tutorials, documentation, community
> websites, implementations, libraries, etc., and ask more specific
> questions. In the general case, asking specific questions narrowed down
> to the context of one particular language are much more likely to yield
> well-informed answers.

With no knowledge of either language the OP can only hope to create
questions of very limited utility. He would not know to ask about OCaml's
pattern matching and polymorphic variants or about Lisp's EVAL, quotations
and history of failed projects.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
From: Pascal Costanza
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <5maqjtFcka38U1@mid.individual.net>
Jon Harrop wrote:
[whatever]

I didn't expect any other reaction.


Pascal


-- 
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
From: Jon Harrop
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <13g0ep3f84psbd4@corp.supernews.com>
Pascal Costanza wrote:
> Jon Harrop wrote:
> [whatever]
> 
> I didn't expect any other reaction.

I led the horse to water...

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
From: Pascal Costanza
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <5mbt68Fckhm5U2@mid.individual.net>
Jon Harrop wrote:

> I led the horse to water...

I agree that this statement reveals your true nature.


Pascal

-- 
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
From: Klaus Schilling
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <87ve9r8flp.fsf@web.de>
Jon Harrop <···@ffconsultancy.com> writes:
> Many people wanting to broaden their knowledge of programming languages
> accidentally take a wrong turn and end up buried in misinformation on this
> newsgroup. I am simply here to help guide these people towards modern
> solutions.


no, Harrop is trying to subvert people into mediocre slave programmers
who submit themselves mindlessly to the fascism of a statically typed, 
hard-compiled, infix-syntaxed language

Klaus Schilling
From: namekuseijin
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <1191765468.153275.25390@r29g2000hsg.googlegroups.com>
On Oct 1, 4:21 am, Klaus Schilling <···············@web.de> wrote:
> Jon Harrop <····@ffconsultancy.com> writes:
> > Many people wanting to broaden their knowledge of programming languages
> > accidentally take a wrong turn and end up buried in misinformation on this
> > newsgroup. I am simply here to help guide these people towards modern
> > solutions.
>
> no, Harrop is trying to subvert people into mediocre slave programmers
> who submit themselves mindlessly to the fascism of a statically typed,
> hard-compiled, infix-syntaxed language
>
> Klaus Schilling

ah, the eternal Good vs Evil debate!  of course, Evil meaning the
other side...
From: Leandro Rios
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <470100a3$0$1348$834e42db@reader.greatnowhere.com>
Jon Harrop escribi�:
> Pascal Costanza wrote:
> 
>> His claims 
>> tend to sound highly arbitrary and generally portray F# and OCaml to be
>> much better than Lisp, with generally unfounded, or at best anecdotal,
>> backing. Many regulars at c.l.l find his behavior very annoying.
> 
> L. Ron Hubbard would dislike South Park for poking fun at the religion he
> created.
> 

That is unfair. But speaking of religions, I would like to point out 
that you are the only preacher here.

Leandro
From: Ken Tilton
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <lG9Mi.18$lz.8@newsfe12.lga>
Leandro Rios wrote:
> Jon Harrop escribi�:
> 
>> Pascal Costanza wrote:
>>
>>> His claims tend to sound highly arbitrary and generally portray F# 
>>> and OCaml to be
>>> much better than Lisp, with generally unfounded, or at best anecdotal,
>>> backing. Many regulars at c.l.l find his behavior very annoying.
>>
>>
>> L. Ron Hubbard would dislike South Park for poking fun at the religion he
>> created.
>>
> 
> That is unfair. But speaking of religions, I would like to point out 
> that you are the only preacher here.

Nonsense. Now please leave your offerings of incense or cash at my feet 
and leave this thread without turning your back on me.

kenny

-- 
http://www.theoryyalgebra.com/

"We are what we pretend to be." -Kurt Vonnegut
From: Leandro Rios
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <47013165$0$1348$834e42db@reader.greatnowhere.com>
Ken Tilton escribi�:
> 
> Nonsense. Now please leave your offerings of incense or cash at my feet 
> and leave this thread without turning your back on me.
> 

I said "preacher". Weren't you a "programming god"? 
http://groups.google.com/group/comp.lang.lisp/msg/b959cdafa870c05a

Now I'm confused (Receding away humbly, just in case... :)

Leandro
From: Ken Tilton
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <nHbMi.2080$hP.1952@newsfe12.lga>
Leandro Rios wrote:
> Ken Tilton escribi�:
> 
>>
>> Nonsense. Now please leave your offerings of incense or cash at my 
>> feet and leave this thread without turning your back on me.
>>
> 
> I said "preacher". Weren't you a "programming god"? 
> http://groups.google.com/group/comp.lang.lisp/msg/b959cdafa870c05a

This NG is like chess: never make a move hoping your opponent won't find 
a response you see.

kenny

-- 
http://www.theoryyalgebra.com/

"We are what we pretend to be." -Kurt Vonnegut
From: Cesar Rabak
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <fds4qi$uvh$1@aioe.org>
Leandro Rios escreveu:
> Ken Tilton escribi�:
>>
>> Nonsense. Now please leave your offerings of incense or cash at my 
>> feet and leave this thread without turning your back on me.
>>
> 
> I said "preacher". Weren't you a "programming god"? 
> http://groups.google.com/group/comp.lang.lisp/msg/b959cdafa870c05a
> 
> Now I'm confused (Receding away humbly, just in case... :)
> 
Leandro, you forgot the incense!! (ten bucks will suffice if you don't 
have the real thing :-)
From: are
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <1191284806.482683.13950@g4g2000hsf.googlegroups.com>
On 30 Sep, 10:19, Pascal Costanza <····@p-cos.net> wrote:
>
> I am going to assume that your original question was indeed an honest one.
>
> If that's really the case, you are just the victim of an extremely
> unlikely accident.

Actually, it's not so unlikely. Newly lurking in c.l.l, I picked up on
the mentions of OCaml without appreciating the associated antagonisms.
I assure all that nobody's asked me to shill for OCaml. I am guilty of
having mistaken a shouting match for a constructive discussion.

> In any case, it is very hard, probably impossible to compare programming
> languages objectively, from a very general point of view.

I agree, but even subjective views could be helpful. Just hearing
someone else's experience when faced with a similar conundrum could be
helpful.  One responder to my original question gave me a few tips
privately about Lisp that I found very helpful (and make me lean
toward Lisp).

> My suggestion would be to take a closer look at one or all of the ones you're
> interested in, look out for good tutorials, documentation, community
> websites, implementations, libraries, etc., and ask more specific
> questions. In the general case, asking specific questions narrowed down
> to the context of one particular language are much more likely to yield
> well-informed answers.

I have taken a closer look at several languages. Some I learned a long
time ago, others I've studied recently and have written a 2000-line
project in Ruby. More to the point, I've worked through the first half
of Practical Common Lisp and have begun one of the on-line OCaml
tutorials. The trouble is that this takes a lot of time. Worse, I
afraid that it's going be  ages before I really get the hang of Lisp
or OCaml, because I've been corrupted by so many years of old-
fashioned imperative programming. That's why I tried to get a feeling
for the languages from people who know them better than I do.
Obviously the attempt has generated more heat than light but some
light nonetheless.
From: Pascal Costanza
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <5mejk6Fd6o3lU1@mid.individual.net>
are wrote:

>> In any case, it is very hard, probably impossible to compare programming
>> languages objectively, from a very general point of view.
> 
> I agree, but even subjective views could be helpful. Just hearing
> someone else's experience when faced with a similar conundrum could be
> helpful.  One responder to my original question gave me a few tips
> privately about Lisp that I found very helpful (and make me lean
> toward Lisp).

About five years ago, I made a switch from Java to Common Lisp. I have 
written down my experiences in a guide, which you can find at 
http://p-cos.net/lisp/guide.html - it contains a couple of high-level 
descriptions of several features of Common Lisp, and a collection of 
links I found useful back then.

You may find this useful as well...


Pascal

-- 
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
From: are
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <1191321642.710763.26830@g4g2000hsf.googlegroups.com>
On 2 Oct, 11:08, Pascal Costanza <····@p-cos.net> wrote:
> are wrote:
> >> In any case, it is very hard, probably impossible to compare programming
> >> languages objectively, from a very general point of view.
>
> > I agree, but even subjective views could be helpful. Just hearing
> > someone else's experience when faced with a similar conundrum could be
> > helpful.  One responder to my original question gave me a few tips
> > privately about Lisp that I found very helpful (and make me lean
> > toward Lisp).
>
> About five years ago, I made a switch from Java to Common Lisp. I have
> written down my experiences in a guide, which you can find athttp://p-cos.net/lisp/guide.html- it contains a couple of high-level
> descriptions of several features of Common Lisp, and a collection of
> links I found useful back then.
>
> You may find this useful as well...

Yes, thank you.  I had noticed your piece a while ago, and it is one
of the things that encouraged me to have a closer look at Lisp.  I'm
just having another look now, in light of what I've learned since
first reading it.
From: Don Geddis
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <87wsu6u71y.fsf@geddis.org>
are <·········@gmx.net> wrote on Sat, 29 Sep 2007:
> On 20 Sep, 18:17, Don Geddis <····@geddis.org> wrote:
>> it's highly unlikely that your original question is legitimate.  Why?
>> Because Lisp and OCaml are sufficiently different languages, that it's
>> almost inconceivable that you might have narrowed down your choice to just
>> those two.
>
> I maintain that my original question springs from a legitimate desire to
> know the answer.

OK, well then the answer is pretty simple.

Both are modern languages with well-thought-out designs, and passionate
user communities.

In terms of the abstract programming language design, OCaml highlights
static type checking (with extensive type inference) and pattern matching
as a style of programming functions.

Common Lisp is a multi-paradigm language specializing especially in dynamic
typing, macros (= defining domain-specific sublanguage), and eval (= treating
code as data).

The problem is, I don't see how you can possibly use this information to help
you.  You already admit that you don't know much about different programming
languages, so I'm unsure how my descriptions -- true though they might be --
can help you make a choice between the two for your personal use.

Meanwhile, the topics that matter for a real programming language choice on a
real project, are often only loosely related to the abstract design of the
programming language.  Surely you must also care about things like: how large
and robust is the user community; are there library routines to do the kinds
of computations that you're interested in; does it run on the platform you
care about; what are the licensing terms for the use you have in mind; are
there textbooks or courses you have access to that can help you learn; do you
know anyone personally who is also using the language; etc.

In short, I don't think the question you asked ("what are the technical
differences in the design of these two languages") will actually help you
resolve the real problem you claim to have ("which language should I use for
my next project").

(This is all leaving aside Pascal's apropos comment that your question echoed
a recent bad-faith thread on exactly the same topic, where the appearance --
but not the actual intent -- was an "objective" comparison of the two
languages.)

        -- Don
_______________________________________________________________________________
Don Geddis                  http://don.geddis.org/               ···@geddis.org
If being an eagle is such a good idea, why are there so few of them?
	-- Wally, from Dilbert
From: are
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <1191287231.986037.246140@w3g2000hsg.googlegroups.com>
On 1 Oct, 17:35, Don Geddis <····@geddis.org> wrote:
>
> Both are modern languages with well-thought-out designs, and passionate
> user communities.

Yeah, I'd say the passion has been coming through loud and clear! :)

> In terms of the abstract programming language design, OCaml highlights
> static type checking (with extensive type inference) and pattern matching
> as a style of programming functions.
>
> Common Lisp is a multi-paradigm language specializing especially in dynamic
> typing, macros (= defining domain-specific sublanguage), and eval (= treating
> code as data).
>
> The problem is, I don't see how you can possibly use this information to help
> you.  You already admit that you don't know much about different programming
> languages, so I'm unsure how my descriptions -- true though they might be --
> can help you make a choice between the two for your personal use.

Thanks -- that *does* help.  It confirms that I already know the core
concepts in Lisp. Now the question I need to pursue is how effectively
I can apply those concepts in my own work.  As for OCaml, I'd picked
up on its rigorous static type and type inference.  I wasn't aware of
the pattern-matching approach to functions, but at least I know what
pattern matching is.

The other thing I want to focus on from here is the big-picture issue
of static vs. dynamic. dynamic. Most of my programming experience is
static and it's still not obvious to what's so great about dynamic.

> Meanwhile, the topics that matter for a real programming language choice on a
> real project, are often only loosely related to the abstract design of the
> programming language.  Surely you must also care about things like: how large
> and robust is the user community; are there library routines to do the kinds
> of computations that you're interested in; does it run on the platform you
> care about; what are the licensing terms for the use you have in mind; are
> there textbooks or courses you have access to that can help you learn; do you
> know anyone personally who is also using the language; etc.

Sure, I *do* care about these things, and I have mentioned some of
them earlier in this thread. These are the reasons, for example, that
I would not consider Clean (no community) or F# (restricts me to
Windows). As far as I can tell, Lisp and OCaml would both be
acceptable from these points of view.
From: Kent M Pitman
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <u4phaj7eq.fsf@nhplace.com>
are <·········@gmx.net> writes:

> The other thing I want to focus on from here is the big-picture issue
> of static vs. dynamic. dynamic. Most of my programming experience is
> static and it's still not obvious to what's so great about dynamic.

It may depend a lot on your problem.  Dynamic is often a lot about
problems that are not well-specified, prone to change, etc.  Not all
problems are like that.  If you're writing a static program, you've
often analyzed something thoroughly, and that's exactly not the
character of the problems Lisp is built for--it's built for the problems
that change all the time, that have exceptions, that aren't homogenous
and pretty at all the edges.  Its interface boundaries and update strategies
are carefully honed over the year to allow updates to programs or partial
programs dynamically while an image is running in a way that makes you
not have to stop the program to receive updates.  Most languages don't
care about that.  Even things like the JVM and CLR that dynamically load
code don't give adequate attention to unloading of code.

For dynamic, think "freedom", and for static, think "safety".  Then
ask yourself how two reasonable might have different theories (in the
real world, I mean) about how much infringement of their freedom they
can take in exchange for how much safety.  (We have that problem going
on every day in the US with the Patriot Act, etc.)  A lot of people
don't use all their freedoms and don't mind them restricted, but some
people mind a lot.  So striking a balance is hard, and it's harder
still because not everyone agrees on what's important to have, or
what's easy to do without. A lot of it comes down to personal style.
In such dialogs, it's often asked by one party "but couldn't you just
do x instead" when talking about getting around either a problem with
freedom or a problem with safety, but usually x involves a different
"style of being" and isn't as easy for others as it sounds.  Saying to
someone "couldn't you just ride the subway" (or "drive a car") isn't
always easy, and yet to the person speaking it may seem totally easy,
so it makes it hard for people to see eye-to-eye.  Similar issues come
up with food issues and health. ("Couldn't you just always eat fish
instead of red meat?"  "Couldn't you just avoid sugar?"  The word
"just" is always in there somewhere, suggesting a misunderstanding of
how easy something is when it's a lifestyle choice.)

In practice, the computer analog is really not about power, although
the champions of type safety always look for the answers there.
Looking to "what can I compute" becomes an exercise in futility
because most languages are Turing machines and there's nothing more to
be said.  But the real issue comes to how much song and dance one must
do in order to avail themselves of dynamicity.  I personally hate how
in most static type systems, I pass something from point A to point B
through some intermediary who thinks the thing is just an Object, but
then point B can't just call some type-specific operation on the thing
because he has to first downcast it to a narrower type.  In Lisp, the
notation hides that part, yes, at the possible cost of some dynamic
errors at runtime.  Those things matter to Lispers.  Static people see
them as potential bugs, while dynamic people see them as potential
infringements of liberty.

It's said that a Republican is a Democrat who has been mugged, or a
Democrat is a Republican who has been arrested.  Issues of type safety
and dynamicity are surely subject to similar metaphors and
point-of-view effects.  You must be careful as you observe the 
situation not to discount very subtle differences that may seem 
unimportant to you but could be quite important to others.

For example, most Lispers just don't worry that much about getting
type errors at compile time--sometimes it's even an impediment. In
fact, one debugging technique I use (not every day, but often enough
to be of note) is to go ahead and run a half-written program, or feed
it not-really-right data (perhaps ill-formed or incomplete or
otherwise not the real thing), and just see how far the program gets,
then write more of it while in the debugger once I can see some
partial program state.  One of the things I find MOST irritating about
static languages is having to have a complete and/or well-formed
program before I can start running it.  That's a HUGE barrier to me.
Lisp is really quite tolerant of leaving out big gaping pieces of
program and still bumbling through it.  That makes it very easy to
stub something together, just to see what happens.
From: are
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <1191321391.193467.292640@57g2000hsv.googlegroups.com>
On 2 Oct, 08:35, Kent M Pitman <······@nhplace.com> wrote:
> are <·········@gmx.net> writes:
> > The other thing I want to focus on from here is the big-picture issue
> > of static vs. dynamic. dynamic. Most of my programming experience is
> > static and it's still not obvious to what's so great about dynamic.
>
> It may depend a lot on your problem.  Dynamic is often a lot about
> problems that are not well-specified, prone to change, etc.  Not all
> problems are like that.  If you're writing a static program, you've
> often analyzed something thoroughly, and that's exactly not the
> character of the problems Lisp is built for--it's built for the problems
> that change all the time, that have exceptions, that aren't homogenous
> and pretty at all the edges.  Its interface boundaries and update strategies
> are carefully honed over the year to allow updates to programs or partial
> programs dynamically while an image is running in a way that makes you
> not have to stop the program to receive updates.

I usually think of my problems and therefore my programs as being
static. In practice, however, I often find that the finished product,
to the extent that it is ever really finished, has migrated quite some
distance from what I thought it would be.  Perhaps I'm at heart a
dynamicist whose become inhibited by years of working in static
languages.

> For dynamic, think "freedom", and for static, think "safety".  Then
> ask yourself how two reasonable might have different theories (in the
> real world, I mean) about how much infringement of their freedom they
> can take in exchange for how much safety.  (We have that problem going
> on every day in the US with the Patriot Act, etc.)

Don't get me started on the Patriot Act and the like!  Last week I got
into an argument with the TSA employee who thought it his duty to
search my carry-on luggage solely because a private company (the
airline on which I was flying) thought it would be a good idea and
would not acknowledge that the TSA's invasion of my privacy was in any
way an imposition on me.  <flame off>  Anyway, despite my complaint I
avoided being sent to Guantanamo Bay and am for the time being still
free to reflect on the irony that my own programming technique has
been highly defensive, i.e., static.

> A lot of people
> don't use all their freedoms and don't mind them restricted, but some
> people mind a lot.  So striking a balance is hard, and it's harder
> still because not everyone agrees on what's important to have, or
> what's easy to do without. A lot of it comes down to personal style.
> In such dialogs, it's often asked by one party "but couldn't you just
> do x instead" when talking about getting around either a problem with
> freedom or a problem with safety, but usually x involves a different
> "style of being" and isn't as easy for others as it sounds.  Saying to
> someone "couldn't you just ride the subway" (or "drive a car") isn't
> always easy, and yet to the person speaking it may seem totally easy,
> so it makes it hard for people to see eye-to-eye.  Similar issues come
> up with food issues and health. ("Couldn't you just always eat fish
> instead of red meat?"  "Couldn't you just avoid sugar?"  The word
> "just" is always in there somewhere, suggesting a misunderstanding of
> how easy something is when it's a lifestyle choice.)
>
> In practice, the computer analog is really not about power, although
> the champions of type safety always look for the answers there.
> Looking to "what can I compute" becomes an exercise in futility
> because most languages are Turing machines and there's nothing more to
> be said.  But the real issue comes to how much song and dance one must
> do in order to avail themselves of dynamicity.  I personally hate how
> in most static type systems, I pass something from point A to point B
> through some intermediary who thinks the thing is just an Object, but
> then point B can't just call some type-specific operation on the thing
> because he has to first downcast it to a narrower type.  In Lisp, the
> notation hides that part, yes, at the possible cost of some dynamic
> errors at runtime.  Those things matter to Lispers.  Static people see
> them as potential bugs, while dynamic people see them as potential
> infringements of liberty.

Sometimes one can turn off type checking for a variable. Wouldn't that
pretty much give you the best of both worlds in this case? Just (yeah,
yeah, I know, I'm imposing my own life-style choice by using that
word :)) turn off type checking for the variable that passes through
the intermediary without being otherwise referenced.

> It's said that a Republican is a Democrat who has been mugged, or a
> Democrat is a Republican who has been arrested.  Issues of type safety
> and dynamicity are surely subject to similar metaphors and
> point-of-view effects.  You must be careful as you observe the
> situation not to discount very subtle differences that may seem
> unimportant to you but could be quite important to others.
>
> For example, most Lispers just don't worry that much about getting
> type errors at compile time--sometimes it's even an impediment. In
> fact, one debugging technique I use (not every day, but often enough
> to be of note) is to go ahead and run a half-written program, or feed
> it not-really-right data (perhaps ill-formed or incomplete or
> otherwise not the real thing), and just see how far the program gets,
> then write more of it while in the debugger once I can see some
> partial program state.  One of the things I find MOST irritating about
> static languages is having to have a complete and/or well-formed
> program before I can start running it.  That's a HUGE barrier to me.
> Lisp is really quite tolerant of leaving out big gaping pieces of
> program and still bumbling through it.  That makes it very easy to
> stub something together, just to see what happens.

Question: one can declare types in Lisp; if one always declared types,
would Lisp be effectively statically typed, or is there some way in
which Lisp would still not be static?
From: Kent M Pitman
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <uzlz1iq24.fsf@nhplace.com>
are <·········@gmx.net> writes:

> Sometimes one can turn off type checking for a variable. Wouldn't that
> pretty much give you the best of both worlds in this case? 

It's mostly about dispatch, and very little about checking.  One of
the features most useful about CLOS and most impossible in other
languages is the ability to directly dispatch on the representational
type, not the declared type.

   (defmethod zap ((x t)) 'any)

   (defclass foo () ())
   (defmethod zap ((x foo)) 'foo)

   (defclass bar () ())
   (defmethod zap ((x bar)) 'bar)

   (defclass foo2 (foo) ())
   (defmethod zap ((x foo2)) 'foo2)

   (mapcar #'zap (mapcar 'make-instance '(foo bar foo2)))

Other languages typically make this kind of thing tough.
(I didn't test this example 'cuz I'm in a hurry.)

> Question: one can declare types in Lisp; if one always declared types,
> would Lisp be effectively statically typed, or is there some way in
> which Lisp would still not be static?

No, because in CL the very definition of type declaration is
different.  It's about promising something to the implementation that
the implementation may not be able to prove, and having it trust you.
And it DOESN'T interfere with dispatching.  It's about that these are
all the same, that type declaration doesn't change them:

  (defun checker (myfoo mybar myfoo2)
    (declare (type foo myfoo myfoo2))
    (declare (type bar mybar))
    (list (zap foo) (zap bar) (zap foo2)))

  (defun checker (myfoo mybar myfoo2)
    (declare (type foo  myfoo))
    (declare (type bar  mybar))
    (declare (type foo2 myfoo2))
    (list (zap foo) (zap bar) (zap foo2)))

  (defun checker (myfoo mybar myfoo2)
    (declare (type t  myfoo))
    (declare (type t  mybar))
    (declare (type t myfoo2))
    (list (zap foo) (zap bar) (zap foo2)))
From: Jeronimo Pellegrini
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <fdtetq$hfk$1@aioe.org>
On 2007-10-02, are <·········@gmx.net> wrote:
> Question: one can declare types in Lisp; if one always declared types,
> would Lisp be effectively statically typed, or is there some way in
> which Lisp would still not be static?

If you build a dialect on top of Common Lisp, you can have very nice
thing such as Qi, which has optional static typing:
http://lambdassociates.org/
Also, check Drew McDermott's Nisp: http://cs-www.cs.yale.edu/homes/dvm/
In both cases, you stil have Common Lisp available.

J.
From: Jon Harrop
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <13g8827k9fmakea@corp.supernews.com>
are wrote:
> Sometimes one can turn off type checking for a variable. Wouldn't that
> pretty much give you the best of both worlds in this case?

There is no need to restrict type checking to either fully on or fully off.
Only with modern functional programming languages are you free to choose
from across the whole spectrum from few to many constraints. Choosing few
constraints gives you all of the advantages of the dynamic style by making
it easy to evolve code organically during development. Choosing to apply
many constraints catches a lot more bugs and should always be done for
production code.

For few constraints, use tuples and open sum types in OCaml:

# let x = `A 3;;
val x : [> `A of int] = `A 3

or cast to the universal "obj" type using the "box" function in F#:

> let x = box 3;;
val x : obj

For more constraints, use explicitly declared types like records and closed
sum types in either OCaml or F#:

# type t = A of int | B of float;;
type t = A of int | B of float;;
# let x = A 3;;
val x : t = A 3

In reality, you'll quickly learn when the freedom is worth having and when
the constraints are worth having but the point is that only static typing
gives you the freedom to choose.

> Just (yeah, 
> yeah, I know, I'm imposing my own life-style choice by using that
> word :)) turn off type checking for the variable that passes through
> the intermediary without being otherwise referenced.

No need: that is already done automatically in all of these languages, the
inferred type will be a type variable:

# let f x = x;;
val f : 'a -> 'a = <fun>

The type variable 'a of the unused value "x" can be any type.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
From: Jon Harrop
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <13g87r6lubvk3e9@corp.supernews.com>
I disagree with the opinion, of course, but there is one factual point as
well:

Kent M Pitman wrote:
> ...Even things like the JVM and CLR that dynamically load code don't give
> adequate attention to unloading of code...

How does the CLR not "give adequate attention to unloading of code"?

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
From: Kent M Pitman
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <ud4vvr9ld.fsf@nhplace.com>
Jon Harrop <···@ffconsultancy.com> writes:

> I disagree with the opinion, of course, but there is one factual point as
> well:
> 
> Kent M Pitman wrote:
> > ...Even things like the JVM and CLR that dynamically load code don't give
> > adequate attention to unloading of code...
> 
> How does the CLR not "give adequate attention to unloading of code"?

My understanding is that one cannot unload an assembly (other than by
throwing away its containing domain, which is a bit heavyweight).

A quick search for "unload an assembly" on google turns up a lot of results
that tell the following basic story:
 http://blogs.msdn.com/jasonz/archive/2004/05/31/145105.aspx
Perhaps you know of something else.  But regardless, whether you agree or
disagree, this was the issue that I was referring to.
From: Jon Harrop
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <13g8ssbaj24pq04@corp.supernews.com>
Kent M Pitman wrote:
> My understanding is that one cannot unload an assembly (other than by
> throwing away its containing domain, which is a bit heavyweight).
> 
> A quick search for "unload an assembly" on google turns up a lot of
> results that tell the following basic story:
>  http://blogs.msdn.com/jasonz/archive/2004/05/31/145105.aspx
> Perhaps you know of something else.  But regardless, whether you agree or
> disagree, this was the issue that I was referring to.

Hmm, I was wondering why metaprogramming wasn't more prolific on .NET. I
think you've just answered my question...

Quite a few pages describe dynamic unloading in Java though. I get the
impression that it works in Java but will probably never work in .NET,
which really sucks.

How does Lisp handle this? Is code just garbage collected along with data?

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
From: Pascal Costanza
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <5mjlgjFdrhvpU1@mid.individual.net>
Jon Harrop wrote:
> Kent M Pitman wrote:
>> My understanding is that one cannot unload an assembly (other than by
>> throwing away its containing domain, which is a bit heavyweight).
>>
>> A quick search for "unload an assembly" on google turns up a lot of
>> results that tell the following basic story:
>>  http://blogs.msdn.com/jasonz/archive/2004/05/31/145105.aspx
>> Perhaps you know of something else.  But regardless, whether you agree or
>> disagree, this was the issue that I was referring to.
> 
> Hmm, I was wondering why metaprogramming wasn't more prolific on .NET. I
> think you've just answered my question...
> 
> Quite a few pages describe dynamic unloading in Java though. I get the
> impression that it works in Java but will probably never work in .NET,
> which really sucks.

It works in Java, but is also quite hard to achieve. You have to 
especially prepare your code for that and have to jump through a few 
hoops to make sure that it works. (Basically, you have to make sure that 
you use your own classloaders, which you can then unload. Classes that 
are loaded in the usual way cannot be unloaded.)

> How does Lisp handle this? Is code just garbage collected along with data?

In Lisp, code and data are the same. So, yes, of course. ;)

However, that alone wouldn't suffice. CLOS actually gives you a number 
of protocols which makes these things very convenient to use. You'd have 
to learn CLOS, though, to understand this.


Pascal

-- 
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
From: Jon Harrop
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <13gaib3gi4feca7@corp.supernews.com>
Pascal Costanza wrote:
> It works in Java, but is also quite hard to achieve. You have to
> especially prepare your code for that and have to jump through a few
> hoops to make sure that it works. (Basically, you have to make sure that
> you use your own classloaders, which you can then unload. Classes that
> are loaded in the usual way cannot be unloaded.)

When you say "unload" do you mean the resource must be managed manually and
is not GCd?

>> How does Lisp handle this? Is code just garbage collected along with
>> data?
> 
> In Lisp, code and data are the same. So, yes, of course. ;)

Good.

> However, that alone wouldn't suffice. CLOS actually gives you a number
> of protocols which makes these things very convenient to use. You'd have
> to learn CLOS, though, to understand this.

Sure. I'm surprised anyone would do it differently. This certainly explains
why MS tout hetereogeneous metaprogramming targetting anything but .NET.

Lisp one, .NET nil...

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
From: Pascal Costanza
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <5mla7sFe60iaU1@mid.individual.net>
Jon Harrop wrote:
> Pascal Costanza wrote:
>> It works in Java, but is also quite hard to achieve. You have to
>> especially prepare your code for that and have to jump through a few
>> hoops to make sure that it works. (Basically, you have to make sure that
>> you use your own classloaders, which you can then unload. Classes that
>> are loaded in the usual way cannot be unloaded.)
> 
> When you say "unload" do you mean the resource must be managed manually and
> is not GCd?

If I remember correctly, a class loader, and all its classes, is 
automatically garbage collected if there is no reference to the class 
loader anymore. But take this with a grain of salt, it has been some 
time since I last looked at that.


Pascal

-- 
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
From: Pascal Costanza
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <5melgcFd4p7bU1@mid.individual.net>
are wrote:
> On 1 Oct, 17:35, Don Geddis <····@geddis.org> wrote:
>> Both are modern languages with well-thought-out designs, and passionate
>> user communities.
> 
> Yeah, I'd say the passion has been coming through loud and clear! :)
> 
>> In terms of the abstract programming language design, OCaml highlights
>> static type checking (with extensive type inference) and pattern matching
>> as a style of programming functions.
>>
>> Common Lisp is a multi-paradigm language specializing especially in dynamic
>> typing, macros (= defining domain-specific sublanguage), and eval (= treating
>> code as data).
>>
>> The problem is, I don't see how you can possibly use this information to help
>> you.  You already admit that you don't know much about different programming
>> languages, so I'm unsure how my descriptions -- true though they might be --
>> can help you make a choice between the two for your personal use.
> 
> Thanks -- that *does* help.  It confirms that I already know the core
> concepts in Lisp. Now the question I need to pursue is how effectively
> I can apply those concepts in my own work.  As for OCaml, I'd picked
> up on its rigorous static type and type inference.  I wasn't aware of
> the pattern-matching approach to functions, but at least I know what
> pattern matching is.
> 
> The other thing I want to focus on from here is the big-picture issue
> of static vs. dynamic. Most of my programming experience is
> static and it's still not obvious to what's so great about dynamic.

Static type systems allow you to express invariants about your code that 
can be automatically checked in order to give guarantees about some 
characteristics of your program. The downside is that you cannot 
(easily) change these invariants anymore later on. As Alan Perlis said, 
one man's constant is another man's variable.

Dynamic type systems by themselves give you flexibility in your 
development process. Basically, you can run programs without having to 
convince the compiler that you got all your types correct. There are 
situations, where you don't care about having _all_ types correct in 
_all_ places of your program, if the only thing you want is to test one 
specific part of it.

Furthermore, static checks cannot guarantee that your programs are 
actually "correct" - you don't know whether your program does what you 
expect it to do until you actually run it. For that reason, many people 
don't trust programs that haven't been tested extensively. However, it 
seems to be the case that once you have an extensive test suite for your 
program, the correctness of your types is silently tested as well - a 
program would simply fail at least some test cases if the types weren't 
"correct." So why test the types twice, and especially, why putting up 
with the involved overhead twice?

[Yes, there is the objection that test cases only provide evidence for 
single data points, whereas static type checks give guarantees for all 
possible cases, but that's a theoretical claim. I am talking about 
actual experience here. There is also the experience from people using 
advanced static type systems who claim that once they get the types 
right, their programs actually _are_ correct. The reason here may simply 
be that different programmers prefer different programming approaches 
for subjective reasons. All such claims about when programs and their 
types are actually observably correct, both from the dynamic and static 
camps, are anecdotal and cannot be proved right or wrong.]

However, there is yet another level to this debate: It can be beneficial 
to be able to evolve a program at runtime, in the sense that you cannot 
only change the values that variables are bound to, but also function 
and method definitions, class definitions and other entities that make 
up your program. If you perform such changes programmatically, you 
basically have self-modifying programs. Although the notion of a 
self-modifying program has a bad reputation, there are actually 
programming techniques that make such self-modifying programs feasible 
and reasonably well to deal with. Lisp is an especially good basis for 
such techniques (more so than Scheme or Smalltalk, which are 
nevertheless also pretty good at that).

Evolving programs at runtime helps you, at least, with developing and 
testing large systems, when you don't want to shut down and restart a 
system just because you changed a few definitions here and there. It can 
also help you with deployment, for example when running server 
applications where you don't want to shut them down for software updates 
in order to decrease downtimes. There are even cooler applications for that.

Common Lisp is especially remarkable because it provides this kind of 
runtime flexibility while staying reasonably efficient in terms of 
execution performance - much better than, say, Python, Ruby, and such 
dynamic languages which are typically chosen in such scenarios. Common 
Lisp also provides enough rope to tweak programs to such an extent that 
you can squeeze out a lot of efficiency, to the degree that you can 
write programs that are on par with static languages, like C, C++, etc. 
You typically have to make trade offs here, when you do that: Whenever 
you improve the performance of a Common Lisp programs, you typically 
lose some of the runtime flexibility. But Common Lisp is nevertheless 
exceptional in that regard because it actually enables you to make these 
choices yourself, and doesn't require you to buy into whatever model the 
designers of other languages happened to prefer.

This all is related to the discussion about static vs. dynamic types 
because, to the best of my knowledge, it is not possible to combine this 
kind of runtime flexibility with static type checking. As soon as a 
program is able to modify itself, static types simply loose. And for 
some (including me), runtime flexibility is far more important than the 
illusion of safety static type systems give you.

Just my 0.02�.


Pascal

-- 
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
From: Jon Harrop
Subject: When static typing is worth it
Date: 
Message-ID: <13g5chf12v686d8@corp.supernews.com>
Some counters here:

Pascal Costanza wrote:
> However, it
> seems to be the case that once you have an extensive test suite for your
> program, the correctness of your types is silently tested as well - a 
> program would simply fail at least some test cases if the types weren't
> "correct." So why test the types twice, and especially, why putting up
> with the involved overhead twice?

Two points here:

. Your argument assumes that static and dynamic solutions require the same
amount of testing. They do not. Static typing typically reduces the need
for unit testing by 10-100x, to the point where automated unit tests and
debuggers are no longer a crippling concern as they are in dynamically
typed languages like Lisp.

. Compiling is typically much faster than testing and testing sufficiently
can be prohibitively slow. Consequently, non-trivial applications can be
developed more quickly in modern statically typed languages than
dynamically typed ones.

> [Yes, there is the objection that test cases only provide evidence for
> single data points, whereas static type checks give guarantees for all
> possible cases, but that's a theoretical claim. I am talking about
> actual experience here. There is also the experience from people using
> advanced static type systems who claim that once they get the types
> right, their programs actually _are_ correct. The reason here may simply
> be that different programmers prefer different programming approaches
> for subjective reasons. All such claims about when programs and their
> types are actually observably correct, both from the dynamic and static
> camps, are anecdotal

For example:

  http://members.verizon.net/~olsongt/c3a/

> and cannot be proved right or wrong.] 

On the contrary, the literature is full of examples demonstrating static
type systems proving correctness, e.g. one paper describes how static
typing can be used to prove that balanced binary tree implementations
retain balancing properties.

In my case, I am often able to prove that run-time errors have been removed
from a block of code by progressively rephrasing the code to leverage the
static type system and remove run-time checks.

As a trivial example, consider a function that requires a sequence that must
contain at least one element:

# let rec reduce f = function
    | [h] -> h
    | h::t -> f h (reduce f t)
    | _ -> raise Not_found;;
val reduce : ('a -> 'a -> 'a) -> 'a list -> 'a = <fun>
# reduce (@) [[1]; [2]; [3]];;
- : int list = [1; 2; 3]
# reduce (@) [];;
Exception: Not_found.

The last clause in the pattern match:

    | _ -> raise Not_found

incurs a run-time error (raising the Not_found exception) if the list is
empty. This exception should never occur but it will if the calling
function has a bug and calls this function with the empty list.

In a dynamic language like Lisp, you must therefore unit test all callers of
this function and try to find any that accidentally call it with the empty
list. This typically requires you to test many of their callers and so on.
This is like searching for a needle in a haystack. Not only are you
completely unable to eliminate the bugs, you cannot even quantify your
confidence in the code.

You might sit down with a pencil and try to prove your code correct.

Better yet, you might get the computer to check the proof directly from the
code.

Ideally, the computer would not only infer the proof from your code but it
would also provide machine-verified documentation synchronized with the
proof such that the proving and documenting are performed automatically
every incremental compilation and evolve as the code is developed. Modern
statically-typed functional programming languages let you do exactly this
easily.

In SML, OCaml, Haskell, F# or Scala, you can rewrite this function such that
the static type system proves that the sequence given to this function
contains at least one element:

# let rec reduce f (h, t) = match t with
    | [] -> h
    | h2::t -> f h (reduce f (h2, t))
    | _ -> raise Not_found;;
Warning U: this match case is unused.
val reduce : ('a -> 'a -> 'a) -> 'a * 'a list -> 'a = <fun>

The OCaml compiler even tells you that the pattern match clause that raises
the run-time error is now unused, proving that this run-time error can
never occur. So we can simply remove it and the OCaml compiler even proves
that this can be done safely (if it were not safe, it would give
an "inexhaustive" warning):

# let rec reduce f (h, t) = match t with
    | [] -> h
    | h2::t -> f h (reduce f (h2, t));;
val reduce : ('a -> 'a -> 'a) -> 'a * 'a list -> 'a = <fun>
# reduce (@) ([1], [2]::[3]::[]);;
- : int list = [1; 2; 3]

Note that the "raise Not_found" has disappeared. We have completely
eliminated this source of run-time errors by getting the static type system
to prove that this run-time error can never occur. All code that uses this
is now guaranteed to be correct in this sense. The type inferred by the
compiler constitutes the machine-verified documentation.

With a powerful static type system (e.g. SML, OCaml, F# or Haskell), you can
eliminate a lot of run-time errors by getting the compiler to prove that
they cannot occur. This is precisely why the modern languages are vastly
superior and represent the evolution of Lisp.

> However, there is yet another level to this debate: It can be beneficial
> to be able to evolve a program at runtime, in the sense that you cannot
> only change the values that variables are bound to, but also function
> and method definitions, class definitions and other entities that make
> up your program. If you perform such changes programmatically, you
> basically have self-modifying programs.

From the static point of view, this is just run-time dispatch and
consequently, is solved using pattern matching in all modern FPLs.

> Although the notion of a 
> self-modifying program has a bad reputation, there are actually
> programming techniques that make such self-modifying programs feasible
> and reasonably well to deal with. Lisp is an especially good basis for
> such techniques (more so than Scheme or Smalltalk, which are
> nevertheless also pretty good at that).

Few modern FPLs provide run-time compilation (MetaOCaml and F# are two) but
it is rarely useful compared to, for example, pattern matching.

> Evolving programs at runtime helps you, at least, with developing and
> testing large systems, when you don't want to shut down and restart a
> system just because you changed a few definitions here and there. It can
> also help you with deployment, for example when running server
> applications where you don't want to shut them down for software updates
> in order to decrease downtimes. There are even cooler applications for
> that.

When you first hear about it, self-modifying code certainly does sound like
a very cool idea with cool applications. However, you only need to toy with
it to discover how it can completely undermine the reliability of any
significant software system. Consequently, prolific use of self-modifying
code is widely known to be fraught with peril and any good software
developer should know that it is bad practice except in the rarest of
circumstances.

The static solution is to provide flexibility by explicitly parameterizing
code over data. This clarifies all dependencies and prevents the rats-nest
characteristic that makes the dynamic approach unmaintainable. You are free
to change the data at run-time but you may also add an arbitrary amount of
static checking to your code. This provides the same spectrum of
flexibility but with a different trade-off in terms of ease of use. Some
systems (e.g. F#) provide the best of both worlds by combining run-time
code generation and collection with both static and dynamic typing. Lisp
provides an entirely dynamic approach with only the most rudimentary forms
of static checking provided inconsistently across compilers.

> Common Lisp is especially remarkable because it provides this kind of
> runtime flexibility while staying reasonably efficient in terms of
> execution performance - much better than, say, Python, Ruby, and such
> dynamic languages which are typically chosen in such scenarios. Common
> Lisp also provides enough rope to tweak programs to such an extent that
> you can squeeze out a lot of efficiency, to the degree that you can
> write programs that are on par with static languages, like C, C++, etc.

The ray tracer language comparison showed that Lisp is harder to optimize
and still slower that many static languages:

  http://www.ffconsultancy.com/languages/ray_tracer/results.html

The Lisp community were far more disgruntled with Lisp's appalling initial
performance results than any other community so they put much more effort
into optimizing the Lisp implementations. I received only a handful of
tweaks for the implementations in other languages but dozens of Lisp
implementations, almost all of which were substantially slower and longer
than Juho's.

Arguably the most vocal Lisp extremist of the time was Dr Thomas
Fischbacher, an expert in high performance computing from the Max Planck
Institute in Germany who was vehemently opposed to my language comparison
for many months, disgusted by the results, and he tried desperately to
improve Lisp's abysmal results:

  http://groups.google.co.uk/group/comp.lang.functional/msg/e48420d41e74f38e

His best implementation of the ray tracer was not only slower than Juho's
but was seven times longer than faster OCaml versions. Perhaps this is why
Thomas is now an OCaml programmer:

http://groups.google.co.uk/groups/search?q=%2B%22Thomas+Fischbacher%22&start=0&scoring=d&hl=en&ie=UTF-8&oe=UTF-8&safe=off&

In the intervening years, I have been lucky enough to participate in many
programming language performance comparisons and Lisp has fared terribly in
all but one (the Minim compiler, where Lisp's run-time compilation is an
advantage) where is was average. For example, the symbolic simplifier
benchmark by Mark Tarver demonstrates how the optimizing pattern match
compilers found in all modern functional programming languages place these
static languages a league ahead of Lisp in terms of performance, clarity
and development time:

  http://www.lambdassociates.org/studies/study10.htm

As this result applies to a wide variety of real programming challenges,
perhaps Mark will also ditch Lisp and become an OCaml programmer. All of
the intelligent Lispers seem to be.

> You typically have to make trade offs here, when you do that: Whenever
> you improve the performance of a Common Lisp programs, you typically
> lose some of the runtime flexibility. But Common Lisp is nevertheless
> exceptional in that regard because it actually enables you to make these
> choices yourself, and doesn't require you to buy into whatever model the
> designers of other languages happened to prefer.

On the contrary, Lisp forces you to buy into the designer's dynamic style.
You cannot automate the static checking of even the most trivial of
constraints in Lisp, let alone prove valuable assurances about critical
parts of your program as you can do so easily with modern statically-typed
languages.

Obtaining dynamic behaviour in a static language is trivial (just box and
parameterize) but obtaining static behaviour in a dynamic language is a
practical impossibility.

> This all is related to the discussion about static vs. dynamic types
> because, to the best of my knowledge, it is not possible to combine this
> kind of runtime flexibility with static type checking. As soon as a
> program is able to modify itself, static types simply loose. And for
> some (including me), runtime flexibility is far more important than the
> illusion of safety static type systems give you.

Both in industry and in academia, the benefits of static typing are widely
appreciated.

If you want your code to work, choose static typing. If you're getting paid
in cash for lashing together porn sites, choose dynamic typing.

For thorough demonstrations of the superiority of modern statically-typed
functional programming languages, subscribe to our journals:

  http://www.ffconsultancy.com/products/ocaml_journal/?cll
  http://www.ffconsultancy.com/products/fsharp_journal/?cll

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
From: ···············@gmail.com
Subject: Re: When static typing is worth it
Date: 
Message-ID: <1191362821.052036.238660@k79g2000hse.googlegroups.com>
On Oct 2, 9:54 pm, Jon Harrop <····@ffconsultancy.com> wrote:

> . Your argument assumes that static and dynamic solutions require the same
> amount of testing. They do not. Static typing typically reduces the need
> for unit testing by 10-100x, to the point where automated unit tests and
> debuggers are no longer a crippling concern as they are in dynamically
> typed languages like Lisp.

I don't write unit tests to make up for a deficiency in the type
system but to verify that my program logic is correct. Type
correctness is but a very small part of this.

> The last clause in the pattern match:
>
>     | _ -> raise Not_found
>
> incurs a run-time error (raising the Not_found exception) if the list is
> empty.

Your example of pattern matching to check for empty lists doesn't seem
like a type checking concern but more like a pre-condition test.

> In a dynamic language like Lisp, you must therefore unit test all callers of
> this function and try to find any that accidentally call it with the empty
> list.

Why can't you just test for the empty list in the function and act
accordingly?

Sorry I'm probably missing something obvious but I'm not convinced by
any of these arguments.

--
Phil
http://phil.nullable.eu/
From: Jon Harrop
Subject: Re: When static typing is worth it
Date: 
Message-ID: <13g5mspml06vofc@corp.supernews.com>
···············@gmail.com wrote:
> I don't write unit tests to make up for a deficiency in the type
> system but to verify that my program logic is correct. Type
> correctness is but a very small part of this.

In dynamically typed languages like Lisp or static languages with poor type
systems, yes. Modern functional programming languages have much more
expressive type systems that allow you to convey a lot more program logic
to the type checker, which then does much more useful checking, eliminating
many more bugs and obviating much of the need for unit testing.

Consequently, unit testing is comparatively rare in these languages. For
example, I wrote 50kLOC of custom object marshalling code in OCaml and the
client insisted on unit testing it. OCaml's powerful static type system
caught many bugs and 24hrs of running unit tests caught precisely zero
bugs. From experience, I already knew the unit tests would be a waste of
time.

>> The last clause in the pattern match:
>>
>>     | _ -> raise Not_found
>>
>> incurs a run-time error (raising the Not_found exception) if the list is
>> empty.
> 
> Your example of pattern matching to check for empty lists doesn't seem
> like a type checking concern but more like a pre-condition test.

Exactly, yes. A pre-condition test that is an inherent risk of unwanted
run-time errors in a dynamic language. Static checking allows you to
eliminate that risk safely.

>> In a dynamic language like Lisp, you must therefore unit test all callers
>> of this function and try to find any that accidentally call it with the
>> empty list.
> 
> Why can't you just test for the empty list in the function and act
> accordingly?

If the test fails then you already gave your client buggy software. Static
typing lets you avoid that humiliation. :-)

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
From: ···············@gmail.com
Subject: Re: When static typing is worth it
Date: 
Message-ID: <1191402252.095986.10480@22g2000hsm.googlegroups.com>
On 3 Oct, 00:50, Jon Harrop <····@ffconsultancy.com> wrote:

> Consequently, unit testing is comparatively rare in these languages. For
> example, I wrote 50kLOC of custom object marshalling code in OCaml and the
> client insisted on unit testing it. OCaml's powerful static type system
> caught many bugs and 24hrs of running unit tests caught precisely zero
> bugs. From experience, I already knew the unit tests would be a waste of
> time.

Well that's the classic error of writing unit tests that you know will
pass. It gives you (or your client) a warm and fuzzy feeling when the
light goes green but in actual fact you've proved nothing at all about
your programs correctness. By admitting that you wrote these tests
knowing they were pointless you were maybe sub-consciously falling
into this trap.

But I'm interested in this idea that unit testing is unnecessary with
"modern functional languages" and I'm not dismissing it as I genuinely
fear becoming a Blub programmer. So if you don't mind, can you look at
this example of the sort of work I do and possibly give me some
pointers to how OCaml's static type system and pattern matching could
reduce my need for testing by 100x:

Our client asks us to code up a new model for our algo-trading
software. Let's say that this is some sort of spread arbitrage model.
It's quite complex so ideal for a powerful language like Lisp or
OCaml. I need to ensure that the rules of this are followed exactly
when certain market conditions arise. So firstly I need to be able to
simulate the market condition. I also need to be sure that the orders
I submit to the trading hosts at the various derivatives exchanges'
execute simultaneously or my client is going to lose lots of money.

Over to you: I'd genuinely love to know how to save myself a lot of
testing time here. And I'm sure a number of other people on c.l.l can
come up with example from their domains for which they would like to
know how OCaml or F# can help them too.

> > Why can't you just test for the empty list in the function and act
> > accordingly?
>
> If the test fails then you already gave your client buggy software.

No I haven't!! I said test for the condition and act accordingly. If
I'm stupid enough to think "act accordingly" means "dump core" then I
should find a different profession...

--
Phil
http://phil.nullable.eu/
From: Rainer Joswig
Subject: Re: When static typing is worth it
Date: 
Message-ID: <joswig-AB286E.11513203102007@news-europe.giganews.com>
In article <·······················@22g2000hsm.googlegroups.com>,
 ···············@gmail.com wrote:

> On 3 Oct, 00:50, Jon Harrop <····@ffconsultancy.com> wrote:
> 
> > Consequently, unit testing is comparatively rare in these languages. For
> > example, I wrote 50kLOC of custom object marshalling code in OCaml and the
> > client insisted on unit testing it. OCaml's powerful static type system
> > caught many bugs and 24hrs of running unit tests caught precisely zero
> > bugs. From experience, I already knew the unit tests would be a waste of
> > time.
> 
> Well that's the classic error of writing unit tests that you know will
> pass. It gives you (or your client) a warm and fuzzy feeling when the
> light goes green but in actual fact you've proved nothing at all about
> your programs correctness. By admitting that you wrote these tests
> knowing they were pointless you were maybe sub-consciously falling
> into this trap.
> 
> But I'm interested in this idea that unit testing is unnecessary with
> "modern functional languages" and I'm not dismissing it as I genuinely
> fear becoming a Blub programmer. So if you don't mind, can you look at
> this example of the sort of work I do and possibly give me some
> pointers to how OCaml's static type system and pattern matching could
> reduce my need for testing by 100x:
> 
> Our client asks us to code up a new model for our algo-trading
> software. Let's say that this is some sort of spread arbitrage model.
> It's quite complex so ideal for a powerful language like Lisp or
> OCaml. I need to ensure that the rules of this are followed exactly
> when certain market conditions arise. So firstly I need to be able to
> simulate the market condition. I also need to be sure that the orders
> I submit to the trading hosts at the various derivatives exchanges'
> execute simultaneously or my client is going to lose lots of money.
> 
> Over to you: I'd genuinely love to know how to save myself a lot of
> testing time here. And I'm sure a number of other people on c.l.l can
> come up with example from their domains for which they would like to
> know how OCaml or F# can help them too.


Are you sure that you want to discuss programming with OCAML
on comp.lang.lisp ? I'd say it is off-topic here.

If you are interested in OCAML (which is fine, btw.), then
you might want to move the discussion to comp.lang.misc, comp.lang.functional
or to a OCAML forum.

Thank you.

> 
> > > Why can't you just test for the empty list in the function and act
> > > accordingly?
> >
> > If the test fails then you already gave your client buggy software.
> 
> No I haven't!! I said test for the condition and act accordingly. If
> I'm stupid enough to think "act accordingly" means "dump core" then I
> should find a different profession...
> 
> --
> Phil
> http://phil.nullable.eu/

-- 
http://lispm.dyndns.org
From: ···············@gmail.com
Subject: Re: When static typing is worth it
Date: 
Message-ID: <1191406578.179478.111910@57g2000hsv.googlegroups.com>
On 3 Oct, 10:51, Rainer Joswig <······@lisp.de> wrote:

> Are you sure that you want to discuss programming with OCAML
> on comp.lang.lisp ? I'd say it is off-topic here.

Of course not or I wouldn't spend what little free time I have writing
open source Common Lisp software.

> If you are interested in OCAML (which is fine, btw.), then
> you might want to move the discussion to comp.lang.misc, comp.lang.functional
> or to a OCAML forum.

I don't see anyone else's techniques for discouraging him working so
why not try to disprove the arguments that are being made. I find this
more productive and potentially interesting than hurling abuse or
serving up "don't feed the troll" ASCII art.

--
Phil
http://phil.nullable.eu/
From: Ken Tilton
Subject: Re: When static typing is worth it
Date: 
Message-ID: <mcNMi.4424$GK6.527@newsfe12.lga>
···············@gmail.com wrote:
> On 3 Oct, 10:51, Rainer Joswig <······@lisp.de> wrote:
> 
> 
>>Are you sure that you want to discuss programming with OCAML
>>on comp.lang.lisp ? I'd say it is off-topic here.
> 
> 
> Of course not or I wouldn't spend what little free time I have writing
> open source Common Lisp software.
> 
> 
>>If you are interested in OCAML (which is fine, btw.), then
>>you might want to move the discussion to comp.lang.misc, comp.lang.functional
>>or to a OCAML forum.
> 
> 
> I don't see anyone else's techniques for discouraging him working so
> why not try to disprove the arguments that are being made. I find this
> more productive and potentially interesting than hurling abuse or
> serving up "don't feed the troll" ASCII art.

Agreed. And we need a chew toy now that Ron does not live here any more.

kenny

-- 
http://www.theoryyalgebra.com/

"We are what we pretend to be." -Kurt Vonnegut
From: Rainer Joswig
Subject: Re: When static typing is worth it
Date: 
Message-ID: <joswig-DE79B5.12223803102007@news-europe.giganews.com>
In article <························@57g2000hsv.googlegroups.com>,
 ···············@gmail.com wrote:

> On 3 Oct, 10:51, Rainer Joswig <······@lisp.de> wrote:
> 
> > Are you sure that you want to discuss programming with OCAML
> > on comp.lang.lisp ? I'd say it is off-topic here.
> 
> Of course not or I wouldn't spend what little free time I have writing
> open source Common Lisp software.
> 
> > If you are interested in OCAML (which is fine, btw.), then
> > you might want to move the discussion to comp.lang.misc, comp.lang.functional
> > or to a OCAML forum.
> 
> I don't see anyone else's techniques for discouraging him working so
> why not try to disprove the arguments that are being made.

These are not honest arguments. Discuss with a spammer is useless.

> I find this
> more productive and potentially interesting than hurling abuse or
> serving up "don't feed the troll" ASCII art.

Please discuss OCAML programming elsewhere. Thanks.

> 
> --
> Phil
> http://phil.nullable.eu/

-- 
http://lispm.dyndns.org
From: ···············@gmail.com
Subject: Re: When static typing is worth it
Date: 
Message-ID: <1191408503.563020.47230@19g2000hsx.googlegroups.com>
On 3 Oct, 11:22, Rainer Joswig <······@lisp.de> wrote:

> These are not honest arguments. Discuss with a spammer is useless.

Whatever label you apply to his posts, they may appear informed to
those less informed than yourself. To simply leave the statements
unchallenged is a bad idea if we want genuine new Lisp programmers to
emerge. And there are a lot of newbies reading comp.lang.lisp
(presumably including the OP) who should be free to make their
judgments based on research and facts. This is what I was trying to do
although I take your point about the OCaml slant (although I'm sure
you agree that it's hard to avoid in a thread which is essentially set
up as Lisp vs. OCaml).

--
Phil
http://phil.nullable.eu/
From: Rainer Joswig
Subject: Re: When static typing is worth it
Date: 
Message-ID: <joswig-DEFB16.13102603102007@news-europe.giganews.com>
In article <·······················@19g2000hsx.googlegroups.com>,
 ···············@gmail.com wrote:

> On 3 Oct, 11:22, Rainer Joswig <······@lisp.de> wrote:
> 
> > These are not honest arguments. Discuss with a spammer is useless.
> 
> Whatever label you apply to his posts, they may appear informed to
> those less informed than yourself. To simply leave the statements
> unchallenged is a bad idea if we want genuine new Lisp programmers to
> emerge. And there are a lot of newbies reading comp.lang.lisp
> (presumably including the OP) who should be free to make their
> judgments based on research and facts.

What should be clear is that for many experienced Lisp users
OCAML is as fine as SML, Haskell, Clean and others.

But 'we' think that Lisp has not (!) been replaced by those
and Lisp has to offer excellent support for exploratory
programming, multi-paradigm programming, interactive
programming, language-based programming among others.
Kent just a few post ago explained why he likes
to use it. Worth reading.

Some features of (Common) Lisp may look ugly, like warts.
But that is the price for a language that directly inherits ideas
from several decades. It allows you to re-explore those ideas
and at the same time use it to write very modern code.

I guess it is useless to discuss how Lisp competes with
static functional programming languages. It was never
thought to do that.

One can explore that and push the limits
forward, but keep in mind that a Mercedes Unimog
was designed to do heavy work with a flexible platform. You can
add all kinds of tools to the Unimog. It can clean streets,
cut trees in forests, carry parts of aircrafts, fight
fire, 

http://img.pcpop.com/upimg2/2005/4/12/4900210548747967.jpg
http://img.pcpop.com/upimg2/2005/4/12/11651613777993210.jpg
http://img.pcpop.com/upimg2/2005/4/12/14532718921152303.jpg

well and carry lots of people and goods:

http://www.ma.utexas.edu/~egerde/unimog.jpg   ;-)

Lisp is the Unimog of programming languages.

The Unimog makes a really bad formula one racing car.

You can use it for racing, but it is then in a different class
http://commons.wikimedia.org/wiki/Image:Unimog_u500_dakar_2006.jpg


So, it is best to discuss Lisp in the context where it
makes sense to be used. That's still a lot of areas...


> This is what I was trying to do
> although I take your point about the OCaml slant (although I'm sure
> you agree that it's hard to avoid in a thread which is essentially set
> up as Lisp vs. OCaml).
> 
> --
> Phil
> http://phil.nullable.eu/

-- 
http://lispm.dyndns.org
From: Ville Oikarinen
Subject: TDD and what tests do other than try to find bugs
Date: 
Message-ID: <Pine.LNX.4.56L0.0710030916001.4624@localhost>
I recognize the merits of both dynamic and static typing (and of no typing
at all!) so I'm not going to discuss it further.

But what is lacking in this debate is that in Test Driven Development
tests are primrarily a force that drives design. Correctness is "just" a
handy side effect. (Of course tests really _prove_ anything rarely, only
when the parameter space is finite and very limited.)

On Wed, 3 Oct 2007, Jon Harrop wrote:

> > Why can't you just test for the empty list in the function and act
> > accordingly?
> 
> If the test fails then you already gave your client buggy software. Static
> typing lets you avoid that humiliation. :-)

In TDD this isn't always true: if the test fails, then and only then you
are ready to implement the feature. Your client hasn't even seen your code
yet, because it doesn't exist.

Of course there will be bugs, and they are fixed using TDD, too. And there
_are_ bugs in statically typed programs, too. What is the procedure then?
What is the first step that drives the fix?

Sometimes TDD feels like the tests are more intelligent than me and the
resulting design is so simple and so elegant that I really feel like some
supernatural force created it for me :)

I haven't used any powerful type systems (like haskell's) so I don't know
how well it can fulfill this driving role of tests. Has anyone else
thought about this and experienced being "led" by it?

- Ville Oikarinen
From: Duane Rettig
Subject: Re: TDD and what tests do other than try to find bugs
Date: 
Message-ID: <o0r6kc17fi.fsf@gemini.franz.com>
Ville Oikarinen <·····@oikarinen.org> writes:

> I recognize the merits of both dynamic and static typing (and of no typing
> at all!) so I'm not going to discuss it further.

I'm not going to discuss it at all :-)

> But what is lacking in this debate is that in Test Driven Development
> tests are primrarily a force that drives design. Correctness is "just" a
> handy side effect. (Of course tests really _prove_ anything rarely, only
> when the parameter space is finite and very limited.)

The parenthetical is incorrect.  If unit tests are added to the
regression test suite as they are created, they serve an invaluable
aid to tell you if the change you just made during development has
somehow had an adverse effect on the rest of your system.

As one who originally comes from a hardware background, which has the
ultimate in "static" types (the types are so static they are committed
to "hard" ware rather than "soft" ware), I can honestly say to you
(well, not to you directly, since you seem to buy into testing, but
rather to our froggy friend and any others like him) that anyone who
does not do testing at various steps along the design _and_
maintenance/redesign process is just begging for trouble.

-- 
Duane Rettig    ·····@franz.com    Franz Inc.  http://www.franz.com/
555 12th St., Suite 1450               http://www.555citycenter.com/
Oakland, Ca. 94607        Phone: (510) 452-2000; Fax: (510) 452-0182   
From: Ken Tilton
Subject: Re: TDD and what tests do other than try to find bugs
Date: 
Message-ID: <KKTMi.13$Uu6.8@newsfe12.lga>
Duane Rettig wrote:
> ... anyone who
> does not do testing at various steps along the design _and_
> maintenance/redesign process is just begging for trouble.
> 

I thought that is why we occasionally move code into production. There 
is no substitute for real world conditions, if you ask me. Oh, sure, I 
could sit here spinning my reals trying to reassure myself my code is 
correct, but it's just no good, is it? I'll never think of everything 
anyway, So why hold up a production release?

My2.

kenny


-- 
http://www.theoryyalgebra.com/

"We are what we pretend to be." -Kurt Vonnegut
From: Rob Warnock
Subject: Re: TDD and what tests do other than try to find bugs
Date: 
Message-ID: <sqSdnaNJXqq5FpjanZ2dnUVZ_ualnZ2d@speakeasy.net>
Ken Tilton  <·········@gmail.com> wrote:
+---------------
| Duane Rettig wrote:
| > ... anyone who does not do testing at various steps along the design
| > _and_ maintenance/redesign process is just begging for trouble.
| 
| I thought that is why we occasionally move code into production. There 
| is no substitute for real world conditions, if you ask me. Oh, sure, I 
| could sit here spinning my reals trying to reassure myself my code is 
| correct, but it's just no good, is it? I'll never think of everything 
| anyway, So why hold up a production release?
+---------------

Just a couple of recent examples why not:   ;-}  ;-}

    http://catless.ncl.ac.uk/Risks/24.83.html#subj4
    Deploy first, test later
    ...
    Arizona State University decided to act like a 90s-style .com:
    deploy first, even if the software is buggy, try to cope with
    the problems, and fix the code later.  ...it didn't work very well.
    3,000 employees were unpaid or underpaid, and the backup procedures
    couldn't scale by nearly enough.
    ...

    http://catless.ncl.ac.uk/Risks/24.84.html#subj1
    LAUSD payroll fiasco
    ...a similar fiasco has been afflicting employees in the
    Los Angeles Unified School District (LAUSD) since early this year.
    ...
    Some eight months after "going live" with their new payroll
    system, employees are still receiving incorrect paychecks or no
    paychecks at all.  The administration does not yet know whether
    correct W2 forms will be issued in January.  Employees retiring
    cannot get correct pension benefits.
    ...


-Rob

-----
Rob Warnock			<····@rpw3.org>
627 26th Avenue			<URL:http://rpw3.org/>
San Mateo, CA 94403		(650)572-2607
From: Ville Oikarinen
Subject: Re: TDD and what tests do other than try to find bugs
Date: 
Message-ID: <Pine.LNX.4.56L0.0710041004420.17686@localhost>
On Wed, 3 Oct 2007, Duane Rettig wrote:

> Ville Oikarinen <·····@oikarinen.org> writes:
> 
> > But what is lacking in this debate is that in Test Driven Development
> > tests are primrarily a force that drives design. Correctness is "just" a
> > handy side effect. (Of course tests really _prove_ anything rarely, only
> > when the parameter space is finite and very limited.)
> 
> The parenthetical is incorrect.  If unit tests are added to the
> regression test suite as they are created, they serve an invaluable
> aid to tell you if the change you just made during development has
> somehow had an adverse effect on the rest of your system.

I guess if you reread what I wrote, we'll agree on this. Yes, I'm a big
fan of TDD and I have lots of positive experience of the bug-preventing
power of tests. Still, very few tests really _prove_ a program or a part
of it correct, like a type system does (for a restricted aspect, at
least.)

- Ville Oikarinen
From: Duane Rettig
Subject: Re: TDD and what tests do other than try to find bugs
Date: 
Message-ID: <o03awqud00.fsf@gemini.franz.com>
Ville Oikarinen <·····@oikarinen.org> writes:

> On Wed, 3 Oct 2007, Duane Rettig wrote:
>
>> Ville Oikarinen <·····@oikarinen.org> writes:
>> 
>> > But what is lacking in this debate is that in Test Driven Development
>> > tests are primrarily a force that drives design. Correctness is "just" a
>> > handy side effect. (Of course tests really _prove_ anything rarely, only
>> > when the parameter space is finite and very limited.)
>> 
>> The parenthetical is incorrect.  If unit tests are added to the
>> regression test suite as they are created, they serve an invaluable
>> aid to tell you if the change you just made during development has
>> somehow had an adverse effect on the rest of your system.
>
> I guess if you reread what I wrote, we'll agree on this. Yes, I'm a big
> fan of TDD and I have lots of positive experience of the bug-preventing
> power of tests. Still, very few tests really _prove_ a program or a part
> of it correct, like a type system does (for a restricted aspect, at
> least.)

Perhaps we just are not taking the same meaning for the word "prove".
A proof can be a mathematical concept, but often it is used in a
broader sense "to show as true and right" (World Book
Dictionary).  Webster goes as far as equating "proving" with "testing"
in its first non-archaic definition.  Such a proof doesn't have
to be 100% - indeed, a software test is in a sense a negative proof; a
failed test proves a regresssion, but a positive test only proves that
that particular aspect that the test is testing is true and right.

The reason for a regression test suite is to expand the domain of the
individual negative proofs by having as large a coverage as possible,
so that when the test suite is run agains the product and no tests
fail, the one doing the testing has a high degree of confidence that
the product has not undergone changes that have regressed it from the
time it was last tested.  But why would it regress?  Well, I've heard
it said (and it lines up with my own experience) that software is 80%
maintenance, and that maintenance involves changes to the software to
make it better; either to add requested features or to fix existing
bugs.  And to run it against a test suite doesn't prove that the whole
of the software is correct, but it does prove that it has not changed
in a negative way any of the aspects of it that have mattered up to
the present.  Such a test/proof is an important aspect that all of the
current users of the software want to be able to trust before they
want to upgrade to the next vesion of that software, or to download
patches.

What I'm really railing against is your phrase, which you repeated and
made more specific in your response, that few tests prove a program or
a part of it.  That simply is not true - any test that is relevant to
the program proves some part of the program, no matter how small.
Of course, I'm assuming that you've weeded out irrelevant tests.
Perhaps a coverage analysis is needed, and I would consider any
tests that are shown to cover 0% of the program to be irrelevant, and
it also may be true that two tests overlap in their coverage, but
that is not the same as what you are saying.

-- 
Duane Rettig    ·····@franz.com    Franz Inc.  http://www.franz.com/
555 12th St., Suite 1450               http://www.555citycenter.com/
Oakland, Ca. 94607        Phone: (510) 452-2000; Fax: (510) 452-0182   
From: Ville Oikarinen
Subject: Re: TDD and what tests do other than try to find bugs
Date: 
Message-ID: <Pine.LNX.4.56L0.0710050830560.25919@localhost>
On Thu, 4 Oct 2007, Duane Rettig wrote:

> Ville Oikarinen <·····@oikarinen.org> writes:
> 
> > On Wed, 3 Oct 2007, Duane Rettig wrote:
> >
> >> Ville Oikarinen <·····@oikarinen.org> writes:
> >> 
> >> > But what is lacking in this debate is that in Test Driven Development
> >> > tests are primrarily a force that drives design. Correctness is "just" a
> >> > handy side effect. (Of course tests really _prove_ anything rarely, only
> >> > when the parameter space is finite and very limited.)
> >> 
> >> The parenthetical is incorrect.  If unit tests are added to the
> >> regression test suite as they are created, they serve an invaluable
> >> aid to tell you if the change you just made during development has
> >> somehow had an adverse effect on the rest of your system.
> >
> > I guess if you reread what I wrote, we'll agree on this. Yes, I'm a big
> > fan of TDD and I have lots of positive experience of the bug-preventing
> > power of tests. Still, very few tests really _prove_ a program or a part
> > of it correct, like a type system does (for a restricted aspect, at
> > least.)
> 
> Perhaps we just are not taking the same meaning for the word "prove".

I think both my original statement AND the context (type systems versus
tests) suggested what kind of proofs I meant. Namely the usual kind, the
one that leaves no room for speculation.

And naturally I was talking about proving _correctness_, a word I
mentioned in the previous sentence. Incorrectness can be proven by a
single test.

> What I'm really railing against is your phrase, which you repeated and
> made more specific in your response, that few tests prove a program or
> a part of it.  That simply is not true - any test that is relevant to
> the program proves some part of the program, no matter how small.

By "part" I didn't mean the kind of part you seem to mean: "this test
proves that function f returns 2 with input value 1". Yes, in a sense f is
"partly proven" by the test. I meant a lexical part i.e. one _whole_
function, class or module. Whatever the test is supposed to test.

- Ville Oikarinen
From: André Thieme
Subject: Re: TDD and what tests do other than try to find bugs
Date: 
Message-ID: <feeui9$g0g$1@registered.motzarella.org>
Duane Rettig schrieb:

 > If unit tests are added to the
> regression test suite as they are created, they serve an invaluable
> aid to tell you if the change you just made during development has
> somehow had an adverse effect on the rest of your system.

This is correct. Jon however is mostly writing academic code that
never needs to run in a production environment.
There are no databases, no shared networks over which he sends requests,
no customers who need/want new features, no laws that change and will
require changes in the application, etc.

So, there really is not very much left that needs to be tested - what
the type checker is doing is already good enough.
But because he works in his isolated world where he mainly writes books
or to this newsgroup it is very hard to see the benefit of testing.


Andr�
-- 
From: Jon Harrop
Subject: Re: TDD and what tests do other than try to find bugs
Date: 
Message-ID: <13gmdlv6gdojvb9@corp.supernews.com>
Andr� Thieme wrote:
> This is correct. Jon however is mostly writing academic code that
> never needs to run in a production environment.

Our code runs in academic institutions like Microsoft, Intel, Canon, Boeing,
Philips and Sun.

> There are no databases,

Microsoft commissioned us to write about databases in the context of F# and
LINQ at the beginning of this year.

> no shared networks over which he sends requests,

You might like to read the chapter in our book F# for Scientists about web
services.

> no customers who need/want new features

Hundreds of customers who all want new features and upgrades. They want a
second edition of OCaml for Scientists, a newer cheaper OCaml book covering
GUI programming, upgrades to F# for Visualization to support XNA, SDL and
GTK support for Smoke, Hamming windows for our C# FFT library, Presenta
reinvented for Mac OS X and so on.

> no laws that change and will require changes in the application, etc.

True. I don't think we've ever had to change our code because of changes in
the law.

> But because he works in his isolated world where he mainly writes books
> or to this newsgroup it is very hard to see the benefit of testing.

The "isolated world of books and software"? Come on Andre, that's just crazy
talk...

Three years ago you would have had a point. OCaml for Scientist was selling
only $500 a month mainly to academics and we were among the first visible
adopters of OCaml in industry. Now, bloody everyone is an OCaml consultant,
OCaml is prolific in industry (Microsoft are deriving their next big
language from it), and OCaml for Scientists is our most successful product
pulling in close to $100,000 per year and almost entirely to industry.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
From: André Thieme
Subject: Re: TDD and what tests do other than try to find bugs
Date: 
Message-ID: <feh2nh$2sd$1@registered.motzarella.org>
Jon Harrop schrieb:
> Andr� Thieme wrote:
>> This is correct. Jon however is mostly writing academic code that
>> never needs to run in a production environment.
> 
> Our code runs in academic institutions like Microsoft, Intel, Canon, Boeing,
> Philips and Sun.

Cute :-)
There is a guy in those companies trying some application that was
developed by you.
The same can be said about Lisp.
But those companies use mostly Java, C++ and C#.
Neither OCaml nor Lisp are interesting for them and won't be in the
coming years.. only as a niche product.


>> There are no databases,
> 
> Microsoft commissioned us to write about databases in the context of F# and
> LINQ at the beginning of this year.

The way you write it, it sounds very important and official.
Probably Ballmer and Gates themselves were discussing this intensively
with your company :-)


>> no shared networks over which he sends requests,
> 
> You might like to read the chapter in our book F# for Scientists about web
> services.

Yeah, running on the F# application servers which can change code during
runtime without restarting, nice.


> Three years ago you would have had a point. OCaml for Scientist was selling
> only $500 a month mainly to academics and we were among the first visible
> adopters of OCaml in industry. Now, bloody everyone is an OCaml consultant,

That is not so surprising, keeping in mind you work in a consualtant 
company...


> OCaml is prolific in industry (Microsoft are deriving their next big
> language from it), and OCaml for Scientists is our most successful product
> pulling in close to $100,000 per year and almost entirely to industry.

Grats


Andr�
-- 
From: namekuseijin
Subject: Re: TDD and what tests do other than try to find bugs
Date: 
Message-ID: <1191985892.346618.28550@50g2000hsm.googlegroups.com>
On Oct 9, 8:26 pm, Andr� Thieme <address.good.until.
···········@justmail.de> wrote:
> The same can be said about Lisp.
> But those companies use mostly Java, C++ and C#.
> Neither OCaml nor Lisp are interesting for them and won't be in the
> coming years.. only as a niche product.

Microsoft has been into Haskell and OCaml for quite some time.

Haskell developers like Simon Peyton Jones and Erik Meijer have been
hired to work at Microsoft Research from times before Haskell gained
momentum (and we can imagine if Microsoft has something to do with
it).

The main result of their efforts now appears as a lot of functional
programming features are revealed to be at the core of the mainstream
Microsoft languages: C# and Visual Basic.  They are coming with list
and monad comprehensions, some rudimentary type inference (first
assignment binds type to a variable) and a lot of other common
functional programming practices.  This is in the core of the
mainstream Microsoft offerings, I repeat.

F# on the other hand is being based mostly on OCaml and is supposedly
targeting functional programming nuts all the way.

come on, guys.  Where is L#?
From: Sacha
Subject: Re: TDD and what tests do other than try to find bugs
Date: 
Message-ID: <IB%Oi.148606$0o.8301582@phobos.telenet-ops.be>
namekuseijin wrote:
> come on, guys.  Where is L#?
> 

http://www.lsharp.org/

While this work is to be commended, it doesn't compare to common lisp... 
Too bad , I would love to have native access to the .net library.

Sacha
From: Jon Harrop
Subject: Re: TDD and what tests do other than try to find bugs
Date: 
Message-ID: <13grn8g3ijj8na3@corp.supernews.com>
Andr� Thieme wrote:
> Jon Harrop schrieb:
>> Our code runs in academic institutions like Microsoft, Intel, Canon,
>> Boeing, Philips and Sun.
> 
> ...
> The same can be said about Lisp.

Microsoft use OCaml for third-party driver verification, analysing XBox
player statistics and running the advertising on MSN live. Can you give
equivalent examples of where they are currently using Lisp?

> Neither OCaml nor Lisp are interesting for them...

On the contrary, their OCaml code is of enormous commercial worth to them.
How much value do you think Intel put on their hardware verification
(written in OCaml), for example?

>> You might like to read the chapter in our book F# for Scientists about
>> web services.
> 
> Yeah, running on the F# application servers which can change code during
> runtime without restarting, nice.

Your misconception that code must mutate at run-time stems from Lisp. There
are better ways to solve the same problems if you choose more modern
languages...

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
From: namekuseijin
Subject: Re: When static typing is worth it
Date: 
Message-ID: <1191825599.150831.204490@57g2000hsv.googlegroups.com>
Jon Harrop:
"# let rec reduce f (h, t) = match t with
    | [] -> h
    | h2::t -> f h (reduce f (h2, t));;

Note that the "raise Not_found" has disappeared. We have completely
eliminated this source of run-time errors by getting the static type
system
to prove that this run-time error can never occur.

> Why can't you just test for the empty list in the function and act
> accordingly?

If the test fails then you already gave your client buggy software.
Static
typing lets you avoid that humiliation. :-)"

I fail to see how this

(define (reduce f h t)
	(if (null? t) h
		(f h (reduce f (car t) (cdr t)))))

is any different than the above code.  It isn't any more buggy than
the "pattern matching" solution above, which you acknowledge to only
be solvable at run-time: "From the static point of view, this is just
run-time dispatch and
consequently, is solved using pattern matching in all modern FPLs."

pattern matching is just syntatic sugar and sure one can write a Lisp
macro to handle it if he so desires...
From: Jon Harrop
Subject: Re: When static typing is worth it
Date: 
Message-ID: <13gkepfavjqop0f@corp.supernews.com>
namekuseijin wrote:
> Jon Harrop:
> "# let rec reduce f (h, t) = match t with
>     | [] -> h
>     | h2::t -> f h (reduce f (h2, t));;
> 
> Note that the "raise Not_found" has disappeared. We have completely
> eliminated this source of run-time errors by getting the static type
> system
> to prove that this run-time error can never occur.
> 
>> Why can't you just test for the empty list in the function and act
>> accordingly?
> 
> If the test fails then you already gave your client buggy software.
> Static
> typing lets you avoid that humiliation. :-)"
> 
> I fail to see how this
> 
> (define (reduce f h t)
> (if (null? t) h
> (f h (reduce f (car t) (cdr t)))))
> 
> is any different than the above code.

You've just traded run-time checking of list length for run-time checking of
function arity (which is equivalent in Lisp/Scheme). That still provides no
static checking and no throwback of an inferred type but, also, it cannot
be used in place of the existing "reduce" function for ordinary lists
because the arity of the function has changed. For example, you can no
longer parameterize a higher order function over reduce functions.

> It isn't any more buggy than 
> the "pattern matching" solution above, which you acknowledge to only
> be solvable at run-time: "From the static point of view, this is just
> run-time dispatch and consequently, is solved using pattern matching in
> all modern FPLs." 

Ah, not quite. I said that run-time dispatch is achieved via pattern
matching in these languages, not that pattern matching is run-time
dispatch. Indeed, this is precisely why the ML approach lets you choose
whether to test at compile-time or defer tests to run-time.

For example:

  let f (a, (b, c)) = ((a, b), c)

The (a, (b, c)) is a pattern match. OCaml knows that this pattern is
exhaustive so there is no need for an explicit match construct or run-time
dispatch but it is pattern matching nonetheless.

Consider this code to sum a two-element list:

  (define (sum2 xs) (+ (car xs) (cadr xs)))

If you give it a one-element list then you get a run-time type error:

> (sum2 '(2))
*** ERROR IN sum2, (console)@1.31 -- (Argument 1) PAIR expected
(cadr '(2))

In Lisp/Scheme, you cannot perform that check statically. In ML, you can.
The original can be translated into the dynamic:

# let sum2 (x1::x2::_) = x1 + x2;;
Warning P: this pattern-matching is not exhaustive.
Here is an example of a value that is not matched:
[]
val sum2 : int list -> int = <fun>

Note the warning because OCaml inserted a run-time check for us. That can
fail at run-time in exactly the same way as the Scheme did:

# sum2 [2];;
Exception: Match_failure ("", 34, -56).

Thanks to integrated static typing and pattern matching, you can replace the
list with a tuple in OCaml and ensure that all not-two-element length
inputs are flagged as errors at compile time:

# let sum2 (x1, x2) = x1 + x2;;
val sum2 : int * int -> int = <fun>

Incorrect use results in a static type error at compile time:

# sum2 (2);;
This expression has type int but is here used with type int * int

> pattern matching is just syntatic sugar and sure one can write a Lisp
> macro to handle it if he so desires...

Turing argument. You can do it, of course, but you'd be writing a
sophisticated static type checker if you want the above functionality.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
From: namekuseijin
Subject: Re: When static typing is worth it
Date: 
Message-ID: <1191861963.738629.10970@o80g2000hse.googlegroups.com>
On 8 out, 11:05, Jon Harrop <····@ffconsultancy.com> wrote:
> namekuseijin wrote:
> > Jon Harrop:
> > "# let rec reduce f (h, t) = match t with
> >     | [] -> h
> >     | h2::t -> f h (reduce f (h2, t));;
>
> > I fail to see how this
>
> > (define (reduce f h t)
> > (if (null? t) h
> > (f h (reduce f (car t) (cdr t)))))
>
> > is any different than the above code.
>
> You've just traded run-time checking of list length for run-time checking of
> function arity (which is equivalent in Lisp/Scheme). That still provides no
> static checking and no throwback of an inferred type but, also, it cannot
> be used in place of the existing "reduce" function for ordinary lists
> because the arity of the function has changed. For example, you can no
> longer parameterize a higher order function over reduce functions.

No.

(null? t) just checks if the list t passed as last argument is empty
or not.  It has
the exact same meaning as in the match reduce f (h, t) = match t with
| [] -> h.

And this check *is* made at run-time, presumably everytime you pass
reduce a list
which has just been populated (or not) by the user.

It may be that if the OCaml compiler sees written code as "reduce + 0
[]" it is able
then to just reduce it to h.  But there's nothing preventing
optimizers for Lisp and
Scheme from doing the same.

Otherwise, it's run-time check.

Indeed, I'd say in world of heavy and many IO transactions mostly of
the string-type,
static checks can't give much safety guarantees.  Once you've put in
the hands of
users rather than programmers the task of feeding data, all you
beautiful code
dealing with very high level types, classes and type classes amount to
gross
conversions from strings to possibly one of your expected types... if
you don't check
for mismatchs in run-time, you're toasted.

> Ah, not quite. I said that run-time dispatch is achieved via pattern
> matching in these languages, not that pattern matching is run-time
> dispatch. Indeed, this is precisely why the ML approach lets you choose
> whether to test at compile-time or defer tests to run-time.

and indeed as we see, run-time checks are much more essential than
programmer's faults or typos:  possibly because the user isn't as
informed
about the inner working of a system as the programmer himself.

>   (define (sum2 xs) (+ (car xs) (cadr xs)))
>
> If you give it a one-element list then you get a run-time type error:
>
> > (sum2 '(2))
>
> *** ERROR IN sum2, (console)@1.31 -- (Argument 1) PAIR expected
> (cadr '(2))
>
> In Lisp/Scheme, you cannot perform that check statically.

have you ever heard of soft type checkers?  They are Lisp/Scheme
programs
that verify calls to functions match the inferred types from function
bodies.  So,
you can have your code type-checked before deploying it.  It just
turns out
it's optional and the developer may only run it once, not everytime.

Besides, your tuples sound wonderful, but in practice are of little
value.  How
do you construct a tuple in run-time, from user input?  If you let the
user
feed it, he may just feed a null tuple as second tuple and you're
screwed.

No run-time checks, just sorryness...

> > pattern matching is just syntatic sugar and sure one can write a Lisp
> > macro to handle it if he so desires...
>
> Turing argument. You can do it, of course, but you'd be writing a
> sophisticated static type checker if you want the above functionality.

And what's the matter with that?  I feel good about having one more
useful
tool under my belt, not above my belly... specially as Lisp libraries
just feel
like any other builtin construct...
From: Jon Harrop
Subject: Re: When static typing is worth it
Date: 
Message-ID: <13glu8083d0k59b@corp.supernews.com>
namekuseijin wrote:
> On 8 out, 11:05, Jon Harrop <····@ffconsultancy.com> wrote:
>> You've just traded run-time checking of list length for run-time checking
>> of function arity (which is equivalent in Lisp/Scheme). That still
>> provides no static checking and no throwback of an inferred type but,
>> also, it cannot be used in place of the existing "reduce" function for
>> ordinary lists because the arity of the function has changed. For
>> example, you can no longer parameterize a higher order function over
>> reduce functions.
> 
> No.
> 
> (null? t) just checks if the list t

There is no assurance that "t" is even a list in a dynamically typed
language. If "t" is an int then one of the extra run-time checks that your
dynamic language silently injected into your code will fail. In this case,
the one in "car":

> (reduce + 1 3)
*** ERROR IN reduce, (console)@3.32 -- (Argument 1) PAIR expected
(car 3)

In contrast, all such run-time tests must either be explicit or the compiler
emits warnings about them in statically typed languages and you are,
consequently, encouraged to remove them as I did.

My OCaml contains no such run-time tests any more and that function cannot
fail at run time as yours just did. This is the primary benefit of static
typing.

> passed as last argument

Actually "t" was not the last argument in the OCaml, it is part of a data
structure that was destructured using the pattern match: (h, t). This is
important because it means the new "reduce" function has the same signature
(is invoked in the same way) as the old reduce function. For example, you
might want a higher-order function parameterized over the "reduce" function
that it uses that will expect to apply "reduce" to only two arguments (a
function and a list).

Your Scheme solution cannot do this because you've changed the arity of
the "reduce" function and it now expects three arguments instead of two.
One could argue that there is little theoretical difference in Lisp or
Scheme because functions accept a list of arguments anyway but, in
practice, many Lisp/Scheme compilers and interpreters will try to
statically check that the arity is correct.

Unfortunately, the SBCL Lisp compiler fails even to find this error
statically:

* (defun reduce* (f hd tl)
  (if (eq hd nil)
      hd
    (funcall f hd (reduce* f (car tl) (cdr tl)))))

REDUCE*
* (defun f () (reduce* '+ '()))

F

So a faithful translation to Scheme would have preserved the arity of
the "reduce" function by passing the data structure as a single argument as
the OCaml did, like this:

> (define (reduce f t)
        (if (null? (cdr t)) (car t)
                (f (car t) (reduce f (cdr t)))))
> (reduce + '(1 2 3))
6
> (reduce + '())
*** ERROR IN reduce, (console)@2.20 -- (Argument 1) PAIR expected
(cdr '())

The Scheme suffers from a run-time error if you accidentally pass in the
empty list. OCaml proved that this error had been removed and,
consequently, guarantees that this source of run-time error does not exist
in the OCaml.

> is empty or not.  It has the exact same meaning as in the match reduce f
> (h, t) = match t with | [] -> h.  

Yes.

> And this check *is* made at run-time, presumably everytime you pass
> reduce a list which has just been populated (or not) by the user.

In this context, you must distinguish between a check that might produce an
error and a run-time dispatch that is guaranteed not to produce an error.
The Scheme does checks (for pairs) that might fail at run-time. The OCaml
does a run-time dispatch that is guaranteed to succeed.

> It may be that if the OCaml compiler sees written code as "reduce + 0
> []"

Note that the list is passed as a single data structure in the OCaml:

# let my_list = (0, []);;
val my_list : int * 'a list = (0, [])
# reduce (+) my_list;;
- : int = 0

This is an important difference that makes it harder to draw a meaningful
comparison with my OCaml and the Scheme solution you posted.

> it is able then to just reduce it to h.  But there's nothing 
> preventing optimizers for Lisp and Scheme from doing the same.

Sure. This is about proof of correctness and not performance.

As an aside, the performance would probably not be significantly different
between the static and dynamic solutions in this case. ML-style pattern
matching is asymptotically faster when there are many match cases in the
pattern match rather than just two as we have here.

> Otherwise, it's run-time check.

In OCaml, it is a run-time dispatch that cannot fail. In Scheme, it is a
run-time check that might fail.

> Indeed, I'd say in world of heavy and many IO transactions mostly of
> the string-type, static checks can't give much safety guarantees.

Absolutely, yes. Static typing only pays off if you can exploit the rich
type system, which you often can.

>> Ah, not quite. I said that run-time dispatch is achieved via pattern
>> matching in these languages, not that pattern matching is run-time
>> dispatch. Indeed, this is precisely why the ML approach lets you choose
>> whether to test at compile-time or defer tests to run-time.
> 
> and indeed as we see, run-time checks are much more essential than
> programmer's faults or typos:  possibly because the user isn't as
> informed about the inner working of a system as the programmer himself.

You're implicitly talking about interface code. You are perfectly correct,
of course, but this is a similarity rather than a difference between the
paradigms. Both must validate user input and both must contain sources of
run-time error because the user only supplies the data at run time. There
is still a debate there though: can static typing be a burden for such
code?

> have you ever heard of soft type checkers?  They are Lisp/Scheme
> programs that verify calls to functions match the inferred types from
> function bodies.  So, you can have your code type-checked before deploying
> it.  It just turns out it's optional and the developer may only run it
> once, not everytime. 

Sure. Have you heard of decideable type checking? There is a huge difference
between the meaning of "type check" in the context of a soft type system
retrofitting onto Lisp or Scheme and the type checking offered by Haskell,
OCaml, SML, Scala and F# because they were all meticulously constructed
with maximally capable type checking in mind.

> Besides, your tuples sound wonderful, but in practice are of little
> value.

Oh, no. Tuples are of absolutely enormous practical value!

By leveraging OCaml's type system using exactly the technique I've presented
here, I was able to remove almost all of the source of run-time error from
a 1kLOC block of OCaml code.

I was learning OCaml at the time and was not yet familiar with the concept
of leveraging static type systems. I tried unit testing first and wasted
over 2 weeks bug hunting with the slow run/error/edit/rerun cycle. When I
realised how I could leverage the static type system (largely by replacing
lists with tuples), I removed 90% of the sources of run-time error in only
2 days using the much faster compile/error/edit/recompile cycle and the
code then passed all unit tests and went straight into production.

Interestingly, this was not some fancy symbolic algorithm from science, it
was actually GUI code for doing mathematical typesetting. The user input
was converted into sum types (like Up, Down, Left, Right). The giant
pattern matches originally all had catchall clauses at the end that threw
run-time errors:

  ...
  | _ -> invalid_arg "foo"

By rearranging the pattern matches so that the OCaml compiler told me when
these run-time error clauses could no longer be reached and could,
therefore, be removed safely, I was able to remove almost all of the
sources of run-time error from this code.

This is a completely general-purpose approach to removing run-time errors
and it is practically impossible to do in Lisp or Scheme because any static
checking their implementations happen to provide is entirely ad-hoc and
very rudimentary by comparison.

> How do you construct a tuple in run-time, from user input?

# let read_pair ch =
    let n = input_line ch in
    let m = input_line ch in
    n, m;;
val read_pair : in_channel -> string * string = <fun>
# read_pair stdin;;
foo
bar
- : string * string = ("foo", "bar")

Again, this is a similarity. The difference comes in what you do after this,
in the rest of the program.

> If you let the user feed it, he may just feed a null tuple as second tuple
> and you're screwed.  
> 
> No run-time checks, just sorryness...

This is another similarity between static and dynamic approaches. Both end
up with run-time tests at interface boundaries like user input. The
difference (where static typing pays off) is the non-interface code where
there are few sources of run-time error in theory but a dynamic language
will litter your code with run-time checks in practice, like laying a
minefield.

You have hit upon the boundary where static typing ceases to be of benefit
though. If you have an active web page that takes regular expressions from
user input and runs them against a giant string, like the bible, and just
slaps the string result back onto the page then you've got no scope for
using expressive types and static typing will buy you nothing. The only
errors you can avoid are of the form of Null pointer exceptions and you can
probably remove them from such code using unit testing and good design
anyway.

>> > pattern matching is just syntatic sugar and sure one can write a Lisp
>> > macro to handle it if he so desires...
>>
>> Turing argument. You can do it, of course, but you'd be writing a
>> sophisticated static type checker if you want the above functionality.
> 
> And what's the matter with that?  I feel good about having one more
> useful tool under my belt, not above my belly... specially as Lisp
> libraries just feel like any other builtin construct... 

You might like Qi but, as I say, you will never see the full benefits of
modern systems without leaving Lisp.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
From: Matthieu Villeneuve
Subject: Re: When static typing is worth it
Date: 
Message-ID: <470b2a5b$0$5169$426a74cc@news.free.fr>
Jon Harrop wrote:
> You might like Qi but, as I say, you will never see the full benefits of
> modern systems without leaving Lisp.

I used to love OCaml, its pattern matching and type system. Then after
a few years, and with better knowledge and experience of both it and Common
Lisp, I realized Lisp would be more productive for me (for all the reasons
others have explained better than I could do), even without features that I
found powerful and reassuring in OCaml. But I guess that to understand
this, one has to spend some time and effort learning both languages in
depth, which not everybody can do...


--
Matthieu Villeneuve
From: Jon Harrop
Subject: Re: When static typing is worth it
Date: 
Message-ID: <13gmg3a9v3ad0c2@corp.supernews.com>
Matthieu Villeneuve wrote:
> I used to love OCaml, its pattern matching and type system. Then after
> a few years, and with better knowledge and experience of both it and
> Common Lisp, I realized Lisp would be more productive for me (for all the
> reasons others have explained better than I could do), even without
> features that I found powerful and reassuring in OCaml. But I guess that
> to understand this, one has to spend some time and effort learning both
> languages in depth, which not everybody can do...

Absolutely, I couldn't agree more. The problem is that people do a single
1st year undergraduate elective course on "Knowing Programming Languages"
that mentions OCaml and then claim that they "know OCaml". Building product
lines and revenue streams using a given language helps you to understand
that but I guess not everybody can do that...

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
From: Matthieu Villeneuve
Subject: Re: When static typing is worth it
Date: 
Message-ID: <470c8b4d$0$25499$426a74cc@news.free.fr>
Jon Harrop wrote:
> Matthieu Villeneuve wrote:
>> I used to love OCaml, its pattern matching and type system. Then after
>> a few years, and with better knowledge and experience of both it and
>> Common Lisp, I realized Lisp would be more productive for me (for all the
>> reasons others have explained better than I could do), even without
>> features that I found powerful and reassuring in OCaml. But I guess that
>> to understand this, one has to spend some time and effort learning both
>> languages in depth, which not everybody can do...
> 
> Absolutely, I couldn't agree more. The problem is that people do a single 
> 1st year undergraduate elective course on "Knowing Programming Languages"
> that mentions OCaml and then claim that they "know OCaml". Building 
> product lines and revenue streams using a given language helps you to
> understand that but I guess not everybody can do that...

I agree with the first part, but this has nothing to do with what I said.
And there is no direct link between selling a product and becoming a better
programmer. Otherwise, most experienced developers would be good
programmers, which is obviously wrong, and there would be only bad
programmers in full time academic or free-software teams, which is also
obviously wrong.

So please stop this pathetic attempt to make people who don't agree with you
look like silly children, after all you are the one who demonstrated clear
ignorance about Lisp programming.


--
Matthieu Villeneuve
From: Jon Harrop
Subject: Re: When static typing is worth it
Date: 
Message-ID: <13grmt5oepkk2a1@corp.supernews.com>
Matthieu Villeneuve wrote:
> And there is no direct link between selling a product and becoming a
> better programmer. Otherwise, most experienced developers would be good
> programmers, which is obviously wrong, and there would be only bad
> programmers in full time academic or free-software teams, which is also
> obviously wrong.

No, if there were no correlation then academic programmers would be of
unrelated quality and not of necessarily poor quality as you say.

Incidentally, basing a pro-Lisp argument on quality is an extremely bad
idea. Compare the quality of programmers here and on the caml-list, for
example.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
From: Matthieu Villeneuve
Subject: Re: When static typing is worth it
Date: 
Message-ID: <470dec53$0$5237$426a34cc@news.free.fr>
Jon Harrop wrote:
> Matthieu Villeneuve wrote:
>> And there is no direct link between selling a product and becoming a
>> better programmer. Otherwise, most experienced developers would be good
>> programmers, which is obviously wrong, and there would be only bad
>> programmers in full time academic or free-software teams, which is also
>> obviously wrong.
> 
> No, if there were no correlation then academic programmers would be of
> unrelated quality and not of necessarily poor quality as you say.

I'll assume that:
  - you are not _completely_ stupid, 
  - you are just pretending not to understand what I wrote (and what
    others write),
  - you just keep hoping people will not realize that bad faith is your
    last resort (now that you haven't seen many people here falling for
    your ignorant arguments).

So, end of the discussion for me.

> Incidentally, basing a pro-Lisp argument on quality is an extremely bad
> idea. Compare the quality of programmers here and on the caml-list, for
> example.

You're funny. :)

On second thought, I think I'll keep reading this entertaining thread,
even if I don't spend any more time talking with someone whose responses
would make him fail at the Turing test...


--
Matthieu Villeneuve
From: Jon Harrop
Subject: Re: When static typing is worth it
Date: 
Message-ID: <13gs3dr9rm6mld9@corp.supernews.com>
Matthieu Villeneuve wrote:
> Jon Harrop wrote:
>> Matthieu Villeneuve wrote:
>>> And there is no direct link between selling a product and becoming a
>>> better programmer. Otherwise, most experienced developers would be good
>>> programmers, which is obviously wrong, and there would be only bad
>>> programmers in full time academic or free-software teams, which is also
>>> obviously wrong.
>> 
>> No, if there were no correlation then academic programmers would be of
>> unrelated quality and not of necessarily poor quality as you say.
> 
> I'll assume that:
>   - you are not _completely_ stupid,
>   - you are just pretending not to understand what I wrote (and what
>     others write),
>   - you just keep hoping people will not realize that bad faith is your
>     last resort (now that you haven't seen many people here falling for
>     your ignorant arguments).

There is no bad faith here. Your statement that programming and commerce
being unrelated makes academics bad programmers simply has no logical
grounding. It is incorrect.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
From: Rainer Joswig
Subject: Re: When static typing is worth it
Date: 
Message-ID: <2007101111560516807-joswig@lispde>
On 2007-10-11 10:06:54 +0200, Jon Harrop <···@ffconsultancy.com> said:

> Matthieu Villeneuve wrote:
>> And there is no direct link between selling a product and becoming a
>> better programmer. Otherwise, most experienced developers would be good
>> programmers, which is obviously wrong, and there would be only bad
>> programmers in full time academic or free-software teams, which is also
>> obviously wrong.
> 
> No, if there were no correlation then academic programmers would be of
> unrelated quality and not of necessarily poor quality as you say.
> 
> Incidentally, basing a pro-Lisp argument on quality is an extremely bad
> idea. Compare the quality of programmers here and on the caml-list, for
> example.

Well, you are here and that drags the group down a lot.
From: George Neuner
Subject: Re: When static typing is worth it
Date: 
Message-ID: <psusg3tf356q2qsg489h6sha9l6d23tmt6@4ax.com>
On Thu, 11 Oct 2007 09:06:54 +0100, Jon Harrop <···@ffconsultancy.com>
wrote:

>Matthieu Villeneuve wrote:
>> And there is no direct link between selling a product and becoming a
>> better programmer. Otherwise, most experienced developers would be good
>> programmers, which is obviously wrong, and there would be only bad
>> programmers in full time academic or free-software teams, which is also
>> obviously wrong.
>
>No, if there were no correlation then academic programmers would be of
>unrelated quality and not of necessarily poor quality as you say.
>
>Incidentally, basing a pro-Lisp argument on quality is an extremely bad
>idea. Compare the quality of programmers here and on the caml-list, for
>example.

The majority of academic programmers I have known have been rather
poor software engineers.  The problem is there are few consequences
for lousy academic software.  In the commercial world, mistakes can
cost your job.

Even better: I used to work on embedded systems for medical devices
and quality control systems for pharmaceutical manufacturing.  The
USFDA can hold programmers personally liable for injuries caused by
software mistakes - that's a black ball next to your name for life
which means you'll be employable as a developer again.  Add the
potential for multi-million dollar personal injury lawsuits by the
victims, against both you personally and the company you work for,
plus the guilt of having needlessly hurt someone, and you have a bunch
of splendid motivators to become the best design engineer and
implementation programmer that you can possibly be.

George
--
for email reply remove "/" from address
From: George Neuner
Subject: Re: When static typing is worth it
Date: 
Message-ID: <65s1h3p89bsb6oiim5gdseqbbpm6lp1p3j@4ax.com>
On Thu, 11 Oct 2007 16:41:12 -0400, George Neuner
<·········@/comcast.net> wrote:

>Even better: I used to work on embedded systems for medical devices
>and quality control systems for pharmaceutical manufacturing.  The
>USFDA can hold programmers personally liable for injuries caused by
>software mistakes - that's a black ball next to your name for life
>which means you'll be employable as a developer again.
                   ^never 

George
--
for email reply remove "/" from address
From: Rainer Joswig
Subject: Re: When static typing is worth it
Date: 
Message-ID: <joswig-3D2246.09245709102007@news-europe.giganews.com>
In article <···············@corp.supernews.com>,
 Jon Harrop <···@ffconsultancy.com> wrote:


Look, you don't need to explain dynamic typing. 

Yes, Lisp is dynamically typed. Get over it.

> Your Scheme solution cannot do this because you've changed the arity of
> the "reduce" function and it now expects three arguments instead of two.
> One could argue that there is little theoretical difference in Lisp or
> Scheme because functions accept a list of arguments anyway but, in
> practice, many Lisp/Scheme compilers and interpreters will try to
> statically check that the arity is correct.
> 
> Unfortunately, the SBCL Lisp compiler fails even to find this error
> statically:
> 
> * (defun reduce* (f hd tl)
>   (if (eq hd nil)
>       hd
>     (funcall f hd (reduce* f (car tl) (cdr tl)))))
> 
> REDUCE*
> * (defun f () (reduce* '+ '()))
> 
> F

; compiling (DEFUN REDUCE* ...)
; compiling (DEFUN TEST ...)
; file: /tmp/test2.lisp
; in: DEFUN TEST
;     (REDUCE* '+ 'NIL)
; 
; caught STYLE-WARNING:
;   The function was called with two arguments, but wants exactly three.
; 
; compilation unit finished
;   caught 1 STYLE-WARNING condition


; /tmp/test2.fasl written
; compilation finished in 0:00:00
#P"/tmp/test2.fasl"
T
NIL


More frog quark...

-- 
http://lispm.dyndns.org
From: André Thieme
Subject: Re: When static typing is worth it
Date: 
Message-ID: <feetsu$dtf$1@registered.motzarella.org>
Jon Harrop schrieb:

> If the test fails then you already gave your client buggy software. Static
> typing lets you avoid that humiliation. :-)

That is the old fashioned approach which you have to go with OCaml for
example. In modern programming languages your application resides on the
server side. While your application is running you can fix bugs or
incorporate changes without having to stop the program. Your customers
can continue working while you extend the application with their wishes.
Uhm, not your customers.. OCaml is not really good at working on modern,
21st century tasks. But you could begin to learn Lisp and be able to
become much more productive than you have even been.
In Lisp you have (with Qi) static typing that is more powerful than what
F# offers, and you will have macros and a dynamic system that can evolve
to your customers needs.


Andr�
-- 
From: Ken Tilton
Subject: Re: When static typing is worth it
Date: 
Message-ID: <aDDOi.378$7y.46@newsfe12.lga>
Andr� Thieme wrote:
> Jon Harrop schrieb:
> 
>> If the test fails then you already gave your client buggy software. 
>> Static
>> typing lets you avoid that humiliation. :-)
> 
> 
> That is the old fashioned approach which you have to go with OCaml for
> example. In modern programming languages your application resides on the
> server side. While your application is running you can fix bugs or
> incorporate changes without having to stop the program. Your customers
> can continue working while you extend the application with their wishes.
> Uhm, not your customers.. OCaml is not really good at working on modern,
> 21st century tasks. But you could begin to learn Lisp and be able to
> become much more productive than you have even been.
> In Lisp you have (with Qi) static typing that is more powerful than what
> F# offers, and you will have macros and a dynamic system that can evolve
> to your customers needs.

If froggy takes up CL and ends up never leaving, I am holding you 
personally responsible.

kenny

-- 
http://www.theoryyalgebra.com/

"We are what we pretend to be." -Kurt Vonnegut
From: Ken Tilton
Subject: It shipped! Well....
Date: 
Message-ID: <pMDOi.379$7y.303@newsfe12.lga>
...there is a download available. Hidden on a remote web page. 
Containing a password-protected self-extracting archive. For winXP only 
(well, maybe Vista, not sure how backward comp that is). And it is just 
a bug ridden copy of the demo screenshotted here:

     http://www.theoryyalgebra.com/demo-11.html

It is a Cello app, btw: Tcl/Tk to get the window, Togl to get the 
OpenGL, all the rest pure Lisp+OpenGL.

This first release is more about me wondering if I found all the DLLs it 
needs. If it does work you will be able to explore and have a lot of fun 
between highly regular crashes.

If you are (a) winXP-enabled and (b) interested in seeing a cool Lisp 
app and (c) known to me or sound sane shoot me an email and I will send 
you some instructions.

A subsequent release will be Just There and not password-protected, 
watch this space for news of that.

ken

-- 
http://www.theoryyalgebra.com/

"We are what we pretend to be." -Kurt Vonnegut
From: John Thingstad
Subject: Re: It shipped! Well....
Date: 
Message-ID: <op.tzyaojbspqzri1@pandora.upc.no>
P� Tue, 09 Oct 2007 06:50:21 +0200, skrev Ken Tilton  
<···········@optonline.net>:

> ...there is a download available. Hidden on a remote web page.  
> Containing a password-protected self-extracting archive. For winXP only  
> (well, maybe Vista, not sure how backward comp that is). And it is just  
> a bug ridden copy of the demo screenshotted here:
>
>      http://www.theoryyalgebra.com/demo-11.html
>
> It is a Cello app, btw: Tcl/Tk to get the window, Togl to get the  
> OpenGL, all the rest pure Lisp+OpenGL.
>
> This first release is more about me wondering if I found all the DLLs it  
> needs. If it does work you will be able to explore and have a lot of fun  
> between highly regular crashes.
>
> If you are (a) winXP-enabled and (b) interested in seeing a cool Lisp  
> app and (c) known to me or sound sane shoot me an email and I will send  
> you some instructions.
>
> A subsequent release will be Just There and not password-protected,  
> watch this space for news of that.
>
> ken
>


Just a suggestion:

If you are uncertain about what dependencies your program uses.
Go to:  
http://www.microsoft.com/technet/sysinternals/ProcessesAndThreads/ProcessExplorer.mspx
And download the ProcessExplorer. A indespensable tool..

Never had any problems running things under Vista.
A few things to look out for are.
Use the Windows routines to get the area for application-data and  
my-documents. In Vista users are under home rather than "Documents and  
Settings".
Make sure it can run with DEP protection on and in restricted mode.
Don't store application data in the program directory. Use "Application  
Data" instead.
Make sure to ask if the user wants to store the program for all users or  
just the current user. If all users is selected make sure to store the  
application data under all users. Preferences etc. should be stored in the  
current users "Application Data" directory. Directory convention is the  
same as under "Program Files" company name > program name > version is  
best to avoid conflicts.
Same applies to registry values. Use a group available to all the users.
These are good conventions under Xp as well, but since Vista to a much  
higher degree encourages the use of restricted mode more home users will  
percieve this as a problem.
From: Ken Tilton
Subject: Re: It shipped! Well....
Date: 
Message-ID: <S3WOi.676$ul3.171@newsfe12.lga>
John Thingstad wrote:
> P� Tue, 09 Oct 2007 06:50:21 +0200, skrev Ken Tilton  
> <···········@optonline.net>:
> 
>> ...there is a download available. Hidden on a remote web page.  
>> Containing a password-protected self-extracting archive. For winXP 
>> only  (well, maybe Vista, not sure how backward comp that is). And it 
>> is just  a bug ridden copy of the demo screenshotted here:
>>
>>      http://www.theoryyalgebra.com/demo-11.html
>>
>> It is a Cello app, btw: Tcl/Tk to get the window, Togl to get the  
>> OpenGL, all the rest pure Lisp+OpenGL.
>>
>> This first release is more about me wondering if I found all the DLLs 
>> it  needs. If it does work you will be able to explore and have a lot 
>> of fun  between highly regular crashes.
>>
>> If you are (a) winXP-enabled and (b) interested in seeing a cool Lisp  
>> app and (c) known to me or sound sane shoot me an email and I will 
>> send  you some instructions.
>>
>> A subsequent release will be Just There and not password-protected,  
>> watch this space for news of that.
>>
>> ken
>>
> 
> 
> Just a suggestion:
> 
> If you are uncertain about what dependencies your program uses.
> Go to:  
> http://www.microsoft.com/technet/sysinternals/ProcessesAndThreads/ProcessExplorer.mspx 
> 
> And download the ProcessExplorer. A indespensable tool..

Thx, I had grabbed that and it helped some, but I could not get it to 
say "this process uses these DLLs". Anyway, I am close to getting it 
running on a virgin Vista laptop I had to buy just for this purpose, 
fortunately for less than I paid for an 8k upgrade for an Apple II.

> 
> Never had any problems running things under Vista.

Nope, so far so good. Actually saw the thing running missing a couple of 
background JPGs. Getting close I hope.

> A few things to look out for are.
> Use the Windows routines to get the area for application-data and  
> my-documents. In Vista users are under home rather than "Documents and  
> Settings".
> Make sure it can run with DEP protection on and in restricted mode.
> Don't store application data in the program directory. Use "Application  
> Data" instead.
> Make sure to ask if the user wants to store the program for all users 
> or  just the current user. If all users is selected make sure to store 
> the  application data under all users. Preferences etc. should be stored 
> in the  current users "Application Data" directory. Directory convention 
> is the  same as under "Program Files" company name > program name > 
> version is  best to avoid conflicts.
> Same applies to registry values. Use a group available to all the users.
> These are good conventions under Xp as well, but since Vista to a much  
> higher degree encourages the use of restricted mode more home users 
> will  percieve this as a problem.

Wow, thx, good stuff.

kt

-- 
http://www.theoryyalgebra.com/

"We are what we pretend to be." -Kurt Vonnegut
From: Raymond Wiker
Subject: Re: It shipped! Well....
Date: 
Message-ID: <m2fy0j1rt4.fsf@RawMBP.local>
Ken Tilton <···········@optonline.net> writes:

> John Thingstad wrote:
>> P� Tue, 09 Oct 2007 06:50:21 +0200, skrev Ken Tilton
>> <···········@optonline.net>:
>>
>>>
>> Just a suggestion:
>> If you are uncertain about what dependencies your program uses.
>> Go to:
>> http://www.microsoft.com/technet/sysinternals/ProcessesAndThreads/ProcessExplorer.mspx
>> And download the ProcessExplorer. A indespensable tool..
>
> Thx, I had grabbed that and it helped some, but I could not get it to
> say "this process uses these DLLs".

	There's a small utility called "Dependency Viewer" (available
as a download from Microsoft somewhere) that might be useful to
discover all dlls used.
From: John Thingstad
Subject: Re: It shipped! Well....
Date: 
Message-ID: <op.tzyzjnvdpqzri1@pandora.upc.no>
P� Wed, 10 Oct 2007 03:39:54 +0200, skrev Ken Tilton  
<···········@optonline.net>:

>>   Just a suggestion:
>>  If you are uncertain about what dependencies your program uses.
>> Go to:   
>> http://www.microsoft.com/technet/sysinternals/ProcessesAndThreads/ProcessExplorer.mspx  
>>  And download the ProcessExplorer. A indespensable tool..
>
> Thx, I had grabbed that and it helped some, but I could not get it to  
> say "this process uses these DLLs".>

In ProcessExplorer go into View menu and under Lower Pane View select  
DLL's.
From: Jon Harrop
Subject: Re: When static typing is worth it
Date: 
Message-ID: <13gmdmrjheaqsba@corp.supernews.com>
Andr� Thieme wrote:
> OCaml is not really good at working on modern, 21st century tasks.

You've just explained why I don't exist...

> But you could begin to learn Lisp and be able to become much more
> productive than you have even been.

I already did. There are many points of interest but only from a historical
perspective. Nothing that I would put near a customer.

> In Lisp you have (with Qi) static typing that is more powerful than what
> F# offers,

You have a blank slate that makes it easier for you to reinvent what I
already have.

> and you will have macros and a dynamic system that can evolve 
> to your customers needs.

I already have that.

How's the Lisp pattern matching library coming along? Given how 21st century
Lisp is, I'd have thought your library wouldn't be many months overdue.
After all, if I ran my business like that, I'd be out of business...

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
From: Don Geddis
Subject: Re: When static typing is worth it
Date: 
Message-ID: <873awt3tc8.fsf@geddis.org>
Jon Harrop <···@ffconsultancy.com> wrote on Tue, 02 Oct 2007:
> If you want your code to work, choose static typing. If you're getting paid
> in cash for lashing together porn sites, choose dynamic typing.

Sweet!  I'm definitely interested in getting paid cash for using Lisp for
porn sites.  Can you give me a reference for this claim of yours?

        -- Don
_______________________________________________________________________________
Don Geddis                  http://don.geddis.org/               ···@geddis.org
Never underestimate the bandwidth of a station wagon full of tapes hurtling
down the highway.  -- Andrew Tannenbaum
From: Ken Tilton
Subject: Re: When static typing is worth it
Date: 
Message-ID: <g2CMi.271$B13.96@newsfe12.lga>
Don Geddis wrote:
> Jon Harrop <···@ffconsultancy.com> wrote on Tue, 02 Oct 2007:
> 
>>If you want your code to work, choose static typing. If you're getting paid
>>in cash for lashing together porn sites, choose dynamic typing.
> 
> 
> Sweet!  I'm definitely interested in getting paid cash for using Lisp for
> porn sites.  Can you give me a reference for this claim of yours?

Nothing up front, but The Bradshaw Prize for the first Lisp porn 
application may help you attract investors.

hth, kenny

-- 
http://www.theoryyalgebra.com/

"We are what we pretend to be." -Kurt Vonnegut
From: Cesar Rabak
Subject: Re: When static typing is worth it
Date: 
Message-ID: <fe1d63$i6f$1@aioe.org>
Ken Tilton escreveu:
> 
> 
> Don Geddis wrote:
>> Jon Harrop <···@ffconsultancy.com> wrote on Tue, 02 Oct 2007:
>>
>>> If you want your code to work, choose static typing. If you're 
>>> getting paid
>>> in cash for lashing together porn sites, choose dynamic typing.
>>
>>
>> Sweet!  I'm definitely interested in getting paid cash for using Lisp for
>> porn sites.  Can you give me a reference for this claim of yours?
> 
> Nothing up front, but The Bradshaw Prize for the first Lisp porn 
> application may help you attract investors.

But there isn't a Lisp application that screwed the competitors already 
claimed that prize?
From: Rob St. Amant
Subject: Re: When static typing is worth it
Date: 
Message-ID: <fduppc$iv3$1@blackhelicopter.databasix.com>
Jon Harrop <···@ffconsultancy.com> writes:

> . Your argument assumes that static and dynamic solutions require the same
> amount of testing. They do not. Static typing typically reduces the need
> for unit testing by 10-100x, to the point where automated unit tests and
> debuggers are no longer a crippling concern as they are in dynamically
> typed languages like Lisp.

It's sad that no systems of any significant size have ever been
implemented in Lisp, given these crippling concerns: operating
systems, production scheduling systems, real-time space mission
planning, video games, large-scale AI projects, and so forth.

But perhaps these concerns are not so crippling after all: Chapter 1
of http://www.paulgraham.com/onlisp.html explains why.
From: Rainer Joswig
Subject: Re: When static typing is worth it
Date: 
Message-ID: <joswig-4363C4.23211202102007@news-europe.giganews.com>
In article <···············@corp.supernews.com>,
 Jon Harrop <···@ffconsultancy.com> wrote:

> Some counters here:
> 
> Pascal Costanza wrote:
> > However, it
> > seems to be the case that once you have an extensive test suite for your
> > program, the correctness of your types is silently tested as well - a 
> > program would simply fail at least some test cases if the types weren't
> > "correct." So why test the types twice, and especially, why putting up
> > with the involved overhead twice?
> 
> Two points here:

Nobody cares about your bullshit.

-- 
http://lispm.dyndns.org
From: Ken Tilton
Subject: Re: When static typing is worth it
Date: 
Message-ID: <10CMi.270$B13.114@newsfe12.lga>
Rainer Joswig wrote:
> In article <···············@corp.supernews.com>,
>  Jon Harrop <···@ffconsultancy.com> wrote:
> 
> 
>>Some counters here:
>>
>>Pascal Costanza wrote:
>>
>>>However, it
>>>seems to be the case that once you have an extensive test suite for your
>>>program, the correctness of your types is silently tested as well - a 
>>>program would simply fail at least some test cases if the types weren't
>>>"correct." So why test the types twice, and especially, why putting up
>>>with the involved overhead twice?
>>
>>Two points here:
> 
> 
> Nobody cares about your bullshit.
> 

Well, I think we need to do an intervention on Pascal. I know someone at 
Betty Ford, I think we can get him in.

kt

-- 
http://www.theoryyalgebra.com/

"We are what we pretend to be." -Kurt Vonnegut
From: Pascal Costanza
Subject: Re: When static typing is worth it
Date: 
Message-ID: <5mfs1bFd54piU1@mid.individual.net>
Jon Harrop wrote:
> Some counters here:
> 
> Pascal Costanza wrote:
>> However, there is yet another level to this debate: It can be beneficial
>> to be able to evolve a program at runtime, in the sense that you cannot
>> only change the values that variables are bound to, but also function
>> and method definitions, class definitions and other entities that make
>> up your program. If you perform such changes programmatically, you
>> basically have self-modifying programs.
> 
> From the static point of view, this is just run-time dispatch and
> consequently, is solved using pattern matching in all modern FPLs.

Yes, that's exactly the part you don't understand.


Pascal

-- 
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
From: Frank Buss
Subject: Re: When static typing is worth it
Date: 
Message-ID: <1htkdn3n6vnzt.1to3xjkf477jw$.dlg@40tude.net>
Jon Harrop wrote:

> . Your argument assumes that static and dynamic solutions require the same
> amount of testing. They do not. Static typing typically reduces the need
> for unit testing by 10-100x, to the point where automated unit tests and
> debuggers are no longer a crippling concern as they are in dynamically
> typed languages like Lisp.

Can you show some examples for the 10-100x factors? I think most of the
time the tests you need to write for testing the algorithm of some
functions, already inlcudes possible problems with runtime errors caused by
passing objects of the wrong type.

> On the contrary, the literature is full of examples demonstrating static
> type systems proving correctness, e.g. one paper describes how static
> typing can be used to prove that balanced binary tree implementations
> retain balancing properties.

This sounds interesting. Do you have a link?

> With a powerful static type system (e.g. SML, OCaml, F# or Haskell), you can
> eliminate a lot of run-time errors by getting the compiler to prove that
> they cannot occur. This is precisely why the modern languages are vastly
> superior and represent the evolution of Lisp.

I don't think so. Lisp and OCaml are just different, and maybe OCaml is
better for you, but the languages have different advantages. In static
typed languages you have to write a full working program before you can
compile and run it. If you want to test something which doesn't fit the
type of other functions, you have to fix all these functions before you can
test it.

In Lisp you can interactively develop your program. It doesn't matter, if
the object type for parameters of already defined functions doesn't work
with new changes, the interactive system will tell it and you can quickly
test new ideas.

OCaml might be a good idea, if you want fast code and if you know the
problem and how to solve it already. Lisp is better if you want to explore
the problem and possible solutions. If it is too slow, you can still
annotate it with type declarations or extract hot spots in native
libraries.

-- 
Frank Buss, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
From: Ken Tilton
Subject: Re: When static typing is worth it
Date: 
Message-ID: <caNMi.4423$GK6.3406@newsfe12.lga>
Frank Buss wrote:
> Jon Harrop wrote:
> 
> 
>>. Your argument assumes that static and dynamic solutions require the same
>>amount of testing. They do not. Static typing typically reduces the need
>>for unit testing by 10-100x, to the point where automated unit tests and
>>debuggers are no longer a crippling concern as they are in dynamically
>>typed languages like Lisp.
> 
> 
> Can you show some examples for the 10-100x factors? 

OK, but those will take longer for me to make up.

Jon
From: Dmitry Statyvka
Subject: Re: When static typing is worth it
Date: 
Message-ID: <m3wsu40zq3.fsf@dstatyvka.ipnet.kiev.ua>
Jon Harrop <···@ffconsultancy.com> writes:

[...]

>> However,  there is  yet another  level to  this debate:  It  can be
>> beneficial to be able to evolve  a program at runtime, in the sense
>> that you cannot only change the values that variables are bound to,
>> but  also function  and method  definitions, class  definitions and
>> other  entities that  make up  your  program. If  you perform  such
>> changes   programmatically,  you   basically   have  self-modifying
>> programs.
>
> From the  static point of view,  this is just  run-time dispatch and
> consequently, is solved using pattern matching in all modern FPLs.

So could  you define  in ocaml function  that returns function  of the
same type?  Something a la

let rec f _ = f;;

[...]
From: Jon Harrop
Subject: Re: When static typing is worth it
Date: 
Message-ID: <13g7rgg7uarrraa@corp.supernews.com>
Dmitry Statyvka wrote:
> Jon Harrop <···@ffconsultancy.com> writes:
>>> However,  there is  yet another  level to  this debate:  It  can be
>>> beneficial to be able to evolve  a program at runtime, in the sense
>>> that you cannot only change the values that variables are bound to,
>>> but  also function  and method  definitions, class  definitions and
>>> other  entities that  make up  your  program. If  you perform  such
>>> changes   programmatically,  you   basically   have  self-modifying
>>> programs.
>>
>> From the  static point of view,  this is just  run-time dispatch and
>> consequently, is solved using pattern matching in all modern FPLs.
> 
> So could  you define  in ocaml function  that returns function  of the
> same type?  Something a la
> 
> let rec f _ = f;;

Yes, the inferred type is given:

# let rec f _ = f;;
val f : 'b -> 'a as 'a = <fun>

Such recursive types are rarely used in real code though. Self-modification
is typically implemented by abstracting over a sum type and dispatching at
run-time using pattern matching.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
From: Dmitry Statyvka
Subject: Re: When static typing is worth it
Date: 
Message-ID: <m3sl4s0ww2.fsf@dstatyvka.ipnet.kiev.ua>
Jon Harrop <···@ffconsultancy.com> writes:

> Dmitry Statyvka wrote:

[...]

>> So could  you define  in ocaml function  that returns function  of the
>> same type?  Something a la
>> 
>> let rec f _ = f;;
>
> Yes, the inferred type is given:
>
> # let rec f _ = f;;
> val f : 'b -> 'a as 'a = <fun>

Hmm.  What language/interpreter produced this output?  I have


        Objective Caml version 3.08.3

# Characters 14-15:
  let rec f _ = f ;;
                ^
This expression has type 'a -> 'b but is here used with type 'b
# 

Btw,  "'b ->  'a as  'a =  <fun>" looks  oddish a  lot as  to strongly
statically typing...  :-)

And  afaik, it's impossible  to infer  such types  with Hindley-Milner
algorithm.

> Such recursive types are rarely used in real code though.

It  doesn't matter.   My goal  is to  show the  natural  limitation of
strongly statically typed language with type inferrence, which untyped
languages is free of.

[...]
From: Jon Harrop
Subject: Re: When static typing is worth it
Date: 
Message-ID: <13g81lspkl5tpd0@corp.supernews.com>
Dmitry Statyvka wrote:
> Jon Harrop <···@ffconsultancy.com> writes:
>> # let rec f _ = f;;
>> val f : 'b -> 'a as 'a = <fun>
> 
> Hmm.  What language/interpreter produced this output?

Vanilla OCaml run with the -rectypes option.

> And  afaik, it's impossible  to infer  such types  with Hindley-Milner
> algorithm.

As you can see, OCaml already does this so it is not "impossible".

>> Such recursive types are rarely used in real code though.
> 
> It  doesn't matter. My goal  is to  show the  natural  limitation of 
> strongly statically typed language with type inferrence, which untyped
> languages is free of.

Even if the examples are of no practical importance?

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
From: Dmitry Statyvka
Subject: Re: When static typing is worth it
Date: 
Message-ID: <m3odff232y.fsf@dstatyvka.ipnet.kiev.ua>
Jon Harrop <···@ffconsultancy.com> writes:

[...]

>> Hmm.  What language/interpreter produced this output?
>
> Vanilla OCaml run with the -rectypes option.

Oops, indeed.

>> And afaik, it's impossible  to infer such types with Hindley-Milner
>> algorithm.
>
> As you can see, OCaml already does this so it is not "impossible".

Yes, if it ain't a dirty hack :-)  But it's offtopic here...

>>> Such recursive types are rarely used in real code though.
>> 
>> It doesn't  matter. My  goal is to  show the natural  limitation of
>> strongly  statically  typed language  with  type inferrence,  which
>> untyped languages is free of.
>
> Even if the examples are of no practical importance?

No if they are.

You never  know when limits  can force you  to make a  worse decision.
It's clear that  Lisp leaves more freedom in  decision making than any
statically typed language, just  because of limitations of static type
systems.

[...]
From: Jon Harrop
Subject: Re: When static typing is worth it
Date: 
Message-ID: <13g8a69r1f9kmf2@corp.supernews.com>
Dmitry Statyvka wrote:
> It's clear that  Lisp leaves more freedom in  decision making than any
> statically typed language, just  because of limitations of static type
> systems.

On the contrary, only a static language allows you to choose if and where to
add statically-checked type constraints.

Lisp offers no such freedom and, instead, puts you into the straight-jacket
of whatever rudimentary static checking your compiler happens to offer and
you end up wasting valuable development time writing and running more tests
as a consequence.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
From: Dmitry Statyvka
Subject: Re: When static typing is worth it
Date: 
Message-ID: <m34ph7877r.fsf@dstatyvka.ipnet.kiev.ua>
Jon Harrop <···@ffconsultancy.com> writes:

> Dmitry Statyvka wrote:
>> It's clear  that Lisp leaves  more freedom in decision  making than
>> any  statically  typed language,  just  because  of limitations  of
>> static type systems.
>
> On the contrary, only a static  language allows you to choose if and
> where to add statically-checked type constraints.

Mm?  You can turn off type checking when it's unwanted?

> Lisp  offers  no  such  freedom  and, instead,  puts  you  into  the
> straight-jacket  of   whatever  rudimentary  static   checking  your
> compiler  happens   to  offer  and  you  end   up  wasting  valuable
> development time writing and running more tests as a consequence.

Lisp offers  any freedom  by its macros.   You can  change compilation
and/or correctness checking as much as  you want to.  Do you need some
pattern matching  or any  other feature which  CL lacks of?   Just use
suitable library or make your own  one.  I know no other language with
such  comparable capabilities.   May be  nemerle which  uses  the same
approch in metaprogramming.  I'm not sure, but it seems that nemerle's
pattern matching implemented also by macros.
From: Jon Harrop
Subject: Re: When static typing is worth it
Date: 
Message-ID: <13gaht782jqhsa3@corp.supernews.com>
Dmitry Statyvka wrote:
> Jon Harrop <···@ffconsultancy.com> writes:
>> Dmitry Statyvka wrote:
>>> It's clear  that Lisp leaves  more freedom in decision  making than
>>> any  statically  typed language,  just  because  of limitations  of
>>> static type systems.
>>
>> On the contrary, only a static  language allows you to choose if and
>> where to add statically-checked type constraints.
> 
> Mm?  You can turn off type checking when it's unwanted?

You just use the loosest type constraints so there is nothing to statically
type check. When you move code into production, you tighten the type
constraints and use the compiler to find bugs rather than writing and
running unit tests.

>> Lisp  offers  no  such  freedom  and, instead,  puts  you  into  the
>> straight-jacket  of   whatever  rudimentary  static   checking  your
>> compiler  happens   to  offer  and  you  end   up  wasting  valuable
>> development time writing and running more tests as a consequence.
>
> Lisp offers  any freedom  by its macros.   You can  change compilation
> and/or correctness checking as much as  you want to.  Do you need some
> pattern matching  or any  other feature which  CL lacks of?   Just use
> suitable library or make your own  one.

You're advocating that ordinary users reimplement large parts of modern
languages on top of Lisp when they could just use an existing
implementation that is already faster and more mature.

What would you say if I told you that assembler offers any freedom? You can
implement your own run-time type checks and garbage collection or any other
features that assembler lacks. Just use a suitable library or write your
own.

> I know no other language with such  comparable capabilities.

On the contrary, all languages have comparable capabilities: you can write
an interpreter or compiler in any language. Indeed, developers no longer
build upon Lisp precisely because it no longer has advantages in this
context. For this purpose, Lisp has been superceded by front-ends written
in higher-level languages (particularly those with pattern matching) and
existing generic back-ends with rich libraries (like the JVM and .NET).

If you want to build a language implementation quickly then you write an
interpreter in a modern statically typed functional programming language
because it will be much shorter and much faster than any equivalent Lisp
implementation can be (look how much shorter and faster the OCaml
implementations of the Minim interpreter are).

If you want to build a fast and independent language implementation then you
write a bootstrapped compiler in C and assembler as INRIA did with OCaml
because you can easily outperform anything written in Lisp (look at how
much shorter and faster the OCaml solutions to the symbolic simplifier
were, a test of OCaml's optimizing pattern match compiler).

If you want to build a language implementation that borrows from a rich set
of libraries then you write a compiler that targets the JVM or .NET as the
creators of Scala and F# are doing (after only a tiny fraction of the
SBCL's development effort, these languages are already more capable in
every respect).

> May be  nemerle which  uses  the same 
> approch in metaprogramming.  I'm not sure, but it seems that nemerle's
> pattern matching implemented also by macros.

ML actually stands for Meta-Language and this family of languages were bred
for that purpose, evolved from Lisp and excel at metaprogramming.

But you're referring specifically to homogeneous metaprogramming rather than
metaprogramming in general. The problem with homogeneous metaprogramming is
that it limits you to the capabilities of the host language. In the case of
Lisp, this means you're limited by poor performance and unreliability (lack
of static checking). Consequently, homogeneous metaprogramming died many
years ago and is no longer a valued language feature.

Heterogeneous metaprogramming rose instead and modern compilers now target
existing languages like C, C-- or GLSL, or frameworks like the JVM
and .NET. Heterogeneous metaprogramming is facilitated by a variety of
language features like expressive static type systems and pattern matching.
You'll notice that these features post-date Lisp and, although you could
theoretically try to retrofit them onto Lisp in some form, there is no
point because awesome implementations of these features (and many more) are
already widely available in all modern functional programming languages.

For example, this is why the FFT routines in Matlab are an OCaml program
that generates C code that then performs the FFTs, rather than a Lisp
program that uses EVAL.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
From: Raffael Cavallaro
Subject: Re: When static typing is worth it
Date: 
Message-ID: <2007100420204250073-raffaelcavallaro@pasdespamsilvousplaitmaccom>
On 2007-10-04 15:56:33 -0400, the falling fly-eater said:

>> 
>> Lisp offers  any freedom  by its macros.   You can  change compilation
>> and/or correctness checking as much as  you want to.  Do you need some
>> pattern matching  or any  other feature which  CL lacks of?   Just use
>> suitable library or make your own  one.
> 
> You're advocating that ordinary users reimplement large parts of modern
> languages on top of Lisp when they could just use an existing
> implementation that is already faster and more mature.

No need to:

<http://common-lisp.net/project/cl-unification/>
<http://www.cliki.net/fare-matcher>
<http://common-lisp.net/project/bese/arnesi.html>
<http://lisa.sourceforge.net/>
From: Jon Harrop
Subject: Re: When static typing is worth it
Date: 
Message-ID: <13gb6b3r64eeedc@corp.supernews.com>
Raffael Cavallaro wrote:
> On 2007-10-04 15:56:33 -0400, the falling fly-eater said:
>>> Lisp offers  any freedom  by its macros.   You can  change compilation
>>> and/or correctness checking as much as  you want to.  Do you need some
>>> pattern matching  or any  other feature which  CL lacks of?   Just use
>>> suitable library or make your own  one.
>> 
>> You're advocating that ordinary users reimplement large parts of modern
>> languages on top of Lisp when they could just use an existing
>> implementation that is already faster and more mature.
> 
> No need to:
> 
> <http://common-lisp.net/project/cl-unification/>
> <http://www.cliki.net/fare-matcher>
> <http://common-lisp.net/project/bese/arnesi.html>
> <http://lisa.sourceforge.net/>

None of those libraries give equivalent functionality, of course, which is
why they remain largely unused.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
From: Raffael Cavallaro
Subject: Re: When static typing is worth it
Date: 
Message-ID: <2007100500271927544-raffaelcavallaro@pasdespamsilvousplaitmaccom>
On 2007-10-04 21:45:20 -0400, the hurtling horned toad said:

> None of those libraries give equivalent functionality, of course, which is
> why they remain largely unused.

Actually, cl-unification gives a full blown unifier, not just a pattern 
matcher, so it gives even greater functionality. They remain little 
used because Common Lispers correctly see pattern matching as a 
specialized need, not the axis mundi you've made it out to be.
From: Ken Tilton
Subject: Re: When static typing is worth it
Date: 
Message-ID: <JfjNi.27$Zn2.1@newsfe12.lga>
Raffael Cavallaro wrote:
> On 2007-10-04 21:45:20 -0400, the winged wart source said:
> 
>> None of those libraries give equivalent functionality, of course, 
>> which is
>> why they remain largely unused.
> 
> 
> Actually, cl-unification gives a full blown unifier, not just a pattern 
> matcher, so it gives even greater functionality. They remain little used 
> because Common Lispers correctly see pattern matching as a specialized 
> need, not the axis mundi you've made it out to be.
> 

Let's settle that excellent point all and for once: let's see a useful 
little real-world example from the land of patterned dispatch. Otherwise 
this thread will just keep hopping from lily pad to lily pad.

kenny

-- 
http://www.theoryyalgebra.com/

"We are what we pretend to be." -Kurt Vonnegut
From: ···············@gmail.com
Subject: Re: When static typing is worth it
Date: 
Message-ID: <1191574712.542683.156740@22g2000hsm.googlegroups.com>
On 5 Oct, 05:41, Ken Tilton <···········@optonline.net> wrote:

> Let's settle that excellent point all and for once: let's see a useful
> little real-world example from the land of patterned dispatch. Otherwise
> this thread will just keep hopping from lily pad to lily pad.

I'd also like some real world example of how inclusion of these
features in Lisp would virtually eliminate my testing. I asked this
question 2 days ago but it was just about the only post that Jon
didn't reply to.

Instead the sort of examples offered are "the Minim interpreter" and
"the symbolic simplifier" which in my mind are not the sort of
programs that generate a 1000 angry phone calls to an under resourced
help desk when they're released with a bug.

I suppose I just get a bit skeptical when the "type theorists" start
telling me how to write "real world" software.

--
Phil
http://phil.nullable.eu/
From: Slobodan Blazeski
Subject: Re: When static typing is worth it
Date: 
Message-ID: <1191579432.372030.104850@19g2000hsx.googlegroups.com>
On Oct 5, 10:58 am, ···············@gmail.com wrote:
> On 5 Oct, 05:41, Ken Tilton <···········@optonline.net> wrote:
>
> > Let's settle that excellent point all and for once: let's see a useful
> > little real-world example from the land of patterned dispatch. Otherwise
> > this thread will just keep hopping from lily pad to lily pad.
>
> I'd also like some real world example of how inclusion of these
> features in Lisp would virtually eliminate my testing. I asked this
> question 2 days ago but it was just about the only post that Jon
> didn't reply to.

It would eliminate the real world testing same as pair programming
would do for a polish keyboard

Last week someone emailed me about a bug in CityDesk which only
appears in Polish Windows, because of the way that operating system
uses Right-Alt to enter special characters. We tested Windows 95,
95OSR2, 98, 98SE, Me, NT 4.0, Win 2000, and Win XP. We tested with IE
5.01, 5.5, or 6.0 installed. We tested US, Spanish, French, Hebrew,
and Chinese Windows. But we hadn't quite gotten around to Polish yet.
http://www.joelonsoftware.com/articles/FiveWorlds.html

Bugs happen and they will continue to happen , in Macedonian windows
there was a problem when people trying to export to excel use
filenames with "/:" and /or Macedonian characters.
Or maybe amphibian language has built in type checking and pattern
matching for Polish keyboards and all other crup that users will throw
at it.

If the input editor has been designed to reject all bad input, an
ingenious idiot will discover a method to get bad data past it.
http://homepages.cwi.nl/~jankok/etc/Laws.html
>
> Instead the sort of examples offered are "the Minim interpreter" and
> "the symbolic simplifier" which in my mind are not the sort of
> programs that generate a 1000 angry phone calls to an under resourced
> help desk when they're released with a bug.
>
> I suppose I just get a bit skeptical when the "type theorists" start
> telling me how to write "real world" software.
>
> --
> Philhttp://phil.nullable.eu/
From: Slobodan Blazeski
Subject: Re: When static typing is worth it
Date: 
Message-ID: <1191612781.656446.175750@19g2000hsx.googlegroups.com>
On Oct 5, 6:41 am, Ken Tilton <···········@optonline.net> wrote:
> Raffael Cavallaro wrote:
> > On 2007-10-04 21:45:20 -0400, the winged wart source said:
>
> >> None of those libraries give equivalent functionality, of course,
> >> which is
> >> why they remain largely unused.
>
> > Actually, cl-unification gives a full blown unifier, not just a pattern
> > matcher, so it gives even greater functionality. They remain little used
> > because Common Lispers correctly see pattern matching as a specialized
> > need, not the axis mundi you've made it out to be.
>
> Let's settle that excellent point all and for once: let's see a useful
> little real-world example from the land of patterned dispatch. Otherwise
> this thread will just keep hopping from lily pad to lily pad.

I'm afraid that his Kennyness will be disappointed. If our resident
toad, Opss troll was able to make any real world programm he would be
doing it instead of wasting time with losers who don't even appreciate
virtues of pattern matching or god help our souls static typing.

What do you call a frog that crosses the road, jumps in a puddle, and
crosses the road again?
A dirty double-crosser!


>
> kenny
>
> --http://www.theoryyalgebra.com/
From: Jon Harrop
Subject: Re: When static typing is worth it
Date: 
Message-ID: <13gdpohh9njgkcb@corp.supernews.com>
Raffael Cavallaro wrote:

> On 2007-10-04 21:45:20 -0400, the hurtling horned toad said:
> 
>> None of those libraries give equivalent functionality, of course, which
>> is why they remain largely unused.
> 
> Actually, cl-unification gives a full blown unifier, not just a pattern
> matcher, so it gives even greater functionality.

It offers no static checking, so it offers only different functionality.

> They remain little 
> used because Common Lispers correctly see pattern matching as a
> specialized need, not the axis mundi you've made it out to be.

Meanwhile, it languages that have good support for pattern matching everyone
uses it.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
From: Raffael Cavallaro
Subject: Re: When static typing is worth it
Date: 
Message-ID: <2007100600552438165-raffaelcavallaro@pasdespamsilvousplaitmaccom>
On 2007-10-05 01:54:58 -0400, Jon Harrop <···@ffconsultancy.com> said:

> Meanwhile, it languages that have good support for pattern matching everyone
> uses it.

In other news, in countries where traffic stays to the left, people 
drive on the left hand side of the road.

This just in, in languages with s-expressions, everyone uses s-expressions.

Wow, you just have no self reflection whatsoever. You come from a world 
based on pattern matching, and you don't realize that the fact that you 
prefer it is because programming style in the language you're used to 
is largely based around it. It just doesn't seem possible to you that 
people who have seen other expressive means have tried *ml sytle 
languages and "powerfully expressive" pattern matching, and chosen 
*not* to use *ml/haskell anyway.

I think you have the worst case of "everybody lives in my head" I've 
ever come across. You just can't conceive that any rational human being 
could not like what you like.

Here, have some pistaccio ice cream - it's your favorite because *I* love it.
From: Dmitry Statyvka
Subject: Re: When static typing is worth it
Date: 
Message-ID: <m3sl4jnb3j.fsf@dstatyvka.ipnet.kiev.ua>
Jon Harrop <···@ffconsultancy.com> writes:

[...]

>>> Lisp  offers  no  such  freedom  and, instead,  puts  you  into  the
>>> straight-jacket  of   whatever  rudimentary  static   checking  your
>>> compiler  happens   to  offer  and  you  end   up  wasting  valuable
>>> development time writing and running more tests as a consequence.
>>
>> Lisp offers  any freedom  by its macros.   You can  change compilation
>> and/or correctness checking as much as  you want to.  Do you need some
>> pattern matching  or any  other feature which  CL lacks of?   Just use
>> suitable library or make your own  one.
>
> You're  advocating that  ordinary users  reimplement large  parts of
> modern languages on top of Lisp when they could just use an existing
> implementation that is already faster and more mature.

No, I'm advocating that professional programmer would implement wanted
features.  "Ordinary  users" is very  loose term.  I'm not  care about
poor programmers.

> What would you say if I  told you that assembler offers any freedom?
> You  can  implement  your  own  run-time  type  checks  and  garbage
> collection or  any other features  that assembler lacks. Just  use a
> suitable library or write your own.

I could if assembler would have such macros as lisp has.  :-)

>> I know no other language with such  comparable capabilities.
>
> On the contrary, all languages have comparable capabilities: you can
> write an interpreter or compiler in any language.

I need no new compiler/interpreter, I want to customize a given one.

[... debatable and unrelated discourse skipped, sorry  ...]

>> May be nemerle which uses the same approch in metaprogramming.  I'm
>> not sure, but it  seems that nemerle's pattern matching implemented
>> also by macros.
>
> ML actually  stands for Meta-Language  and this family  of languages
> were  bred  for  that  purpose,  evolved  from  Lisp  and  excel  at
> metaprogramming.

"Meta-"    in   "Meta-language"   is    unrelated   to    "meta-"   in
"metaprogramming".  I have no idea what you mean.

> But  you're referring  specifically  to homogeneous  metaprogramming
> rather than metaprogramming in general.

Yes.  Metaprogramming in general is not specific to lisp.

> The problem  with homogeneous metaprogramming is that  it limits you
> to the capabilities of the host language.

It's not a problem as soon  as the host language is extensible because
of homogeneous metaprogramming.

> In the case  of Lisp, this means you're  limited by poor performance
> and unreliability (lack of static checking).

Performance and reliability  tends to be relient on  program design at
most rather language features.

> Consequently, homogeneous metaprogramming died many years ago and is
> no longer a valued language feature.

It seems likely that you give a free range to fancy.

[...]

ps.

Dear Dr Harrop, I will (at least I'll try to) not discuse further with
you on this NG.  I came to  a decision that you appears here as either
the troll or  the evangelist.  I believe it tied  to your business but
it  makes any  furhter  discussion unproductive  and uninteresting  to
me. Your messages in F# maling list are far more adequate.
From: Jon Harrop
Subject: Re: When static typing is worth it
Date: 
Message-ID: <13grmm4qe8j1ma0@corp.supernews.com>
Dmitry Statyvka wrote:
> Jon Harrop <···@ffconsultancy.com> writes:
>> You're  advocating that  ordinary users  reimplement large  parts of
>> modern languages on top of Lisp when they could just use an existing
>> implementation that is already faster and more mature.
> 
> No, I'm advocating that professional programmer would implement wanted
> features.

While I am all for learning, it is simply not possible for
every "professional" programmer to learn how to reimplement everything
themselves, let alone actually write the reimplementations themselves.
Finally, even if this were theoretically impossible it would still be an
awful idea in practice because it completely undermines interoperability
between programmers. 

Ask the Lisp community why it is a bad idea to overuse macros, for example.

If you want a practical example, try reimplementing the run-time
capabilities of the pattern matchers in ocamlopt, ghc for fsc. You will
need to read a lot of research papers before you can even start. After
that, you're looking at tens of thousands of lines of code. Finally, your
work will be far less mature and tested than those. Can you really imagine
a world where a "good" Lisp programmer must try to do this?

> "Ordinary  users" is very  loose term.  I'm not  care about 
> poor programmers.

Scientists do great work for mankind and many use computers as tools.
Insisting that they either reimplement everything themselves or branding
them "poor programmers" is silly.

>>> I know no other language with such comparable capabilities.
>>
>> On the contrary, all languages have comparable capabilities: you can
>> write an interpreter or compiler in any language.
> 
> I need no new compiler/interpreter, I want to customize a given one.

You can customise the compilers/interpreters of other languages as well.
There is no difference between OCaml and Lisp in this respect (both have
macro systems).

>> ML actually  stands for Meta-Language  and this family  of languages
>> were  bred  for  that  purpose,  evolved  from  Lisp  and  excel  at
>> metaprogramming.
> 
> "Meta-"    in   "Meta-language"   is    unrelated   to    "meta-"   in
> "metaprogramming".

No, they are the same.

> I have no idea what you mean. 

The ML family of languages excel at manipulating programs written in any
language.

>> The problem  with homogeneous metaprogramming is that  it limits you
>> to the capabilities of the host language.
> 
> It's not a problem as soon as the host language is extensible because
> of homogeneous metaprogramming.

Does Microsoft SQL server execute Lisp? Does an nVidia GPU execute Lisp?

>> In the case  of Lisp, this means you're  limited by poor performance
>> and unreliability (lack of static checking).
> 
> Performance and reliability  tends to be relient on  program design at
> most rather language features.

Implementation is still far more error prone than design. Consequently, many
important ways to improve software reliability depend upon the static
checking of written source code. Static type checking is the most common
method but full-blown automated theorem proving is not uncommon. Look at
the extensive use of OCaml for verification by Microsoft and Intel, for
example.

>> Consequently, homogeneous metaprogramming died many years ago and is
>> no longer a valued language feature.
> 
> It seems likely that you give a free range to fancy.

What metaprogramming approach underpins the FFT routines in MATLAB?

What is the primary purpose of Microsoft's LINQ?

These are not "fancy", they are core components in billion dollar
industries.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
From: Rainer Joswig
Subject: Re: When static typing is worth it
Date: 
Message-ID: <2007101112043575249-joswig@lispde>
On 2007-10-11 10:03:08 +0200, Jon Harrop <···@ffconsultancy.com> said:

> You can customise the compilers/interpreters of other languages as well.
> There is no difference between OCaml and Lisp in this respect (both have
> macro systems).

Only that it is not used in OCAML and OCAML's 'macros' are a preprocessor,
while Lisp's macros are built-in and are used everywhere. Check
out the Hyperspec for macros in Common Lisp. In OCAML the
preprocessor is just an add-on and even the OCAML implementation
does not use it at all. Shows, I'd say.

...

> These are not "fancy", they are core components in billion dollar
> industries.

Yeah, MS Word is used in almost every company. Now Microsoft Word
is responsible for Multi-billion dollar industries. And VBA, especially.

Autolisp has been used for drafting many things around you.
Now that is multi-billion.

ICAD has been used for many turbines used in Boeing and Airbus 
machines. Now add the value
of all flights of Boeing in the last decades. Wow!

Ford has been using PTC's Proengineer design (a Lisp app) for the 
design of many cars.
Add them up.

Emacs has been used in multi-million lines of code.
Most OCAML programs are written with Emacs.
Emacs owns OCAML practically.
From: Jon Harrop
Subject: Re: When static typing is worth it
Date: 
Message-ID: <13gs3ad95tkikd8@corp.supernews.com>
Rainer Joswig wrote:
> ...even the OCAML implementation does not use it at all. Shows, I'd say.

Misinformation.

>> These are not "fancy", they are core components in billion dollar
>> industries.
> 
> Yeah, MS Word is used in almost every company. Now Microsoft Word
> is responsible for Multi-billion dollar industries. And VBA, especially.
> 
> Autolisp has been used for drafting many things around you.
> Now that is multi-billion.
> 
> ICAD has been used for many turbines used in Boeing and Airbus
> machines. Now add the value
> of all flights of Boeing in the last decades. Wow!
> 
> Ford has been using PTC's Proengineer design (a Lisp app) for the
> design of many cars.
> Add them up.

Is Common Lisp still used in any of these applications?

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
From: Rainer Joswig
Subject: Re: When static typing is worth it
Date: 
Message-ID: <2007101114252750073-joswig@lispde>
On 2007-10-11 13:38:46 +0200, Jon Harrop <···@ffconsultancy.com> said:

> Rainer Joswig wrote:
>> ...even the OCAML implementation does not use it at all. Shows, I'd say.
> 
> Misinformation.

Look at the OCAML source. The preprocessor is used for nothing. Nada. Nichts.
You could delete the directory, change the build scripts and all runs fine.

> 
>>> These are not "fancy", they are core components in billion dollar
>>> industries.
>> 
>> Yeah, MS Word is used in almost every company. Now Microsoft Word
>> is responsible for Multi-billion dollar industries. And VBA, especially.
>> 
>> Autolisp has been used for drafting many things around you.
>> Now that is multi-billion.
>> 
>> ICAD has been used for many turbines used in Boeing and Airbus
>> machines. Now add the value
>> of all flights of Boeing in the last decades. Wow!
>> 
>> Ford has been using PTC's Proengineer design (a Lisp app) for the
>> design of many cars.
>> Add them up.
> 
> Is Common Lisp still used in any of these applications?

As far as I know Microsoft does not use Common Lisp for MS Word anymore.

Though I once found a mock-up of the Microsoft Word application
written in Macintosh Common Lisp on some developer CD. (no joke)
They used Macintosh Common Lisp to prototype the user interface
of the Macintosh-based MS Word. The application had a very complete
implementation of the MS Word user interface. You could only
see that it was written in Lisp, by inspecting it.
That was some years ago.
But now Microsoft is basically all over F#, which makes F# a 
multi-gazillion dollar
business. I heard. Or so, something like that...

Check out this one:   http://www.ascent.com/aviation-airlines.html

Means that Delta Airlines, Japan Airlines and others are basically
managing their operations with some Lisp apps. That means
baggage belts and all that.
Their software also operates major airports like San Francisco 
International Airport.
The new buildings at SFO were costing 2.4 Billion dollars. All that 
they can manage
the stuff with some Lisp apps.

Though verifying driver code with F# in Microsoft Windows is almost as 
exciting.
Hmm. Maybe. Maybe not.
From: Klaus Schilling
Subject: Re: When static typing is worth it
Date: 
Message-ID: <87tzod577p.fsf@web.de>
Jon Harrop <···@ffconsultancy.com> writes:
>
> While I am all for learning, it is simply not possible for
> every "professional" programmer to learn how to reimplement everything
> themselves, let alone actually write the reimplementations themselves.
> Finally, even if this were theoretically impossible it would still be an
> awful idea in practice because it completely undermines interoperability
> between programmers. 

interoperability is obsolete. Decent programmers are autist savants and 
don't care a dime for such an awful absurdity.

>
> Ask the Lisp community why it is a bad idea to overuse macros, for example.
>


it is nowhere near a bad idea
>
> What is the primary purpose of Microsoft's LINQ?

perverting, corrupting, exploiting, and oppressing mankind

            Klaus Schilling
From: Dmitry Statyvka
Subject: Re: When static typing is worth it
Date: 
Message-ID: <m3r6k3nb1n.fsf@dstatyvka.ipnet.kiev.ua>
Jon Harrop <···@ffconsultancy.com> writes:

[...]

>>> Lisp  offers  no  such  freedom  and, instead,  puts  you  into  the
>>> straight-jacket  of   whatever  rudimentary  static   checking  your
>>> compiler  happens   to  offer  and  you  end   up  wasting  valuable
>>> development time writing and running more tests as a consequence.
>>
>> Lisp offers  any freedom  by its macros.   You can  change compilation
>> and/or correctness checking as much as  you want to.  Do you need some
>> pattern matching  or any  other feature which  CL lacks of?   Just use
>> suitable library or make your own  one.
>
> You're  advocating that  ordinary users  reimplement large  parts of
> modern languages on top of Lisp when they could just use an existing
> implementation that is already faster and more mature.

No, I'm advocating that professional programmer would implement wanted
features.  "Ordinary  users" is very  loose term.  I'm not  care about
poor programmers.

> What would you say if I  told you that assembler offers any freedom?
> You  can  implement  your  own  run-time  type  checks  and  garbage
> collection or  any other features  that assembler lacks. Just  use a
> suitable library or write your own.

I could if assembler would have such macros as lisp has.  :-)

>> I know no other language with such  comparable capabilities.
>
> On the contrary, all languages have comparable capabilities: you can
> write an interpreter or compiler in any language.

I need no new compiler/interpreter, I want to customize a given one.

[... debatable and unrelated discourse skipped, sorry  ...]

>> May be nemerle which uses the same approch in metaprogramming.  I'm
>> not sure, but it  seems that nemerle's pattern matching implemented
>> also by macros.
>
> ML actually  stands for Meta-Language  and this family  of languages
> were  bred  for  that  purpose,  evolved  from  Lisp  and  excel  at
> metaprogramming.

"Meta-"    in   "Meta-language"   is    unrelated   to    "meta-"   in
"metaprogramming".  I have no idea what you mean.

> But  you're referring  specifically  to homogeneous  metaprogramming
> rather than metaprogramming in general.

Yes.  Metaprogramming in general is not specific to lisp.

> The problem  with homogeneous metaprogramming is that  it limits you
> to the capabilities of the host language.

It's not a problem as soon  as the host language is extensible because
of homogeneous metaprogramming.

> In the case  of Lisp, this means you're  limited by poor performance
> and unreliability (lack of static checking).

Performance and reliability  tends to be relient on  program design at
most rather language features.

> Consequently, homogeneous metaprogramming died many years ago and is
> no longer a valued language feature.

It seems likely that you give a free range to fancy.

[...]

ps.

Dear Dr Harrop, I will (at least I'll try to) not discuse further with
you on this NG.  I came to  a decision that you appears here as either
the troll or  the evangelist.  I believe it tied  to your business but
it  makes any  furhter  discussion unproductive  and uninteresting  to
me. Your messages in F# maling list are far more adequate.
From: Dmitry Statyvka
Subject: Re: When static typing is worth it
Date: 
Message-ID: <m3prznnaxv.fsf@dstatyvka.ipnet.kiev.ua>
Jon Harrop <···@ffconsultancy.com> writes:

[...]

>>> Lisp  offers  no  such  freedom  and, instead,  puts  you  into  the
>>> straight-jacket  of   whatever  rudimentary  static   checking  your
>>> compiler  happens   to  offer  and  you  end   up  wasting  valuable
>>> development time writing and running more tests as a consequence.
>>
>> Lisp offers  any freedom  by its macros.   You can  change compilation
>> and/or correctness checking as much as  you want to.  Do you need some
>> pattern matching  or any  other feature which  CL lacks of?   Just use
>> suitable library or make your own  one.
>
> You're  advocating that  ordinary users  reimplement large  parts of
> modern languages on top of Lisp when they could just use an existing
> implementation that is already faster and more mature.

No, I'm advocating that professional programmer would implement wanted
features.  "Ordinary  users" is very  loose term.  I'm not  care about
poor programmers.

> What would you say if I  told you that assembler offers any freedom?
> You  can  implement  your  own  run-time  type  checks  and  garbage
> collection or  any other features  that assembler lacks. Just  use a
> suitable library or write your own.

I could if assembler would have such macros as lisp has.  :-)

>> I know no other language with such  comparable capabilities.
>
> On the contrary, all languages have comparable capabilities: you can
> write an interpreter or compiler in any language.

I need no new compiler/interpreter, I want to customize a given one.

[... debatable and unrelated discourse skipped, sorry  ...]

>> May be nemerle which uses the same approch in metaprogramming.  I'm
>> not sure, but it  seems that nemerle's pattern matching implemented
>> also by macros.
>
> ML actually  stands for Meta-Language  and this family  of languages
> were  bred  for  that  purpose,  evolved  from  Lisp  and  excel  at
> metaprogramming.

"Meta-"    in   "Meta-language"   is    unrelated   to    "meta-"   in
"metaprogramming".  I have no idea what you mean.

> But  you're referring  specifically  to homogeneous  metaprogramming
> rather than metaprogramming in general.

Yes.  Metaprogramming in general is not specific to lisp.

> The problem  with homogeneous metaprogramming is that  it limits you
> to the capabilities of the host language.

It's not a problem as soon  as the host language is extensible because
of homogeneous metaprogramming.

> In the case  of Lisp, this means you're  limited by poor performance
> and unreliability (lack of static checking).

Performance and reliability  tends to be relient on  program design at
most rather language features.

> Consequently, homogeneous metaprogramming died many years ago and is
> no longer a valued language feature.

It seems likely that you give a free range to fancy.

[...]

ps.

Dear Dr Harrop, I will (at least I'll try to) not discuse further with
you on this NG.  I came to  a decision that you appears here as either
the troll or  the evangelist.  I believe it tied  to your business but
it  makes any  furhter  discussion unproductive  and uninteresting  to
me. Your messages in F# maling list are far more adequate.
From: Dmitry Statyvka
Subject: Re: When static typing is worth it
Date: 
Message-ID: <m3odf7nau0.fsf@dstatyvka.ipnet.kiev.ua>
Jon Harrop <···@ffconsultancy.com> writes:

[...]

>>> Lisp  offers  no  such  freedom  and, instead,  puts  you  into  the
>>> straight-jacket  of   whatever  rudimentary  static   checking  your
>>> compiler  happens   to  offer  and  you  end   up  wasting  valuable
>>> development time writing and running more tests as a consequence.
>>
>> Lisp offers  any freedom  by its macros.   You can  change compilation
>> and/or correctness checking as much as  you want to.  Do you need some
>> pattern matching  or any  other feature which  CL lacks of?   Just use
>> suitable library or make your own  one.
>
> You're  advocating that  ordinary users  reimplement large  parts of
> modern languages on top of Lisp when they could just use an existing
> implementation that is already faster and more mature.

No, I'm advocating that professional programmer would implement wanted
features.  "Ordinary  users" is very  loose term.  I'm not  care about
poor programmers.

> What would you say if I  told you that assembler offers any freedom?
> You  can  implement  your  own  run-time  type  checks  and  garbage
> collection or  any other features  that assembler lacks. Just  use a
> suitable library or write your own.

I could if assembler would have such macros as lisp has.  :-)

>> I know no other language with such  comparable capabilities.
>
> On the contrary, all languages have comparable capabilities: you can
> write an interpreter or compiler in any language.

I need no new compiler/interpreter, I want to customize a given one.

[... debatable and unrelated discourse skipped, sorry  ...]

>> May be nemerle which uses the same approch in metaprogramming.  I'm
>> not sure, but it  seems that nemerle's pattern matching implemented
>> also by macros.
>
> ML actually  stands for Meta-Language  and this family  of languages
> were  bred  for  that  purpose,  evolved  from  Lisp  and  excel  at
> metaprogramming.

"Meta-"    in   "Meta-language"   is    unrelated   to    "meta-"   in
"metaprogramming".  I have no idea what you mean.

> But  you're referring  specifically  to homogeneous  metaprogramming
> rather than metaprogramming in general.

Yes.  Metaprogramming in general is not specific to lisp.

> The problem  with homogeneous metaprogramming is that  it limits you
> to the capabilities of the host language.

It's not a problem as soon  as the host language is extensible because
of homogeneous metaprogramming.

> In the case  of Lisp, this means you're  limited by poor performance
> and unreliability (lack of static checking).

Performance and reliability  tends to be relient on  program design at
most rather language features.

> Consequently, homogeneous metaprogramming died many years ago and is
> no longer a valued language feature.

It seems likely that you give a free range to fancy.

[...]

ps.

Dear Dr Harrop, I will (at least I'll try to) not discuse further with
you on this NG.  I came to  a decision that you appears here as either
the troll or  the evangelist.  I believe it tied  to your business but
it  makes any  furhter  discussion unproductive  and uninteresting  to
me. Your messages in F# maling list are far more adequate.
From: Dmitry Statyvka
Subject: Re: When static typing is worth it
Date: 
Message-ID: <m3myurnash.fsf@dstatyvka.ipnet.kiev.ua>
Jon Harrop <···@ffconsultancy.com> writes:

[...]

>>> Lisp  offers  no  such  freedom  and, instead,  puts  you  into  the
>>> straight-jacket  of   whatever  rudimentary  static   checking  your
>>> compiler  happens   to  offer  and  you  end   up  wasting  valuable
>>> development time writing and running more tests as a consequence.
>>
>> Lisp offers  any freedom  by its macros.   You can  change compilation
>> and/or correctness checking as much as  you want to.  Do you need some
>> pattern matching  or any  other feature which  CL lacks of?   Just use
>> suitable library or make your own  one.
>
> You're  advocating that  ordinary users  reimplement large  parts of
> modern languages on top of Lisp when they could just use an existing
> implementation that is already faster and more mature.

No, I'm advocating that professional programmer would implement wanted
features.  "Ordinary  users" is very  loose term.  I'm not  care about
poor programmers.

> What would you say if I  told you that assembler offers any freedom?
> You  can  implement  your  own  run-time  type  checks  and  garbage
> collection or  any other features  that assembler lacks. Just  use a
> suitable library or write your own.

I could if assembler would have such macros as lisp has.  :-)

>> I know no other language with such  comparable capabilities.
>
> On the contrary, all languages have comparable capabilities: you can
> write an interpreter or compiler in any language.

I need no new compiler/interpreter, I want to customize a given one.

[... debatable and unrelated discourse skipped, sorry  ...]

>> May be nemerle which uses the same approch in metaprogramming.  I'm
>> not sure, but it  seems that nemerle's pattern matching implemented
>> also by macros.
>
> ML actually  stands for Meta-Language  and this family  of languages
> were  bred  for  that  purpose,  evolved  from  Lisp  and  excel  at
> metaprogramming.

"Meta-"    in   "Meta-language"   is    unrelated   to    "meta-"   in
"metaprogramming".  I have no idea what you mean.

> But  you're referring  specifically  to homogeneous  metaprogramming
> rather than metaprogramming in general.

Yes.  Metaprogramming in general is not specific to lisp.

> The problem  with homogeneous metaprogramming is that  it limits you
> to the capabilities of the host language.

It's not a problem as soon  as the host language is extensible because
of homogeneous metaprogramming.

> In the case  of Lisp, this means you're  limited by poor performance
> and unreliability (lack of static checking).

Performance and reliability  tends to be relient on  program design at
most rather language features.

> Consequently, homogeneous metaprogramming died many years ago and is
> no longer a valued language feature.

It seems likely that you give a free range to fancy.

[...]

ps.

Dear Dr Harrop, I will (at least I'll try to) not discuse further with
you on this NG.  I came to  a decision that you appears here as either
the troll or  the evangelist.  I believe it tied  to your business but
it  makes any  furhter  discussion unproductive  and uninteresting  to
me. Your messages in F# maling list are far more adequate.
From: Dmitry Statyvka
Subject: Re: When static typing is worth it
Date: 
Message-ID: <m3lkabnar6.fsf@dstatyvka.ipnet.kiev.ua>
Jon Harrop <···@ffconsultancy.com> writes:

[...]

>>> Lisp  offers  no  such  freedom  and, instead,  puts  you  into  the
>>> straight-jacket  of   whatever  rudimentary  static   checking  your
>>> compiler  happens   to  offer  and  you  end   up  wasting  valuable
>>> development time writing and running more tests as a consequence.
>>
>> Lisp offers  any freedom  by its macros.   You can  change compilation
>> and/or correctness checking as much as  you want to.  Do you need some
>> pattern matching  or any  other feature which  CL lacks of?   Just use
>> suitable library or make your own  one.
>
> You're  advocating that  ordinary users  reimplement large  parts of
> modern languages on top of Lisp when they could just use an existing
> implementation that is already faster and more mature.

No, I'm advocating that professional programmer would implement wanted
features.  "Ordinary  users" is very  loose term.  I'm not  care about
poor programmers.

> What would you say if I  told you that assembler offers any freedom?
> You  can  implement  your  own  run-time  type  checks  and  garbage
> collection or  any other features  that assembler lacks. Just  use a
> suitable library or write your own.

I could if assembler would have such macros as lisp has.  :-)

>> I know no other language with such  comparable capabilities.
>
> On the contrary, all languages have comparable capabilities: you can
> write an interpreter or compiler in any language.

I need no new compiler/interpreter, I want to customize a given one.

[... debatable and unrelated discourse skipped, sorry  ...]

>> May be nemerle which uses the same approch in metaprogramming.  I'm
>> not sure, but it  seems that nemerle's pattern matching implemented
>> also by macros.
>
> ML actually  stands for Meta-Language  and this family  of languages
> were  bred  for  that  purpose,  evolved  from  Lisp  and  excel  at
> metaprogramming.

"Meta-"    in   "Meta-language"   is    unrelated   to    "meta-"   in
"metaprogramming".  I have no idea what you mean.

> But  you're referring  specifically  to homogeneous  metaprogramming
> rather than metaprogramming in general.

Yes.  Metaprogramming in general is not specific to lisp.

> The problem  with homogeneous metaprogramming is that  it limits you
> to the capabilities of the host language.

It's not a problem as soon  as the host language is extensible because
of homogeneous metaprogramming.

> In the case  of Lisp, this means you're  limited by poor performance
> and unreliability (lack of static checking).

Performance and reliability  tends to be relient on  program design at
most rather language features.

> Consequently, homogeneous metaprogramming died many years ago and is
> no longer a valued language feature.

It seems likely that you give a free range to fancy.

[...]

ps.

Dear Dr Harrop, I will (at least I'll try to) not discuse further with
you on this NG.  I came to  a decision that you appears here as either
the troll or  the evangelist.  I believe it tied  to your business but
it  makes any  furhter  discussion unproductive  and uninteresting  to
me. Your messages in F# maling list are far more adequate.
From: Dmitry Statyvka
Subject: Re: When static typing is worth it
Date: 
Message-ID: <m3k5pvnaqd.fsf@dstatyvka.ipnet.kiev.ua>
Jon Harrop <···@ffconsultancy.com> writes:

[...]

>>> Lisp  offers  no  such  freedom  and, instead,  puts  you  into  the
>>> straight-jacket  of   whatever  rudimentary  static   checking  your
>>> compiler  happens   to  offer  and  you  end   up  wasting  valuable
>>> development time writing and running more tests as a consequence.
>>
>> Lisp offers  any freedom  by its macros.   You can  change compilation
>> and/or correctness checking as much as  you want to.  Do you need some
>> pattern matching  or any  other feature which  CL lacks of?   Just use
>> suitable library or make your own  one.
>
> You're  advocating that  ordinary users  reimplement large  parts of
> modern languages on top of Lisp when they could just use an existing
> implementation that is already faster and more mature.

No, I'm advocating that professional programmer would implement wanted
features.  "Ordinary  users" is very  loose term.  I'm not  care about
poor programmers.

> What would you say if I  told you that assembler offers any freedom?
> You  can  implement  your  own  run-time  type  checks  and  garbage
> collection or  any other features  that assembler lacks. Just  use a
> suitable library or write your own.

I could if assembler would have such macros as lisp has.  :-)

>> I know no other language with such  comparable capabilities.
>
> On the contrary, all languages have comparable capabilities: you can
> write an interpreter or compiler in any language.

I need no new compiler/interpreter, I want to customize a given one.

[... debatable and unrelated discourse skipped, sorry  ...]

>> May be nemerle which uses the same approch in metaprogramming.  I'm
>> not sure, but it  seems that nemerle's pattern matching implemented
>> also by macros.
>
> ML actually  stands for Meta-Language  and this family  of languages
> were  bred  for  that  purpose,  evolved  from  Lisp  and  excel  at
> metaprogramming.

"Meta-"    in   "Meta-language"   is    unrelated   to    "meta-"   in
"metaprogramming".  I have no idea what you mean.

> But  you're referring  specifically  to homogeneous  metaprogramming
> rather than metaprogramming in general.

Yes.  Metaprogramming in general is not specific to lisp.

> The problem  with homogeneous metaprogramming is that  it limits you
> to the capabilities of the host language.

It's not a problem as soon  as the host language is extensible because
of homogeneous metaprogramming.

> In the case  of Lisp, this means you're  limited by poor performance
> and unreliability (lack of static checking).

Performance and reliability  tends to be relient on  program design at
most rather language features.

> Consequently, homogeneous metaprogramming died many years ago and is
> no longer a valued language feature.

It seems likely that you give a free range to fancy.

[...]

ps.

Dear Dr Harrop, I will (at least I'll try to) not discuse further with
you on this NG.  I came to  a decision that you appears here as either
the troll or  the evangelist.  I believe it tied  to your business but
it  makes any  furhter  discussion unproductive  and uninteresting  to
me. Your messages in F# maling list are far more adequate.
From: Dmitry Statyvka
Subject: Re: When static typing is worth it
Date: 
Message-ID: <m3ir5fnapt.fsf@dstatyvka.ipnet.kiev.ua>
Jon Harrop <···@ffconsultancy.com> writes:

[...]

>>> Lisp  offers  no  such  freedom  and, instead,  puts  you  into  the
>>> straight-jacket  of   whatever  rudimentary  static   checking  your
>>> compiler  happens   to  offer  and  you  end   up  wasting  valuable
>>> development time writing and running more tests as a consequence.
>>
>> Lisp offers  any freedom  by its macros.   You can  change compilation
>> and/or correctness checking as much as  you want to.  Do you need some
>> pattern matching  or any  other feature which  CL lacks of?   Just use
>> suitable library or make your own  one.
>
> You're  advocating that  ordinary users  reimplement large  parts of
> modern languages on top of Lisp when they could just use an existing
> implementation that is already faster and more mature.

No, I'm advocating that professional programmer would implement wanted
features.  "Ordinary  users" is very  loose term.  I'm not  care about
poor programmers.

> What would you say if I  told you that assembler offers any freedom?
> You  can  implement  your  own  run-time  type  checks  and  garbage
> collection or  any other features  that assembler lacks. Just  use a
> suitable library or write your own.

I could if assembler would have such macros as lisp has.  :-)

>> I know no other language with such  comparable capabilities.
>
> On the contrary, all languages have comparable capabilities: you can
> write an interpreter or compiler in any language.

I need no new compiler/interpreter, I want to customize a given one.

[... debatable and unrelated discourse skipped, sorry  ...]

>> May be nemerle which uses the same approch in metaprogramming.  I'm
>> not sure, but it  seems that nemerle's pattern matching implemented
>> also by macros.
>
> ML actually  stands for Meta-Language  and this family  of languages
> were  bred  for  that  purpose,  evolved  from  Lisp  and  excel  at
> metaprogramming.

"Meta-"    in   "Meta-language"   is    unrelated   to    "meta-"   in
"metaprogramming".  I have no idea what you mean.

> But  you're referring  specifically  to homogeneous  metaprogramming
> rather than metaprogramming in general.

Yes.  Metaprogramming in general is not specific to lisp.

> The problem  with homogeneous metaprogramming is that  it limits you
> to the capabilities of the host language.

It's not a problem as soon  as the host language is extensible because
of homogeneous metaprogramming.

> In the case  of Lisp, this means you're  limited by poor performance
> and unreliability (lack of static checking).

Performance and reliability  tends to be relient on  program design at
most rather language features.

> Consequently, homogeneous metaprogramming died many years ago and is
> no longer a valued language feature.

It seems likely that you give a free range to fancy.

[...]

ps.

Dear Dr Harrop, I will (at least I'll try to) not discuse further with
you on this NG.  I came to  a decision that you appears here as either
the troll or  the evangelist.  I believe it tied  to your business but
it  makes any  furhter  discussion unproductive  and uninteresting  to
me. Your messages in F# maling list are far more adequate.
From: Dmitry Statyvka
Subject: Re: When static typing is worth it
Date: 
Message-ID: <m3hckznanb.fsf@dstatyvka.ipnet.kiev.ua>
Jon Harrop <···@ffconsultancy.com> writes:

[...]

>>> Lisp  offers  no  such  freedom  and, instead,  puts  you  into  the
>>> straight-jacket  of   whatever  rudimentary  static   checking  your
>>> compiler  happens   to  offer  and  you  end   up  wasting  valuable
>>> development time writing and running more tests as a consequence.
>>
>> Lisp offers  any freedom  by its macros.   You can  change compilation
>> and/or correctness checking as much as  you want to.  Do you need some
>> pattern matching  or any  other feature which  CL lacks of?   Just use
>> suitable library or make your own  one.
>
> You're  advocating that  ordinary users  reimplement large  parts of
> modern languages on top of Lisp when they could just use an existing
> implementation that is already faster and more mature.

No, I'm advocating that professional programmer would implement wanted
features.  "Ordinary  users" is very  loose term.  I'm not  care about
poor programmers.

> What would you say if I  told you that assembler offers any freedom?
> You  can  implement  your  own  run-time  type  checks  and  garbage
> collection or  any other features  that assembler lacks. Just  use a
> suitable library or write your own.

I could if assembler would have such macros as lisp has.  :-)

>> I know no other language with such  comparable capabilities.
>
> On the contrary, all languages have comparable capabilities: you can
> write an interpreter or compiler in any language.

I need no new compiler/interpreter, I want to customize a given one.

[... debatable and unrelated discourse skipped, sorry  ...]

>> May be nemerle which uses the same approch in metaprogramming.  I'm
>> not sure, but it  seems that nemerle's pattern matching implemented
>> also by macros.
>
> ML actually  stands for Meta-Language  and this family  of languages
> were  bred  for  that  purpose,  evolved  from  Lisp  and  excel  at
> metaprogramming.

"Meta-"    in   "Meta-language"   is    unrelated   to    "meta-"   in
"metaprogramming".  I have no idea what you mean.

> But  you're referring  specifically  to homogeneous  metaprogramming
> rather than metaprogramming in general.

Yes.  Metaprogramming in general is not specific to lisp.

> The problem  with homogeneous metaprogramming is that  it limits you
> to the capabilities of the host language.

It's not a problem as soon  as the host language is extensible because
of homogeneous metaprogramming.

> In the case  of Lisp, this means you're  limited by poor performance
> and unreliability (lack of static checking).

Performance and reliability  tends to be relient on  program design at
most rather language features.

> Consequently, homogeneous metaprogramming died many years ago and is
> no longer a valued language feature.

It seems likely that you give a free range to fancy.

[...]

ps.

Dear Dr Harrop, I will (at least I'll try to) not discuse further with
you on this NG.  I came to  a decision that you appears here as either
the troll or  the evangelist.  I believe it tied  to your business but
it  makes any  furhter  discussion unproductive  and uninteresting  to
me. Your messages in F# maling list are far more adequate.
From: Dmitry Statyvka
Subject: Re: When static typing is worth it
Date: 
Message-ID: <m3fy0jnami.fsf@dstatyvka.ipnet.kiev.ua>
Jon Harrop <···@ffconsultancy.com> writes:

[...]

>>> Lisp  offers  no  such  freedom  and, instead,  puts  you  into  the
>>> straight-jacket  of   whatever  rudimentary  static   checking  your
>>> compiler  happens   to  offer  and  you  end   up  wasting  valuable
>>> development time writing and running more tests as a consequence.
>>
>> Lisp offers  any freedom  by its macros.   You can  change compilation
>> and/or correctness checking as much as  you want to.  Do you need some
>> pattern matching  or any  other feature which  CL lacks of?   Just use
>> suitable library or make your own  one.
>
> You're  advocating that  ordinary users  reimplement large  parts of
> modern languages on top of Lisp when they could just use an existing
> implementation that is already faster and more mature.

No, I'm advocating that professional programmer would implement wanted
features.  "Ordinary  users" is very  loose term.  I'm not  care about
poor programmers.

> What would you say if I  told you that assembler offers any freedom?
> You  can  implement  your  own  run-time  type  checks  and  garbage
> collection or  any other features  that assembler lacks. Just  use a
> suitable library or write your own.

I could if assembler would have such macros as lisp has.  :-)

>> I know no other language with such  comparable capabilities.
>
> On the contrary, all languages have comparable capabilities: you can
> write an interpreter or compiler in any language.

I need no new compiler/interpreter, I want to customize a given one.

[...]

>> May be nemerle which uses the same approch in metaprogramming.  I'm
>> not sure, but it  seems that nemerle's pattern matching implemented
>> also by macros.
>
> ML actually  stands for Meta-Language  and this family  of languages
> were  bred  for  that  purpose,  evolved  from  Lisp  and  excel  at
> metaprogramming.

"Meta-"    in   "Meta-language"   is    unrelated   to    "meta-"   in
"metaprogramming".  I have no idea what you mean.

> But  you're referring  specifically  to homogeneous  metaprogramming
> rather than metaprogramming in general.

Yes.  Metaprogramming in general is not specific to lisp.

> The problem  with homogeneous metaprogramming is that  it limits you
> to the capabilities of the host language.

It's not a problem as soon  as the host language is extensible because
of homogeneous metaprogramming.

> In the case  of Lisp, this means you're  limited by poor performance
> and unreliability (lack of static checking).

Performance and reliability  tends to be relient on  program design at
most rather language features.

> Consequently, homogeneous metaprogramming died many years ago and is
> no longer a valued language feature.

It seems likely that you give a free range to fancy.

[...]

ps.

Dear Dr Harrop, I will (at least I'll try to) not discuse further with
you on this NG.  I came to  a decision that you appears here as either
the troll or  the evangelist.  I believe it tied  to your business but
it  makes any  furhter  discussion unproductive  and uninteresting  to
me. Your messages in F# maling list are far more adequate.
From: Dmitry Statyvka
Subject: Re: When static typing is worth it
Date: 
Message-ID: <m3d4vnnalf.fsf@dstatyvka.ipnet.kiev.ua>
Jon Harrop <···@ffconsultancy.com> writes:

[...]

>>> Lisp  offers  no  such  freedom  and, instead,  puts  you  into  the
>>> straight-jacket  of   whatever  rudimentary  static   checking  your
>>> compiler  happens   to  offer  and  you  end   up  wasting  valuable
>>> development time writing and running more tests as a consequence.
>>
>> Lisp offers  any freedom  by its macros.   You can  change compilation
>> and/or correctness checking as much as  you want to.  Do you need some
>> pattern matching  or any  other feature which  CL lacks of?   Just use
>> suitable library or make your own  one.
>
> You're  advocating that  ordinary users  reimplement large  parts of
> modern languages on top of Lisp when they could just use an existing
> implementation that is already faster and more mature.

No, I'm advocating that professional programmer would implement wanted
features.  "Ordinary  users" is very  loose term.  I'm not  care about
poor programmers.

> What would you say if I  told you that assembler offers any freedom?
> You  can  implement  your  own  run-time  type  checks  and  garbage
> collection or  any other features  that assembler lacks. Just  use a
> suitable library or write your own.

I could if assembler would have such macros as lisp has.  :-)

>> I know no other language with such  comparable capabilities.
>
> On the contrary, all languages have comparable capabilities: you can
> write an interpreter or compiler in any language.

I need no new compiler/interpreter, I want to customize a given one.

[...]

>> May be nemerle which uses the same approch in metaprogramming.  I'm
>> not sure, but it  seems that nemerle's pattern matching implemented
>> also by macros.
>
> ML actually  stands for Meta-Language  and this family  of languages
> were  bred  for  that  purpose,  evolved  from  Lisp  and  excel  at
> metaprogramming.

"Meta-"    in   "Meta-language"   is    unrelated   to    "meta-"   in
"metaprogramming".  I have no idea what you mean.

> But  you're referring  specifically  to homogeneous  metaprogramming
> rather than metaprogramming in general.

Yes.  Metaprogramming in general is not specific to lisp.

> The problem  with homogeneous metaprogramming is that  it limits you
> to the capabilities of the host language.

It's not a problem as soon  as the host language is extensible because
of homogeneous metaprogramming.

> In the case  of Lisp, this means you're  limited by poor performance
> and unreliability (lack of static checking).

Performance and reliability  tends to be relient on  program design at
most rather language features.

> Consequently, homogeneous metaprogramming died many years ago and is
> no longer a valued language feature.

It seems likely that you give a free range to fancy.

[...]

ps.

Dear Dr Harrop, I will (at least I'll try to) not discuse further with
you on this NG.  I came to  a decision that you appears here as either
the troll or  the evangelist.  I believe it tied  to your business but
it  makes any  furhter  discussion unproductive  and uninteresting  to
me. Your messages in F# maling list are far more adequate.
From: Dmitry Statyvka
Subject: Re: When static typing is worth it
Date: 
Message-ID: <m3hcky53vj.fsf@dstatyvka.ipnet.kiev.ua>
Dmitry Statyvka <·········@ipnet.kiev.ua> writes:

[...]

I'm very very sorry, it was some transport error.  Sorry.
From: Dmitry Statyvka
Subject: Re: When static typing is worth it
Date: 
Message-ID: <m3k5q322km.fsf@dstatyvka.ipnet.kiev.ua>
Jon Harrop <···@ffconsultancy.com> writes:

[...]

> Even if the examples are of no practical importance?

btw, I have  a very practical (and actual to  me) example.  What about
aspect-oriented programming?  Given an instance of unknown class, need
to modify  all of its  methods to perform  writing in log  file.  What
about pattern-matching?  :-)
From: Jon Harrop
Subject: Re: When static typing is worth it
Date: 
Message-ID: <13g8d3l9s8th6f7@corp.supernews.com>
Dmitry Statyvka wrote:
> Jon Harrop <···@ffconsultancy.com> writes:
>> Even if the examples are of no practical importance?
> 
> btw, I have  a very practical (and actual to  me) example.  What about
> aspect-oriented programming?  Given an instance of unknown class, need
> to modify  all of its  methods to perform  writing in log  file.  What
> about pattern-matching?  :-)

Your example is a solution expressed in a typeless OOP style rather than a
generic problem description. Although you can always translate such a
solution into another paradigm, the result is not typically representative
of real programs and, therefore, is often useless and misleading.

One form of literal translation in this case is to transpose the OOP
solution into a functional solution. Each member X of each class Y becomes
a match case Y in the run-time dispatch (pattern match) of a function X.
The process of logging method calls turns into a combinator. In a static
language, this combinator might be parameterized over function(s) that
extract the necessary metadata from the method arguments.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
From: Rainer Joswig
Subject: Re: When static typing is worth it
Date: 
Message-ID: <joswig-C1ABB6.21314603102007@news-europe.giganews.com>
In article <··············@dstatyvka.ipnet.kiev.ua>,
 Dmitry Statyvka <·········@gmail.com> wrote:

> Jon Harrop <···@ffconsultancy.com> writes:
> 
> [...]
> 
> >> However,  there is  yet another  level to  this debate:  It  can be
> >> beneficial to be able to evolve  a program at runtime, in the sense
> >> that you cannot only change the values that variables are bound to,
> >> but  also function  and method  definitions, class  definitions and
> >> other  entities that  make up  your  program. If  you perform  such
> >> changes   programmatically,  you   basically   have  self-modifying
> >> programs.
> >
> > From the  static point of view,  this is just  run-time dispatch and
> > consequently, is solved using pattern matching in all modern FPLs.
> 
> So could  you define  in ocaml function  that returns function  of the
> same type?  Something a la
> 
> let rec f _ = f;;
> 
> [...]

Wrong newsgroup.

-- 
http://lispm.dyndns.org
From: Jon Harrop
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <13g5d7et2sk3lde@corp.supernews.com>
are wrote:
> The other thing I want to focus on from here is the big-picture issue
> of static vs. dynamic. dynamic. Most of my programming experience is
> static and it's still not obvious to what's so great about dynamic.

This is a major matter of contention and you will not be able to get a
definitive answer. In fact, you cannot even get coherent definitions of
static and dynamic in this context. For example, the SBCL Lisp compiler
goes to great lengths to try to find type errors at compile time but isn't
that static behaviour? Conversely, the F# programming language has a very
statically typed ML heritage but it carries run-time type information
everywhere, allows you to dispatch over it and its library provides an
almost-universal type "obj" and those are all dynamic behaviours. So the
distinction between static and dynamic is not even clear.

If you only ask in this newsgroup then you will get only the pro-dynamic
half of the argument. To get the other half of the argument you must ask
people who are intimately familiar with modern static type systems, e.g.
polymorphic variants.

I personally use both static and dynamic languages but I only resort to
dynamic languages when they have better libraries. For example, I generate
graphs using Mathematica because OCaml and F# don't yet have similar
graphing capabilities or a graphical top-level. However, I do high
performance computing and not web or telecoms programming.

I have spent several years trying to work out if and when a dynamic language
might be preferable. I think you can make the most headway by learning how
to leverage a good static type system and then studying under what
circumstances it provides little to no benefit.

Static typing is of little use when your programs are tiny or trivial. For
example, if you are reading a CSV file and translating a certain column
from one date format to another then you only have two types (string and
string sequence) and there is nothing for a static type system to work
with. In any language, the code will look something like:

  map (apply n convert) sequence

Static typing is not advantageous here but it is also not a direct
hindrance.

However, people can and do build complex systems from large numbers of tiny
or trivial independent components. This approach is commonly seen in
telecoms and web programming. So static typing might be of little benefit
in such applications and, indeed, dynamic languages (e.g. JavaScript,
Erlang) have their largest market shares here.

There is also a difference in the activation barrier of learning. Dynamic
languages are trivial to learn: they simply lack a static type system.
Rather than learning the language, you spend your time learning how to
write unit tests and how to trawl through run-time traces after run-time
errors.

Modern static languages are harder to learn because they reject your
incorrect code and you must first learn to understand how the error
messages correlate with the mistakes in your code. However, you don't have
to waste your time with test driven development and debuggers. Later, you
can also learn how to make more effective use of the static type system by
changing your style of coding. This challenge is vastly more difficult if
you have previously limited yourself to dynamic languages.

Incidentally, I did a podcast with .NET Rocks! about F#:

  http://www.dotnetrocks.com/default.aspx?showNum=266

and their most recent podcast discusses dynamic languages and the DLR:

  http://www.dotnetrocks.com/default.aspx?showNum=277

I think it will be very interesting to watch F# and IronPython compete next
year. I predict that F# will be adopted very rapidly by technical users and
IronPython (and other DLR languages) will be adopted very quickly by
non-technical users. In particular, this will drastically reduce the need
for C# and VB and will change the face of .NET.

From an industrial perspective, dynamic programming languages also have the
advantage that developers are in abundance, very cheap and unencumbered by
college education.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
From: Kent M Pitman
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <uvea54025.fsf@nhplace.com>
[ comp.lang.lisp only; http://www.nhplace.com/kent/PFAQ/cross-posting.html ]

are <·········@gmx.net> writes:

> On Sep 19, 6:52 pm, Raffael Cavallaro <················@pas-d'espam-
> s'il-vous-plait-mac.com> wrote:
> > On 2007-09-19 19:18:24 -0400, are <·········@gmx.net> said:
> >
> > > Wanting something
> > > that's fast and high-level, I've zeroed in on Lisp and OCaml.
> > > Superficially, these two seem very different from one another, yet
> > > I've noticed that there a some who post to both of these groups.
> > > Would anyone who knows both languages well (let's not start a flame
> > > war, please!) care to comment on the similarities and differences
> > > between them?
> >
> > Wanting something that's fast and high-level,
> > I've zeroed in on Lisp and Scheme.
> > Superficially, these two seem very different
> > from one another, yet I've noticed
> > that there are some who post to both of these groups.
> > Would anyone who knows both languages well (let's not start a
> > flame war, please!) care to comment on the similarities
> > and differences between them? ;^)
> >
> > ------------------------------------------
> >
> > Anyone else here on c.l.l think that 'are' should choose
> > OCaml, decamp to c.l.functional, and take frog-boy with him?
> 
> Yeah, well, I admit it was optimistic of me to hope that a flame war
> might be avoided regardless of how genuine my interest in the question
> posed was.

Although Raffael's tone may have been a bit flippant, I do think that
if you peel past the personal-sounding bits, there's a serious
suggestion hiding in there that's worth looking at.

Sometimes when faced with a decision like this, the flamewar you
anticipate is caused not by someone failing to taking someone
seriously, but by taking them seriously.

The problem is that we are still recovering in this group from an
extensive discussion of this very issue, and all you have to do is
peel back a couple of months to see it.  It was long and painful,
and the ratio of signal to noise was not nearly as high as many would
like, but it's all archived for your convenience.  

We don't necessarily have to relive it.  It wasn't pleasant and it 
sapped energy from more pleasant discussions we'd like to be having.

Moreover, people often think it's a diss to say "go elsewhere" but not
every language is for every person, and it's quite common for people
to be properly placed in a language other than Lisp.  We are not
threatened by people going elsewhere, and you ought not take that as a
negative.  Languages serve user communities and those user communities
each have biases.  (See my http://www.nhplace.com/kent/PS/Lambda.html
for an elaboration of this theme.)  There are two reasons to shop for
a language: (a) because you need a specific feature [in which case you
know what that feature is in advance and should just ask] or (b)
because you want something that just lets you write stuff the way you
want to say it.  In the latter case, I think you want to look at some
programs and decide what feels good.

Feature set comparisons are easily divisive, depending on how they are
worded, and it's easy to see how you might think someone trying to keep
you from having an open discussion about comparative feature sets might
be trying to do you an injustice, but it can be just the opposite.

Pick one or both languages and just write some code.  It's good to
know a lot of languages anyway.  So don't make people choose for
you--if you have it narrowed to two, just learn both.  Then see where
you get.  

And preferrably, don't assume the programs will have the same
shape. Try to avoid questions that ask about what the "word for x" is
in the other language, as if the only difference between languages was
what word you use to say the exact identical thing.  Languages vary in
subtle and important ways that change the way you write programs in
them even to accomplish a task.  Focus on accomplishing a goal, not on
syntax.  If you're at the point of wanting pedantically a particular
syntax, you should just ask which language has it and when they raise
their hand, you should dive for it because now you're back in category
(a) of my choices above.

Questions on this forum (and probably on any other, too) are better
treated when they're asked by someone who genuinely seems to want to
worry about just getting something done in the language, rather than
just having us justify the fact that we happen to prefer this language
to others.  (Adding cross-posting is a devastatingly bad thing to do
in this regard.  See the URL at top of this post for a detailed
explanation, and why the fact that "union" does not equal
"intersection" matters.)  Forums have titles in order to attract
people who like to talk about those things.  The preference for Lisp
by people who post here is not, a priori, a rejection of other
options.  But when we want to talk about those languages, we go to
their forums mostly.  It's just been a sore spot that for the
particular language you mention, a major proponent of that language
has overrun us with comparisons whether we wanted it or not.  So that
brings me back to my original point, and I'll stop there.
From: Pillsy
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <1190333894.279324.301890@d55g2000hsg.googlegroups.com>
On Sep 20, 10:58 am, are <·········@gmx.net> wrote:
[...]
> Yeah, well, I admit it was optimistic of me to hope that a flame war
> might be avoided regardless of how genuine my interest in the question
> posed was.

Asking proponents of Language X about why Language X is better than
Language Y is a wonderfully reliable way to start a flamewar. Indeed,
it's so efficient it will work nine times out of ten even if your
intent is not to start a flamewar. In any event, even if it weren't
inherently flamebaity, it's still unlikely to generate much useful
information.

People who hang around in a Common Lisp newsgroup do so because they
have some sort of investment in Common Lisp. They may love it, they
may hate it but have to deal with it, or they may just be trying to
learn it, but one way or another, they're united by their involvement
with Common Lisp.

They aren't really likely to have any sort of investment or extensive
experience with OCaml. You're better off asking about it here than in
a forum devoted to contract bridge or something, but that's not saying
much.

If you describe your problem domain and your tastes a little better,
you'll probably get some good information about whether Common Lisp is
right for you. You can ask the analogous question in the OCaml group
and probably get useful information from them. Then you'll have to
make the final decision which language is best for your purposes---but
then, you were going to have to do that anyway.

Cheers,
Pillsy
From: Damien Kick
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <13flhv3skcjqb07@corp.supernews.com>
are wrote:

> Yeah, well, I admit it was optimistic of me to hope that a flame war
> might be avoided regardless of how genuine my interest in the question
> posed was.

I know.  Not long ago, I posted a genuine question to an Israeli and a 
Palestinian newsgroup asking for an honest comparison of Judaism and 
Islam, because I genuinely wanted to know which was the better religion, 
and you would've thought that I just walked into an airport with 
explosives strapped to my chest.  I mean, really.  How was I supposed to 
know that this was a touchy subject?
From: George Neuner
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <aaslf31td22ldb1s924quhjkgost3u9b6m@4ax.com>
On Wed, 26 Sep 2007 14:43:23 -0500, Damien Kick <·····@earthlink.net>
wrote:

>Not long ago, I posted a genuine question to an Israeli and a 
>Palestinian newsgroup asking for an honest comparison of Judaism and 
>Islam, because I genuinely wanted to know which was the better religion, 
>and you would've thought that I just walked into an airport with 
>explosives strapped to my chest.  I mean, really.  How was I supposed to 
>know that this was a touchy subject?

More proof that you're stupid.  

All religions are equally bad.  God[*] didn't create any religion,
they were all created by humans attempting to control the behavior of
other humans.  There is no "right" or "wrong" belief ... what you
believe is just as valid as what anyone else believes.

[*] The term "God", as it is used here, is not intended to refer to
the preferred deity of any particular religion, but refers to the
collective belief in a knowledge and/or power greater than human.

George
--
for email reply remove "/" from address
From: Damien Kick
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <13fm28p2uekhr61@corp.supernews.com>
George Neuner wrote:
> On Wed, 26 Sep 2007 14:43:23 -0500, Damien Kick <·····@earthlink.net>
> wrote:
> 
>>                               I mean, really.  How was I supposed to 
>> know that this was a touchy subject?
> 
> More proof that you're stupid.
> 
> All religions are equally bad.  [...]

You should look up the word sarcasm in that big dictionary of yours.
From: Damien Kick
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <13fm2tgl02klof2@corp.supernews.com>
George Neuner wrote:
> On Wed, 26 Sep 2007 14:43:23 -0500, Damien Kick <·····@earthlink.net>
> wrote:
>  
>>                                                    How was I supposed to 
>> know that this was a touchy subject?
> 
> More proof that you're stupid.  
> 
> All religions are equally bad.  [...]

Man, even the Discommodiously Defenestrated Toad, later in this thread, 
could tell that I was being sarcastic.

DDT escreveu:

> I'm surprised to see anyone making a mountain out of this mole hill. In the
> big picture, OCaml and Lisp are both functional languages and most people
> can learn a lot by comparing and contrasting them, which is all the OP was
> asking us to do. 

He still doesn't understand netiquette [1], but at least he didn't start 
lecturing us on theology.

[1] Actually, I'm sure he understands it.  He's just free to ignore it 
and he does.
From: Jon Harrop
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <13flsvnrvavnqb5@corp.supernews.com>
Damien Kick wrote:
> are wrote:
>> Yeah, well, I admit it was optimistic of me to hope that a flame war
>> might be avoided regardless of how genuine my interest in the question
>> posed was.
> 
> I know.  Not long ago, I posted a genuine question to an Israeli and a
> Palestinian newsgroup asking for an honest comparison of Judaism and
> Islam, because I genuinely wanted to know which was the better religion,
> and you would've thought that I just walked into an airport with
> explosives strapped to my chest.  I mean, really.  How was I supposed to
> know that this was a touchy subject?

I'm surprised to see anyone making a mountain out of this mole hill. In the
big picture, OCaml and Lisp are both functional languages and most people
can learn a lot by comparing and contrasting them, which is all the OP was
asking us to do.

Perhaps a lesson that we can all take away from this is that community
friendliness can be very important when learning a language and this is
unquestionably the weakest point of Lisp. If anyone still has faith in Lisp
it might be worthwhile trying to write honest and impartial responses to
other people's questions here in future.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
OCaml for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/?usenet
From: Cesar Rabak
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <fdf0fa$3he$1@aioe.org>
Jon Harrop escreveu:
> Damien Kick wrote:
>> are wrote:
>>> Yeah, well, I admit it was optimistic of me to hope that a flame war
>>> might be avoided regardless of how genuine my interest in the question
>>> posed was.
>> I know.  Not long ago, I posted a genuine question to an Israeli and a
>> Palestinian newsgroup asking for an honest comparison of Judaism and
>> Islam, because I genuinely wanted to know which was the better religion,
>> and you would've thought that I just walked into an airport with
>> explosives strapped to my chest.  I mean, really.  How was I supposed to
>> know that this was a touchy subject?
> 
> I'm surprised to see anyone making a mountain out of this mole hill. In the
> big picture, OCaml and Lisp are both functional languages and most people
> can learn a lot by comparing and contrasting them, which is all the OP was
> asking us to do.
> 

Er... no. Lisp is a multi paradigm language, which allows you to use 
functional programming.

> Perhaps a lesson that we can all take away from this is that community
> friendliness can be very important when learning a language and this is
> unquestionably the weakest point of Lisp. If anyone still has faith in Lisp
> it might be worthwhile trying to write honest and impartial responses to
> other people's questions here in future.
> 
There is no lesson to take from nothing. Lest about friendliness or lack of.

If you have faith in the language you promote you could start being 
honest in the postings of yours in this NG.
From: Jon Harrop
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <13fn904o56qvs21@corp.supernews.com>
Cesar Rabak wrote:
> Jon Harrop escreveu:
>> Damien Kick wrote:
>>> are wrote:
>>>> Yeah, well, I admit it was optimistic of me to hope that a flame war
>>>> might be avoided regardless of how genuine my interest in the question
>>>> posed was.
>>> I know.  Not long ago, I posted a genuine question to an Israeli and a
>>> Palestinian newsgroup asking for an honest comparison of Judaism and
>>> Islam, because I genuinely wanted to know which was the better religion,
>>> and you would've thought that I just walked into an airport with
>>> explosives strapped to my chest.  I mean, really.  How was I supposed to
>>> know that this was a touchy subject?
>> 
>> I'm surprised to see anyone making a mountain out of this mole hill. In
>> the big picture, OCaml and Lisp are both functional languages and most
>> people can learn a lot by comparing and contrasting them, which is all
>> the OP was asking us to do.
> 
> Er... no. Lisp is a multi paradigm language, which allows you to use
> functional programming.

There is no difference in this respect.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
From: namekuseijin
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <1191763466.539943.312690@w3g2000hsg.googlegroups.com>
On Sep 26, 10:22 pm, Cesar Rabak <·······@yahoo.com.br> wrote:
> Er... no. Lisp is a multi paradigm language, which allows you to use
> functional programming.

what is that supposed to mean anyway?  Have you noticed "multi-
paradigm" is the new buzzword of the day?  Lisp is multi-paradigm?  So
is OCaml.  So is Java.  So is, gasp!, C!

"multi-paradigm" just means "it's able to deal with all the wacky
trends in computer science of the last XX years, old ones and new
too".  And all Turing-complete languages are able to do that...
From: Cesar Rabak
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <feb41o$t45$1@aioe.org>
namekuseijin escreveu:
> On Sep 26, 10:22 pm, Cesar Rabak <·······@yahoo.com.br> wrote:
>> Er... no. Lisp is a multi paradigm language, which allows you to use
>> functional programming.
> 
> what is that supposed to mean anyway?  Have you noticed "multi-
> paradigm" is the new buzzword of the day?  Lisp is multi-paradigm?  So
> is OCaml.  So is Java.  So is, gasp!, C!
> 
> "multi-paradigm" just means "it's able to deal with all the wacky
> trends in computer science of the last XX years, old ones and new
> too".  And all Turing-complete languages are able to do that...
> 
Where in OCalm is OO, MOP, and macros?

Talking about being a 'modern' language, where is research in 
application of OCalm for Aspect Oriented Programming?
From: Ken Tilton
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <rF8Oi.27$gM.20@newsfe12.lga>
Cesar Rabak wrote:
> namekuseijin escreveu:
> 
>> On Sep 26, 10:22 pm, Cesar Rabak <·······@yahoo.com.br> wrote:
>>
>>> Er... no. Lisp is a multi paradigm language, which allows you to use
>>> functional programming.
>>
>>
>> what is that supposed to mean anyway?  Have you noticed "multi-
>> paradigm" is the new buzzword of the day?  Lisp is multi-paradigm?  So
>> is OCaml.  So is Java.  So is, gasp!, C!
>>
>> "multi-paradigm" just means "it's able to deal with all the wacky
>> trends in computer science of the last XX years, old ones and new
>> too".  And all Turing-complete languages are able to do that...
>>
> Where in OCalm is OO, MOP, and macros?

Hunh? O'Clam does not those? The lack of macros would explain all the 
redundancy I saw in Jon's claimed code triumph.

Anyway, never mind all that, where is The Road to *ML Survey? Not here:

    http://wiki.alu.org/RtL_Highlight_Film

Given the vastly greater popularity of those languages, all DrJon needs 
do is cut and past my questions and spam c.l.functional for a few days 
seeking respondents. I realize the good doctor is not comfortable with 
spamming, but...hang on. No, I think we're good.

kenny

-- 
http://www.theoryyalgebra.com/

"We are what we pretend to be." -Kurt Vonnegut
From: Jon Harrop
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <13gib24hregvt62@corp.supernews.com>
Cesar Rabak wrote:
> Where in OCalm is OO...

  http://caml.inria.fr/pub/docs/manual-ocaml/manual005.html

> macros...

  http://caml.inria.fr/pub/docs/manual-camlp4/index.html

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
From: Klaus Schilling
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <87wstwby78.fsf@web.de>
Jon Harrop <···@ffconsultancy.com> writes:

> Cesar Rabak wrote:
>
>> macros...
>
>   http://caml.inria.fr/pub/docs/manual-camlp4/index.html

camlp4 is no more Ocaml than pattern matching packages are common lisp.
even worse, p4 sticks out of Ocaml like a sore thumb,
as do analogous extensions to Lua, Python, and similar ilk,
whereas pattern-matching packages integrate 
smoothly into the Lisp syntax.

         Klaus Schilling
From: namekuseijin
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <1191833135.773621.10450@v3g2000hsg.googlegroups.com>
On Oct 7, 2:15 pm, Cesar Rabak <·······@yahoo.com.br> wrote:
> Where in OCalm is OO, MOP, and macros?

what do you think the O means in this otherwise ML language?  and
AFAIK, it comes with a macro preprocessor, much more in the Lisp lines
than C...
From: Rainer Joswig
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <joswig-F39ADB.11402708102007@news-europe.giganews.com>
In article <·······················@v3g2000hsg.googlegroups.com>,
 namekuseijin <············@gmail.com> wrote:

> On Oct 7, 2:15 pm, Cesar Rabak <·······@yahoo.com.br> wrote:
> > Where in OCalm is OO, MOP, and macros?
> 
> what do you think the O means in this otherwise ML language?  and
> AFAIK, it comes with a macro preprocessor, much more in the Lisp lines
> than C...

Lisp macros are not provided by a preprocessor.

-- 
http://lispm.dyndns.org
From: Jon Harrop
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <13gkesei0l3n610@corp.supernews.com>
Rainer Joswig wrote:
> In article <·······················@v3g2000hsg.googlegroups.com>,
>  namekuseijin <············@gmail.com> wrote:
>> On Oct 7, 2:15 pm, Cesar Rabak <·······@yahoo.com.br> wrote:
>> > Where in OCalm is OO, MOP, and macros?
>> 
>> what do you think the O means in this otherwise ML language?  and
>> AFAIK, it comes with a macro preprocessor, much more in the Lisp lines
>> than C...
> 
> Lisp macros are not provided by a preprocessor.

Meaningless.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
From: Rainer Joswig
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <joswig-322027.17534908102007@news-europe.giganews.com>
In article <···············@corp.supernews.com>,
 Jon Harrop <···@ffconsultancy.com> wrote:

> Rainer Joswig wrote:
> > In article <·······················@v3g2000hsg.googlegroups.com>,
> >  namekuseijin <············@gmail.com> wrote:
> >> On Oct 7, 2:15 pm, Cesar Rabak <·······@yahoo.com.br> wrote:
> >> > Where in OCalm is OO, MOP, and macros?
> >> 
> >> what do you think the O means in this otherwise ML language?  and
> >> AFAIK, it comes with a macro preprocessor, much more in the Lisp lines
> >> than C...
> > 
> > Lisp macros are not provided by a preprocessor.
> 
> Meaningless.

No, in Lisp the Macros are normal Lisp functions and you
can run it everywhere. There is no separate proprocessor
needed. It is all nicely integrated.

-- 
http://lispm.dyndns.org
From: Jon Harrop
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <13glq0ngtpn9t9a@corp.supernews.com>
Rainer Joswig wrote:
> No, in Lisp the Macros are normal Lisp functions and you
> can run it everywhere. There is no separate proprocessor
> needed. It is all nicely integrated.

Same as OCaml, except that OCaml also provides a batch preprocessor for
compiled files.

We've covered this before. I even gave examples. There is no difference
between the languages in this respect.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
From: Rainer Joswig
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <joswig-A84D95.07412109102007@news-europe.giganews.com>
In article <···············@corp.supernews.com>,
 Jon Harrop <···@ffconsultancy.com> wrote:

> Rainer Joswig wrote:
> > No, in Lisp the Macros are normal Lisp functions and you
> > can run it everywhere. There is no separate proprocessor
> > needed. It is all nicely integrated.
> 
> Same as OCaml, except that OCaml also provides a batch preprocessor for
> compiled files.
> 
> We've covered this before. I even gave examples. There is no difference
> between the languages in this respect.

You can check out the source of any Common Lisp implementation.
You will find macros everywhere. Since they are integrated
in the language and no preprocessor is needed.

Check out the source of OCaml. Not a single use of the
preprocessor (other than in parts of the preprocessor itself).

Go figure.
From: Jon Harrop
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <13gmetghlff88bf@corp.supernews.com>
Rainer Joswig wrote:
> You can check out the source of any Common Lisp implementation.
> You will find macros everywhere. Since they are integrated
> in the language and no preprocessor is needed.
> 
> Check out the source of OCaml. Not a single use of the
> preprocessor (other than in parts of the preprocessor itself).

Macros are used primarily to address deficits in Lisp that don't appear in
OCaml? That was easy...

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
From: Sacha
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <kEIOi.147100$ZT7.8292444@phobos.telenet-ops.be>
Jon Harrop wrote:
> Rainer Joswig wrote:
>> Check out the source of OCaml. Not a single use of the
>> preprocessor (other than in parts of the preprocessor itself).
> 
> Macros are used primarily to address deficits in Lisp that don't appear in
> OCaml? That was easy...
> 

:)

What's next ? are you going to kick him in the nuts ?

Let's build a ring, and let the strongest prevail !

Kent Pitman will act as the referee ensuring the rules are respected 
(nuts kicking is non-conforming), and I believe Kenny has a thing with 
arithmetics, he'll be counting the points using a fancy cells/opengl 
powered program.

Because of the lack of documentation, you should be able to invoke a 
type error if you loose the fight.

Sacha
From: Tim Bradshaw
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <1191938712.324060.177330@22g2000hsm.googlegroups.com>
On Oct 9, 11:23 am, Sacha <····@address.spam> wrote:

>
> What's next ? are you going to kick him in the nuts ?

Here in cll we have only two standard penalties: melting down for
glue, and impaling heads on stakes.  the second is preferred as it is
more ecologically sound (all that heat and, frankly, you only need so
much glue).  We usually get the offender to do the sawing themselves.
From: Leandro Rios
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <470b9e1d$0$1340$834e42db@reader.greatnowhere.com>
Sacha escribi�:
> What's next ? are you going to kick him in the nuts ?
> 
> Let's build a ring, and let the strongest prevail !
> 

I don't think this is a good idea. We are civilised people who try to 
reach common agreement through amenable conversation and respect ot each 
other, even when our opinions could strongly differ. No sir, this is no 
good idea at all.

But in case you decide to build it anymay, please make it big enough to 
hold at least 50 people. I don't know how you will stop many of us 
jumping to it in order to give Rainer a hand :)

Leandro
From: Tim Bradshaw
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <1192025187.896747.244060@22g2000hsm.googlegroups.com>
On Oct 9, 4:28 pm, Leandro Rios <··················@gmail.com> wrote:
> We are civilised people

We are not.  Some of us are not even people.
From: Rainer Joswig
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <joswig-111D13.18430209102007@news-europe.giganews.com>
In article <···············@corp.supernews.com>,
 Jon Harrop <···@ffconsultancy.com> wrote:

> Rainer Joswig wrote:
> > You can check out the source of any Common Lisp implementation.
> > You will find macros everywhere. Since they are integrated
> > in the language and no preprocessor is needed.
> > 
> > Check out the source of OCaml. Not a single use of the
> > preprocessor (other than in parts of the preprocessor itself).
> 
> Macros are used primarily to address deficits in Lisp that don't appear in
> OCaml? That was easy...

Shows that you have no idea what macros do in Lisp.

-- 
http://lispm.dyndns.org
From: namekuseijin
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <1191858943.312303.89600@y42g2000hsy.googlegroups.com>
On 8 out, 06:40, Rainer Joswig <······@lisp.de> wrote:
> Lisp macros are not provided by a preprocessor.

you mean the preprocessor is integrated to the language... sure Lisp
macros are preprocessed/expanded before the code they contain is
executed...
From: Harald Hanche-Olsen
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <pcoodfbf3kj.fsf@shuttle.math.ntnu.no>
+ namekuseijin <············@gmail.com>:

> "multi-paradigm" just means "it's able to deal with all the wacky
> trends in computer science of the last XX years, old ones and new
> too".  And all Turing-complete languages are able to do that...

This is just a silly word game.  Being "able to" is not at all what is
meant by a term such as multi-paradigm.  That, as you have observed,
just reduces the term to meaning Turing completeness, for which we
already have a perfectly good phrase.  No, the only sensible way to
understand "multi-paradigm" is that the language must make it /easy/
and /natural/ to write in several different styles, or paradigms if
you wish.  Here we are entering the realm of subjective opinion of
course, since there is no universal agreement of what is easy or
natural.  But in my opinion, a universal Turing machine is very much
uni-paradigm.  (Its main utility being to serve as proof that such
critters exist.)  And Lisp is certainly way /more/ multi-paradigm than
C is.  But it's all clearly a question of degrees.

-- 
* Harald Hanche-Olsen     <URL:http://www.math.ntnu.no/~hanche/>
- It is undesirable to believe a proposition
  when there is no ground whatsoever for supposing it is true.
  -- Bertrand Russell
From: Pascal Costanza
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <5ms6j7Ff2c9gU1@mid.individual.net>
namekuseijin wrote:
> On Sep 26, 10:22 pm, Cesar Rabak <·······@yahoo.com.br> wrote:
>> Er... no. Lisp is a multi paradigm language, which allows you to use
>> functional programming.
> 
> what is that supposed to mean anyway?  Have you noticed "multi-
> paradigm" is the new buzzword of the day?  Lisp is multi-paradigm?  So
> is OCaml.  So is Java.  So is, gasp!, C!

http://www.lisp.org/table/objects.htm


Pascal

-- 
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
From: Ken Tilton
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <fEGKi.747$fT2.178@newsfe12.lga>
Jon Harrop wrote:
> Damien Kick wrote:
> 
>>are wrote:
>>
>>>Yeah, well, I admit it was optimistic of me to hope that a flame war
>>>might be avoided regardless of how genuine my interest in the question
>>>posed was.
>>
>>I know.  Not long ago, I posted a genuine question to an Israeli and a
>>Palestinian newsgroup asking for an honest comparison of Judaism and
>>Islam, because I genuinely wanted to know which was the better religion,
>>and you would've thought that I just walked into an airport with
>>explosives strapped to my chest.  I mean, really.  How was I supposed to
>>know that this was a touchy subject?

Reminds me of my speech on the positive side of the KKK to the Million 
Man March down in DC a few years back. Talk about intolerance!

> Perhaps a lesson that we can all take away from this is that community
> friendliness can be very important when learning a language and this is
> unquestionably the weakest point of Lisp. If anyone still has faith in Lisp
> it might be worthwhile trying to write honest and impartial responses to
> other people's questions here in future.
> 

Then can I kill them?

kenny

ps. Being lectured by Dr. Jon "Sorry for the sewage I am dumping in your 
NG but my Web site needs hits" Harrop on social skills is easily the 
high point of my day. k

-- 
http://www.theoryyalgebra.com/

"We are what we pretend to be." -Kurt Vonnegut
From: are
Subject: Re: Flamebait if I ever saw it
Date: 
Message-ID: <1191098339.134921.240240@22g2000hsm.googlegroups.com>
On 26 Sep, 20:43, Damien Kick <·····@earthlink.net> wrote:
> are wrote:
> > Yeah, well, I admit it was optimistic of me to hope that a flame war
> > might be avoided regardless of how genuine my interest in the question
> > posed was.
>
> I know.  Not long ago, I posted a genuine question to an Israeli and a
> Palestinian newsgroup asking for an honest comparison of Judaism and
> Islam, because I genuinely wanted to know which was the better religion,
> and you would've thought that I just walked into an airport with
> explosives strapped to my chest.  I mean, really.  How was I supposed to
> know that this was a touchy subject?

In the OP I did not ask which was better, I asked for a comparison of
the two.  I fully expect that Lisp is better for some things and OCaml
for others.

In addition, I would ask a small degree of forgiveness for failing to
anticipate that people would take programming languages as seriously
as religions :-).  A schoolboy error, to be sure, which I shall not
make again.
From: Jon Harrop
Subject: Re: Lisp and OCaml
Date: 
Message-ID: <13f3f00svu0r8e5@corp.supernews.com>
You've cross posted to fa.caml which is just a mirror of the caml-list so
nobody will see your post there. You should post directly to the OCaml
mailing list (or beginners list on Yahoo groups).

are wrote:
> Getting back to doing some programming after a long absence, I've been
> reviewing the available languages to see which would be most suitable
> for some numerically intensive simulation work.  Wanting something
> that's fast and high-level, I've zeroed in on Lisp and OCaml.
> Superficially, these two seem very different from one another, yet
> I've noticed that there a some who post to both of these groups.
> Would anyone who knows both languages well (let's not start a flame
> war, please!) care to comment on the similarities and differences
> between them?

The similarities are that both Lisp and OCaml are multiparadigm languages
that allow functional programming. However, the programming styles used in
the two languages are substantially different. Specifically, OCaml is a
modern functional programming language that integrates high-performance
pattern matching and a sophisticated static type system. In contrast, Lisp
is dynamically typed and typically makes much heavier use of macros and
unit testing.

If you are using Linux or Mac OS X then I would recommend OCaml for
simulation work. If you are using Windows then I would recommend F#. Our
company website has a wealth of information, both free and commercial,
about these languages:

http://www.ffconsultancy.com/products/ocaml_for_scientists/
http://www.ffconsultancy.com/products/ocaml_journal/
http://www.ffconsultancy.com/ocaml/benefits/
http://www.ffconsultancy.com/ocaml/

http://www.ffconsultancy.com/products/fsharp_journal/
http://www.ffconsultancy.com/dotnet/fsharp/

The only area where Lisp might outperform OCaml for numerically intensive
work is the when self-contained partial specialization using EVAL may be of
benefit. However, such situations are rare and you can easily write OCaml
programs that generate other programs (see FFTW, for example). Lisp is
typically 1-2x slower than OCaml:

http://www.ffconsultancy.com/languages/ray_tracer/

You may also like to look at Scheme.

Disclaimer: I am much more familiar with C++, OCaml and F# than any other
languages including Lisp. However, this was a conscious decision made
because my area of expertise is scientific computing. We continue to
diversify and the next most interesting languages for me are Scala and
Haskell.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
OCaml for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/?usenet
From: Griff
Subject: Re: Lisp and OCaml
Date: 
Message-ID: <1190254508.429353.302500@d55g2000hsg.googlegroups.com>
On Sep 19, 7:06 pm, Jon Harrop <····@ffconsultancy.com> wrote:
> If you are using Windows then I would recommend F#.

Is it better to learn F# directly through F# literature or through
OCaml?

http://research.microsoft.com/fsharp/books.aspx
From: Ken Tilton
Subject: Re: Lisp and OCaml
Date: 
Message-ID: <8ClIi.430$GW.140@newsfe12.lga>
Griff wrote:
> On Sep 19, 7:06 pm, Jon Harrop <····@ffconsultancy.com> wrote:
> 
>>If you are using Windows then I would recommend F#.
> 
> 
> Is it better to learn F# directly through F# literature or through
> OCaml?

Through a hole in your head, and the higher the caliber the bigger the 
hole and the shorter the learning curve. Hollow-point bullets really 
grease the skids.

hth, kenny (massively enjoying Jon's elaborate staging of this outburst 
of enthusiasm for Ocaml)

-- 
http://www.theoryyalgebra.com/

"We are what we pretend to be." -Kurt Vonnegut
From: David Young
Subject: Re: Lisp and OCaml
Date: 
Message-ID: <1190294173.939519.233650@57g2000hsv.googlegroups.com>
Thanks Ken. You gave me a good laugh this morning.

-- david
From: Ken Tilton
Subject: Re: Lisp and OCaml
Date: 
Message-ID: <TZuIi.6$wz2.0@newsfe12.lga>
David!

Good to hear from you. Isn't Harrop a pisser? I would say f#%ker, but I 
don't want to push him any gigher.

kt

-- 
http://www.theoryyalgebra.com/

"We are what we pretend to be." -Kurt Vonnegut
From: David Young
Subject: Re: Lisp and OCaml
Date: 
Message-ID: <1190296828.868623.98100@57g2000hsv.googlegroups.com>
Yeah, he's something else isn't he? I think his value-add for this
group is the humorous responses he draws. Most entertaining.

-- david
From: George Neuner
Subject: Re: Lisp and OCaml
Date: 
Message-ID: <5uf5f391pq2jin5gpuhfqk1dacl2sm6tt1@4ax.com>
On Wed, 19 Sep 2007 23:14:05 -0400, Ken Tilton
<···········@optonline.net> wrote:

>Griff wrote:
>> 
>> Is it better to learn F# directly through F# literature or through
>> OCaml?
>
>Through a hole in your head, and the higher the caliber the bigger the 
>hole and the shorter the learning curve. Hollow-point bullets really 
>grease the skids.

Hollow points just frag against the skull ... unless they're filled
with nitroglycerin.  Best to use metal jacketed.

George
--
for email reply remove "/" from address
From: Ken Tilton
Subject: Re: Lisp and OCaml
Date: 
Message-ID: <BJAIi.485$GW.225@newsfe12.lga>
George Neuner wrote:
> On Wed, 19 Sep 2007 23:14:05 -0400, Ken Tilton
> <···········@optonline.net> wrote:
> 
> 
>>Griff wrote:
>>
>>>Is it better to learn F# directly through F# literature or through
>>>OCaml?
>>
>>Through a hole in your head, and the higher the caliber the bigger the 
>>hole and the shorter the learning curve. Hollow-point bullets really 
>>grease the skids.
> 
> 
> Hollow points just frag against the skull ... unless they're filled
> with nitroglycerin.  Best to use metal jacketed.

Thx, will do! This NG rocks!!!

kenny

-- 
http://www.theoryyalgebra.com/

"We are what we pretend to be." -Kurt Vonnegut
From: Jon Harrop
Subject: Re: Lisp and OCaml
Date: 
Message-ID: <13f3mmr2uin4g23@corp.supernews.com>
Griff wrote:
> On Sep 19, 7:06 pm, Jon Harrop <····@ffconsultancy.com> wrote:
>> If you are using Windows then I would recommend F#.
> 
> Is it better to learn F# directly through F# literature or through
> OCaml?
> 
> http://research.microsoft.com/fsharp/books.aspx

Although F# shares a common subset and many design choices with OCaml, it is
a significantly different language. I think there are now enough
F#-specific resources that you should be able to learn the language without
having to resort to literature on OCaml. Having said that, there are some
excellent generic-ML resources like Okasaki's excellent book on purely
functional data structures in ML.

There are many facets to any language and Robert Pickering's Foundations of
F# book is a solid introduction to this language. The F#.NET Journal
contains lots of other material as well as tutorial videos and downloadable
source code projects.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
OCaml for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/?usenet
From: are
Subject: Re: Lisp and OCaml
Date: 
Message-ID: <1190301039.687009.288100@r29g2000hsg.googlegroups.com>
On Sep 19, 7:06 pm, Jon Harrop <····@ffconsultancy.com> wrote:
> You've cross posted to fa.caml which is just a mirror of the caml-list so
> nobody will see your post there. You should post directly to the OCaml
> mailing list (or beginners list on Yahoo groups).

Thanks.

> The similarities are that both Lisp and OCaml are multiparadigm languages
> that allow functional programming. However, the programming styles used in
> the two languages are substantially different. Specifically, OCaml is a
> modern functional programming language that integrates high-performance
> pattern matching and a sophisticated static type system. In contrast, Lisp
> is dynamically typed and typically makes much heavier use of macros and
> unit testing.
>
> If you are using Linux or Mac OS X then I would recommend OCaml for
> simulation work. If you are using Windows then I would recommend F#.

Using Linux.

> Lisp is typically 1-2x slower than OCaml:

For my purposes, factors of 2 or so in execution speed are not
important, although factors of 10 are.

> You may also like to look at Scheme.

I have looked at Scheme and really liked it.  I wish I had been
introduced to programming via Scheme.  But for my purposes, I find
there are two major drawbacks:

  1.  The formally defined language lacks some things I'd really like
to have, like OO.  Of course you can roll your own, but that's not
where I want to be spending my time.  Or you can use a proprietary
extension, like that in MzScheme, but I don't want to be locked into a
single supplier.

  2.  From what I've seen Scheme is too slow, even if I'm not worried
about factors of two in execution time.
From: Jon Harrop
Subject: Re: Lisp and OCaml
Date: 
Message-ID: <13f55sq3f8fune9@corp.supernews.com>
are wrote:
> On Sep 19, 7:06 pm, Jon Harrop <····@ffconsultancy.com> wrote:
>> Lisp is typically 1-2x slower than OCaml:
> 
> For my purposes, factors of 2 or so in execution speed are not
> important, although factors of 10 are.

For floating-point intensive code, you can probably always get within 2x
OCaml's performance in Lisp using SBCL with enough effort. If a factor of 2
is not so important then you'll be more interested in hearing about the
differences in programming style between Lisp and OCaml. This boils down to
little more than the difference between static and dynamic typing.

>> You may also like to look at Scheme.
> 
> I have looked at Scheme and really liked it.  I wish I had been
> introduced to programming via Scheme.  But for my purposes, I find
> there are two major drawbacks:
> 
>   1.  The formally defined language lacks some things I'd really like
> to have, like OO.  Of course you can roll your own, but that's not
> where I want to be spending my time.  Or you can use a proprietary
> extension, like that in MzScheme, but I don't want to be locked into a
> single supplier.

The ML family of languages provide better forms of encapsulation than OOP. I
do not value OOP in the context of numerical simulation (or most other
applications).

>   2.  From what I've seen Scheme is too slow, even if I'm not worried
> about factors of two in execution time.

To the best of my knowledge, no Common Lisp compilers come close to the
performance of Stalin-compiled Scheme.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
OCaml for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/?usenet
From: are
Subject: Re: Lisp and OCaml
Date: 
Message-ID: <1190306437.843581.5110@o80g2000hse.googlegroups.com>
On Sep 20, 10:43 am, Jon Harrop <····@ffconsultancy.com> wrote:
> If a factor of 2
> is not so important then you'll be more interested in hearing about the
> differences in programming style between Lisp and OCaml. This boils down to
> little more than the difference between static and dynamic typing.

That's interesting.  I lean towards static, as I've just never been
able to figure out what's so great about dynamic.

> The ML family of languages provide better forms of encapsulation than OOP. I
> do not value OOP in the context of numerical simulation (or most other
> applications).

Hmmm..., I'd say I've found OOP very useful in simulation work.  And
it was after all Simula that first introduced OOP.  I must admit,
thought, that I've not yet learned enough about the ML family to have
a feel for its approach to encapsulation.
From: Jon Harrop
Subject: Re: Lisp and OCaml
Date: 
Message-ID: <13f5aghh7kbpv0a@corp.supernews.com>
are wrote:
> On Sep 20, 10:43 am, Jon Harrop <····@ffconsultancy.com> wrote:
>> If a factor of 2
>> is not so important then you'll be more interested in hearing about the
>> differences in programming style between Lisp and OCaml. This boils down
>> to little more than the difference between static and dynamic typing.
> 
> That's interesting.  I lean towards static, as I've just never been
> able to figure out what's so great about dynamic.

Static typing can be a hindrance if you're constantly boxing and unboxing
values because their types cannot be pinned down completely. Dynamic typing
can relieve that. These characteristics appear when you have many tiny
programs rather than one large self-contained one. So dynamic languages do
well for web programming and static languages do well for application
programming.

>> The ML family of languages provide better forms of encapsulation than
>> OOP. I do not value OOP in the context of numerical simulation (or most
>> other applications).
> 
> Hmmm..., I'd say I've found OOP very useful in simulation work.  And
> it was after all Simula that first introduced OOP.  I must admit,
> thought, that I've not yet learned enough about the ML family to have
> a feel for its approach to encapsulation.

Modules and functors are the core of encapsulation in ML. OCaml has all the
usual ML features and, in practice, these render its OO facilities almost
useless.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
OCaml for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/?usenet
From: Klaus Schilling
Subject: Re: Lisp and OCaml
Date: 
Message-ID: <873ax9f5mv.fsf@web.de>
are <·········@gmx.net> writes:
>
> That's interesting.  I lean towards static, as I've just never been
> able to figure out what's so great about dynamic.

static typing is ball and chain for the creative mind,
dynamic typing provides for flexible thinking

> Hmmm..., I'd say I've found OOP very useful in simulation work. 

simulation is the only justifiable usage of OO

Klaus Schilling
From: Förster vom Silberwald
Subject: Re: Lisp and OCaml
Date: 
Message-ID: <1191005566.405664.117990@19g2000hsx.googlegroups.com>
On Sep 20, 5:40 pm, are <·········@gmx.net> wrote:
> On Sep 20, 10:43 am, Jon Harrop <····@ffconsultancy.com> wrote:
>
> > If a factor of 2
> > is not so important then you'll be more interested in hearing about the
> > differences in programming style between Lisp and OCaml. This boils down to
> > little more than the difference between static and dynamic typing.
>
> That's interesting.  I lean towards static, as I've just never been
> able to figure out what's so great about dynamic.
>

In Bigloo you can give basic types, e.g.

==
(define (add-a-b::double a::double b::double)
   (+ a b))
==

is equal to:

==
(define (add-a-b a b)
   (+ a b))
==

The Bigloo compiler is not a strict when spotting compile type errors
and sometimes it will not spot but in general it will spot a lot of
type mismatches. The following will give an error:

==
(print (add_a_b 2 (vector 3 4))
==
From: Förster vom Silberwald
Subject: Re: Lisp and OCaml
Date: 
Message-ID: <1191005415.661336.239220@w3g2000hsg.googlegroups.com>
On Sep 20, 4:43 pm, Jon Harrop <····@ffconsultancy.com> wrote:

> >   2.  From what I've seen Scheme is too slow, even if I'm not worried
> > about factors of two in execution time.
>
> To the best of my knowledge, no Common Lisp compilers come close to the
> performance of Stalin-compiled Scheme.

Jon:

But lets get real: Stalin has not much in store except for
performance. Moreover there is not much documented experience on
larger scale performance behaviors of Stalin.


If people want to do more than just calculating values they should
better be venting into something like Dr Scheme, Bigloo, Chicken.
From: George Neuner
Subject: Re: Lisp and OCaml
Date: 
Message-ID: <t4g5f394jphd11f6qrb9d0139ou00i5ueq@4ax.com>
On Thu, 20 Sep 2007 08:10:39 -0700, are <·········@gmx.net> wrote:

>I have looked at Scheme and really liked it.  I wish I had been
>introduced to programming via Scheme.  But for my purposes, I find
>there are two major drawbacks:
>
>  1.  The formally defined language lacks some things I'd really like
>to have, ...

Don't be put off by the small size of the standard - almost no Scheme
implements only the standard functionality.  Extensions to the
standard are called "SRFIs" and Scheme has a long list of them (see
http://srfi.schemers.org/).  Some require native support (e.g., to
support arrays of unboxed values), but most are portable.  The set of
SRFIs considered by the community to be very important are implemented
by most Schemes and the heavyweight Schemes (Chez, PLT, etc.)
implement a large number of useful ones.

[Anyone can submit an SRFI and some are, admittedly, frivolous.  SRFIs
with strong community support tend to quickly find their way into
implementations.]


> ... like OO.  Of course you can roll your own, but that's not
>where I want to be spending my time.  Or you can use a proprietary
>extension, like that in MzScheme, but I don't want to be locked into a
>single supplier.

Scheme has a portable CLOS implementation called TinyCLOS.  It's
lacking a few of the advanced features of CL CLOS, but it suffices for
most OO programming.  TinyCLOS has a MOP though not all
implementations support it.

PLT Scheme (mzScheme) has Swindle, which, in addition to a version of
CLOS, provides many other features of CL in Scheme.  I don't know how
portable Swindle itself is, but you could check with the author, Eli
Barzilay.

I understand your not wanting to be locked into a single
implementation, but you should understand that many of the things
which are not portable among Scheme implementations are the same
things that not portable among CL implementations: networking, FFI,
compiler optimizations, proprietary extensions, etc.


>  2.  From what I've seen Scheme is too slow, even if I'm not worried
>about factors of two in execution time.

Stalin produces very fast executables that are comparable to optimized
CL.  Even John Harrop was/is impressed by it.  The main complaint
against Stalin is that the compiler itself is quite slow ... users
tend to do initial development with another implementation and then
switch to Stalin once the code base becomes stable.

Dylan also produces fast executables.  Although Dylan is technically a
variant of Scheme, it uses a conventional syntax rather than sexprs
and programming in it "feels" quite un-lispy.  That said, some people
love it.

George
--
for email reply remove "/" from address
From: Ken Tilton
Subject: Re: Lisp and OCaml
Date: 
Message-ID: <XqHIi.200$mS7.87@newsfe12.lga>
George Neuner wrote:
> ... the heavyweight Schemes...

Oxy. Moron. Please note concatenation.

kenny

-- 
http://www.theoryyalgebra.com/

"We are what we pretend to be." -Kurt Vonnegut
From: George Neuner
Subject: Re: Lisp and OCaml
Date: 
Message-ID: <3ckaf3dkjsqpln6tfhh0dkd2bupuh6ghvt@4ax.com>
On Fri, 21 Sep 2007 00:04:00 -0400, Ken Tilton
<···········@optonline.net> wrote:

>George Neuner wrote:
>> ... the heavyweight Schemes...
>
>Oxy. Moron. Please note concatenation.

Yeah, yeah.  I just mean the implementations that aren't toys ... I
don't have a better adjective.

George
--
for email reply remove "/" from address
From: Rob Warnock
Subject: Re: Lisp and OCaml
Date: 
Message-ID: <LoqdnQof5vlUpW7bnZ2dnUVZ_u6rnZ2d@speakeasy.net>
are <·········@gmx.net> wrote:
+---------------
| I have looked at Scheme and really liked it.  I wish I had been
| introduced to programming via Scheme.  But for my purposes, I find
| there are two major drawbacks:
| 
|   1.  The formally defined language lacks some things I'd really like
| to have, like OO.  Of course you can roll your own, but that's not
| where I want to be spending my time.
+---------------

Ditto, which is one of the reasons I switched from Scheme to CL.

+---------------
| Or you can use a proprietary extension, like that in MzScheme,
| but I don't want to be locked into a single supplier.
+---------------

After trying several other flavors, I *had* actually "settled on"
using MzScheme, mainly for it's performance [compared to the other
Scheme's I'd tried] and its clean FFI [MzScheme calls external
C code with a Tcl-like/shell-like "int argc, Scheme_Object **argv"
calling sequence] and support for runtime DSO lining. I had no
particular concerns myself about being "locked" to a "supplier",
since the code is in C and builds from scratch fairly easily.
I used MzScheme quite happily for a number of years.  [But...]

+---------------
|   2.  From what I've seen Scheme is too slow, even if I'm not
| worried about factors of two in execution time.
+---------------

MzScheme now comes with a compiler to C, "mzc", that speeds things
up somewhat. But the speed of compiled CL is certainly one of the
reasons I eventually "turned to the dark side" and embraced CL.

That, and getting tired of reinventing stuff all the time.

[And having a major app that I'd written in MzScheme v.50 break
horribly by a major change in internals that occurred circa
MzScheme v.103...]

Even with CL, you will probably find yourself "settling into"
a specific implementation of CL for most of your work. [I use
and like CMUCL. YMMV.] Don't worry about it.  The good news
is that if you *do* have to change implementations later, that
rather large portion of your code which was written to conform
to the ANSI Standard (a.k.a. CLHS) will probably "just work";
only the implementation-specific extension bits will have to change.
[And you kept those factored aside anyway... DIDN'T YOU?!?  ;-} ]


-Rob

-----
Rob Warnock			<····@rpw3.org>
627 26th Avenue			<URL:http://rpw3.org/>
San Mateo, CA 94403		(650)572-2607
From: Förster vom Silberwald
Subject: Re: Lisp and OCaml
Date: 
Message-ID: <1191005169.990948.322470@g4g2000hsf.googlegroups.com>
On Sep 20, 4:10 pm, are <·········@gmx.net> wrote:

>
> > You may also like to look at Scheme.
>
> I have looked at Scheme and really liked it.  I wish I had been
> introduced to programming via Scheme.  But for my purposes, I find
> there are two major drawbacks:
>
>   1.  The formally defined language lacks some things I'd really like
> to have, like OO.  Of course you can roll your own, but that's not
> where I want to be spending my time.  Or you can use a proprietary
> extension, like that in MzScheme, but I don't want to be locked into a
> single supplier.
>
>   2.  From what I've seen Scheme is too slow, even if I'm not worried
> about factors of two in execution time.


Hello: Give Bigloo a try!

Bigloo gives you a very fast compiled language and has lost of add on
stuff. Okay, you must stick to Bigloo then cos Bigloo goes far beyond
any minimal Scheme standard. Bigloo has native object oriented
programming facilities. But I must confess that though never done any
elaborate Common Lisp programming myself, Common Lisp object oriented
programming gives you surely more power than Bigloo ist one.

Maybe yoy are happy with Python? Python has lots of libraries to put
you aside with Matlab or IDL so to speak.

But best: play around and decide for yourself which suits you best! A
computer programming language is often no substitute for creativity. I
wished it were.
From: Jeronimo Pellegrini
Subject: Re: Lisp and OCaml
Date: 
Message-ID: <fctfem$5nr$1@aioe.org>
On 2007-09-20, Jon Harrop <···@ffconsultancy.com> wrote:
> Lisp is typically 1-2x slower than OCaml:
>
> http://www.ffconsultancy.com/languages/ray_tracer/

That graph does not support the statement you just made.

- For the red dots (which show results on 32-bit architecture), Lisp
and OCaml are very close. Only for 64 bit SBCL was slower. It would be
a good idea to split the graphs;

- You have tested SBCL only, with one program only. That would hardly
qualify as evidence of typical running time.

J.
From: Jon Harrop
Subject: Re: Lisp and OCaml
Date: 
Message-ID: <13f561hauvr9ec@corp.supernews.com>
Jeronimo Pellegrini wrote:
> On 2007-09-20, Jon Harrop <···@ffconsultancy.com> wrote:
>> Lisp is typically 1-2x slower than OCaml:
>>
>> http://www.ffconsultancy.com/languages/ray_tracer/
> 
> That graph does not support the statement you just made.
>
> - For the red dots (which show results on 32-bit architecture), Lisp
> and OCaml are very close.

OCaml is 4% faster in the fastest case.

> Only for 64 bit SBCL was slower.

OCaml is 55% faster in the fastest case.

That does not disagree with "Lisp is typically 1-2x slower than OCaml".

> It would be a good idea to split the graphs;

Yes. I'd like to write a JavaScript front end that lets you display only the
results you're interested in. The static GIF was fine when there were fewer
entrants...

> - You have tested SBCL only,

Free performant Lisp compilers are few and far between. SBCL stands head and
shoulders above the rest.

> with one program only. 

Five programs solving one problem. There are other benchmarks solving
different problems and they also do not disagree with my assertion:

SBCL-compiled Lisp >1.7x slower than OCaml on symbolic simplifier:

http://www.lambdassociates.org/studies/study10.htm

The spectral-norm benchmark from the shootout takes 9.4s in both languages
on my machine.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
OCaml for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/?usenet
From: Cesar Rabak
Subject: Re: Lisp and OCaml
Date: 
Message-ID: <fcv5e3$r87$1@aioe.org>
Jon Harrop escreveu:
> Jeronimo Pellegrini wrote:
>> On 2007-09-20, Jon Harrop <···@ffconsultancy.com> wrote:
>>> Lisp is typically 1-2x slower than OCaml:
>>>
>>> http://www.ffconsultancy.com/languages/ray_tracer/
>> That graph does not support the statement you just made.
>>
>> - For the red dots (which show results on 32-bit architecture), Lisp
>> and OCaml are very close.
> 
> OCaml is 4% faster in the fastest case.
> 
>> Only for 64 bit SBCL was slower.
> 
> OCaml is 55% faster in the fastest case.
> 
> That does not disagree with "Lisp is typically 1-2x slower than OCaml".
> 
>> It would be a good idea to split the graphs;
> 
> Yes. I'd like to write a JavaScript front end that lets you display only the
> results you're interested in. The static GIF was fine when there were fewer
> entrants...
> 

Why "JavaScript" and not OCaml?
From: Jon Harrop
Subject: Re: Lisp and OCaml
Date: 
Message-ID: <13fgek6rg1blm47@corp.supernews.com>
Cesar Rabak wrote:
> Jon Harrop escreveu:
>> Yes. I'd like to write a JavaScript front end that lets you display only
>> the results you're interested in. The static GIF was fine when there were
>> fewer entrants...
> 
> Why "JavaScript" and not OCaml?

JavaScript is more widely supported by browsers and is still on my TODO list
of languages to learn.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
OCaml for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/?usenet
From: Vesa Karvonen
Subject: Re: Lisp and OCaml
Date: 
Message-ID: <fcvk4h$o8s$1@oravannahka.helsinki.fi>
Jon Harrop <···@ffconsultancy.com> wrote:
[...]
> Yes. I'd like to write a JavaScript front end that lets you display only the
> results you're interested in. The static GIF was fine when there were fewer
> entrants...
[...]

You might want to try this one: http://www.itu.dk/people/mael/smltojs/ .

-Vesa Karvonen
From: Jeronimo Pellegrini
Subject: Re: Lisp and OCaml
Date: 
Message-ID: <fddpnq$63d$1@aioe.org>
On 2007-09-20, Jon Harrop <···@ffconsultancy.com> wrote:
Jon Harrop <···@ffconsultancy.com> wrote:
> OCaml is 55% faster in the fastest case.

One thing I didn't find in the benchmark description -- did you run a
precompiled SBCL in both cases? Compiled from source?
Just wondering if you didn't end up running a version of SBCL fo 32 bit
on the 64 bit architecture.

J.
From: Jon Harrop
Subject: Re: Lisp and OCaml
Date: 
Message-ID: <13flso3s2jngvb3@corp.supernews.com>
Jeronimo Pellegrini wrote:
> On 2007-09-20, Jon Harrop <···@ffconsultancy.com> wrote:
> Jon Harrop <···@ffconsultancy.com> wrote:
>> OCaml is 55% faster in the fastest case.
> 
> One thing I didn't find in the benchmark description -- did you run a
> precompiled SBCL in both cases? Compiled from source?
> Just wondering if you didn't end up running a version of SBCL fo 32 bit
> on the 64 bit architecture.

Debian binary packages in both cases.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
OCaml for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/?usenet
From: Jeronimo Pellegrini
Subject: Re: Lisp and OCaml
Date: 
Message-ID: <fdfvqi$iqj$1@aioe.org>
On 2007-09-26, Jon Harrop <···@ffconsultancy.com> wrote:
> Jeronimo Pellegrini wrote:
>> On 2007-09-20, Jon Harrop <···@ffconsultancy.com> wrote:
>> Jon Harrop <···@ffconsultancy.com> wrote:
>>> OCaml is 55% faster in the fastest case.
>> 
>> One thing I didn't find in the benchmark description -- did you
>> run a precompiled SBCL in both cases? Compiled from source?
>> Just wondering if you didn't end up running a version of SBCL fo 32 
>> bit on the 64 bit architecture.
>
> Debian binary packages in both cases.

In this case --
Unless you installed Debian for AMD64, you were running a 32-bit binary.

I would either repeat the experiment with the binary from sbcl.org (the
current version is 1.0.9) or in a Debian/AMD64 installation. If you
decide to run the binary from sbcl.org, you still need a Linux kernel
running in 64-bit mode (an ordinary i386 installation will not do);
you may need to reinstall Linux.

J.
From: Jon Harrop
Subject: Re: Lisp and OCaml
Date: 
Message-ID: <13fn8sss5qrpg20@corp.supernews.com>
Jeronimo Pellegrini wrote:
> Unless you installed Debian for AMD64, you were running a 32-bit binary.
> 
> I would either repeat the experiment with the binary from sbcl.org (the
> current version is 1.0.9) or in a Debian/AMD64 installation. If you
> decide to run the binary from sbcl.org, you still need a Linux kernel
> running in 64-bit mode (an ordinary i386 installation will not do);
> you may need to reinstall Linux.

Yes, this is an x86_64 Debian install. All of the 64-bit results are from
compilers generating 64-bit code in this 64-bit OS.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
From: Tim Bradshaw
Subject: Re: Lisp and OCaml
Date: 
Message-ID: <1190291796.157848.42120@57g2000hsv.googlegroups.com>
On Sep 20, 12:18 am, are <·········@gmx.net> wrote:
> I've zeroed in on Lisp and OCaml.
> Superficially, these two seem very different from one another, yet
> I've noticed that there a some who post to both of these groups.

The main issue to be aware of is your exposure to Jon Harrop.  Really,
you can use any language you want but you need to make sure you're a
long way from him.  Personally, I confess to programming nowadays
entirely in APL on Z/OS after some extensive research showed that this
would minimize Harrop exposure.  Remember he is lethal in even
moderate doses (people have died from as few as 980 characters), and
is cumulative.  There are rumours that anyone exposed to him is to be
culled, as well, to reduce the danger of contamination.
From: Rainer Joswig
Subject: Re: Lisp and OCaml
Date: 
Message-ID: <joswig-9BADC0.17483320092007@news-europe.giganews.com>
In article <·······················@57g2000hsv.googlegroups.com>,
 Tim Bradshaw <··········@tfeb.org> wrote:

> On Sep 20, 12:18 am, are <·········@gmx.net> wrote:
> > I've zeroed in on Lisp and OCaml.
> > Superficially, these two seem very different from one another, yet
> > I've noticed that there a some who post to both of these groups.
> 
> The main issue to be aware of is your exposure to Jon Harrop.  Really,
> you can use any language you want but you need to make sure you're a
> long way from him.  Personally, I confess to programming nowadays
> entirely in APL on Z/OS after some extensive research showed that this
> would minimize Harrop exposure.  Remember he is lethal in even
> moderate doses (people have died from as few as 980 characters), and
> is cumulative.  There are rumours that anyone exposed to him is to be
> culled, as well, to reduce the danger of contamination.

Too bad that it won't be cross posted to their mailing list. :-(

-- 
http://lispm.dyndns.org
From: Slobodan Blazeski
Subject: Re: Lisp and OCaml
Date: 
Message-ID: <1190273358.459658.53880@g4g2000hsf.googlegroups.com>
On Sep 20, 1:18 am, are <·········@gmx.net> wrote:
> Getting back to doing some programming after a long absence, I've been
> reviewing the available languages to see which would be most suitable
> for some numerically intensive simulation work.  Wanting something
> that's fast and high-level, I've zeroed in on Lisp and OCaml.
> Superficially, these two seem very different from one another, yet
> I've noticed that there a some who post to both of these groups.
> Would anyone who knows both languages well (let's not start a flame
> war, please!) care to comment on the similarities and differences
> between them?

The only one who post in both newsgroups is our resident spammer.
I don't know well Ocaml, though I've tried it in the past. But
probably the best way to answer is lisp for you it's just to try it.
You can learn fundamentals of lisp in few hours, so download one of
this:
(free commercial software)
http://www.lispworks.com/downloads/index.html
http://www.franz.com/downloads/clp/survey
(opensource are the one with CLisp, SBCL  &  OpenMCL, pick whicever
you want it doesn't matter which one )
http://www.gigamonkeys.com/lispbox/#download

And try this tutorial :
http://lib.store.yahoo.net/lib/paulgraham/acl2.txt

Or check on some of the free ebooks:
[shameless selfquoting]
For learning common lisp if you're already  experienced in some other
language and you just want to get on creating applications with lisp:
1. http://www.gigamonkeys.com/book/    free as ebook, worth every
cent
of the paper edition.

If you're new to programming or just prefer slower pace :
2. Gentle introduction  to symbolic computation
http://www-cgi.cs.cmu.edu/afs/cs.cmu.edu/user/dst/www/LispBook/index....
out of print

The other free ebooks worth looking at, some of them offer printed
editions are,
3.Succesfull Common lisp http://www.psg.com/~dlamkins/sl/contents.html
4.Loving lisp http://www.markwatson.com/opencontent/
5. COMMON LISP: An Interactive Approach http://www.cse.buffalo.edu/~shapiro/Commonlisp/
6. Basic Lisp Techniques,  http://www.franz.com/resources/educational_resources/cooper.book.pdf

There's some nice videos that Franz made available free of charge
from
their certification program at http://www.franz.com/services/classes/download.lhtml


AND MAKE UP YOUR OWN MIND

cheers
Slobodan
From: are
Subject: Re: Lisp and OCaml
Date: 
Message-ID: <1190301948.449962.288490@d55g2000hsg.googlegroups.com>
On Sep 20, 2:29 am, Slobodan Blazeski <·················@gmail.com>
wrote:
>
> AND MAKE UP YOUR OWN MIND

That's really what I'd like to do -- learn both languages well and
make a decision.  But that's going to take a long time.  While I have
learned some Lisp and have enjoyed doing so, I fear that it's going to
be a long time before I really "get it," before I can break out of the
non-Lisp thought patterns that I've acquired from using Algol-like
languages and truly access Lisp's power.  Hence, I post here, to try
to accelerate the process by gaining a little insight from those who
know more about it than I.

Thanks for the e-resources on Lisp.
From: Slobodan Blazeski
Subject: Re: Lisp and OCaml
Date: 
Message-ID: <1190358513.287014.174810@g4g2000hsf.googlegroups.com>
On Sep 20, 5:25 pm, are <·········@gmx.net> wrote:
> On Sep 20, 2:29 am, Slobodan Blazeski <·················@gmail.com>
> wrote:
>
>
>
> > AND MAKE UP YOUR OWN MIND
>
> That's really what I'd like to do -- learn both languages well and
> make a decision.  But that's going to take a long time.  While I have
> learned some Lisp and have enjoyed doing so, I fear that it's going to
> be a long time before I really "get it," before I can break out of the
> non-Lisp thought patterns that I've acquired from using Algol-like
> languages and truly access Lisp's power.
Don't worry about that, learning from a good lispbook will make you
think lispway, I'm coming from basic/pascal/c/c++/c# heritage but
found that s-expressions are my natural way of thinking.
> Hence, I post here, to try
> to accelerate the process by gaining a little insight from those who
> know more about it than I.
>

> Thanks for the e-resources on Lisp.
From: Klaus Schilling
Subject: Re: Lisp and OCaml
Date: 
Message-ID: <87bqbxrhjy.fsf@web.de>
are <·········@gmx.net> writes:

> Getting back to doing some programming after a long absence, I've been
> reviewing the available languages to see which would be most suitable
> for some numerically intensive simulation work.  Wanting something
> that's fast and high-level, I've zeroed in on Lisp and OCaml.
> Superficially, these two seem very different from one another, yet
> I've noticed that there a some who post to both of these groups.
> Would anyone who knows both languages well (let's not start a flame
> war, please!) care to comment on the similarities and differences
> between them?

Ocaml's syntax is unreadable and corrupt, as is typical for
infix languages.

Klaus Schilling
From: Tamas Papp
Subject: Re: Lisp and OCaml
Date: 
Message-ID: <87ejgttsks.fsf@pu100877.student.princeton.edu>
are <·········@gmx.net> writes:

> Getting back to doing some programming after a long absence, I've been
> reviewing the available languages to see which would be most suitable
> for some numerically intensive simulation work.  Wanting something
> that's fast and high-level, I've zeroed in on Lisp and OCaml.

I don't know about OCaml (but tried Haskell before switching to Lisp).
I am using SBCL for number-crunching and simulations (solving dynamic
recursive macroeconomic models).  CL is fast, friendly, best language
for the job IMO.

Tamas
From: are
Subject: Re: Lisp and OCaml
Date: 
Message-ID: <1190302063.254845.289850@n39g2000hsh.googlegroups.com>
On Sep 20, 7:44 am, Tamas Papp <······@gmail.com> wrote:
> I don't know about OCaml (but tried Haskell before switching to Lisp).

How would you compare Haskell and Lisp?