Re: F#


Markus E Leypold wrote:

I assume that Rainer talks about ITA, and for the
case in question, they have chosen Common Lisp _because_ of the
performance one can gain with it, not in spite of it. People really
But is it _faster_ than OCaml: Jons says: No. It might be as fast. So
the question, according to Jon: Why did they take Lisp? And not better
Ocaml? My answer: The support and maintenance argument, maybe.


The efficiency of a program is very hard to predict, especially for

True.

large programs, and the programming language and implementation
thereof that is used is only one of many different factors.

Absolutely. And that was the point I wanted to make: Technical
properties of the language are only a part of the picture.

Different languages and programming paradigms probably induce
different programming styles, which probably has an overall effect
on the architecture of a system, and hence on the overall
performance. If the favored programming style of a certain language
doesn't fit the preferences of the involved programmers, the result
is probably going to be bad no matter what you do. And so on...

Right.

On top of that, it is a well-known fact that efficiency is
counter-intuitive. What works well for small examples doesn't
necessarily scale to large ones

That, actually is an important point.

because the bottlenecks shift to
different places. And the bottlenecks are never where you expect them
to be.



have a completely wrong perception of what is and what isn't possible
in Common Lisp.
I think, everything is possible in Lisp (hell, even in FORTRAN
everything is possible, though much more painful).

I don't know whether Fortran is painful. I have never used it, so I
cannot judge it.

It is, believe me .-).


Indeed, a computer doesn't care what programming language you use, it
executes whatever you feed it. If you are able to use a language
proficiently, then you win. The important aspect here is that the
choice of programming language depends a lot more on the human factor
than on the machine factor. Because of this, it's plain silly to
assume that there is a single programming language, or a single
programming paradigm covering a family of languages, that is well
suited for any problem. The important question is: Is it well suited
for the programmers at hand?

It's ultimately a question of convenience: Which approach allows me to
most conveniently express what I want. It's apparent that different
programmers prefer different styles of expression (even among
programmers that know a lot more than one style). Convenience is
ultimately a subjective choice.

I am not trying to advocate Lisp here. Well, ok, in fact I am ;) , but
only to the extent to make sure that people don't have the wrong
prejudices about this language. A lot of people find Common Lisp very


Agreed. I respect your approach here.

convenient to use and use it in a broad range of settings, including
those where high performance is needed as well as for scenarios which
require high flexibility.

Quoting success stories at me, doesn't help at all too: MS-Windows is
a big success, economically, and ... well, I don't need to continue, I
think. Knowing a success story only tells me that other people
succeeded in Lisp as other other people succeed in Ocaml (e.g. St
Janes). It doesn't help me to understand the factors causative for
success or failure.

...but it gives you a good indication which languages you should and
shouldn't single out as potentially good candidates.

That is the point I'd like to dispute: Success stories reflect was is
popular. Not necessarily what works (at the end almost everything
works, somehow), and certainly not what works well.


And since this are not double blind experiments, not even experiments
with a control experiment in another language, comparisons are
difficult to make and signifikance is difficult to assess: My
impression is more that everyone who has been successful has a really
good story why he has been successful: Only -- it's only a story, told
by the successful (hardly a neutral party), uncorroborated by any
impartial witnesses, that perhaps would also see the "success" a bit
less untainted.

I agree, but it's the best we have, with very few

The other avenue to approach the problem would be not to work from
empirical eveidence, but from a theoretical understanding of the
process of programming / development and show that a given language
fits well into that process. Of course, at the moment we don't have a
"theory of programming", so that approach stay science fiction for the
moment.

exceptions. http://norvig.com/java-lisp.html is one exception that I
am aware of. (Yes, this specific example is a biased choice of mine,
but I cannot immediately come up with better examples off the top of
my head.)

To sum it up: Success stories (like SF and detective stories) make
entertaining reading. As a source of data to make decisions they are
to be treated with suspicion. Their model to explain why success
happened is probably not reliable.

Agreed.

:-).



Does ECLM also invite people that tell them how they failed
with Lisp?

That's not the purpose of such a meeting. ECLM is not an academic venue.


Or what about the Fortran 90 success stories: "How I
couldn't live without Fortran 90 -- It saved my day ... and our
valuable simulation ... business critical ... and ..."? Those
certainly exist.

Sure, why not. I am certain that there are people who prefer Fortran
over other languages. Why shouldn't they? It seems to be a successful
language, after all.

So should I use FORTRAN for my projects? :-).

My warning: Don't believe people when they tell you why they where
successful. Only scientific and _impartial_ investigation can uncover
the truth in those matters and I fear it hasn't happend yet in the
programming language domain. Until then we can talk, but we can't
insist.

The main problem seems to me that the methods of social sciences are
not appreciated enough in computer science.

I completely agree!

Regards -- Markus

.