Python syntax in Lisp and Scheme

[Joe Marshall]

Re: Python syntax in Lisp and Scheme

Paul Foley <see@below.inva lid> writes:
[color=blue]
> On Fri, 10 Oct 2003 00:34:10 -0400, Lulu of the Lotus-Eaters wrote:
>[color=green]
>> Kenny Tilton <ktilton@nyc.rr .com> wrote previously:
>> |> It's only been out, what, twenty years? And another twenty before that
>> |> for other lisps... How much time do you think you need?[/color]
>[color=green]
>> |Hey, we've been dead for thirty years, give us a break.
>> |The bad news for other languages is that the evolution of programming
>> |languages, like baseball, is a game played without a clock.[/color]
>[color=green]
>> I would think Lisp is more like cricket: wickets bracket both ends, no
>> one can actually understand the rules, but at least the players wear
>> white.[/color]
>
> Oh, come on! Anyone can understand cricket! There are two teams.
> The team that's in sits out, except for two batsmen, and the other
> team come out and try to get the men that are in out. When a man goes
> out, he goes in and another man comes out. When the team that's in
> are all out, except for the one who's not out, the other team goes in,
> until they're all out, too; and then a second innings is played.
> That's more or less all there is to it![/color]

In other words, the man that's in may be out or in. If he's in, he
can go back out, but if he's out, then he can't go back in. Once
everyone is out, everyone goes out, then once the in team is out
again, the out team goes in again and everyone in can go out again.

Thanks for straightening that out!

[Björn Lindberg]

Re: startup time (was: Python syntax in Lisp and Scheme)

Bruce Lewis <brlspam@yahoo. com> writes:
[color=blue]
> j-anthony@rcn.com (Jon S. Anthony) writes:
>[color=green]
> > If your problems are trivial, I suppose the presumed lower startup
> > costs of Python may mark it as a good solution medium.[/color]
>
> I find no significant difference in startup time between python and
> mzscheme.[/color]

My preliminary results in this very important benchmark indicates that
python performs equally well to the two benchmarked Common Lisps:

200 bjorn@nex:~> time for ((i=0; i<100; i++)); do lisp -noinit -eval '(quit)'; done

real 0m2,24s
user 0m1,36s
sys 0m0,83s
201 bjorn@nex:~> time for ((i=0; i<100; i++)); do lisp -noinit -eval '(quit)'; done

real 0m2,24s
user 0m1,39s
sys 0m0,82s
202 bjorn@nex:~> time for ((i=0; i<100; i++)); do clisp -q -x '(quit)'; done

real 0m2,83s
user 0m1,74s
sys 0m1,03s
203 bjorn@nex:~> time for ((i=0; i<100; i++)); do clisp -q -x '(quit)'; done

real 0m2,79s
user 0m1,67s
sys 0m1,09s
204 bjorn@nex:~> time for ((i=0; i<100; i++)); do python -c exit; done

real 0m2,41s
user 0m1,85s
sys 0m0,52s
205 bjorn@nex:~> time for ((i=0; i<100; i++)); do python -c exit; done

real 0m2,41s
user 0m1,89s
sys 0m0,52s

</sarcasm>


Björn

[Marco Antoniotti]

Re: Python syntax in Lisp and Scheme



Rainer Deyke wrote:[color=blue]
> Pascal Costanza wrote:
>[color=green]
>>Pick the one Common Lisp implementation that provides the stuff you
>>need. If no Common Lisp implementation provides all the stuff you
>>need, write your own libraries or pick a different language. It's as
>>simple as that.[/color]
>
>
> Coming from a C/C++ background, I'm surprised by this attitude. Is
> portability of code across different language implementations not a priority
> for LISP programmers?
>[/color]

It is. However, history has run against Lisp in this respect. First of
all, there are more than 1.84 implementations of Lisp (4 commercial
ones) and the vendors do not have much incentive in making something
completely portable. OTOH *there are* cross platforms compatibility
layers for many of the things you need. But the problem facing any
Common Lisp library writer is to decide how much to go in terms of cross
implementation and cross platform portability.

Having said that, lets note however, that the actual footprint of CL is
large enough to allow you to write nice portable programs in a much
easier way than e.g. in Scheme or in pre- (and, to some extent post-)
STL C++.

Cheers
--
Marco

[Marco Antoniotti]

Re: Python syntax in Lisp and Scheme



Andrew Dalke wrote:
[color=blue]
> Edi Weitz[/color]
....[color=blue]
>[color=green]
>>So, here are your choices:
>>
>>1. Buy a commercial Lisp. I've done that and I think it was a good
>> decision.[/color]
>
>
> I'm already making my living from doing Python, so I've got an
> incentive to stay with it. ;)
>
> In the scientific conferences I attend, no one I've seen uses Lisp
> for their work, excepting those old enough that they started before
> there were other high-quality high-level languages.[/color]

Maybe thos of us "old enough" know that some high-level high-quality
languages are better than others :)

[color=blue]
>
> No one has told me they would hire me for contract work "if only
> you were a Lisp programmer."
>
> If the barrier to entry to do what are common-place tasks requires
> I buy a commercial Lisp then it's much less likely others will use
> my code. I like having others use my code.
>
> (Then why do I use Python? It's a tradeoff, since writing Java/C++
> is just too tedious. And I like the people in Python (Hi Laura!).
> And I'm picky the domain -- I like doing computational life sciences.)[/color]

Well, I am doing that too. Do you know what is the core of
Biocyc/Ecocyc/Metacyc written in?
[color=blue][color=green]
>>2. Try to improve the situation of the free CL implementations by
>> writing libraries or helping with the infrastructure. That's how
>> this "Open Source" thingy is supposed to work. I'm also doing this.[/color]
>
>
> And I'm doing it for Python. For my domain, it seems like a much
> better language choice, for reasons I've mentioned here several times.[/color]

Your reasons seem to boil down to the "I do not know Lisp enough" thingy
you hear over and over. I know I sound trite, but that is exactly the
point. Meanwhile, CL languishes because people don't understand
Greespun's Tenth :)

I know I am whining :) I *am* an old geezer :)

[color=blue]
>
>[color=green]
>>3. Run around complaining that you can't use Lisp because a certain
>> combination of features is not available for free. We have far too
>> many of these guys on c.l.l.[/color]
>
>
> Technically I'm cross-posting from c.l.py. And I actually complain
> for other reasons. ;)
>
>[color=green]
>>4. Just don't use it. That's fine with me.[/color]
>
>
> So far I've made ... 4(?) half-hearted attempts at learning Lisp.
> And 1 at learning Haskell. And 0.1 at learning OCaml.
>
>[color=green]
>>It currently looks like the number of people choosing #2 is
>>increasing. Looks promising. You are invited to take part - it's a
>>great language and a nice little community... :)[/color]
>
>
> "A rising tide lifts all boats". The same is true in Python, in
> Java, in Ruby, in ...[/color]

With the main difference that Greespun's Tenth Rule of Programming does
not apply in only one case :)

Cheers
--
marco

[Marco Antoniotti]

Re: Python syntax in Lisp and Scheme



Andrew Dalke wrote:
[color=blue]
> Thomas F. Burdick:
>[color=green]
>>With Lisp, you're not at the mercy of your vendor; if
>>you know damn well that some readable code A can be transformed into
>>equivalent, but efficient code B, you can cause it to happen![/color]
>
>
> Not at the mercy of your vendor unless you want to use something
> which isn't in the standard, like unicode (esp "wide" unicode, >16bit),[/color]

Given that there are more than 1.84 implementations of Common Lisp, yes,
you are at the mercy of the implementor to have access to a good UNICODE
implementation. (Now, whn is the last time I really really really
needed to write error messages in Tamil script? >:| )
[color=blue]
> regular expressions (esp. regexps of unicode),[/color]

There are several completely portable regexps libraires. For UNICODE
see above.
[color=blue]
> sockets,[/color]

There are at least two completely portable sockets libraries for CL.
[color=blue]
> or ffi?[/color]

Last I checked UFFI did pretty much the right thing.
[color=blue]
>
> But that's just flaming -- ignore me. ;)[/color]

I am a fireman :)

Cheers
--
Marco

[Alex Martelli]

Re: Python syntax in Lisp and Scheme

Kenny Tilton wrote:
...[color=blue][color=green]
>> Doug Tolton <doug@nospam.co m> wrote previously:
>> |Yes, this discussion is frustrating. It's deeply frustrating to hear
>> |someone without extensive experience with Macros arguing why they are
>> |so destructive.[/color][/color]
...[color=blue]
> Hey! No pulling rank! :) Actually, I think we heard Mr. Martelli say
> something along these lines at one point, tho I grok that he does know
> his stuff. As for having "a better understanding", hmmm, check your
> lotus, I think you'll find something in there about Beginner's Mind.[/color]

Doug was not talking about understanding, but experience. I've had
such experience -- perhaps not "extensive" enough for him? -- and I
have personally experienced and suffered the problems.

[color=blue]
> Alex reports his experience of The Divergence Problem and blames macros.
> Hell, I worked in Tall Buildings for years. I saw Divergence,
> Convergence, /and/ the dread Regurgitation Problems everywhere I went.
> No macros, tho, just groups of programmers.
>
> So I think the groups are the problem.[/color]

I never claimed that without macros there would be no possible problems
whatsoever. Human biology guarantees that such sociological problems
remain possible. However, technology aspects, as well as cultural ones,
can either ameliorate or exacerbate the issues. Python's overall culture
of consensus and simplicity matters: at a BOF as OSCON, somebody was
asking "...so I don't know if I should just do the simple thing here or
rather do something clever..." and the audience immediately gave their
feedback -- if you think of it as "something clever", _don't do it_.
(Not in production code, not in code that you AND more relevantly many
others will have to maintain, enhance, and change for years to come).

Are you familiar with the "JAPH" idea, those bazillion clever ways that
Perl programmers have dreamed up to emit the string "just another perl
hacker" in delightfully contorted ways? Well, somebody once asked how
a Pythonista would go about it -- and the answer was unanimous:
print "Just another Python hacker"
Sure, this will get you no kudos for cleverness, but the point is that
cleverness does NOT garner kudos among Pythonistas. Simplicity, clarity,
explicitness, directness -- these are the community's core values. Do
we all always live by them? No way -- we're not saints, just practical
guys trying to get our jobs done -- and perhaps make the world a little
better along the way.

Technological aspects interplay with the cultural ones. Again speaking
in terms of ideals and targets, I quote Antoine de Saint-Exupery:
"La perfection est atteinte non quand il ne reste rien à ajouter, mais
quand il ne reste rien à enlever." (perfection is achieved not when
nothing is left to add, but when nothing is left to take away). Now,
since "practicali ty beats purity", one doesn't (e.g.) remove 'if' just
because it can reasonably be substituted by 'while' -- we're not talking,
in fact, about truly minimalist practice. But the only apparently
irreducible use of macros would appear to be in (some form of) code
that "reasons about itself" (not just by simple reflection and
introspection, quite easy to achieve without macros, but in that
"with-condition-maintained" example which was apparently [or allegedly]
able to analyze and modify reactor-control code to affect the reactor's
temperature limits). Do I need or want such exoterica in the kind of
code that I am interested in writing, and helping others write? No way:
such "creative", deep merging of discourse and meta-discourse does not
appear to be at all necessary in these endeavours -- and if it not
strictly necessary, I would MUCH rather use a simpler, lighter-weight
tool that does not support it. When I need to modify (e.g.) some
class's constructor at runtime, I can do it by such blazingly obvious
code as
someclass.__new __ = staticmethod(co structor_implem entation)
though the Lisp'er originally proposing such needs, in an attempt to
show how complicated Python's approach was, used a hugely messy call to
type.__setattr_ _ with a weirdly and unjustifiably long lambda in it.

Won't fly, friends. We're simple, down-to-earth folks, doing simple,
down-to-earth things. I suspect some kind of 10/90 rules apply: our
simple tools may be barely 10% of what CL has got, but they cover the
needs arising in 90% of applications. (Maybe it's 15/85 or whatever:
no, I don't have scientific studies in the matter to quote so you
can exert your ingenuity at shooting them down:-). When we need to
process some specialized language we may use roughly-traditional parser
technology, keeping language and meta-language separated, rather than
embed and entwine them inside each other.

My perhaps-not-extensive-enough experience with macros showed them
being used to merge language and meta-language -- in widely different
ways in different labs or even within a given lab -- while at the
same time other firms were using languages without macros (APL and
variants thereof) and processing them with different and separate
metalanguages AND thereby managing to achieve better (intra-firm, at
least) cooperation. As "adventures in programming", those glorious
lisp-dialects-cum-hardware-description-languages-inside-them were,
no doubt, a hoot. For somebody looking for a more productive way to
design chips, and particularly to foster cooperation in this design
task, they looked (and in retrospect still look) sub-optimal to me.

The macros ended up being used to bend and stretch the general
purpose language to express specialized issues (about hardware design,
in that case) which it was not optimally suited to express -- and
since it WAS a case of bending and stretching, it was inevitable that
each different lab and faction would stretch and bend in divergent
directions. The computer-scientists in question were no doubt happy
as larks with their toys and in some cases their shiny new lisp
machines (I think TI ended up making a LM of their own a bit later,
but that was after my time); us engineers weren't _quite_ as happy,
though. And the chips didn't get designed as well, nor as fast...


Alex

[Marco Antoniotti]

Re: Python syntax in Lisp and Scheme



Alex Martelli wrote:
[color=blue]
> Kenny Tilton wrote:
>[/color]
.....[color=blue]
>
> The very 'feature' that was touted by Erann Gat as macros' killer advantage
> in the WITH-CONDITION-MAINTAINED example he posted is the crucial
> difference: functions (HO or not) and classes only group some existing code
> and data; macros can generate new code based on examining, and presumably to
> some level *understanding* , a LOT of very deep things about the code
> arguments they're given. If all you do with your macros is what you could
> do with HOF's, it's silly to have macros in addition to HOF's -- just
> MTOWTDItis encouraging multiple different approaches to solve any given
> problem -- this, of course, in turn breeds divergence when compared to a
> situation in which just one approach is encouraged. If you do use the
> potential implied in that example from Gat, to do things that functions and
> classes just couldn't _begin_ to, it's worse -- then you're really
> designing your own private divergent language (which most posters from
> the Lisp camp appear to assert is an unalloyed good, although admittedly
> far from all). This is far from the first time I'm explaining this, btw.[/color]

I am extremely careful to design new macros for my "extensions ". And
when I do so I do it in my specialized packages. Moreover, I am
personally against blindly importing names when you do not actually need to.

This may or may not cause language divergence. It is a social issue
that is rather independent. For example, people forget Greenspun's
Tenth Rule of programming every other day and continue to diverge :)

[color=blue]
>
> Oh, and if you're one of those who disapprove of Gat's example feel free
> to say so, but until I hear a substantial majority denouncing it as idiotic
> (and I haven't seen anywhere near this intensity of disapproval for it from
> your camp) I'm quite justifyied in taking it as THE canonical example of a
> macro doing something that is clearly outside the purview of normal tools
> such as functions and classes. As I recall there was a lot of that going
> on in TI labs, too -- instead of writing and using compilers for hardware
> description languages, circuit simulators, etc, based on appropriate and
> specialized languages processed with the help general-purpose ones,
> the specialized languages (divergent and half-baked) were embedded in
> programs coded in the general-purpose languages (Lisp variants, including
> Scheme; that was in 1980) using macros that were supposed to do
> everything but serve you coffee while you were waiting -- of course when
> the snippets you passed (to represent hardware operation) were correct
> from the GP language viewpoint but outside the limited parts thereof that
> the macros could in fact process significantly down to circuit design &c,
> the error messages you got (if you were lucky enough to get error
> messages rather than just weird behavior) were QUITE interesting.[/color]

What people were doing not too long ago (1998) in a major electronic CAD
company was to develop special intermediate languages to represent some
design modules (we are talking about a not-so-cheap application here).
Guess what. They were using a tabbed format. Going from version 1.0 of
the product to version 2.0 involved writing a complex "migration" tool,
as the previous format would break (not to mention the common place "cut
and paste" errors).

How would you do that today? You would write a XML DTD (or Schema, if
you are so inclined) to achieve the same goal. Now, given that XML is
S-expr in a drag, Greenspun's Tenth applies again.

This has nothing to do with HOF vs Macros etc etc, but it shows that you
are always using some "language design" thingy while you program. After
all, Stroustroup correctly said that "library design" is "language
design". Jumping back to the topic, the bottom line is that you want
both macros and HOFs. If you do not want both you are just reconfirming
Greenspun's Tenth Rule of Programming :)

[color=blue]
>[color=green]
>>One popular macro is WITH-OUTPUT-TO-FILE. My budding RoboCup starter kit
>>was a vital WITH-STD-ATTEMPT macro. Oh god, no! I need to see the ANSI[/color]
>
>
> Do they do things a HOF or class could do? If so why bother using such
> an over-powered tool as macros instead of HOFs or classes? If not, how do
> they specially process and understand code snippets they're passed?[/color]

Because you have them and because they are easier to use than a HOF. If
you have both you can make the best of both. If you miss either, you
have one less tool in your belt. As for the previous examples, you do
not necessarily need to understand the code snippets that are passed to
the macros. Most of the time macros are used as code transformations .
If you use them carefully, then your (Common Lisp) programs get more
succinct and more readable (and, incidentally more efficient, as Common
Lisp can use macros to shortcut the road to the *NATIVE CODE* compiler).
You cannot achieve this effect if you do not have both.

Cheers
--
marco

[Alex Martelli]

Re: Code block literals

Bengt Richter wrote:
...[color=blue]
> This way lambda would only be needed for backwards compatibility, and
> since "def(" is a syntax error now, IWT it could be introduced cleanly.[/color]

In theory, yes, I think it could (and wrt my similar idea with 'do' has
the advantage of not requiring a new keyword). In practice, trying to
hack the syntax to allow it seems a little nightmare. Wanna try your
hand at it? I'm thinking of Grammar/Grammar and Modules/parsermodule.c ...


Alex

[Marco Antoniotti]

Re: Python syntax in Lisp and Scheme


Ok. At this point I feel the need to apoligize to everybody for my
rants and I promise I will do my best to end this thread.

I therefor utter the H-word and hopefully cause this thread to stop.

Cheers
--
marco

[Alex Martelli]

Re: The compiler canard

Lulu of the Lotus-Eaters wrote:
...[color=blue]
> Python never had an "aspiration " of being "just a scripting language",[/color]

Hmmm, at the start it sure seemed like that. Check out

http://www.python.org/search/hypermail/python-1992/0001.html

actually from late '91. By 1991 Guido was already calling Pyhton
"a prototyping language" and "a programming language" (so, the
"just a scripting language" was perhaps only accurate in 1990), but
in late '91 he still wrote:

"""
The one thing that Python definitely does not want to be is a GENERAL
purpose programming language. Its lack of declarations and general laziness
about compile-time checking is definitely aimed at small-to-medium-sized
programs.
"""

Apparently, it took us (collectively speaking) quite a while to realize
that the lack of declarations and compile-time checks aren't really a
handicap for writing larger programs (admittedly, Lispers already knew
it then -- so did I personally, thanks also to experiences with e.g.
Rexx -- but I didn't know of Python then). So, it _is_ historically
interesting to ascertain when the issue of large programs first arose.
[color=blue]
> nor WAS it ever such a thing. From its release, Python was obviously a
> language very well suited to large scale application development (as[/color]

Well, clearly that was anything but obvious to Guido, from the above
quote. Or maybe you mean by "release" the 1.0.0 one, in 1994? At
that time, your contention becomes quite defensible (though I can't
find a Guido quote to support it, maybe I'm just not looking hard
enough), e.g. http://www.python.org/search/hyperma...94q1/0050.html
where Bennett Todd muses
"""
I think Python will outstrip every other language out there, and Python
(extended where necessary in C) will be the next revolutionary programming
tool ... Perl seems (in my experience) to be weak for implementing large
systems, and having them run efficiently and be clear and easy to maintain.
I hope Python will do better.
"""
So, here, the idea or hope that Python "will do better" (at least wrt
Perl) "for implementing large systems" seems already in evidence, though
far from a community consensus yet.


I do find it fascinating that such primary sources are freely available
on the net -- a ball for us amateur historians...!-)



Alex

[Erann Gat]

Re: Python syntax in Lisp and Scheme

In article <Wpyhb.194741$h E5.6583756@news 1.tin.it>, aleax@aleax.it wrote:
[color=blue]
> Björn Lindberg wrote:
> ...[color=green][color=darkred]
> >> Agreed. I pointed out elsewhere that there has been no systematic
> >> study to show that Lisp code is indeed "so much shorter than the
> >> equivalent code in other languages" where "other languages" include
> >> Python, Perl, or Ruby.[/color]
> >
> > It would be interesting to see such studies made.[/color]
>
> Absolutely![/color]

Lutz Prechelt has done a number (at least two that I know of) of such
studies. I did one too: http://www.flownet.com/gat/lisp-java.pdf

E.

[Alex Martelli]

Re: Python syntax in Lisp and Scheme

Pascal Costanza wrote:
[color=blue]
> Matthias wrote:
>[color=green]
>> Why the smiley? Many hours of discussions could be spared if there
>> were real, scientific, solid studies on the benefit of certain
>> language features or languages in certain domains or for certain types
>> of programmers.[/color]
>
> This presumes that language features can be judged in isolation. I think
> it's rather more likely that good programming languages are holistic
> systems, in the sense that the whole language is more than the sum of
> its features.[/color]

....and/or less, if N features are just offering N different ways to
perform essentially the same tasks, of course. Still, be the whole
more or less than "the sum of the parts", one still can't rule out
(as no "hard-scientific studies" are ever likely to exist) such
non-linearities and complications. This, of course, points out that
programming languages are NOT "mathematic s", as some claim -- they
are engineering designs, and interact with human minds, sociology
of groups, cultural and educational features, at least as much as
they interact with the architecture and capabilities of computers.


Alex

[Alex Martelli]

Re: Python syntax in Lisp and Scheme

Edi Weitz wrote:
...[color=blue][color=green][color=darkred]
>> > > I think it's about a single namespace (Scheme, Python, Haskell,
>> > > ...) vs CLisp's dual namespaces. People get used pretty fast
>> > > to having every object (whether callable or not) "first-class"
>> > > -- e.g. sendable as an argument without any need for stropping[/color][/color][/color]
...[color=blue][color=green]
>> He's talking about NAMESPACES. "namespace" occurs twice in his
>> paragraph, while "function" occurs only once, that should have given
>> you a hint.[/color]
>
> Thanks, I think my reading comprehension is quite good. What you said
> doesn't change the fact that Mr. Martelli's wording insinuates that in
> Scheme and Python functions are first-class objects and in Common Lisp[/color]

I put "first class" in quotes and immediately explained what I meant.
[color=blue]
> they're not. For the sake of c.l.p readers who might not know CL I
> think this should be corrected.
>
> * (let ((fn (lambda (x) (* x x))))
> (mapcar fn (list 1 2 3 4 5)))
>
> (1 4 9 16 25)
>
> There you have it. I can create a function, assign it to a variable
> and pass it to another function like any other object, that's what I'd
> call a "first-class object."[/color]

Yes, but:
[color=blue][color=green]
>> Namely, he's saying that people used to write: (mapcar cadr '((a 1)
>> (b 2))) don't like having to write: (mapcar #'cadr '((a 1) (b 2)))
>> in Common-Lisp.[/color]
>
> This old namespace debate only makes me yawn, sorry.[/color]

If so then why jump on assertions related exactly just to that --
namespaces? Re-read my quote above, o you of self-proclaimed "quite
good" reading comprehension: I was trying to explain to Doug Tolton
why many think that Haskell, Scheme or Python "do HOFs better",
while he was claiming that the use of #' if "far clearner" (sic)
because "in lisp with #' it's immediately obvious that you are
receiving or sending a HOF that will potentially alter how the
call operates". I.e., it IS strictly a namespace debate from the
word go. Whether it SHOULD be emphasized with horns and bells
that "warning, HOF coming!!!" -- as Doug claimed -- or not.

If you're bored by debating namespaces, don't jump into a debate
on namespaces -- seems simple common sense (as opposed to
common lisp?)...


Alex

[Jon S. Anthony]

Re: startup time (was: Python syntax in Lisp and Scheme)

Bruce Lewis <brlspam@yahoo. com> writes:
[color=blue]
> j-anthony@rcn.com (Jon S. Anthony) writes:
>[color=green]
> > If your problems are trivial, I suppose the presumed lower startup
> > costs of Python may mark it as a good solution medium.[/color]
>
> I find no significant difference in startup time between python and
> mzscheme.[/color]

Category error. The context (I would have thought) clearly indicated
that "startup costs" concerned the effort needed to use the language!

/Jon

[Pascal Costanza]

Re: Python syntax in Lisp and Scheme

Alex Martelli wrote:
[color=blue]
> Pascal Costanza wrote:
>
>[color=green]
>>Matthias wrote:
>>
>>[color=darkred]
>>>Why the smiley? Many hours of discussions could be spared if there
>>>were real, scientific, solid studies on the benefit of certain
>>>language features or languages in certain domains or for certain types
>>>of programmers.[/color]
>>
>>This presumes that language features can be judged in isolation. I think
>>it's rather more likely that good programming languages are holistic
>>systems, in the sense that the whole language is more than the sum of
>>its features.[/color]
>
>
> ...and/or less, if N features are just offering N different ways to
> perform essentially the same tasks, of course. Still, be the whole
> more or less than "the sum of the parts", one still can't rule out
> (as no "hard-scientific studies" are ever likely to exist) such
> non-linearities and complications. This, of course, points out that
> programming languages are NOT "mathematic s", as some claim -- they
> are engineering designs, and interact with human minds, sociology
> of groups, cultural and educational features, at least as much as
> they interact with the architecture and capabilities of computers.[/color]

I definitely agree. Computer science is more a sociological science than
a natural science IMHO.

Pascal