Lisp and OCaml
are
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?
Raffael Cavallaro
> 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?
Jon Harrop
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).
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
Griff
> If you are using Windows then I would recommend F#.
Is it better to learn F# directly through F# literature or through
OCaml?
Jon Harrop
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.
Ken Tilton
Griff wrote:
> On Sep 19, 7:06 pm, Jon Harrop <j...@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
Slobodan Blazeski
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
Jeronimo Pellegrini
> 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.
Klaus Schilling
Ocaml's syntax is unreadable and corrupt, as is typical for
infix languages.
Klaus Schilling
Tim Bradshaw
> 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.
Tamas Papp
> 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
David Young
-- david
Ken Tilton
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
David Young
group is the humorous responses he draws. Most entertaining.
-- david
are
s'il-vous-plait-mac.com> 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.
are
> 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.
are
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.
are
> I don't know about OCaml (but tried Haskell before switching to Lisp).
How would you compare Haskell and Lisp?
Rainer Joswig
Tim Bradshaw <tfb+g...@tfeb.org> wrote:
Too bad that it won't be cross posted to their mailing list. :-(
Jon Harrop
> On Sep 19, 7:06 pm, Jon Harrop <j...@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.
Jon Harrop
> On 2007-09-20, Jon Harrop <j...@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.
are
> 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.
Jon Harrop
> On Sep 20, 10:43 am, Jon Harrop <j...@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.
Don Geddis
>> On 2007-09-19 19:18:24 -0400, are <Propon...@gmx.net> said:
>> > Wanting something that's fast and high-level, I've zeroed in on Lisp and
>> > OCaml.
>
> 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/ d...@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
George Neuner
<kenny...@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
Kent M Pitman
are <Prop...@gmx.net> writes:
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.
Ken Tilton
Thx, will do! This NG rocks!!!
kenny
George Neuner
>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.
Pillsy
[...]
> 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
Cesar Rabak
> Jeronimo Pellegrini wrote:
>> On 2007-09-20, Jon Harrop <j...@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?
Rob Warnock
+---------------
| 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 <rp...@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Ken Tilton
George Neuner wrote:
> ... the heavyweight Schemes...
Oxy. Moron. Please note concatenation.
Vesa Karvonen
[...]
> 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
Slobodan Blazeski
> On Sep 20, 2:29 am, Slobodan Blazeski <slobodan.blaze...@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.
think lispway, I'm coming from basic/pascal/c/c++/c# heritage but
found that s-expressions are my natural way of thinking.
Klaus Schilling
>
> 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
George Neuner
<kenny...@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.
Jon Harrop
> 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.
Jeronimo Pellegrini
> 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.
Damien Kick
> 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?
Jon Harrop
Debian binary packages in both cases.
Jon Harrop
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.
George Neuner
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.
Cesar Rabak
> 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.
Damien Kick
> On Wed, 26 Sep 2007 14:43:23 -0500, Damien Kick <dk...@earthlink.net>
> wrote:
>
>> I mean, really. How was I supposed to
>> know that this was a touchy subject?
>
> More proof that you're stupid.
>
You should look up the word sarcasm in that big dictionary of yours.
Damien Kick
> On Wed, 26 Sep 2007 14:43:23 -0500, Damien Kick <dk...@earthlink.net>
> wrote:
>
>> How was I supposed to
>> know that this was a touchy subject?
>
> More proof that you're stupid.
>
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.
Ken Tilton
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
Jeronimo Pellegrini
> Jeronimo Pellegrini wrote:
>> On 2007-09-20, Jon Harrop <j...@ffconsultancy.com> wrote:
>> Jon Harrop <j...@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.
Jon Harrop
> 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
Jon Harrop
> 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
Förster vom Silberwald
>
> > 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.
Förster vom Silberwald
> > 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.
Förster vom Silberwald
> On Sep 20, 10:43 am, Jon Harrop <j...@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))
==
are
> 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.
are
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.
Jon Harrop
> On 20 Sep, 18:17, Don Geddis <d...@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.
Pascal Costanza
> On 20 Sep, 18:17, Don Geddis <d...@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/
Klaus Schilling
>
> 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
Jon Harrop
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.
Jon Harrop
> 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.
Klaus Schilling
>
> 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
Pascal Costanza
[whatever]
I didn't expect any other reaction.
Jon Harrop
> Jon Harrop wrote:
> [whatever]
>
> I didn't expect any other reaction.
I led the horse to water...
Jon Harrop
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...
Pascal Costanza
> Klaus Schilling wrote:
>> Jon Harrop <j...@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.
Klaus Schilling
> 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
Pascal Costanza
...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 Costanza
> I led the horse to water...
I agree that this statement reveals your true nature.
Leandro Rios
> 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
Cesar Rabak
[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.
Jon Harrop
> 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...
Ken Tilton
Nonsense. Now please leave your offerings of incense or cash at my feet
and leave this thread without turning your back on me.
kenny
Don Geddis
> On 20 Sep, 18:17, Don Geddis <d...@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/ d...@geddis.org
If being an eagle is such a good idea, why are there so few of them?
-- Wally, from Dilbert
Leandro Rios
>
> 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
Ken Tilton
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.
Pascal Costanza
> 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.
Jon Harrop
> Jon Harrop wrote:
>
> 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.
Jon Harrop
> 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.
are
>
> 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.
Cesar Rabak
have the real thing :-)
Cesar Rabak
> 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.
>
are
>
> 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.
Kent M Pitman
> 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.
Pascal Costanza
>> 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...
are
> are <Propon...@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.
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?
Pascal Costanza
> On 1 Oct, 17:35, Don Geddis <d...@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
> 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€.
are
> 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
> 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.
Jon Harrop
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.
Rainer Joswig
Jon Harrop <j...@ffconsultancy.com> wrote:
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.
Raffael Cavallaro
> 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.
Jeronimo Pellegrini
> 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.
Kent M Pitman
> 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)))
Jon Harrop
> ...you are constantly posting false information...
> ...Earlier he was banned from Wikipedia, because he was spamming
> there, too...
How ironic. :-)
Jon Harrop
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.
Jon Harrop
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:
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
Jon Harrop
> 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.
Rainer Joswig
Jon Harrop <j...@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)
Rainer Joswig
Jon Harrop <j...@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.
Pascal Costanza
> 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.
philip....@gmail.com
> . 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/
Rainer Joswig
Jon Harrop <j...@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 dev...@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)
;-)