Python syntax in Lisp and Scheme

[Rainer Joswig]

Re: Python syntax in Lisp and Scheme

In article <m3r81no4bq.fsf @javamonkey.com >,
Peter Seibel <peter@javamonk ey.com> wrote:
[color=blue]
> Rainer Joswig <joswig@lispmac hine.de> writes:
>[color=green]
> > In article <6CZgb.3273$dn6 .860@newsread4. news.pas.earthl ink.net>,
> > "Andrew Dalke" <adalke@mindspr ing.com> wrote:
> >
> > snip
> >[color=darkred]
> > > And here's Table 31-2
> > >
> > > Statements per
> > > Language Level Function Point
> > > -------- ----- --------------
> > > Assembler 1 320
> > > Ada 83 4.5 70
> > > AWK 15 25
> > > C 2.5 125
> > > C++ 6.5 50
> > > Cobol (ANSI 85) 3.5 90
> > > dBase IV 9 35
> > > spreadsheets ~50 6
> > > Focus 8 40
> > > Fortran 77 3 110
> > > GW Basic 3.25 100
> > > Lisp 5 65
> > > Macro assembler 1.5 215
> > > Modula 2 4 80
> > > Oracle 8 40
> > > Paradox 9 35
> > > Pascal 3.5 90
> > > Perl 15 25
> > > Quick Basic 3 5.5 60
> > > SAS, SPSS, etc. 10 30
> > > Smalltalk (80 & V) 15 20
> > > Sybase 8 40
> > > Visual Basic 3 10 30
> > >
> > > Source: Adapted from data in 'Programming Languages
> > > Table' (Jones 1995a)[/color]
> >
> > I thought these numbers were bogus. Weren't many of them just
> > guesses with actually zero data or methodology behind them???[/color]
>
> Well, here are some other interesting entries (from the table on p.89
> of Jones's _Applied Software Measurement_):
>
> Language Level Function Point
> -------- ----- --------------
> CLOS 12.0 27
> KSH 12.0 27
> PERL 12.0 27 [it had 27, while the the other table had 25]
> MAKE 15.0 21
>
> I'm not sure what to make of CLOS being separate from Common Lisp, but
> there it is. But it's sort of moot because by this measure, MAKE is a
> higher level language than either Lisp, Perl, or C++. Personally, I
> think I'll be looking for another metric.
>
> -Peter[/color]

Just look at this:

http://www.theadvisors.com/langcomparison.htm

And read:

The languages and levels in Table 2 were gathered in four ways.

* Counting Function Points and Source Code
* Counting Source Code
* Inspecting Source Code
* Researching Languages

and

Researching Languages

Research was done by reading descriptions and genealogies
of languages and making an educated guess as to their levels. KL,
CLOS, TWAICE, and FASBOL are examples of languages that were
assigned tentative levels merely from descriptions of the
language, rather than from actual counts.

Well, I guess CLOS is, ... about, say, hmm, scratching my head, hmm,
let's say 73.

Right?

Let's say it differently, the comparison is a BAD joke.

[Pascal Costanza]

Re: Python syntax in Lisp and Scheme

Christopher C. Stacy wrote:
[color=blue]
> JAVA has multi-methods with non-congruent arglist.
> (It doesn't have multiple inheritence, but that doesn't
> matter to dynamic type dispatching, except maybe in how
> you implement searching your handler tables.) In JAVA,
> the correspondance of the "signature" of the function call
> and the method definition are what's important;
> and there are no restricting "generic functions".
>
> public class RandomAccessFil e extends Object,implemen ts DataOutput {
> public void write(byte[] b) throws IOException;
> public void write(byte[] b, int off, int len) throws IOException;
> ...
> }[/color]

Maybe this is just a terminological issue, but in my book these are not
multi-methods. In Java, methods with the same name but different
signatures are selected at compile time, and this is rather like having
the parameter types as part of the method name.

This can lead to subtle bugs. Here is an example in Java:

public class test {

static void m(Object o) {
System.out.prin tln("m/Object");
}

static void m(String s) {
System.out.prin tln("m/String");
}

static void n(Object o) {
m(o);
}

public static void main(String[] args) {
n("test");
}

}

This prints "m/Object", instead of "m/String" as you might expect. (This
is one of the reasons why the Visitor pattern is relatively tedious to
implement in Java.)


Pascal

[David Rush]

Re: Python syntax in Lisp and Scheme

On 08 Oct 2003 22:17:48 +0200, Pascal Bourguignon[color=blue]
> Alexander Schmolck <a.schmolck@gmx .net> writes:[color=green]
>> And the blanket claim that Japanese spelling in kana is badly designed
>> compared to say, English orthography seems really rather dubious to me.[/color]
> I was criticising the graphical aspect on a discrimination stand-point.
>
> For example, the difference between the latin glyphs for "ka" and "ga"
> is bigger than that between the corresponding kana glyphs.[/color]

But the actual pronunciation difference (consonantal vocalization) is far
closer to the graphical difference in kana.
[color=blue]
> But it does not matter since the topic was kanji...[/color]

But Kanji are not, and no-one has ever even remotely claimed that Kanji
are phonetic. In fact their main advantage is that they are *not* phonetic.
They were made that way by the Chinese so that all parts of the empire
could communicate even though they spoke widely varying dialects.

david rush
--
(\x.(x x) \x.(x x)) -> (s i i (s i i))
-- aki helin (on comp.lang.schem e)

[Andrew Dalke]

Re: Python syntax in Lisp and Scheme

Peter Seibel:[color=blue]
> PERL 12.0 27 [it had 27, while the the other table[/color]
had 25]

I double checked. McConnell lists "25".
[color=blue]
> MAKE 15.0 21
>
> I'm not sure what to make of CLOS being separate from Common Lisp, but
> there it is. But it's sort of moot because by this measure, MAKE is a
> higher level language than either Lisp, Perl, or C++. Personally, I
> think I'll be looking for another metric.[/color]

McConnell said that if you *could* do it in a given higher level
language then you should. Eg, spreadsheets are listed as a very
high level language, but you wouldn't write a word processor
in one.

I don't know the background behind the paper you referenced.
I suspect is has the same qualifier. If so, it's quite true that
using make for its domain is more appropriate than a more general
general purpose language.

Andrew
dalke@dalkescie ntific.com

[Christopher C. Stacy]

Re: Python syntax in Lisp and Scheme

>>>>> On Wed, 08 Oct 2003 16:51:44 -0400, Joe Marshall ("Joe") writes:
Joe> "Carlo v. Dango" <oest@soetu.e u> writes:
[color=blue][color=green]
>> method overloading,[/color][/color]

Joe> Now I'm *really* confused. I thought method overloading involved
Joe> having a method do something different depending on the type of
Joe> arguments presented to it. CLOS certainly does that.

He probably means "operator overloading" -- in languages where
there is a difference between built-in operators and functions,
their OOP features let them put methods on things like "+".

Lisp doesn't let you do that, because it turns out to be a bad idea.
When you go reading someone's program, what you really want is for
the standard operators to be doing the standard and completely
understood thing. Most commonly, the operators that people in C++
like to overload are the mathematical ones, like "*" and "+".
Lisp has carefully defined those operations to do all the things
that are both well-understood (like complex numbers) and missing
from languages like C++. And in Lisp if you want to do some
other kind of arithmetic, you must make up your names for those
operators. This is considered to be a good feature.

Not surprisingly, the designers of JAVA understood this as well:
JAVA doesn't let you overload operators, either.

[Bengt Richter]

Re: Python syntax in Lisp and Scheme

On Wed, 08 Oct 2003 16:41:44 -0400, Joe Marshall <jrm@ccs.neu.ed u> wrote:
[color=blue]
>David Rush <drush@aol.ne t> writes:
>[color=green]
>> You know I think that this thread has so far set a comp.lang.* record
>> for civilitiy in the face of a massively cross-posted language
>> comparison thread. I was even wondering if it was going to die a quiet
>> death, too.
>>
>> Ah well, We all knew it was too good to last. Have at it, lads!
>>
>> Common Lisp is an ugly language that is impossible to understand with
>> crufty semantics
>>
>> Scheme is only used by ivory-tower academics and is irerelevant to
>> real world programming
>>
>> Python is a religion that worships at the feet of Guido vanRossum
>> combining the syntactic flaws of lisp with a bad case of feeping
>> creaturisms taken from languages more civilized than itself
>>
>> There. Is everyone pissed off now?[/color]
>
>No, that seems about right.[/color]
LOL ;-)

Regards,
Bengt Richter

[Andrew Dalke]

Re: Python syntax in Lisp and Scheme


Rainer Joswig[color=blue][color=green]
> > I thought these numbers were bogus. Weren't many
> > of them just guesses with actually zero data
> > or methodology behind them???[/color][/color]

Pascal Costanza[color=blue]
> Apart from that, what does the author mean by "Lisp"? Is it Common Lisp
> or some other Lisp dialect? Scheme?[/color]

As I mentioned, I don't have the primary sources, so I can't
give any more information about the data.

In general, there are very few methodological studies on the
effectiveness of different languages on general purpose
programming problems when used by sets of people with
roughly comparable experience. The only other one I have
is Prechelt's "An empirical comparison ..."

http://www.ipd.uka.de/~prechelt/Biblio/

with the followup of Java v. Lisp at

http://www.flownet.com/gat/papers/lisp-java.pdf

That data also suggests that Tcl/Perl/Python/Lisp development time
is comparable.
[color=blue]
> According to this table, Modula-2 and Lisp are in the same league - I
> have used both languages, and this just doesn't align with my experience.[/color]

Good thing I didn't try to skew the data by leaving that out. ;)
[color=blue]
> Furthermore, CLOS can be regarded as a superset of Smalltalk. How can it
> be that Smalltalk is more than three times better than Lisp? Even if you
> take Scheme that doesn't come with an object system out of the box, you
> can usually add one that is at least as powerful as Smalltalk. Or did
> they add the LOC of infrastructure libraries to their results?[/color]

Again, I don't have the primary source.

Andrew
dalke@dalkescie ntific.com

[Andrew Dalke]

Re: Python syntax in Lisp and Scheme

Pascal Bourguignon:[color=blue]
> Some differences in this table look suspect to me. Perhaps they did
> not take into account other important factors, such as the use of
> libraries.[/color]

Anyone here know more about the original reference?
[color=blue]
> For example, when I write awk code, I really don't feel like I'm
> programming in a higher level languange than LISP... (and I won't
> mention perl).[/color]

The specific definition of "higher level language" is the number
of assembly instructions replaced. Eg, spreadsheets are in that
table despite not being a good general purpose programming
language.

I also suspect the numbers were taken from the analysis
of existing programs, and people would have used awk
for cases where it was appropriate.
[color=blue]
> Also, the ordering of Fortran vs. C fell strange (given the libraries
> I use in C and the fact that I don't use Fortran).[/color]

Hmm... You don't do scientific programming, do you. ;)

Andrew
dalke@dalkescie ntific.com

[Karl A. Krueger]

Re: Python syntax in Lisp and Scheme

In comp.lang.lisp David Rush <drush@aol.ne t> wrote:[color=blue]
> Ah well, We all knew it was too good to last. Have at it, lads!
>
> Common Lisp is an ugly language that is impossible to understand with
> crufty semantics
>
> Scheme is only used by ivory-tower academics and is irerelevant to real
> world programming
>
> Python is a religion that worships at the feet of Guido vanRossum
> combining the syntactic flaws of lisp with a bad case of feeping
> creaturisms taken from languages more civilized than itself
>
> There. Is everyone pissed off now?[/color]

This seems like a good juncture to post my list of common myths and
misconceptions about popular programming languages. Contributions are
welcome; flames only if they're funny. Anyone who needs to see :) on
things to know they're meant in jest should stop reading now.


== Programming Language Myths ==

BASIC Myth: People who learn BASIC go on to learn other languages.
Reality: Most people who learn BASIC go on to find less nerdy ways of
writing "Mr. Gzabowski is a lame teacher" over and over again.

C Myth: C programs are insecure, full of buffer overflows and such.
Reality: C programs are only insecure if written by imperfect programmers.
Since all C programmers know that they are perfect, there's no
problem.

COBOL Myth: COBOL is dead.
Reality: It stalks from out the ancient vaults of death, its putrid mind
drawn to the blood of the living.

Forth Myth: Forth makes no sense.
Reality: backwards. think to have just you sense, perfect makes Forth

Java Myth: You need Java to do business applications.
Reality: You need Java to get a job.

Lisp Myth: Lisp is an interpreted language.
Reality: Lisp is COMPILED DAMMIT COMPILED! IT'S IN THE FUCKING STANDARD!!!

Pascal Myth: Pascal is a toy.
Reality: Oh, wait, that is not a myth, it is true ...

Perl Myth: Perl is impossible to read.
Reality: You are not taking enough psychedelics.

Python Myth: Python's only problem is the whitespace thing.
Reality: Python's only problem is that it is fucking slow.

--
Karl A. Krueger <kkrueger@examp le.edu>
Woods Hole Oceanographic Institution
Email address is spamtrapped. s/example/whoi/
"Outlook not so good." -- Magic 8-Ball Software Reviews

[Erann Gat]

Re: Python syntax in Lisp and Scheme


In article <bm20rh$2t$1@ne wsreader2.netco logne.de>, Pascal Costanza
<costanza@web.d e> wrote:
[color=blue]
> Christopher C. Stacy wrote:
>[color=green]
> > JAVA has multi-methods with non-congruent arglist.
> > (It doesn't have multiple inheritence, but that doesn't
> > matter to dynamic type dispatching, except maybe in how
> > you implement searching your handler tables.) In JAVA,
> > the correspondance of the "signature" of the function call
> > and the method definition are what's important;
> > and there are no restricting "generic functions".
> >
> > public class RandomAccessFil e extends Object,implemen ts DataOutput {
> > public void write(byte[] b) throws IOException;
> > public void write(byte[] b, int off, int len) throws IOException;
> > ...
> > }[/color]
>
> Maybe this is just a terminological issue, but in my book these are not
> multi-methods. In Java, methods with the same name but different
> signatures are selected at compile time,[/color]

When the selection is done is immaterial. The point is that it's done at
all. There's no reason why the same algorithm that is used to select
methods at compile time can't also be used to select methods at run time.
The claim that congruent argument lists are necessary for multi-method
dispatch is clearly false.
[color=blue]
> and this is rather like having
> the parameter types as part of the method name.[/color]

No. It's the "system" keeping track of the types, not the user. That's
the key. The fact that C++ and Java just happen to do it at compile time
rather than at run time is a red herring.
[color=blue]
>
> This can lead to subtle bugs. Here is an example in Java:[/color]

These "subtle bugs" are a reflection of the limitation of compile-time
type inference in Java, not a limitation of multi-method dispatch with
non-congruent argument lists.

E.

[Mike Rovner]

Re: Code block literals

Dave Benjamin wrote:[color=blue]
> Dave Benjamin wrote:
>[color=green][color=darkred]
>> >>> print mylist.map({ |x| return x + 2 }, range(5))[/color]
>> 0, 2, 4, 6, 8[/color]
>
> Duh... sorry, that should read:
> print range(5).map({ |x| return x + 2 })[/color]

I either case it will be [2, 3, 4, 5, 6] :)

Instead of lambda use list comprehensions:

print [x+2 for x in range(5)]

Unnamed code blocks considered evil :), use named instead (functions).

With nested scopes you can do amazing things. I myself was used to code
blocks due to perl background, but python idiom are not worse to say the
least.
For example:

class C(object):
...
def aprop():
def reader(self): return 0
def writer(self,new val): pass
return reader, writer
aprop=property( aprop())


Mike

[Dave Benjamin]

Re: Python syntax in Lisp and Scheme

Karl A. Krueger wrote:
[color=blue]
> This seems like a good juncture to post my list of common myths and
> misconceptions about popular programming languages. Contributions are
> welcome; flames only if they're funny. Anyone who needs to see :) on
> things to know they're meant in jest should stop reading now.[/color]

Haha... that's really funny... except the last one. Not that I'm a
Python purist (a big fan, yes, but not a purist), but I rarely complain
about its slowness. Java is too easy of a target for that one... =)

Python Myth: Python's only problem is the whitespace thing.
Reality: Python's only problem is that it is not Common Lisp.

How about that?

Dave

[Edi Weitz]

Re: Python syntax in Lisp and Scheme

On Wed, 08 Oct 2003 23:05:28 GMT, Dave Benjamin <dave@3dex.co m> wrote:
[color=blue]
> Python Myth: Python's only problem is the whitespace thing.
> Reality: Python's only problem is that it is not Common Lisp.
>
> How about that?[/color]

A good one... :)

Edi.

[prunesquallor@comcast.net]

Re: Python syntax in Lisp and Scheme

"Andrew Dalke" <adalke@mindspr ing.com> writes:
[color=blue]
> Marco Antoniotti:[color=green]
>> Come on. Haskell has a nice type system. Python is an application of
>> Greespun's Tenth Rule of programming.[/color]
>
> Oh? Where's the "bug-ridden" part? :)
>
> That assertion also ignores the influence of user studies (yes,
> research into how the syntax of a language affects its readabilty
> and understandabili ty) on Python's development; a topic which
> is for the most part ignored in Lisp.[/color]

For some reason people who don't like fully parenthesized polish
notation seem to think that Lisp hackers don't know any better,
haven't seen anything else, and that if we were only shown the light,
we'd switch in an instant.

Allow me to point out that `standard algabraic notation' has been
available in Lisp for 40 years. McCarthy designed M-expressions for
Lisp in 1962 (if not earlier) and the Lisp 1.5 manual is written using
them.

Vaughn Pratt's CGOL (which I mentioned before) was written in 1977.

Dylan adopted an algabraic syntax sometime in the late 80's

In every one of these cases, algabraic syntax never quite caught on.

So either the syntax doesn't make a whole hell of a lot of difference
in readability, or readability doesn't make a whole hell of a lot of
difference in utility.

[Robin Becker]

Re: Python syntax in Lisp and Scheme

In article <h6Ygb.186263$h E5.6269806@news 1.tin.it>, Alex Martelli
<aleax@aleax.it > writes
......[color=blue]
>So, I hope the cultural difference is sharply clear. To us, consensus
>is culturally important, we are keen to ensure we all keep using the
>same language; *you* would be happier if you could use a language that
>is different from those of others, thanks to syntax extensions you
>write yourself. Since I consider programming to be mainly a group
>activity, and the ability to flow smoothly between several groups to
>be quite an important one, I'm hardly likely to appreciate the divergence
>in dialects encouraged by such possibilities, am I?
>[/color]
.......
I'm fairly sure I agree with the central point. Average programming
should be understandable by a large population ie concensus.

However, I don't think that the comprehensibili ty argument is reasonable
against the far corners of a language.

I know that that that that that boy said is OK. There are deep corners
even in English.

Perhaps a truly expressive programming language should be allowed to
express truths about itself.

This statement is false. This language is inconsistent. Let's do Geo.
Bool and have no far corners. No sir!
[color=blue]
>Alex
>[/color]

--
Robin Becker