Python syntax in Lisp and Scheme

[Kenny Tilton]

Matthias wrote:

> Kenny Tilton <ktilton at nyc.rr.com> writes:
> 
> 
>>Pascal Costanza wrote:
>>
>>>>No studies, tho.
>>>
>>>Here they are: http://home.adelphi.edu/sbloch/class/hs/testimonials/
>>
>>Oh, please:
>>
>>"My point is... before I started teaching Scheme, weak students would
>>get overwhelmed by it all and would start a downward spiral. With
>>Scheme, if they just keep plugging along, weak students will have a
>>strong finish. And that's a great feeling for both of us!"
>>
>>That kind of anecdotal crap is meaningless. We need statistics!
>>Preferably with lots of decimal places so we know they are accurate.
>>
>>:)
> 
> 
> Why the smiley?  


Sorry, I was still laughing to myself about that study with the lines of 
code count (and measuring the power of a language by the number of 
machine instructions per line or whatever that was).

> ...Many hours of discussions could be spared if there
> were real, scientific, solid studies on the benefit of certain
> language features or languages...

Studies schmudies. Everyone knows 10% of the people do 90% of the code 
(well it might be 5-95). Go ask them. I think they are all saying (some) 
Lisp and/or Python right now.

  in certain domains or for certain types
> of programmers. 

There's that relativism thing again. I think a good programming language 
will be good for everyone, not some. What many people do not know is 
that Lisp (macros aside!) is just a normal computer language with a 
kazillion things done better, like generic functions and special 
variables to name just two. Norvig himself talked about this, pardon my 
alziness in not scaring up that well-know URL: Python is getting to be a 
lot like Lisp, though again macros forced him into some hand-waving.

>.. It would help get successful languages become
> accepted in slow/big/dump organizations. 

Why you starry-eyed dreamer, you! Yes, here comes the PHB now waving his 
copy of Software Engineering Quarterly.

  It would point language
> designers in the right directions. Project leaders could replace
> trail-and-error by more efficient search techniques.  (Assuming for a
> second, programmers or managers would make rational decisions when
> choosing a programming language and having available trustworthy
> data.)

Careful, any more of that and the MIB will come get you and send you 
back to the planet you came from.

> 
> I imagine such studies are quite hard to do properly, but having them
> would be useful.

OK, I am smiling again at the first half of that sentence. But there is 
hope. My Cells package naturally exposes the interdependency of program 
state, something Brooks (correctly) identified as a huge problem in 
software engineering, hence his (mistaken) conviction there could be no 
magic bullet.

Now Cells can (and have been to various degrees) been ported to C++, 
Java, and Python. If those ports were done as fully as possible, such 
that they passed the regression tests used on the Lisp reference 
implementation, we could then measure productivity, because (I am 
guessing) the internal state dependencies will serve quite nicely as a 
measure of "how much" program got written by a team, one which could be 
used to compare intelligently the productivity on different projects in 
different languages. (You can't have the same team do the same project, 
and you can't use two different teams, for obvious reasons.)

kenny


-- 
http://tilton-technology.com
What?! You are a newbie and you haven't answered my:
  http://alu.cliki.net/The%20Road%20to%20Lisp%20Survey