Python any good?
Patrick Useldinger
I am an experienced programmer, but completely new to OO. After looking at
the various websites, comparisons and quite some books, I'd prefer to use
Python as a programming language to start experiencing OO.
As I am unable to tell whether it is really suitable from the OO point of
view, I am interested in your opinion. Is this a suitable language for OO,
is there anything important missing?
BTW, I as this question as there seems no FAQ to be available...
-Patrick
--
email: 'dXNlbHBhQG15cmVhbGJveC5jb20=\n'.decode('base64')
Tim Ottinger
> Hello,
>
> I am an experienced programmer, but completely new to OO. After looking at
> the various websites, comparisons and quite some books, I'd prefer to use
> Python as a programming language to start experiencing OO.
>
> As I am unable to tell whether it is really suitable from the OO point of
> view, I am interested in your opinion. Is this a suitable language for OO,
> is there anything important missing?
>
> BTW, I as this question as there seems no FAQ to be available...
It is very good. You can do almost anything with it, the syntax is
(mostly) very simple, and it supports polymorphism with or without
inheritance (dynamic typing! Yay!), it has encapsulation into classes
(if you don't consider that to mean "strict data hiding"), it has
message passing, Garbage collection, and a whalloping big collection
of libraries -- standard and third-party. It also has great docs on
the web, and some of the books you get via html are better than the
best you can find for other languages at USD$50.00 per or worse.It
even has good tutorials.
As for easing into OO, it's got plenty of data structures and handy
tools and idioms to help you get a lot done, even without creating
new classes for your self. The libraries tend to be sane.
It also performs "well enough" for most of what you want to do.
If you're on windows, I recommend getting ActiveState's distro. Nice
debugger and editor (I prefer vim) and COM libraries included. For
GUI I recommend WxPython currently. I may go to AnyGui when it matures.
Enjoy!
Glen
Patrick Useldinger wrote:
Python is very very good.
In fact the only downside to python is that not many people use python!
This reminds me of a qoute about chess:
"
Its been said that 'Lifes too short for chess'.
This is not a flaw with chess but rather a flaw with life!
"
Also, Python is not fast. It is meant to be a high level language for
non-speed critical applications and scripts.
Glen.
Carl Caulkett
wrote:
>Hello,
>
>I am an experienced programmer, but completely new to OO. After looking at
>the various websites, comparisons and quite some books, I'd prefer to use
>Python as a programming language to start experiencing OO.
>
>As I am unable to tell whether it is really suitable from the OO point of
>view, I am interested in your opinion. Is this a suitable language for OO,
>is there anything important missing?
>
>BTW, I as this question as there seems no FAQ to be available...
Hi Patrick,
Tim has already given a good explanation as to why Python is an
excellent choice for learning OOP. I'd just like to add that there is
some very tutorial material available at http://www.python.org.
You may also find some useful links in the Python section at
http://www.cetus-links.org/.
Lastly, you should check out the comp.lang.python newsgroup which is
frequented by some very helpful and knowledgable Python experts who
seem to be happy to spend time helping newcomers.
--
Cheers,
Carl
JXStern
>view, I am interested in your opinion. Is this a suitable language for OO,
>is there anything important missing?
Good for OO, BUT it lacks declarations, so you are subject to many
typos.
J.
David Jaquay
> Hello,
>
> I am an experienced programmer, but completely new to OO. After looking at
> the various websites, comparisons and quite some books, I'd prefer to use
> Python as a programming language to start experiencing OO.
>
> As I am unable to tell whether it is really suitable from the OO point of
> view, I am interested in your opinion. Is this a suitable language for OO,
> is there anything important missing?
I've been in C++ and/or Java for maybe 10 years, and Python for the
past year. I certainly like it as an OO language. Bruce Eckel,
author of Thinking in C++ and Thinking in Java is now at work on
Thinking in Python, if that sways your opinion any (see
www.bruceeckel.com for more details on that).
The other side of the coin is that Python is loosely typed. One
consequence of this is that you won't be getting any enforcement of
(or in some cases, need for) interfaces as you would in Java or C++.
It also lets you break the rules in terms of public/private access,
should you so desire, but then there are ways to do bad stuff in
Java/C++ as well. But you can do encapsulation, polymorphism and
inheritance, though, covering the OO fundamentals nicely.
IMHO it's a great language for getting your feet wet with OO
programming.
Dave
Phil Tomson
>Hello,
>
>I am an experienced programmer, but completely new to OO. After looking at
>the various websites, comparisons and quite some books, I'd prefer to use
>Python as a programming language to start experiencing OO.
>
>As I am unable to tell whether it is really suitable from the OO point of
>view, I am interested in your opinion. Is this a suitable language for OO,
>is there anything important missing?
>
You should also look into Ruby:
http://www.ruby-lang.org
http://www.rubycentral.com (Programming Ruby book is available here)
Phil
Davor Cengija
> Hello,
>
> I am an experienced programmer, but completely new to OO. After looking at
> the various websites, comparisons and quite some books, I'd prefer to use
> Python as a programming language to start experiencing OO.
>
> As I am unable to tell whether it is really suitable from the OO point of
> view, I am interested in your opinion. Is this a suitable language for OO,
> is there anything important missing?
>
Besides Python, people like Ruby as a good OO language, you might want to
try it, www.ruby-lang.org. But Python is a good choice, as well.
--
Davor Cengija, dcengija...@inet.hr
N D Efford
> In fact the only downside to python is that not many people use python!
A lot of people use it: enough for O'Reilly to have published seven
Python books, anyway - eight if you count the one on Jython.
But if you mean that Python has lived in the shadow of languages like
Perl for a long while, I wouldn't disagree with you.
However, that is changing. Companies like Industrial Light & Magic
and Google are coming clean about the importance of Python to
their work; a number of computer games developers are turning to
Python to write the scripting and high-level code for their products;
etc etc...
> Also, Python is not fast. It is meant to be a high level language for
> non-speed critical applications and scripts.
True. The language developers have always held qualities such
elegance, clarity and ease of maintenance of code in higher
esteem than sheer performance.
Nick
Kaz Kylheku
It takes extra typing to write declarations. On top of that, mandatory
declarations lead to an explosion of code. Dynamically typed programs
are usually much smaller. Less typing, fewer typos.
After the dust is settled and typos are fixed, a good Python
programmer can lay to waste probably some five good Java programmers,
and ten good C++ ones---including ones who are also good Python
programmers like him or her.
Kaz Kylheku
> Also, Python is not fast. It is meant to be a high level language for
> non-speed critical applications and scripts.
Python is basically a terrible syntactic interface to a subset of the
semantics of a language resembling Lisp. It has no ANSI standard, and
only one poorly optimized implementation.
Python syntax is fractured in a Fortran like way: some things are
expressions, some are statements. This leads to bizarre restrictions,
like not being able to write a statement where an expression is
expected.
There is no representation of Python source code a a Python data
structure which would give rise to macro programming; consequently,
the ability to define abstractions is severely limited.
As far as performance is concerned, Lisp has a good number of
implementations that have optimizing, native compilers. A few compile
by translating to C and using a C compiler. A few compile to bytecode.
Corman Lisp compiles *everything* it reads to 80x86 code, and executes
only that---it contains no interpreter whatsoever. Its EVAL function
compiles, then branches to the machine code. So much for the
``interpreted language'' myth.
There is an ANSI standard to which the vendors try to conform. Though
you can use it as a scripting language, it's meant for real software
development at any level, with the possible exception of fitting a
full implementation of the language into a tiny embedded system.
If you want bad syntax for it, you can write your own parser: you can
make it indentation sensitive and all, allowing you to express your
semantics in a notation resembling Python, while preserving your
freedom to choose any one of the mature, optimized implementations
underneath.
It's possible for a Lisp program to define a custom lexical analyzer
and parser, which is applied to specially delimited parts of its own
source code, and this can be done in a completely ANSI conforming way.
The custom parsing can do anything whatsoever: basically a function is
called, and it gets a stream object from which characters can be read.
Whatever object it returns becomes a piece of source code that is put
into the program in place of the construct.
Here is a Lisp and Python comparison page:
http://www.norvig.com/python-lisp.html
Tim Ottinger
"Not fast" is always one of those terms that I worry about.
Is python "not fast" becuse it uses a virtual machine? Let's not wind up
the Java, Smalltalk, etc. guys here and have that discussion. Or lets,
and see what conclusions we have.
Is it "not fast" because it has GC? Let's wind up the Java, Smalltalk,
Ruby, and the C++ GC guys on that one and let them roll. Having GC and
an interpreter doesn't mean that adding numbers will take 1/20ths of
seconds.
Certainly there are ways to do things that are not fast. The guys who
work on the core are always finding more efficient ways to do things,
and writing them into the interpreter (why is smalltalk so fast? Same
reason -- the environment becomes faster). A lot of performance talk on
the python ngs is correcting naively slow ways of doing things.
What do you need to go fast? It has a profiler which works quite well.
I found that I'd once written a python program that was clearly not fast
(not fast enough), ran the profiler, and then fixed the stupid mistake I
made. I had a huge loop hidden in a function, and it had a huge
temporary data structure. Duh. And that function was being called on
almost every string that I outputted -- Double-duh. It should have been
obvious, but I was concentrating on getting the desired effect. That's
how those things are. I fixed it in about 5 minutes, and the code was
quite peppy from then on.
Need more than that? there are little boosters like psycho which can
speed things up, and the Parrot guys claim now that they will run Python
faster than Python can. I'm not sure where PyInline is right now, but
that was supposed to make it easy to run modules written in other
languages.
Okay, the problem is partly that interpreters are very
democratic/altruistic, doing the greatest good for the greatest number.
You may have special problems that need special measures. Then you have
the old standbys like Boost and SWIG and the other ways to extend the
interpreter with C or C++.
How fast is fast? What does it take for a language to be considered
fast? Is C++ ever "not fast"?
I just don't want the world thinking that any program written in python
will be too slow for production use. I think that if you look at the
applications in the world that use python, you'll be surprized at how
amazingly well they perform.
Besides, if you have a database, you seldom have to optimize code --
it's almost always the data storage and I/O. <wink> By the way, python
does I/O better all the time, too.
Tim
Justin Farley
>> Good for OO, BUT it lacks declarations, so you are subject to many
>> typos.
>
> It takes extra typing to write declarations.
Irrelevant. Fast typers can type code faster than they can think in any
language... learn to type faster. Readability and maintainability are
what counts.
> On top of that, mandatory
> declarations lead to an explosion of code. Dynamically typed programs
> are usually much smaller.
IDEs for statically-typed languages are able to auto-generate a lot more
code.
> Less typing, fewer typos.
Intellisense/autocompletion, squigly-underlining auto-spellers... I'm
not sure what IDE planet you are living on by suggesting this. I can
only presume you are comparing languages from the perspective of your
favourite text editor.
> After the dust is settled and typos are fixed, a good Python
> programmer can lay to waste probably some five good Java programmers,
> and ten good C++ ones---including ones who are also good Python
> programmers like him or her.
C++ sure. Java/C# with a good IDE, I doubt it. VB.NET/Delphi... no
chance ;-)
More seriously... In general business markets, where you spend a lot of
time re-using a huge variety of pre-written classes, good IDEs with
statically-typed frameworks are far more productive. In niche/academic
markets, you are able/expected to hold all the nescessary linguistics in
your head, and so the productivity is more dependant on that
understanding.
This leads on to the question of whether there is any future for the
"professional software developer". Or whether that role should be
subsumed by the existing professions (medical developer, manufacturing
develper, electrical developer, accounting developer, etc.)? The IT
profession could then be limited to hardware/comms. Scary thought, but
I fear that is the way it should be.
--
Justin
JXStern
wrote:
>> Good for OO, BUT it lacks declarations, so you are subject to many
>> typos.
>
>It takes extra typing to write declarations. On top of that, mandatory
>declarations lead to an explosion of code. Dynamically typed programs
>are usually much smaller. Less typing, fewer typos.
Ridiculous. Not even worth discussing, but if you want to, talk to
Justin, who seems to understand. There is simply no chance of doing
commercial or industrial quality software without declarations.
Period.
>After the dust is settled and typos are fixed, a good Python
>programmer can lay to waste probably some five good Java programmers,
>and ten good C++ ones---including ones who are also good Python
>programmers like him or her.
Again rather as Justin said, within the domain of GUI executables, the
VB development environment makes a VB programmer 2x or more productive
than a VC++ programmer. Avoiding big compiles and builds is the main
difference. However, as Python is totally unsuited for such works,
there is really no point in discussing productivity, plus or minus
compiles.
Just add in optional declarations, Pythoners. I'd do it myself, were
I sufficiently bored. And, I'm not talking lint.
J.
Glen
Tim Ottinger wrote:
>
> I just don't want the world thinking that any program written in python
> will be too slow for production use. I think that if you look at the
> applications in the world that use python, you'll be surprized at how
> amazingly well they perform.
>
>
> Tim
>
Python is great language. There is nothing wrong with it IMHO. As a
bonus it is open source.
Python has many advantages and features: see python.org.
When I say "not fast" I meant no critism.
Maybe I should have said "not for computation intensive problems". Not
as fast as c or c++.
I didn't mean to say it is slow. It is great for most business
applications.
I believe it is possible to write parts of a python app in C++ is
needed. I have never needed to do this.
Also maybe I should have said "less popular than C++" "not as many hits
on monster for python programmers"
Glen. [python programmer]
Glen
Kaz Kylheku wrote:
> Glen <lpep...@nycap.rr.com> wrote in message news:<3E4D71EC...@nycap.rr.com>...
>
>>Also, Python is not fast. It is meant to be a high level language for
>>non-speed critical applications and scripts.
>>
>
> Python is basically a terrible syntactic interface to a subset of the
> semantics of a language resembling Lisp. It has no ANSI standard, and
> only one poorly optimized implementation.
>
This is probably the most misleading thing anyone has said here
excluding Topmind!
Python is open source. There is much less need for a standard for open
source languages. You can get python for unix, windows, or whatever and
they will all be the same because they all are ports of the same open
source software.
Also I have used lisp [in college only] and really lisp and python look
nothing alike.
Last time I checked Lisp wasn't an OOP language-- We are on comp.object
aren't we [not comp.70s-programming].
Glen.
Glen
JXStern wrote:
> On 17 Feb 2003 09:52:58 -0800, k...@ashi.footprints.net (Kaz Kylheku)
> wrote:
>
>>>Good for OO, BUT it lacks declarations, so you are subject to many
>>>typos.
>>>
>>It takes extra typing to write declarations. On top of that, mandatory
>>declarations lead to an explosion of code. Dynamically typed programs
>>are usually much smaller. Less typing, fewer typos.
>>
>
> Ridiculous. Not even worth discussing, but if you want to, talk to
> Justin, who seems to understand. There is simply no chance of doing
> commercial or industrial quality software without declarations.
> Period.
>
J,
I believe you can make python strongly typed if you wish. If your
concerned about a weakness I would ask at the python group to see the
solution. Python is meant for large projects- its not a baby language.
Glen.
Tim Ottinger
> Again rather as Justin said, within the domain of GUI executables, the
> VB development environment makes a VB programmer 2x or more productive
> than a VC++ programmer. Avoiding big compiles and builds is the main
> difference. However, as Python is totally unsuited for such works,
> there is really no point in discussing productivity, plus or minus
> compiles.
Well, then, let's be thankful that there are no major projects using it.
Could you imagine what would happen if Yahoo or Infoseek or (yikes)
Google were based on python? Or what if NASA tried using it! That would
be a nightmare! Or if someone tried to build a major mailing list
manager, even, don't you think the reliability and performance would be
abysmal?
You certainly wouldn't find any commercial organizations using it for
anything important! Not even open-source zealots like Red Hat, right?
Without any declarations, some naive fool might put together something
important, like maybe protein discovery or gene expression with pythan,
and you can bet they'd have trouble, right? Wow. Good thing that
nobody's doing that.
Now, for the odd utility and web script (low performance, naturally) you
might get away with it. But certainly not for large-scale physics codes
on massively parallel supercomputers! For that you *must* have
declarations! Let's give the devil his due.
And of course, companies who have to make a profit would never touch the
stuff. Nobody big like Disney, ILM or their ilk would touch it with a
ten foot pole!
Or maybe they all would: http://www.python.org/psa/Users.html
You know, untyped variables aren't only present in toy languages.
Smalltalk hasn't been a flop either. FWIW, I learned C++ before any
other OOPL, and I do appreciate having my problems showing up as syntax
errors rather than runtime errors, but in time I found out that it's not
that big a deal, since you can test interactively.
A professor once told me that the class of errors that the static typing
catches doesn't really occur that often in the dynamically typed
languages. We're protected from errors we don't tend to make if the
language is simplified. I wonder if everything Ralph told me about
smalltalk is true, too, and why I'm not hacking smalltalk for a living.
After all, the term OO was created to describe a language with strongly
typed objects and untyped variables.
Tim
JXStern
wrote:
>Without any declarations, some naive fool might put together something
>important, like maybe protein discovery or gene expression with pythan,
>and you can bet they'd have trouble, right? Wow. Good thing that
>nobody's doing that.
yeah, i'll go with pythan any day.
J.
Tim Ottinger
:-) Must have been written by Guido's second cousin, Nathan.
Nice catch.
Tim
JXStern
wrote:
>>>Without any declarations, some naive fool might put together something
>>>important, like maybe protein discovery or gene expression with pythan,
>>>and you can bet they'd have trouble, right? Wow. Good thing that
>>>nobody's doing that.
>>
>> yeah, i'll go with pythan any day.
>>
>> J.
>
>:-) Must have been written by Guido's second cousin, Nathan.
>Nice catch.
Just thought it was more concise than listing all the failures and
explosions and idiocies one sees in misused tools and poorly conceived
projects all over the place.
J.
Rainer Joswig
> Last time I checked Lisp wasn't an OOP language-- We are on comp.object
> aren't we [not comp.70s-programming].
Glen, please check again. Since the 70s a lot of thinks
have happend. There might be a few surprises for you.
Rainer
Nils Goesche
> Kaz Kylheku wrote:
>
> > Python is basically a terrible syntactic interface to a subset of
> > the semantics of a language resembling Lisp. It has no ANSI
> > standard, and only one poorly optimized implementation.
>
> Also I have used lisp [in college only] and really lisp and python
> look nothing alike.
Maybe you should look a bit deeper than syntax-level.
> Last time I checked Lisp wasn't an OOP language-- We are on
> comp.object aren't we [not comp.70s-programming].
The first ANSI standard for an object-oriented language was... the
ANSI Common Lisp standard (X3.226-1994).
Regards,
--
Nils Gösche
"Don't ask for whom the <CTRL-G> tolls."
PGP key ID 0x0655CFA0
Kaz Kylheku
Yes, and one of those surprises is that the source code of the latest
release of some implementation no longer defines a language. In this
millennium, we have language standards, to which we can hold even the
open source language impelmentors accountable.
Kaz Kylheku
> aren't we [not comp.70s-programming].
There are people doing object-oriented programming in Lisp who weren't
even born yet the last time you checked. Put on your reading glasses
and do some Googling.
Glen
Kaz Kylheku wrote:
welll sorry!
You could see where I might think someone was pushing a non-oo language
on comp.object because people do it all the time!
Didn't mean to sell your favorite language short.
Glen.
Martijn Faassen
> Glen <lpep...@nycap.rr.com> wrote in message news:<3E4D71EC...@nycap.rr.com>...
>> Also, Python is not fast. It is meant to be a high level language for
>> non-speed critical applications and scripts.
>
> Python is basically a terrible syntactic interface to a subset of the
> semantics of a language resembling Lisp.
A compliment! Any grudging admission that a language resembles Lisp from
a Lisp-head is a compliment. And no non-Lisp head would compare a language
with Lisp that way. :)
> It has no ANSI standard, and only one poorly optimized implementation.
There are two implementations, CPython (often called just plain 'python')
and Jython on top of the JVM. There were also a few aborted efforts in
the past, and a number of them underway now (PyPy, Python on top of Parrot).
There is optimization work being done (Psyco). There is also a mixture of
C and Python called Pyrex.
> Python syntax is fractured in a Fortran like way: some things are
> expressions, some are statements. This leads to bizarre restrictions,
> like not being able to write a statement where an expression is
> expected.
Some people like different semantic concepts to have different syntactic
expression. It can be argued that this leads to an easier time to beginners,
such as in this paper (too much orthogonality can be confusing):
http://www.csse.monash.edu.au/~damian/papers/PDF/SevenDeadlySins.pdf
and can also lead to more readable code as there are more recognizable
idioms. Coming from Lisp however I can see how this would look like a pain. :)
> There is no representation of Python source code a a Python data
> structure which would give rise to macro programming; consequently,
> the ability to define abstractions is severely limited.
Generally other strategies are used. OO abstractions of course, and
metaclasses.
[snip Lisp is cool bits]
> If you want bad syntax for it, you can write your own parser: you can
> make it indentation sensitive and all, allowing you to express your
> semantics in a notation resembling Python, while preserving your
> freedom to choose any one of the mature, optimized implementations
> underneath.
There was some idea years ago in the scheme community to do this with
Guile I believe. Nothing ever materialized as far as I'm aware.
It would be cool though.
Regards,
Martijn
--
History of the 20th Century: WW1, WW2, WW3?
No, WWW -- Could we be going in the right direction?
Martijn Faassen
So you are suggesting nobody should've used Lisp before they standardized
it? (or was it okay last millennium but not anymore suddenly?). Or are
you suggesting no languages should be used that aren't standardized?
How are new languages going to be born then? All like Ada? :)
Or should innovation end here? Or perhaps it should be restricted to the
Lisp community? :)
Anyway, Python does have language standards, though they're probably
more informal than you'd like and not deposited with an official language
body. There are multiple implementations of Python around, after all..
Shayne Wissler
"Martijn Faassen" <m.fa...@vet.uu.nl> wrote in message
news:b37k6r$q4m$1...@newshost.accu.uu.nl...
> Kaz Kylheku <k...@ashi.footprints.net> wrote:
> > Glen <lpep...@nycap.rr.com> wrote in message
news:<3E4D71EC...@nycap.rr.com>...
> >> Also, Python is not fast. It is meant to be a high level language for
> >> non-speed critical applications and scripts.
> >
> > Python is basically a terrible syntactic interface to a subset of the
> > semantics of a language resembling Lisp.
>
> A compliment! Any grudging admission that a language resembles Lisp from
> a Lisp-head is a compliment. And no non-Lisp head would compare a language
> with Lisp that way. :)
What I don't understand is how a Lisper could complain about any language's
syntax!
Shayne Wissler
Patrick May
> What I don't understand is how a Lisper could complain about any
> language's syntax!
Can you suggest a language with a cleaner syntax?
Regards,
Patrick
------------------------------------------------------------------------
S P Engineering, Inc. | The experts in large scale distributed OO
| systems design and implementation.
p...@spe.com | (C++, Java, ObjectStore, Oracle, CORBA, UML)
Shayne Wissler
"Patrick May" <p...@spe.com> wrote in message
news:m3of54q...@localhost.localdomain...
> "Shayne Wissler" <thal...@yahoo.com> writes:
> > What I don't understand is how a Lisper could complain about any
> > language's syntax!
>
> Can you suggest a language with a cleaner syntax?
An ascii dump of machine code comes to mind...
Kaz Kylheku
Easy: he does not find in that other the consistency and convenient
meta-syntactic programming which comprise his day to day Lisp
programming experience.
Dividing a language into statements and expressions is idiocy. You end
up with inconsistencies, like not being able to use a statement
somewhere, because the syntax calls for an expression.
The prefix notation is great, because very long, nested expressions
can be formatted into multiple lines in a way that is consistent, easy
to do even manually, can be learned in minutes, and can be wonderfully
supported by editors.
A large Lisp expression written across multiple lines can be easily
visualized as a sideways tree (similar to a GUI tree control). This is
not possible with infix syntax.
E.g, sideways tree picture:
a +-- b +--- c
| |
| +--- d +--- e
| |
| +--- f
| |
| +---- g
+-- h +--- i
|
+--- j
Lisp expression, same layout:
(a (b c
(d e
f
g))
(h i
j))
Can't do that with infix notations! A few levels of nesting, and you
start having to break it up using the skeleton statement structure,
introducing temporary variables to hold the intermediate results of
what would be subexpressions, etc.
It took me very little training to instantly see the former tree
structure, when looking at the parenthesized expression, and to write
canonically formatted Lisp.
Note that I picked Lisp in 2001 after twenty years of programming in
other languages, all of which have idiotic syntaxes with infix
operators, and statement/expression divides, poor support for
meta-programming, etc.
I'm not someone with a ``Lisp background'' or ``coming from Lisp''.
I'm a C++ developer; that's what pays my mortgage and bills.
Shayne Wissler
"Kaz Kylheku" <k...@ashi.footprints.net> wrote in message
news:cf333042.03022...@posting.google.com...
> > > > Python is basically a terrible syntactic interface to a subset of
the
> > > > semantics of a language resembling Lisp.
> > >
> > > A compliment! Any grudging admission that a language resembles Lisp
from
> > > a Lisp-head is a compliment. And no non-Lisp head would compare a
language
> > > with Lisp that way. :)
> >
> > What I don't understand is how a Lisper could complain about any
language's
> > syntax!
>
> Easy: he does not find in that other the consistency and convenient
> meta-syntactic programming which comprise his day to day Lisp
> programming experience.
It's easy to be self-consistent if you stick with the simplistic. The other
languages are trying to do more for the programmer (too bad most don't do as
much as lisp "under the hood").
My guess is that even though you prefer the lisp syntax, you're going to
find a lot more programmers who don't. I guess you think they're idiots or
something? If not, then perhaps you could wonder what it is about the other
syntaxes that are good, and maybe even synthesize a new syntax that has the
benefits of both approaches, and the drawbacks of neither.
> Dividing a language into statements and expressions is idiocy. You end
> up with inconsistencies, like not being able to use a statement
> somewhere, because the syntax calls for an expression.
Could you give an example of something you'd like to do, say, in C++, but
can't? I wonder if we could tweak the C++ syntax a little to give you what
you want.
Shayne Wissler
Patrick May
> > > What I don't understand is how a Lisper could complain about any
> > > language's syntax!
> >
> > Can you suggest a language with a cleaner syntax?
>
> An ascii dump of machine code comes to mind...
My question was actually quite serious. Aside from Scheme (and
no, I am not interested in starting another "Is Scheme a Lisp?" flame
war), I don't know of a language with a more consistent, powerful
syntax. I'm genuinely interested in learing of one, if such exists.
Tim Ottinger
>
> My question was actually quite serious. Aside from Scheme (and
> no, I am not interested in starting another "Is Scheme a Lisp?" flame
> war), I don't know of a language with a more consistent, powerful
> syntax. I'm genuinely interested in learing of one, if such exists.
>
How does it compare with smalltalk, in the simplicity and power category?
--
+---------------------------+--------------------------+
| Tim Ottinger | OpenOffice Mozilla Samba |
| Indianapolis, IN USA | Python, C++, Whatever |
| I promote Free Software | Linux! (MS if I have to) |
|---------------------------+--------------------------|
| OO Architecture, Design, Teacher/Mentor |
+------------------------------------------------------+
Shayne Wissler
> "Shayne Wissler" <thal...@yahoo.com> writes:
> > > > What I don't understand is how a Lisper could complain about any
> > > > language's syntax!
> > >
> > > Can you suggest a language with a cleaner syntax?
> >
> > An ascii dump of machine code comes to mind...
>
> My question was actually quite serious. Aside from Scheme (and
> no, I am not interested in starting another "Is Scheme a Lisp?" flame
> war), I don't know of a language with a more consistent, powerful
> syntax. I'm genuinely interested in learing of one, if such exists.
I was being serious too--lisp syntax doesn't do much, which is why it's
"clean". It's not a powerful syntax--the thing that gives lisp its power is
its semantics.
Shayne Wissler
Patrick May
> > My question was actually quite serious. Aside from Scheme
> > (and no, I am not interested in starting another "Is Scheme a
> > Lisp?" flame war), I don't know of a language with a more
> > of one, if such exists.
>
> How does it compare with smalltalk, in the simplicity and power
> category?
I'll let you know, as soon as I finish learning Smalltalk with my
11-year-old!
Patrick May
> I was being serious too--lisp syntax doesn't do much, which is why
> it's "clean". It's not a powerful syntax--the thing that gives lisp
> its power is its semantics.
Your original statement was "What I don't understand is how a
Lisper could complain about any language's syntax!" Lisp syntax _is_
simple, and that contributes to its power. Its simplicity is also why
real Lispers (I code in C++ and Java for a living, Lisp for personal
projects) complain about the syntax of other languages that manage to
be simultaneously more complex and less powerful.
You have been edified! You are welcome.
Shayne Wissler
> "Shayne Wissler" <thal...@yahoo.com> writes:
> > I was being serious too--lisp syntax doesn't do much, which is why
> > it's "clean". It's not a powerful syntax--the thing that gives lisp
> > its power is its semantics.
>
> Your original statement was "What I don't understand is how a
> Lisper could complain about any language's syntax!" Lisp syntax _is_
> simple,
Lisp syntax is *trivial*.
> and that contributes to its power.
The syntax is no more powerful than XML's syntax, or any simplistic
tree-entry syntax. The power lies in the language, not its syntax.
Really I don't understand all the elaborate justifications of the triviality
known as "lisp syntax"--historically, the original inventor wanted a real
syntax, but didn't have time to add it. I think you guys are in love with
the semantics (which is fine), but call it "syntax".
> Its simplicity is also why
> real Lispers (I code in C++ and Java for a living, Lisp for personal
> projects) complain about the syntax of other languages that manage to
> be simultaneously more complex and less powerful.
>
> You have been edified! You are welcome.
On the contrary. It would be nice if you Lispers even understood what it was
you liked about Lisp. If I were the inventor of Lisp, I'd feel betrayed.
Shayne Wissler
Michael Schuerig
> Lisp syntax is trivial.
>
>> and that contributes to its power.
>
> The syntax is no more powerful than XML's syntax, or any simplistic
> tree-entry syntax. The power lies in the language, not its syntax.
The syntax of Lisp is what makes it practical to treat programs as data
and manipulate them -- within the language itself! -- with macros.
Michael
--
Michael Schuerig They tell you that the darkness
mailto:schu...@acm.org is a blessing in disguise.
http://www.schuerig.de/michael/ --Janis Ian, "From Me To You"
Shayne Wissler
"Michael Schuerig" <schu...@acm.org> wrote in message
news:b3becg$r66$04$1...@news.t-online.com...
> Shayne Wissler wrote:
>
> > Lisp syntax is trivial.
> >
> >> and that contributes to its power.
> >
> > The syntax is no more powerful than XML's syntax, or any simplistic
> > tree-entry syntax. The power lies in the language, not its syntax.
>
> The syntax of Lisp is what makes it practical to treat programs as data
> and manipulate them -- within the language itself! -- with macros.
No, all that's required for that (very nice) feature is some cannonical
internal format for the program that's accessible/modifiable by the
programmer. The Lisp syntax has absolutely nothing to do with it.
Shayne Wissler
Michael Schuerig
Indeed, that's all that's required to make it _possible_. I'm wondering,
though, where it is _actual_, apart from Lisp. Can you point me to any
other, non-research language? That's the meaning of "practical".
Have a look at the Java Syntactic Extender
(http://www.ai.mit.edu/~jrb/jse/jse.pdf) to see an attempt (by people
from the Lisp tradition) to bring Lisp-like macros to Java. Looks more
painful to me than it is in Lisp.
Also, Lisp has the advantage that the language itself *is* its
"canonical internal format". Thus, there's no need to learn two
representations, one external, the other internal. This is a
significant point. Maybe not in theory -- but in practice.
Michael
--
Michael Schuerig Contests between male toads over females are
mailto:schu...@acm.org often settled by the depth of the croak.
http://www.schuerig.de/michael/ --John Maynard Smith
JXStern
<schu...@acm.org> wrote:
>Also, Lisp has the advantage that the language itself *is* its
>"canonical internal format". Thus, there's no need to learn two
>representations, one external, the other internal. This is a
>significant point. Maybe not in theory -- but in practice.
Surely no major Lisp system interprets ASCII text directly? Doesn't
everyone tokenize to some internal form first? I mean, in practice?
J.
Michael Schuerig
I'm not a Lisp expert (rather a novice as far as actual use is
concerned), so take everything I say on Lisp with a grain of salt.
Current Lisp implementations usually compile textual representations of
programs into machine code. I prefer to talk of (logical)
representations instead of (physical) formats. I take it, Shayne had
the same in mind. The actual, physical format of compiled code or any
intermediate data structures is irrelevant (for this discussion).
Generally, source code can be represented by an abstract syntax tree,
which in turn could be considered the programs canonical
representation.
Now, as it happens, in Lisp there's an obvious and easy 1-to-1
correspondence between the nested lists of Lisp code and the AST. If
you want to manipulate the AST, you don't have to learn some entirely
new and different language or framework. You just use the ordinary list
manipulation functions as elsewhere in the program. There's no
linquistic break. Lisp macros look pretty much the same as other Lisp
code does. Have a look at the JSE paper I refered to earlier and see
for yourself if the shown Java + macros code seems obvious.
Michael
--
Michael Schuerig Nothing is as brilliantly adaptive
mailto:schu...@acm.org as selective stupidity.
http://www.schuerig.de/michael/ --A.O. Rorty, "The Deceptive Self"
Shayne Wissler
How is all this relevant to the previous disagreement?
Shayne Wissler
"Michael Schuerig" <schu...@acm.org> wrote in message
news:b3blb5$auu$03$1...@news.t-online.com...
Michael Schuerig
> Michael,
>
> How is all this relevant to the previous disagreement?
I'm sorry, I don't understand what you mean. What disagreement exactly?
I was responding to JXStern, not you.
Michael
--
Michael Schuerig Failures to use one's frontal lobes
mailto:schu...@acm.org can result in the loss of them.
http://www.schuerig.de/michael/ --William H. Calvin
Kaz Kylheku
I think Michael's point is really that you would actually need *three*
representations.
There is always an internal and external one, so you in effect already
have at least two. But in Lisp, the correspondence between these two
is trivial.
In Lisp, we have the property that a tree structure can be printed,
and the printed form is what you would type to produce that structure.
It makes a big difference when you are debugging complex macros.
If you add some ad-hoc, one-way syntax into the mix, you have a third
representation, but you still need the other two, so that you can
conveniently work with the program as data.
The problem is that arbitrary syntax, like that exhibited by Python,
Java, C++ and so forth, is a one-way interface. Not every possible
abstract syntax tree can be mapped back to the syntax. Suppose that
your macro produces bad syntax, like perhaps it inserts an extra
element into a list, or whatever. What notation shall it use to show
you the bad syntax, so that you can discover your error?
Or, you can look the problem from the other direction. You have some
programming language, and you want to add structural macro processing
to it. Okay, until now, you haven't had to describe *what* a program
is, beyond the printed text representation that programers actually
write into files. You are going to have to choose a representation,
and make it known. Now you face a second problem: representations are
abstract! To actually work with them on paper, or in the machine, you
need a notation which can capture them, so that you can show various
transformations and operations in terms of that notation. Now you run
into the issue that the ad-hoc syntax of your programming language is
a completely inappropriate, inadequate, suboptimal choice of notation.
Kaz Kylheku
Right, and so what you are saying is that you can provide this nice
canonical format, but provide no printed representation for it by
which the programmer can express that representation to the machine,
and by which the machine can show a structure to the programmer? Or
you are saying that the original syntax of the language is always
adequate for this?
Kaz Kylheku
> "Patrick May" <p...@spe.com> wrote in message
> news:m37kbqr...@localhost.localdomain...
> > "Shayne Wissler" <thal...@yahoo.com> writes:
> > > I was being serious too--lisp syntax doesn't do much, which is why
> > > it's "clean". It's not a powerful syntax--the thing that gives lisp
> > > its power is its semantics.
> >
> > Your original statement was "What I don't understand is how a
> > Lisper could complain about any language's syntax!" Lisp syntax _is_
> > simple,
>
> Lisp syntax is *trivial*.
>
> > and that contributes to its power.
>
> The syntax is no more powerful than XML's syntax, or any simplistic
> tree-entry syntax. The power lies in the language, not its syntax.
Actually the syntax is far more expressive than XML, because it
expresses properly typed objects, not just plain text which has been
chopped up and arranged into a tree hierarchy.
You can express objects like lists, vectors, symbols, strings,
integers, real numbers, rationals, complex numbers, structures, etc.
Representing all of these things in XML requires piles of ad-hoc
conventions, and extra processing on top of the XML parsing and
formatting layer.
> Really I don't understand all the elaborate justifications of the triviality
> known as "lisp syntax"--historically, the original inventor wanted a real
> syntax, but didn't have time to add it.
This is a very distorted account of history. Note that this was in
1958; since then, Lisp could have been augmented with different syntax
such as M-expressions, but nobody wanted them.
Yes, McCarthy thought that the S-expressions would be a disadvantage,
but then he realized he was mistaken.
Being at the forefront of programming language research, he can be
pardoned for having initially entertained a bad intuition. Look at the
crap that the man's Fortran peers were coming up with!
This just shows you that even the principal inventor did not
immediately see all the advantages, which is why it's hard to explain
certain things even today.
Lisp syntax is not all parenthesized expressions, by the way. There
are various prefix shorthands, most of them introduced by the macro
dispatch character #. For instance 'EXPR stands for (QUOTE EXPR), #(1
2 3) is a vector rather than a list, #c(2 3) is a complex number,
12/13 is a ratio, and #'FOO returns the function object that is named
by the symbol FOO. #1=(a b c #1#) is a cyclic structure: a list which
contains itself as an element. These convenient notations did not
exist in the 1958 language. All of them are carefully designed not to
break any of the advantages of S-expressions. The dot notation for
consing, which is arguably a bit of infix, is quite ancient.
> I think you guys are in love with the semantics (which is fine),
> but call it "syntax".
The syntax is closely tied to semantics to the extent of representing
a structure; a real object inside a computer with elements that
exhibit value and type. Yes, without the semantics of this
correspondence, the syntax by itself isn't useful. It's unsurprising
that syntax isn't useful if it doesn't stand for something!
It's just that in Lisp, the syntax (or what programmers using other
languages understand to be syntax, but which is called ``read syntax''
by Lispers) doesn't stand for too much or too little.
There is a second layer semantics which defines the constructs of a
programming language. This would be the semantics proper, so to speak.
This layer tells us that when we evaluate the *object* that is notated
by the read syntax (list 'a 1), it produces the object notated by (a
1). We are no longer talking about syntax now, this is something else.
When we are speaking about the advantages of the Lisp read syntax, and
how it gives us reversible transformation between text and data, we
are certainly not talking about the programming language semantics.
Kaz Kylheku
> "Kaz Kylheku" <k...@ashi.footprints.net> wrote in message
> news:cf333042.03022...@posting.google.com...
>
> > > > > Python is basically a terrible syntactic interface to a subset of
> the
> > > > > semantics of a language resembling Lisp.
> > > >
> > > > A compliment! Any grudging admission that a language resembles Lisp
> from
> > > > a Lisp-head is a compliment. And no non-Lisp head would compare a
> language
> > > > with Lisp that way. :)
> > >
> > > What I don't understand is how a Lisper could complain about any
> language's
> > > syntax!
> >
> > Easy: he does not find in that other the consistency and convenient
> > meta-syntactic programming which comprise his day to day Lisp
> > programming experience.
>
> It's easy to be self-consistent if you stick with the simplistic. The other
> languages are trying to do more for the programmer (too bad most don't do as
They do more for the programmer when he sticks to exactly the kind of
programming that the designers have in mind. For example, C does
certain things quite right for you if you write Unix device drivers.
> much as lisp "under the hood").
Yes, those other languages do their work *over* the hood---a place for
useless vanitites, like fiberglass spoilers, ornaments and whatnot.
> My guess is that even though you prefer the lisp syntax, you're going to
> find a lot more programmers who don't. I guess you think they're idiots or
> something?
No, they are just like what I was before I learned about it.
I'd say they are idiots if after actually working with it for some
time they still don't get it.
As a recent Lisp beginner, I still remember that certain matters are
far from obvious. It probably takes at least a few months to ``get
it''.
At times I felt like a Fortran programmer trying to learn OO, to use
an analogy.
> If not, then perhaps you could wonder what it is about the other
> syntaxes that are good, and maybe even synthesize a new syntax that has the
> benefits of both approaches, and the drawbacks of neither.
What's good about those other syntaxes is that you can achive a nice
looking, condensed notation that is excellent for expressing the kinds
of textbook examples that it was designed to support.
The right approach is to allow for those other syntaxes: that's why in
Lisp you can write your own lexical analysis, to design a read syntax
from the ground up.
If you prefer writing a[i, j] = f(x += 3, 4) you can have that.
There is a piece of portable Lisp freeware which will give you that
notation, in fact.
> > Dividing a language into statements and expressions is idiocy. You end
> > up with inconsistencies, like not being able to use a statement
> > somewhere, because the syntax calls for an expression.
>
> Could you give an example of something you'd like to do, say, in C++, but
> can't?
No; Turing completeness means that I can do anything in C++, like for
instance write a poorly optimized Lisp implementation, and then write
the rest of the program in that.
I can think of things I'd like to express directly, but they are so
out of reach of C++ that it's inconceivable to even want them in C++.
To provide them, C++ would have to become something so radically
different that this new thing couldn't even be viewed as a derivative
of C++.
What I'd like to be able to do is to write completely custom syntax
and semantics to suit every whim. This destroys the very concept
behind a language like C++, which takes hard-coded syntax and
semantics as one of its founding design principles.
I don't just want new instances of hard-coded syntax that solves
specific problems!
> I wonder if we could tweak the C++ syntax a little to give you what
> you want.
That's like asking, could you make a few improvements to that hooker
standing on the corner to turn her into wife material? Sure: just
replace her disease-infested, drug-abused body, and then give her a
new brain, and voila! But you now have a different person with a new
identity. :)
Tim Ottinger
> I'll let you know, as soon as I finish learning Smalltalk with my
> 11-year-old!
That's really cool. Kay intended it to be used by children.
He's quite an interesting guy to read about. Similarly,
Guido von Rossum is promoting Python as a first programming
language for children.
Neither language is a "baby language", and lots of very real
work has been done in both. Some smalltalk work (a lot of it)
has even been ground-breaking.
JXStern
<schu...@acm.org> wrote:
>Now, as it happens, in Lisp there's an obvious and easy 1-to-1
>correspondence between the nested lists of Lisp code and the AST.
As long as you stick to list processing. If you have to descend to
the level of procedural loops or the like, then either you start doing
expression lifting and the like, or you lose in the performance area.
I don't know what the state of the art is in compiler optimizations
for Lisp, but I doubt if it's as simple as you suggest.
> Lisp macros look pretty much the same as other Lisp code does.
>Have a look at the JSE paper I refered to earlier and see
>for yourself if the shown Java + macros code seems obvious.
Macros are one thing, terminal source syntax another, tokenized
another, optimized yet another. You can have a cannonical
representation for language X, you can have language X and Y share a
tokenized representation or virtual machine (or share a real
machine!), but there is no universal cannonical representation for any
and all languages.
I don't like C++ templates or high-level language macros generally,
but I don't base that on arguments of cannonical form, just matters of
readability, generated code, and development environment support
considerations.
Joshua Stern
Shayne Wissler
"Kaz Kylheku" <k...@ashi.footprints.net> wrote in message
news:cf333042.03022...@posting.google.com...
No.
Shayne Wissler
"Kaz Kylheku" <k...@ashi.footprints.net> wrote in message
news:cf333042.03022...@posting.google.com...
> > > Dividing a language into statements and expressions is idiocy. You end
> > > up with inconsistencies, like not being able to use a statement
> > > somewhere, because the syntax calls for an expression.
> >
> > Could you give an example of something you'd like to do, say, in C++,
but
> > can't?
> I can think of things I'd like to express directly, but they are so
> out of reach of C++ that it's inconceivable to even want them in C++.
> To provide them, C++ would have to become something so radically
> different that this new thing couldn't even be viewed as a derivative
> of C++.
>
> What I'd like to be able to do is to write completely custom syntax
> and semantics to suit every whim. This destroys the very concept
> behind a language like C++, which takes hard-coded syntax and
> semantics as one of its founding design principles.
But can you give an *example* of something? It doesn't matter if you have
whims to see something a given way. What matters is whether seeing it that
way actually improves productivity. So let's see an example of something
where modifying the syntax is called for, and where it's hard to solve the
problem without changing the syntax.
Also, you say that you can provide a "completely custom syntax and
semantics"--does that mean that you can make lisp look like C++? In which
case, aren't you just building a C++ compiler out of lisp? We can build
compilers out of C++ too. If that's all you're doing, I don't see what
you're so excited about. Of course, with lisp you can generate code at
run-time and execute it, which is nice, but not profound.
Shayne Wissler
Michael Schuerig
> On Mon, 24 Feb 2003 01:54:23 +0100, Michael Schuerig
> <schu...@acm.org> wrote:
>>Now, as it happens, in Lisp there's an obvious and easy 1-to-1
>>correspondence between the nested lists of Lisp code and the AST.
>
> As long as you stick to list processing. If you have to descend to
> the level of procedural loops or the like, then either you start doing
> expression lifting and the like, or you lose in the performance area.
> I don't know what the state of the art is in compiler optimizations
> for Lisp, but I doubt if it's as simple as you suggest.
We might be talking past each other here. I was trying to say that Lisp
code itself essentially consists of nested lists. Between these lists
that make up the program source code and the parsed abstract syntax
tree there's a trivial 1-to-1 relation. Manipulating the AST (in a
restricted way, to be sure) is as simple as and very similar to
manipulating ordinary list data structures. Lisp programs are not at
all limited to list data structures; there's a plethora of others
readily and easily available.
>> Lisp macros look pretty much the same as other Lisp code does.
>>Have a look at the JSE paper I refered to earlier and see
>>for yourself if the shown Java + macros code seems obvious.
>
> Macros are one thing, terminal source syntax another, tokenized
> another, optimized yet another. You can have a cannonical
> representation for language X, you can have language X and Y share a
> tokenized representation or virtual machine (or share a real
> machine!), but there is no universal cannonical representation for any
> and all languages.
True -- but take Java as an example. There, ordinary source code,
serialized/printable representations of lists or trees, and ASTs look
all very different. In general this doesn't cause problems, of course.
But if you're trying to augment the language with new, user-defined
constructs, it isn't nearly as convenient as it is in Lisp. Do you
really think otherwise?
Michael
--
Michael Schuerig Life is just as deadly
mailto:schu...@acm.org as it looks.
http://www.schuerig.de/michael/ --Richard Thompson, "Sibella"
JXStern
The BNF for Lisp is much shorter than the one for Java, but I do not
see this as an advantage for Lisp. List processing is fun, but I
vastly prefer the syntax of plain old everyday run of the mill
imperative Algol-like languages, plus or minus OO features. I've used
macros in lots of places, and basically, they provide a way for
low-level languages to make believe they are higher level. Macros are
especially convenient and appropriate for programming in assembler.
Developing macros is fun. I've done a fair amount of it, written my
own macro processors and everything. However, it is only
meta-productive to actually getting applications built, and there are
lots of programmers who just don't deal well with them at all, which
further limits my enthusiasm for their use in real-world projects.
J.
Michael Schuerig
Hm, do you realize that in the above paragraph you are arguing an
entirely different point from the one we discussed earlier?
To recapitulate, the point was *not* whether someone likes or does not
prefer the syntax of Lisp over another language, or vice versa. Also,
the point was *not* whether macros are good and useful or rather
dangerous. Instead, the point was *only* whether Lisp syntax makes the
use of macros as easy as they can get. I've presented arguments in
favor of this last point.
Now, regarding the entirely different question whether macros are a good
thing, I'd like to point out that domain-specific (embedded) languages
have been a hot topic in programming language research for several
years. Macros are one of the prime facilitators for embedding a
domain-specific language in a host language. (Another route starts with
lazy evaluation.)
So, is this DSEL and macro stuff purely academic hocus pocus? I don't
think so. For one thing, there's something rather similar happening
currently in the "industry" -- model-driven architecture. In MDA, you
essentially define a very high level language. Apparently people shy
away from calling it a programming language; and they don't program in
this new language, they "model" in it, whatever the difference may be.
Then, the model is transformed by some translation tool into the target
language.
If MDA is supposed to be a good thing, I'm sure it's even better, if
modeling language, translator, and target language can all be
seamlessly expressed in one single programming language. In Lisp this
seems to be possible.
Michael
(Am I inadvertently turning into a Lisp advocate, or what?)
--
Michael Schuerig The usual excuse for our most unspeakable
mailto:schu...@acm.org public acts is that they are necessary.
http://www.schuerig.de/michael/ --Judith N. Shklar
Patrick May
> Patrick May wrote:
> > I'll let you know, as soon as I finish learning Smalltalk with my
> > 11-year-old!
>
> That's really cool. Kay intended it to be used by children. He's
> quite an interesting guy to read about. Similarly, Guido von Rossum
> is promoting Python as a first programming language for children.
That's really good to know. She has already learned Logo and
still uses it but wants to do some projects that don't fit that
language terribly well (strategy games, initially). I wasn't aware
that Smalltalk was intended for use by children, but from what little
exposure I have to it, it seems much easier to learn with her than to
teach her C++ or Java.
Dave Harris
> > My question was actually quite serious. Aside from Scheme (and
> > no, I am not interested in starting another "Is Scheme a Lisp?" flame
> > war), I don't know of a language with a more consistent, powerful
> > syntax. I'm genuinely interested in learing of one, if such exists.
> >
>
> How does it compare with smalltalk, in the simplicity and power
> category?
Smalltalk's syntax is less simple and less powerful, in my view. In some
ways this makes it easier to use - because of the earlier point about
expressing different semantics with different syntax. The main feature
lost is macros.
Dave Harris, Nottingham, UK | "Weave a circle round him thrice,
bran...@cix.co.uk | And close your eyes with holy dread,
| For he on honey dew hath fed
http://www.bhresearch.co.uk/ | And drunk the milk of Paradise."
Martijn Faassen
[snip snip]
Lots of arguments that make sense. I'm just going to drop in some
other points for consideration here from a Python perspective.
> I can think of things I'd like to express directly, but they are so
> out of reach of C++ that it's inconceivable to even want them in C++.
> To provide them, C++ would have to become something so radically
> different that this new thing couldn't even be viewed as a derivative
> of C++.
I have the same feeling coming from Python to C++ (actually I came the
othe way around). Dynamic typing for instance is so useful and pervasive in
Python, and making C++ dynamically typed would make it a very different
language indeed. And all names in Python are references to objects, instead
of the number of choices you have in C++ which complicate life. Taking away
those choices in C++ would also turn it into something quite different
(it'd be more like Java).
> What I'd like to be able to do is to write completely custom syntax
> and semantics to suit every whim. This destroys the very concept
> behind a language like C++, which takes hard-coded syntax and
> semantics as one of its founding design principles.
>
> I don't just want new instances of hard-coded syntax that solves
> specific problems!
The risk of custom syntax "to suito every whim" is that there's a risk
your code will become harder to maintain and harder to read. Idioms
while perhaps more easily abstracted away into new syntax will also
be harder to recognize.
I think there is definitely something to say for some "arbitrary" syntax
to make idioms more clearly recognizable and uniform between different
pieces of software. Flexibility in a language can
certainly exist beyond the syntactic level (and this exists in Lisp
as well of course).
See it as a user interface thing -- while a user interface consisting of
a grid of different boxes is certainly very flexible and powerful, and
easily programmable to boot (character based screen), it becomes more easy
to recognize things when they look different (windows, menus, colors, icons).
One can take this too far of course.
There's a tradeoff between orthogonality in user interface and
distinguishability/recognisability. Both can help in enhancing
ease of learning and can increase power, but both can hurt in places
as well.
Python is a language about tradeoffs. The "Zen of Python" displays that:
http://www.python.org/doc/Humor.html#zen
especially this part:
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Regards,
Martijn
--
History of the 20th Century: WW1, WW2, WW3?
No, WWW -- Could we be going in the right direction?
Kaz Kylheku
> On Mon, 24 Feb 2003 19:03:53 +0100, Michael Schuerig
> <schu...@acm.org> wrote:
> >True -- but take Java as an example. There, ordinary source code,
> >serialized/printable representations of lists or trees, and ASTs look
> >all very different. In general this doesn't cause problems, of course.
> >But if you're trying to augment the language with new, user-defined
> >constructs, it isn't nearly as convenient as it is in Lisp. Do you
> >really think otherwise?
>
> The BNF for Lisp is much shorter than the one for Java, but I do not
> see this as an advantage for Lisp.
The BNF for the Lisp *read* syntax is shorter, but it's not the whole
story. There is another level of syntax, which is actually quite
large! The Lisp language is full of functions and special operators,
each of which has its own syntax.
To understand an object semantically as a piece of Lisp source code,
you have to know the higher level syntax and semantics of the
operators.
The advantage is in not conflating the two levels of syntax: the read
syntax and structural syntax.
In Java, the two are jumbled together. You can't intercept a
structured representation of the Java source after the read syntax has
been processed, but before the deeper syntax has been analyzed.
Characters go in, .class file pops out.
Incidentally, library functions count toward the syntax of a language.
For example, in C, we have the memcpy function in <string.h>. This
most certainly is a piece of syntax: there are three arguments, and
the destination goes on the left. If you don't remember number, types
and order of arguments of a function while coding, you have to look it
up.
In Lisp, functions and special forms look about the same, only the
evaluation rules are different, and the special forms have nested
argument lists.
Library design is language design---how true. Who said or wrote that,
Meyers?
Because of the way the Lisp language works, understanding the syntax
of a special form like COND or IF is similar to understanding the
syntax of a function. A symbol on the left identifies the construct,
and the remaining pieces are arguments that are expected to have some
type. The difference is that, depending on the form, some of the
pieces may be nested argument lists that are subject to an embedded
syntax, whereas a function just has one flat argument.
This is a great consistency; you don't have special-case stupidities,
like for instance that in C, you must use parentheses in
do ... while (expr);
but are not required to use them in:
return expr;
> List processing is fun, but I
> vastly prefer the syntax of plain old everyday run of the mill
> imperative Algol-like languages, plus or minus OO features. I've used
If I don't need to extend the syntax, and the existing one fits the
programming task, I don't mind it.
> macros in lots of places, and basically, they provide a way for
> low-level languages to make believe they are higher level. Macros are
In Lisp the whole object system is done with macros; so it's a little
more than fantasy. It's not make-believe that DEFCLASS defines a
class. ;)
> especially convenient and appropriate for programming in assembler.
> Developing macros is fun. I've done a fair amount of it, written my
> own macro processors and everything.
Text based macro preprocessing is not the same thing as Lisp macros,
which are structural. Only the term is the same. (You wouldn't think
that Microsoft Excel ``macros'' are the same as C macros, right?)
Text macros are not clean. They break!
The features of an Algol-like programming language *are* essentially
structural macros, but they are hard coded into the grammar, and
handle the read syntax and structural syntax in one package.
What does a typical C compiler do when it sees `while (condition())
foo();''? Quite possibly, the read syntax is first grokked---the
parentheses must be there, the semicolon and so forth. Then a tree
node is made which expresses the while loop abstractly; the Lisp
notation for that tree might look like (while (condition) (foo)).
The next step is translation from the tree to some intermediate code,
and this is nothing other than treating the tree as a programming
language whose nodes are operators that combine and substitute the
constituent pieces. In other words, macros.
Later, that while-tree will result in some intermediate instructions
being emitted, with an auto-generated label for the backward branch
and for the skip. The code for the two pieces will be recursively
inserted, etc.
In Lisp, a macro will do exactly this sort of thing, and you can write
it yourself and stick it into your program.
It's almost misleading to call it macro preprocessing, due to the
connotations that it raises in the minds of most programmers who have
come into contact with C or C++.
I sometimes simply say that in a Lisp program, you can write small,
self-contained compilers for custom language features, and that these
are called macros.
Kaz Kylheku
> "Kaz Kylheku" <k...@ashi.footprints.net> wrote in message
> news:cf333042.03022...@posting.google.com...
>
> > > > Dividing a language into statements and expressions is idiocy. You end
> > > > up with inconsistencies, like not being able to use a statement
> > > > somewhere, because the syntax calls for an expression.
> > >
> > > Could you give an example of something you'd like to do, say, in C++,
> but
> > > can't?
>
> > I can think of things I'd like to express directly, but they are so
> > out of reach of C++ that it's inconceivable to even want them in C++.
> > To provide them, C++ would have to become something so radically
> > different that this new thing couldn't even be viewed as a derivative
> > of C++.
> >
> > What I'd like to be able to do is to write completely custom syntax
> > and semantics to suit every whim. This destroys the very concept
> > behind a language like C++, which takes hard-coded syntax and
> > semantics as one of its founding design principles.
>
> But can you give an *example* of something? It doesn't matter if you have
> whims to see something a given way. What matters is whether seeing it that
> way actually improves productivity. So let's see an example of something
> where modifying the syntax is called for, and where it's hard to solve the
> problem without changing the syntax.
Look at my Meta-CVS project, and grep for ``defmacro''. There are a
few interesting ones.
One macro turns filesystem directory traversal into a first-class
iterative construct that appears to be a built-in language feature,
with solid error recovery.
I have a function memoization macro which lets me memoize a function
simply by replacing DEFUN by DEFINE-MEMOIZED-FUNCTION. Memoization can
reduce the running time of some kinds of recursive functions from
exponential to polynomial time.
I have a macro called FIND-BIND which provides custom syntax for
retrieving multiple elements from a sequence by matching keys, and
binding the results to lexical variables. It has useful subtleties;
for example, multiple matches retrieve in left to right order. You can
specify defaults if there are no matches, specify what parts of the
elements to retrieve and what parts to use as keys, and what
comparison function to use. This macro blows away a whole lot of
tedious, and in some cases error-prone coding:
(let ((name-list '(("joe" "smith")
("harry" "schiffer")
("harry" "potter"))))
(find-bind (:test #'string-equal :key #'first :take #'second)
((j "joe") (h "harry") (h2 "harry") (b "foo") (c "bar"
"x"))
name-list
;; j is bound to "smith", h to "schiffer" and h2 to "potter"
;; b is bound to NIL (no match on "foo")
;; c is bound to "x" (no match on "bar", default value "x"
taken).
)
After I wrote it, I found some unexpected uses for it; I realized that
for instance it could be used in pulling out information about restart
points in the program's condition handler.
There is also one big macro called IN-SANDBOX-ROOT-DIR which sets up
the environment for a Meta-CVS operation. It searches the filesystem
to find the root of the sandbox and changes the current directory
there (taking care to restore it no matter how it terminates!) It
loads the contents of a few special metadata files, and such. Also, it
introduces lexically scoped operators for converting pathnames across
the directory change displacement.
Meta-CVS is less than 200 kilobytes of source, but manages to
implement a substantially more powerful version control system over
the CVS platform.
> Also, you say that you can provide a "completely custom syntax and
> semantics"--does that mean that you can make lisp look like C++? In which
Yes, in principle you can. In practice, if something like that was
done, it would look like C++, but retain the features of a dynamic
language.
> case, aren't you just building a C++ compiler out of lisp? We can build
> compilers out of C++ too.
The difference is that this compiler would be part of your Lisp
program. One part of the program defines the compiler, other parts can
be written in the language accepted by the compiler.
Another difference is that the compiler would only have to handle the
source to source transformation, not any code generation or
optimization: that would be taken care of by Lisp. Just produce the
Lisp source, and feed it to the compiler you already have in the
language.
> If that's all you're doing, I don't see what
> you're so excited about. Of course, with lisp you can generate code at
> run-time and execute it, which is nice, but not profound.
Not only that, but you can compile it to native machine code, using
any one of the mature Lisp implementations.
It may not be profound, but it's missing from most other languages.
Michael Schuerig
> Library design is language design---how true. Who said or wrote that,
> Meyers?
Andrew Koenig, Barbara Moo: Ruminations on C++
Chap 25: "Library design is language design"
Chap 26: "Language design is library design"
Michael
--
Michael Schuerig Not only does lightning not strike
mailto:schu...@acm.org twice, it usually doesn't strike once.
http://www.schuerig.de/michael/ --Salman Rushdie, "Fury"
Martijn Faassen
> I have a function memoization macro which lets me memoize a function
> simply by replacing DEFUN by DEFINE-MEMOIZED-FUNCTION. Memoization can
> reduce the running time of some kinds of recursive functions from
> exponential to polynomial time.
In python one can do this with a custom object with a minimum amount of
hassle:
def somefunction(args):
pass
somefunction = MemoizedFunction(somefunction)
um, from the top of my head:
class MemoizedFunction:
def __init__(self, function):
self.function = function
self.cache = {}
# handle both normal and keyword arguments, basically any signature
def __call__(self, *args, **kw):
# should use more sophisticated key generation method in the face
# of arguments that are mutable objects
key = (args, kw) # should replace this with more sophisitacimo
if self.cache.has_key(key):
return self.cache[key]
else:
result = self.function(*args, **kw)
self.cache[key] = result
return result
I wouldn't want to do this in C++ or Java, but one doesn't need macros
to do a thing like this.
> I have a macro called FIND-BIND which provides custom syntax for
> retrieving multiple elements from a sequence by matching keys, and
> binding the results to lexical variables. It has useful subtleties;
> for example, multiple matches retrieve in left to right order. You can
> specify defaults if there are no matches, specify what parts of the
> elements to retrieve and what parts to use as keys, and what
> comparison function to use.
I think that this is also possible to implement in Python (again without
macros; Python has none). I think here an idiomatic way to do so in
Python will get close, though:
> This macro blows away a whole lot of
> tedious, and in some cases error-prone coding:
>
> (let ((name-list '(("joe" "smith")
> ("harry" "schiffer")
> ("harry" "potter"))))
> (find-bind (:test #'string-equal :key #'first :take #'second)
> ((j "joe") (h "harry") (h2 "harry") (b "foo") (c "bar"
> "x"))
> name-list
>
> ;; j is bound to "smith", h to "schiffer" and h2 to "potter"
> ;; b is bound to NIL (no match on "foo")
> ;; c is bound to "x" (no match on "bar", default value "x"
> taken).
> )
name_list = {
"joe": "smith",
"harry": ("schiffer", "potter")
}
j, h, h2, b, c = (name_list["joe"], name_list["harry"][0],
name_list["harry"][1], name_list.get("foo"),
name_list.get("bar", "x"))
b will be bound to None (equivalent of NIL in Python). .get() is a builtin
method on dictionaries. I use dictionaries (hash table) here so I can't do the
left to right trick, and instead the more explicit indexing is used.
(of course one could write a function to do this and using a datastructure
which allowed double keys).
Anyway, if the above idiom gets too tedious (even though it's pretty short),
one could write a function along these lines:
def foo(dict, *args):
return [dict.get(key, default) for key, default in args]
# skipping double harry issue
j, h, b, c = foo(name_list,
("joe", None), ("harry", None), ("foo", None), ("bar", "x"))
Anyway, this is not to say that Lisp's simple orthogonal syntax doesn't
allow one to do powerful things with macros. But some of these examples
at least are not hard to accomplish satisfactorily (I think) in a language
that doesn't offer a macro facility, such as Python. Dynamic typing and
powerful built-in datastructures count for a lot.
Martijn Faassen
> Kaz Kylheku wrote:
>
>> Library design is language design---how true. Who said or wrote that,
>> Meyers?
>
> Andrew Koenig, Barbara Moo: Ruminations on C++
> Chap 25: "Library design is language design"
> Chap 26: "Language design is library design"
Andrew Koenig incidentally also uses Python. :)
Anton Muhin
> "Shayne Wissler" <thal...@yahoo.com> writes:
>
>>>>What I don't understand is how a Lisper could complain about any
>>>>language's syntax!
>>>
>>
>>An ascii dump of machine code comes to mind...
>
>
> My question was actually quite serious. Aside from Scheme (and
> no, I am not interested in starting another "Is Scheme a Lisp?" flame
> war), I don't know of a language with a more consistent, powerful
> syntax. I'm genuinely interested in learing of one, if such exists.
>
>
> Patrick
>
> ------------------------------------------------------------------------
> S P Engineering, Inc. | The experts in large scale distributed OO
> | systems design and implementation.
> p...@spe.com | (C++, Java, ObjectStore, Oracle, CORBA, UML)
There are several languages with rather simple syntax that came in my
mind: Haskell, Forth.
Lisp seems much worse on comparison with them.
Anton.
Robert Klemme
"Anton Muhin" <anton...@sendmail.ru> schrieb im Newsbeitrag
news:b3g3gr$2g9i$1...@news.peterlink.ru...
> Patrick May wrote:
> > "Shayne Wissler" <thal...@yahoo.com> writes:
> >
> >>>>What I don't understand is how a Lisper could complain about any
> >>>>language's syntax!
> >>>
> >>> Can you suggest a language with a cleaner syntax?
> >>
> >>An ascii dump of machine code comes to mind...
> >
> >
> > My question was actually quite serious. Aside from Scheme (and
> > no, I am not interested in starting another "Is Scheme a Lisp?" flame
> > war), I don't know of a language with a more consistent, powerful
> > syntax. I'm genuinely interested in learing of one, if such exists.
> There are several languages with rather simple syntax that came in my
> mind: Haskell, Forth.
>
> Lisp seems much worse on comparison with them.
IMHO ruby has a clear syntax, too. This is much easier to read and less
cluttered than perl for example.
robert
Steve Holden
> Tim Ottinger <tott...@indy.rr.com> writes:
> > Patrick May wrote:
> > > I'll let you know, as soon as I finish learning Smalltalk with my
> > > 11-year-old!
> >
> > That's really cool. Kay intended it to be used by children. He's
> > quite an interesting guy to read about. Similarly, Guido von Rossum
> > is promoting Python as a first programming language for children.
>
> That's really good to know. She has already learned Logo and
> still uses it but wants to do some projects that don't fit that
> language terribly well (strategy games, initially). I wasn't aware
> that Smalltalk was intended for use by children, but from what little
> exposure I have to it, it seems much easier to learn with her than to
> teach her C++ or Java.
>
In that case I would strongly recommend you try Squeak, which is a very
accessible implementation of SmallTalk. It has some nice features like a toy
car that you can program visually, for example, and it could help to
introduce a child to additional programming concepts.
The only trouble is it takes an adult a while to come to terms with Squeak
in order to be able to explain it to the child :-)
Python, of course, has also been used in some interesting programming
projects by schoolkids, and the forthcoming PyCon conference in DC will
include a description of some of the more recent work in this area.
regards
--
Steve Holden http://www.holdenweb.com/
Python Web Programming http://pydish.holdenweb.com/pwp/
Register for PyCon now! http://www.python.org/pycon/reg.html
Steve Holden
> "Shayne Wissler" <thal...@yahoo.com> wrote ...
> > "Kaz Kylheku" <k...@ashi.footprints.net> wrote ...
> >
> > > > > > Python is basically a terrible syntactic interface to a subset
of
> > the
> > > > > > semantics of a language resembling Lisp.
> > > > >
> > > > > A compliment! Any grudging admission that a language resembles
Lisp
> > from
> > > > > a Lisp-head is a compliment. And no non-Lisp head would compare a
> > language
> > > > > with Lisp that way. :)
> > > >
> > > > What I don't understand is how a Lisper could complain about any
> > language's
> > > > syntax!
> > >
> > > Easy: he does not find in that other the consistency and convenient
> > > meta-syntactic programming which comprise his day to day Lisp
> > > programming experience.
> >
> > It's easy to be self-consistent if you stick with the simplistic. The
other
> > languages are trying to do more for the programmer (too bad most don't
do as
>
> They do more for the programmer when he sticks to exactly the kind of
> programming that the designers have in mind. For example, C does
> certain things quite right for you if you write Unix device drivers.
>
drivers? (offhand there's no reason why not, if Forth can be used to write
device firmware). If it's so clear to you, kindly explain *exactly* the kind
of programming that Python, or C, or C++, was designed for. For extra marks,
explain why each supports such a diverse set of applications, and how this
diverse set falls into a exactly-demarcated application space.
> > much as lisp "under the hood").
>
> Yes, those other languages do their work *over* the hood---a place for
> useless vanitites, like fiberglass spoilers, ornaments and whatnot.
>
Sorry to bring you back to Earth, but perhaps you could explain what the
"useless vanities" in Python are. Last time I looked it was a well-designed
language for object-oriented and procedural programming.
> > My guess is that even though you prefer the lisp syntax, you're going to
> > find a lot more programmers who don't. I guess you think they're idiots
or
> > something?
>
> No, they are just like what I was before I learned about it.
>
And now you are a superman, able to condescend to those without your
superior knowledge? Even if you regard them as naiively ignorant, your
approach doesn't appear calculated to convert them.
> I'd say they are idiots if after actually working with it for some
> time they still don't get it.
>
Ah, right, so EVERYBODY shoudl be using Lisp. Strange that they don't
though.
> As a recent Lisp beginner, I still remember that certain matters are
> far from obvious. It probably takes at least a few months to ``get
> it''.
>
Well, I'm glad you still remember your mortal existence.
> At times I felt like a Fortran programmer trying to learn OO, to use
> an analogy.
>
> > If not, then perhaps you could wonder what it is about the other
> > syntaxes that are good, and maybe even synthesize a new syntax that has
the
> > benefits of both approaches, and the drawbacks of neither.
>
> What's good about those other syntaxes is that you can achive a nice
> looking, condensed notation that is excellent for expressing the kinds
> of textbook examples that it was designed to support.
>
That's a sweeping generalisation, given the huge range of software
applications that have been written in an enormous range of languages.
Again, even if it were true I hardly see that it's a criticism of a language
to say that it's suitable for the use cases it was designed to support.
Excuse me, isn't that the *point* of language design?
> The right approach is to allow for those other syntaxes: that's why in
> Lisp you can write your own lexical analysis, to design a read syntax
> from the ground up.
>
I think I see what's coming here ...
> If you prefer writing a[i, j] = f(x += 3, 4) you can have that.
> There is a piece of portable Lisp freeware which will give you that
> notation, in fact.
>
> > > Dividing a language into statements and expressions is idiocy. You end
> > > up with inconsistencies, like not being able to use a statement
> > > somewhere, because the syntax calls for an expression.
> >
> > Could you give an example of something you'd like to do, say, in C++,
but
> > can't?
>
OK, so it's all right to implement C++ in Lisp, but it isn't all right to
use the same language processed by a fixed-purpose compilation system?
Pardon me, but this begins to sound a little like bigotry. Not that there's
anything wrong with that: at least you always know exactly where you are
with a bigot :-)
> No; Turing completeness means that I can do anything in C++, like for
> instance write a poorly optimized Lisp implementation, and then write
> the rest of the program in that.
>
> I can think of things I'd like to express directly, but they are so
> out of reach of C++ that it's inconceivable to even want them in C++.
> To provide them, C++ would have to become something so radically
> different that this new thing couldn't even be viewed as a derivative
> of C++.
>
Well. bully for you. What you want is DWIM mode, apparently. Those with less
lofty goals, however, do sometimes find that other langauges than Lisp are
entirely appropriate for their purposes.
> What I'd like to be able to do is to write completely custom syntax
> and semantics to suit every whim. This destroys the very concept
> behind a language like C++, which takes hard-coded syntax and
> semantics as one of its founding design principles.
>
Indeed. It also completely nullifies the point of common syntax and
semantics. If you are prepared to write custom syntax and semantics to suit
your whim, you force other programmers to learn your whimsical constructs
before they can understand your programs. I'd call that poor engineering
design.
Programming languages are for communication between humans as well as for
expressing problem solutions to computers. Or doesn't anyone else ever read
any of your code? Even if they don't, wouldn't you imagine that returning to
your program after a gap of several months might be a painful experience if
the syntax and semantics of said program were completely customised?
> I don't just want new instances of hard-coded syntax that solves
> specific problems!
>
> > I wonder if we could tweak the C++ syntax a little to give you what
> > you want.
>
> That's like asking, could you make a few improvements to that hooker
> standing on the corner to turn her into wife material? Sure: just
> replace her disease-infested, drug-abused body, and then give her a
> new brain, and voila! But you now have a different person with a new
> identity. :)
I will refrain from further comment on the gender-biased choice of metaphor.
Suffice it to say that you don't seem to understand that a certain amount of
syntactic concreteness is necessary in order to keep programs
comprehensible. Different people are happy with different levels of
concreteness, which suit their different purposes. That's why some people
"don't get" Lisp. You might also be surprised to learn that even some people
who "do get" Lisp still prefer less abstract languages.
I'm quite happy to let you completely revise the syntax and semantics of an
environment you use by yourself. I'd rather not have to debug any of your
code under such circumstances, though.
Not everyone likes to program in metasyntacical generality. If you don't
like the set of programming abstractions implemented by a particular
langauge that's your perogative, but please don't expect everyone else (the
"idiots" that "don't get it", for example) to feel comfortable in your
particular ivory tower.
Steve Holden
> > "Kaz Kylheku" <k...@ashi.footprints.net> wrote ...
> >
> > > > > Dividing a language into statements and expressions is idiocy. You
end
> > > > > up with inconsistencies, like not being able to use a statement
> > > > > somewhere, because the syntax calls for an expression.
> I have a macro called FIND-BIND which provides custom syntax for
> retrieving multiple elements from a sequence by matching keys, and
> binding the results to lexical variables. It has useful subtleties;
> for example, multiple matches retrieve in left to right order. You can
> specify defaults if there are no matches, specify what parts of the
> elements to retrieve and what parts to use as keys, and what
> comparison function to use. This macro blows away a whole lot of
> tedious, and in some cases error-prone coding:
>
> (let ((name-list '(("joe" "smith")
> ("harry" "schiffer")
> ("harry" "potter"))))
> (find-bind (:test #'string-equal :key #'first :take #'second)
> ((j "joe") (h "harry") (h2 "harry") (b "foo") (c "bar"
> "x"))
> name-list
>
> ;; j is bound to "smith", h to "schiffer" and h2 to "potter"
> ;; b is bound to NIL (no match on "foo")
> ;; c is bound to "x" (no match on "bar", default value "x"
> taken).
> )
>
[...]
Nick Vargish
> There is simply no chance of doing commercial or industrial quality
> software without declarations. Period.
The Zope people might take exception to that wholly-unsubstantiated
claim.
Have you managed to _not_ use google in the past 24 hours?
According to someone who works there, the NY Stock Exchange uses
significant amounts of Python. To paraphrase, "the C++ project was
six weeks over deadline, the entire Python implementation was written
in two weeks, and is still in use."
Entire IDEs for Python are written in Python, and several of them are
at least as good as some of the commercial ones I've seen.
Nick
--
# sigmask.py || version 0.2 || 2003-01-07 || Feed this to your Python.
print reduce(lambda x,y:x+chr(ord(y)-1),'Ojdl!Wbshjti!=obwAqbusjpu/ofu?','')
JXStern
wrote:
>> There is simply no chance of doing commercial or industrial quality
>> software without declarations. Period.
>
>The Zope people might take exception to that wholly-unsubstantiated
>claim.
Well, I suppose if you wrap enough framework around it that you never
see the language, the declarations are, in principle, less important.
>Have you managed to _not_ use google in the past 24 hours?
Do they use Python? Yet, Google is not a transaction-based system
handling real money or even guarantying much of anything to anybody.
>According to someone who works there, the NY Stock Exchange uses
>significant amounts of Python. To paraphrase, "the C++ project was
>six weeks over deadline, the entire Python implementation was written
>in two weeks, and is still in use."
Reminds me of the R1/XCON expert system at DEC twenty years ago. The
Cobol crowd there was unable to build a configuration checker, so they
invited in Carnegie Mellon and John McDermott, who built a ... heck, I
forget, used to know all about this, but it was some kind of
rule-based, bleeding-edge technology, not Cobol. It worked, sort of,
for a while, with a crew of "knowledge engineers" massaging it. But
I'll betcha that someone like McDermott could have built it in Cobol,
and probably in half the time. It wasn't the shoes, after all.
Here, let me Google:
http://www.newi.ac.uk/jacksonk/public/ai/history.html
>Entire IDEs for Python are written in Python, and several of them are
>at least as good as some of the commercial ones I've seen.
Faint praise indeed. I used a couple of them, briefly, and yes, I've
used some really bad commercial IDEs. Then what?
J.
Martijn Faassen
> On 25 Feb 2003 16:18:57 -0500, Nick Vargish <n...@adams.patriot.net>
> wrote:
>>> There is simply no chance of doing commercial or industrial quality
>>> software without declarations. Period.
>>
>>The Zope people might take exception to that wholly-unsubstantiated
>>claim.
>
> Well, I suppose if you wrap enough framework around it that you never
> see the language, the declarations are, in principle, less important.
In Zope you do see the language and Zope is written in Python.
Anyway, Zope is a showcase of both strengths and weaknesses of Python.
I make my living programming Python (and working with the Zope framework).
But perhaps even though we're in business doing Python our code
is not "commercial quality", I don't know. :)
>>Have you managed to _not_ use google in the past 24 hours?
>
> Do they use Python? Yet, Google is not a transaction-based system
> handling real money or even guarantying much of anything to anybody.
I think you're underestimating Google; while they may not be explicitly
guaranteeing anything to their end users, it'd better perform pretty
well all the time or they'll be in trouble.
That said, I believe the performance critical parts of google are written
in C++. By all accounts Python is in use a lot within Google as well though.
Anyway, I agree it's an unsubstantiated statement to claim that
you can't do quality software without declarations; I believe the Smalltalkers
have been doing things like things for a while now, for instance.
Kaz Kylheku
You've got to be kidding. Forth is just a sequence of words. As such,
that is easy, but to understand the structure, you have to know how
the evaluation of each word transforms the stack. Given the words A B
C D, if you don't know what they do, you are in the dark. A B and C
could each deposit something on the stack that D consumes, so that
it's like the Lisp expression (D A B C). Or maybe C operates on the
results of A B, which is then fed to D, so that it's like (D (C A B)).
Or maybe the sequence causes a stack underflow. Effectively, the
second level of parsing, beyond just ``sequence of words'', is
conflated into evaluation. The calling conventions---how much mut be
put on a stack to satisfy a function---are under the program's
control.
The structure of Haskell is probably readable once you study the
grammar. I've spent only several hours studying Haskell, but got
nowhere. To me, even small examples in that language look like the
garbage characters that appear on the terminal when you have a noisy
serial cable. It's an ill-designed, ad-hoc monstrosity designed by
someone who thought that every programming language design problem can
be solved by slapping on more syntax.
But much of the structure of Lisp (though clearly not the semantics)
was obvious to me from the first point of contact. What required study
was the special notations: quote, backquote, # ,@ and so on. But even
for these, it was immediately obvious that, syntactically, they were
prefixes that apply somehow to the object that follows. When you can
see how something hangs together without touching a reference manual,
you can safely call it readable syntax.
Brian Quinlan
> think in any language... learn to type faster.
From Eric Raymond:
"That was my first surprise. My second came a couple of
hours into the project, when I noticed (allowing for
pauses needed to look up new features in Programming
Python) I was generating working code nearly as fast as
I could type.
http://www.linuxjournal.com/article.php?sid=3882
> Readability and maintainability are what counts.
True enough. Python tends to be more readable than C++/Java (for a
variety of reasons e.g. more builtin types, less extraneous syntax)
and type declarations can actually hurt maintainability because they
force a comittement that may have to be changed in the future.
> IDEs for statically-typed languages are able to auto-generate a lot more
> code.
Right. It's nice of them to do that work for you but I'd prefer if my
language simply didn't need such a feature.
> C++ sure. Java/C# with a good IDE, I doubt it. VB.NET/Delphi... no
> chance ;-)
It depends on the problem domain. For GUI programms, I would
definately go with C# in .NET. For server-side applications, I'd use
Python. Since you mentioned . NET, I'll point out that .NET is a lot
more dynamic than MFC because of the "object" common base. And
"object" is used quite frequently in the framework. Clearly Microsoft
decided, in those cases, that dynamic flexibility was more important
than type safety.
> More seriously... In general business markets, where you spend
> a lot of time re-using a huge variety of pre-written classes,
> good IDEs with statically-typed frameworks are far more productive.
I do C# and Python development. I really like VS .NET but, except for
GUI programming, I am still more productive in Python.
Cheers,
Brian
Shayne Wissler
>> Readability and maintainability are what counts.
>
> True enough. Python tends to be more readable than C++/Java (for a
> variety of reasons e.g. more builtin types, less extraneous syntax)
> and type declarations can actually hurt maintainability because they
> force a comittement that may have to be changed in the future.
Hurt maintainability? I don't think so. A change to a type name may cause
you to need to go mechanically change all the places it's used--but that's
easy compared to hunting down some obscure bug caused from not being able
to find the places to change in the first place.
Shayne Wissler
Brian Quinlan
> expressions, some are statements. This leads to bizarre restrictions,
> like not being able to write a statement where an expression is
> expected.
This is deliberate. Some common error patterns can be removed if
statements are different than expressions e.g.
while (a = 2)
....
I think that the only difference between C++/Java and Python, with
regards to expressions vs statements is that assignment is not an
expression in Python.
> There is no representation of Python source code a a Python data
> structure which would give rise to macro programming; consequently,
> the ability to define abstractions is severely limited.
Macro programming doesn't exist in Python because no one has yet
designed a maco system that doesn't have serious potential for abuse.
People have proposed Python macro systems over the years and they have
consistently been rejected because people might actually use them.
> A few compile to bytecode.
CPython (the official implementation) compiles to it's own set of
bytecodes.
Jython compiles to Java bytecodes.
Pyco and Pyrex convert to C code and then compile.
> There is an ANSI standard to which the vendors try to conform. Though
> you can use it as a scripting language, it's meant for real software
> development at any level, with the possible exception of fitting a
> full implementation of the language into a tiny embedded system.
Python runs on the Cray 3TE and the Palm Pilot. It is used by NASA and
by 3 person programming teams.
> Here is a Lisp and Python comparison page:
> http://www.norvig.com/python-lisp.html
This comparison seems fair. I'll sumarize the conclusion section:
1. it is an excellent language for the author's use :-)
2. it is easy to use
3. it is easier to read than Lisp (for people who have used neither)
4. Python code looks like pseudocode
5. Python doesn't do enough compile-time error checking
6. Python is ~10x slower than compiled Lisp
Brian Quinlan
> cluttered than perl for example.
Ruby is a nice language. I only have 2 criticisms:
1. immature libraries
2. the use of Perl magic variables e.g. $_
Cheers,
Brian
JXStern
wrote:
>Anyway, I agree it's an unsubstantiated statement to claim that
>you can't do quality software without declarations; I believe the Smalltalkers
>have been doing things like things for a while now, for instance.
You can drive a car without wearing a seatbelt or even opening your
eyes, but that doesn't make it a good idea.
Plenty of people do things the hard way in all walks of life, or
deliver half the results they could with a better tool, and brag about
it.
Or maybe you're DareDevil, blind to declarations but with lexical
senses super-developed over those of mere mortals, and you wear that
red jumpsuit when you program.
I've used languages with and without, and there is simply no
comparison, huge categories of errors that just don't occur if you
require declarations. Of course it doesn't solve all problems, and
just because a language requires declarations doesn't mean it's better
in all ways or even overall than one that does not. I like variable
type flexibility as well as the next guy, but what I do not like at
all are typos that the compiler/interpreter could have found.
Just tell me, how hard would it be to add an option to Python to
require declarations? Not hard at all. And the benefit would be
tremendous, for those who like to take advantage of tremendous
benefits. But nobody would force you to do so.
J.
Brian Quinlan
> you to need to go mechanically change all the places it's used--but that's
> easy compared to hunting down some obscure bug caused from not being
> able to find the places to change in the first place.
If you are just changing a name, then you will have very little to change in
Python.
The type name will only be present where objects are actually created (i.e.
not
everywhere that they are used) and the same global search/replace operations
will
work.
If you are changing the interface of a type, then the story gets a bit more
tricky.
Say, for example, you've decided to split up a class or interface into two
new
interfaces. So you are going from A to A, B and C (where C inherits from B
and
C).
In C++ or Java, you now have to figure out where A was used and change the
type declaration to one of A, B or C, depending on what methods the consumer
actually needs. In Python, you would be done after the split.
Regarding hunting down obscure bugs: Python will generate a nice exception,
at runtime, if you attempt to use a method that doesn't exist.
Surely you don't release software having only successfully compiled it? You
do
test all of your code live, right?
In Python, there is a nice builtin unit testing framework (similar to JUnit)
to catch
regressions.
Cheers,
Brian
Shayne Wissler
particular line of code was executed or not. That is *valuable*, for at
least two reasons:
- Unit tests can't catch type errors as reliably as a compiler--some lines
of code might not have been exercised by only running the unit tests.
- Often a compiler will dump all the type errors for a given file--you
don't have to keep running to failure and fix the problems line by line.
I don't know why it is that every time this issue comes up, proponents of
untyped languages fail to recognize or even to understand this issue.
> Surely you don't release software having only successfully compiled it?
> You do test all of your code live, right?
No, I release code whenever the Make completes successfully. Actually I dump
all the errors and warnings to /dev/null, and release whenever the planets
are aligned.
IOW: What kind of a ... question is that?!
Shayne Wissler
Tim Rowe
> as fast as c or c++.
For my postgrad dissertation I had to do a lot of number crunching on
big data files (adaptive digital filtering of millions of datapoints, if
you're interested). I decided to code in Python, and when I hit
performance bottlenecks to shift the critical code into C.
I never hit any performance bottlenecks, and I never used any C.
Brian Quinlan
> deliver half the results they could with a better tool, and brag about
> it.
There was an IEEE arcticle called something like "An Empirical
comparison of Python, C++ [a bunch of other languages]" (try
Google searching for it). I recall three results:
1. Python programmers produce the same amount of code/unit time
as C++/Java programmers
2. Python programs tend to be 3x shorter than their Java/C++
counterparts
3. The standard deviation in Python results was much smaller in
in the Python tests
Ignoring objective evidence, my experience suggests the same :-)
I use several languages in my daily development and I turn to Python
when I need something done quickly because experience has taught
me that that strategy is successful.
There are even a few projects that I have completed in Python and then
recoded in either C# or Java. The recoding effort was greater than the
original coding effort, which is really quite amazing considering that I had
already fully analysed the problem.
You can also look at the size of the files in the Python standard library
to get a feel for how little code you need to get things done in Python.
I do a lot of XML programming in C++ and Python. Python has a
complete DOM implementation in <1,000 LOC (it relies on a SAX
stream). In C++, I use Xerces, which uses >10,000 LOC for it's
DOM implementation (it relies on a SAX stream).
> I've used languages with and without, and there is simply no
> comparison, huge categories of errors that just don't occur if you
> require declarations.
Very true. I would argue that these errors don't appear very frequently
in practice and are easily detected at runtime.
> Of course it doesn't solve all problems, and
> just because a language requires declarations doesn't mean it's better
> in all ways or even overall than one that does not. I like variable
> type flexibility as well as the next guy, but what I do not like at
> all are typos that the compiler/interpreter could have found.
You will quickly get a runtime error if you misspelled something..
Also, have thought about the time that Python saves you by not having a
separate compile step?
> Just tell me, how hard would it be to add an option to Python to
> require declarations? Not hard at all. And the benefit would be
> tremendous, for those who like to take advantage of tremendous
> benefits. But nobody would force you to do so.
So would declarations be optional or not? If they are required then
Python becomes a lot less dynamic and you lose productivity.
There has been work done in the past were function arguments
could be (optionally) typed. The type checking was still done at
runtime though.
Cheers,
Brian
Brian Quinlan
lines
> of code might not have been exercised by only running the unit tests.
Then you should get a code converage tool and redesign your unit tests. I
feel very uncomfortable releasing code that has never actually been
executed.
The kind of type errors caught by compilers tend to be very coarse i.e.
the will tell you that you didn't pass a integer but not that you didn't
pass
an even natural number <= maxint / 2.
> - Often a compiler will dump all the type errors for a given file--you
> don't have to keep running to failure and fix the problems line by line.
Fair enough. This doesn't happen frequently enough, at least for me,
to be an issue.
> I don't know why it is that every time this issue comes up, proponents of
> untyped languages fail to recognize or even to understand this issue.
I think that we understand the issue but don't think that it is very
important.
> > Surely you don't release software having only successfully compiled it?
> > You do test all of your code live, right?
>
> No, I release code whenever the Make completes successfully. Actually I
dump
> all the errors and warnings to /dev/null, and release whenever the planets
> are aligned.
>
> IOW: What kind of a ... question is that?!
My point is that code converage is the only way to test software such that
it actually
has a reasonable chance of working. Unit tests are a great way of catching
such
errors. Those same tests, which you have to write anyway, will find type
errors
(even ones that the compiler doesn't).
Cheers,
Brian
Shayne Wissler
>> - Unit tests can't catch type errors as reliably as a compiler--some
> lines
>> of code might not have been exercised by only running the unit tests.
>
> Then you should get a code converage tool and redesign your unit tests. I
> feel very uncomfortable releasing code that has never actually been
> executed.
I agree with this in principle. In practice code-coverage tools can be
expensive--though for most commercial efforts the cost is worth it (last
time I bought it, Purify was several thousand dollars).
I noticed that Python had at least one code-coverage tool...
> The kind of type errors caught by compilers tend to be very coarse i.e.
> the will tell you that you didn't pass a integer but not that you didn't
> pass an even natural number <= maxint / 2.
I don't think that's a very interesting case. Most types programs deal with
are not mathematical.
>> - Often a compiler will dump all the type errors for a given file--you
>> don't have to keep running to failure and fix the problems line by line.
>
> Fair enough. This doesn't happen frequently enough, at least for me,
> to be an issue.
I think refactoring causes this type of thing often. Just changing a method
name will cause it.
>> I don't know why it is that every time this issue comes up, proponents of
>> untyped languages fail to recognize or even to understand this issue.
>
> I think that we understand the issue but don't think that it is very
> important.
I think you're just used to your tool of preference, and the only other
kinds of tools you can compare to lack the nice features of Python (e.g.,
C++), so it only seems that it's not important and/or bad to have typed
objects.
Typing is a good thing--it adds capability to a language. It also takes
quite a bit of effort to get it done and get it done right--so it's no
wonder that a lot of these grass-roots scripting languages don't have that
ability.
That doesn't mean that C++ is "better" than Python (actually I'd say the two
languages are not comparable on that level), it just means that Python
lacks what would be a nice feature.
Shayne Wissler
Kaz Kylheku
Yes it is, but only on April Fool's day! :)
> use the same language processed by a fixed-purpose compilation system?
> Pardon me, but this begins to sound a little like bigotry. Not that there's
No; the difference is between being locked to one notation, and having
a choice.
> I can think of things I'd like to express directly, but they are so
> > out of reach of C++ that it's inconceivable to even want them in C++.
> > To provide them, C++ would have to become something so radically
> > different that this new thing couldn't even be viewed as a derivative
> > of C++.
> >
> Well. bully for you. What you want is DWIM mode, apparently. Those with less
Or EWIM: express what I mean! Or GTHOOMW: get the hell out of my way!
:)
> lofty goals, however, do sometimes find that other langauges than Lisp are
> entirely appropriate for their purposes.
Yes; but you can't have the same non-lofty goals all your life. Once
you achieve your non-lofty goals, you then need slightly-lofty ones,
and after those, semi-lofty ones and so forth. Otherwise you are just
then an automaton, cranking out the same stuff over again.
> If you are prepared to write custom syntax and semantics to suit
> your whim, you force other programmers to learn your whimsical constructs
> before they can understand your programs. I'd call that poor engineering
> design.
No matter how you write software, you force other programmers to
understand what you have done. When you write a C++ function or class,
you are also designing custom syntax and semantics. You just have
limited power in what you can do---you don't control the evaluation of
the parameters, and they are just a linear sequence---but that doesn't
necessarily make it easier to understand what you have done.
We all have syntax in our heads; when we don't have it in the
language, we do the expansion as we type out the code. Valuable
information is filtered out in the process: the behavior is achieved
in the code, but the drama of the programming pattern is dissolved and
diluted in the expansion.
> Programming languages are for communication between humans as well as for
> expressing problem solutions to computers.
Exactly. So how do I communicate to you that I have a wonderful
programming pattern that neatly corresponds to a language construct,
if the programming language I'm using to express myself doesn't handle
this?
Once upon a time, some assembly language programmer had to wake up and
realize that there could something called a ``while loop'', and that
the notation could be used to program directly, instead of writing a
test with a forward branch over some code that has a backward branch.
> Or doesn't anyone else ever read
> any of your code? Even if they don't, wouldn't you imagine that returning to
> your program after a gap of several months might be a painful experience if
> the syntax and semantics of said program were completely customised?
No! Finally, in Lisp, I have a great time returning to code after
absences, like never before. The code I have most trouble with is the
one with no macros, that was written without any meta-thinking. I have
to reverse-engineer what I was thinking about when I wrote it. But
those macros, boy do they jog the memory and connect the dots.
> Suffice it to say that you don't seem to understand that a certain amount of
> syntactic concreteness is necessary in order to keep programs
> comprehensible.
I don't understand that *now*. But, to my credit, I did understand it
once. :)
> Different people are happy with different levels of
> concreteness, which suit their different purposes. That's why some people
> "don't get" Lisp. You might also be surprised to learn that even some people
Some people don't get computer programming at all. Some people don't
get checkbook balancing. So what?
> who "do get" Lisp still prefer less abstract languages.
Yes; usually the ones who run off and design them, and never mention
the four-letter L word to their new flock. If you have the ego of a
programming language designer, you will find the ideas in the Lisp
community very useful, but unfortunately, that community won't give
you the ego stroking you crave by actually using or approving anything
you come up with. What you have to do is invent a dumbed-down dialect
and find naive users elsewhere.
> I'm quite happy to let you completely revise the syntax and semantics of an
> environment you use by yourself.
No, not revise! Augment! Revision is usually stupid; you don't expect
something familiar to behave differently. You embed your syntax into
the environment, without breaking anything.
> Not everyone likes to program in metasyntacical generality.
That depends on what population you sample, obviously. If you sample
from among the programmers who actually know how to do this, or even
that it's possible to do in a straightforward way, you might find that
a great proportion likes it.
The observation that out of the entire set of all programmers, very
few do metasyntactic programming, does not support the conclusion that
programmers don't *like* it.
Out of the set of all humans, a small fraction are programmers. Thus
it would appear that humans don't like to program computers. But you
and I do, right?
> If you don't
> like the set of programming abstractions implemented by a particular
> langauge that's your perogative, but please don't expect everyone else (the
The point is not that I don't like the set, only being confined to a
set.
Justin Farley
>> Irrelevant. Fast typers can type code faster than they can
>> think in any language... learn to type faster.
>
> From Eric Raymond:
> "That was my first surprise. My second came a couple of
> hours into the project, when I noticed (allowing for
> pauses needed to look up new features in Programming
> Python) I was generating working code nearly as fast as
> I could type.
"nearly" being the operative word. Typing speed isn't a limitation.
>> Readability and maintainability are what counts.
>
> True enough. Python tends to be more readable than C++/Java (for a
> variety of reasons e.g. more builtin types, less extraneous syntax)
I find the explicit declaration of types more readable. I do however
like the lean syntax of Python (in particular the use of indentation for
structure).
> and type declarations can actually hurt maintainability because they
> force a comittement that may have to be changed in the future.
This has been debated before, but I feel that the *constraint* of type
declarations actually helps maintainibility across subsystem boundaries
(component orientation). For example, here is my contract world, I
won't break it, and if I do I'll release a new version so you can stick
with the old version until you're ready to re-compile against the new
version with incompatibilities statically pointed out at compile-time.
You don't need to worry about any of my internal unit tests.
> It depends on the problem domain. For GUI programms, I would
> definately go with C# in .NET. For server-side applications, I'd use
> Python.
That's interesting. Is it the re-use of other classes (GUI frameworks),
that makes C#/Java more preferable for GUI programs, whereas with
server-side apps you are working in relatively clean/controlled
environment... or what?
> Since you mentioned . NET, I'll point out that .NET is a lot
> more dynamic than MFC because of the "object" common base. And
> "object" is used quite frequently in the framework. Clearly Microsoft
> decided, in those cases, that dynamic flexibility was more important
> than type safety.
MFC isn't the right comparison to make IMO. COM to .NET is the move MS
made, dragging VB kicking and screaming. The VB community has gradually
moved from a dynamic to a statically typed language (first with Option
Explicit, and now Option Strict in VB.NET). The fact that VB'ers have
been there done that with (albeit clumsy) dynamic typing, and now
recommend Option Strict, is counter testament.
--
Justin
JXStern
wrote:
>There was an IEEE arcticle called something like "An Empirical
>comparison of Python, C++ [a bunch of other languages]" (try
>Google searching for it).
Links off the Python page:
http://www.ipd.uka.de/~prechelt/Biblio/jccpprtTR.pdf
An empirical comparison of C, C++, Java, Perl, Python, Rexx, and Tcl
for a search/string-processing program
Lutz Prechelt (prec...@ira.uka.de)
Fakult ¨ at f ¨ ur Informatik
Universit ¨ at Karlsruhe
D-76128 Karlsruhe, Germany
+49/721/608-4068, Fax: +49/721/608-7343
http://wwwipd.ira.uka.de/EIR/
Technical Report 2000-5
March 10, 2000
--
Oh boy:
"The sample of programs used here comprises only those that passed the
acceptance test. Several subjects decided to give up after zero, one,
or several attempts at passing this test."
"Taken together, I expect that the script and non-script programmer
populations are roughly comparable — at least if we ignore the worst
few from the non-script group, because their would-be counterparts in
the script group have probably given up and not submitted a program at
all. Let’s keep this in mind for the interpretation of the results
below."
Sample size small, average qualifications and expertise both low and
uncontrolled, many dropouts, ... and a toy problem. Whatever the
validity, it's entirely unclear that it scales to anything
interesting.
> I recall three results:
>1. Python programmers produce the same amount of code/unit time
> as C++/Java programmers
Including what for testing? I'd have to re-read the article to see
what they did about failing acceptance.
>2. Python programs tend to be 3x shorter than their Java/C++
> counterparts
What language feature could possibly account for that - list datatypes
and string operators? Ah yes, remember the task.
>3. The standard deviation in Python results was much smaller in
> in the Python tests
If they average shorter, the deviation better be smaller!
>Ignoring objective evidence, my experience suggests the same :-)
??
>I use several languages in my daily development and I turn to Python
>when I need something done quickly because experience has taught
>me that that strategy is successful.
What do you choose when you need to "quickly" complete something which
is going to be 10,000 LOC?
>There are even a few projects that I have completed in Python and then
>recoded in either C# or Java. The recoding effort was greater than the
>original coding effort, which is really quite amazing considering that I had
>already fully analysed the problem.
>
>You can also look at the size of the files in the Python standard library
>to get a feel for how little code you need to get things done in Python.
>I do a lot of XML programming in C++ and Python. Python has a
>complete DOM implementation in <1,000 LOC (it relies on a SAX
>stream). In C++, I use Xerces, which uses >10,000 LOC for it's
>DOM implementation (it relies on a SAX stream).
OK, so if you're doing XML, let me guess that what counts again is
string processing. Python's native string facilities are strong. It
might take the development of a set of nice utility functions in C++
to do the equivalent, and you might or might not want to count that in
LOC. If you don't build some nice utilities, you will get a huge
expansion.
>> I've used languages with and without, and there is simply no
>> comparison, huge categories of errors that just don't occur if you
>> require declarations.
>
>Very true. I would argue that these errors don't appear very frequently
>in practice and are easily detected at runtime.
That's requiring white-box testing, and putting the responsibility for
quality on testing, rather than building it in. This is a TQM no-no.
Typos rare? Who are you kidding?
>> Of course it doesn't solve all problems, and
>> just because a language requires declarations doesn't mean it's better
>> in all ways or even overall than one that does not. I like variable
>> type flexibility as well as the next guy, but what I do not like at
>> all are typos that the compiler/interpreter could have found.
>
>You will quickly get a runtime error if you misspelled something..
You will more quickly get a runtime error if you don't declare
something. And much more certainly.
>Also, have thought about the time that Python saves you by not having a
>separate compile step?
Compared to what? Yes, I've mostly used VB and SQL in recent years,
and neither requires a significant compile step during development.
That's why I prefer them to C++ (that, and doing GUI development in VB
is 10x faster and easier for a number of reasons).
>> Just tell me, how hard would it be to add an option to Python to
>> require declarations? Not hard at all. And the benefit would be
>> tremendous, for those who like to take advantage of tremendous
>> benefits. But nobody would force you to do so.
>
>So would declarations be optional or not?
The developer gets to choose by setting a pragma, or whatever.
>If they are required then
>Python becomes a lot less dynamic and you lose productivity.
You spend a little more time writing declarations, maybe 5% of your
LOC, and you make it up several times over in testing, and you make it
up 100 times over by not shipping bugs.
>There has been work done in the past were function arguments
>could be (optionally) typed. The type checking was still done at
>runtime though.
The little Python I've written, I was writing assertions in functions
to type-check things. I was told this was non-Python style. Well,
that's fine for little hacks that I run myself, but not for stuff I'm
going to ship.
J.
Brian Quinlan
> expensive--though for most commercial efforts the cost is worth it (last
> time I bought it, Purify was several thousand dollars).
Yeah, buying Purify is expensive but it pays for itself pretty quickly.
> I noticed that Python had at least one code-coverage tool...
There is one included with the distribution.
> > The kind of type errors caught by compilers tend to be very coarse i.e.
> > the will tell you that you didn't pass a integer but not that you didn't
> > pass an even natural number <= maxint / 2.
>
> I don't think that's a very interesting case. Most types programs deal
with
> are not mathematical.
You can make similar arguments for other types e.g. strings containing only
ASCII characters.
> I think you're just used to your tool of preference, and the only other
> kinds of tools you can compare to lack the nice features of Python (e.g.,
> C++), so it only seems that it's not important and/or bad to have typed
> objects.
What languages should I compare Python to? I am an proficient in Java, C++
and C#. I used to be pretty good with Lisp and Basic.
Cheers,
Brian
Brian Quinlan
> uncontrolled, many dropouts, ... and a toy problem. Whatever the
> validity, it's entirely unclear that it scales to anything
> interesting.
OK, but it is some evidence to boster my claim that Python is a more
productive language than C++. Is there any counter evidence?
> Including what for testing? I'd have to re-read the article to see
> what they did about failing acceptance.
Why would Python require more testing time? I would expect it to need less
because you can more easily express the tests.
> >2. Python programs tend to be 3x shorter than their Java/C++
> > counterparts
>
> What language feature could possibly account for that - list datatypes
> and string operators? Ah yes, remember the task.
There is a lot more to Python than that but having string fundamental types
is very important.
> What do you choose when you need to "quickly" complete something which
> is going to be 10,000 LOC?
I've written one 10,000+ LOC Python program in a solo development
environment. I would estimate that the C version would be over 50,000 LOC.
> OK, so if you're doing XML, let me guess that what counts again is
> string processing. Python's native string facilities are strong. It
> might take the development of a set of nice utility functions in C++
> to do the equivalent, and you might or might not want to count that in
> LOC. If you don't build some nice utilities, you will get a huge
> expansion.
Actually, the Xerces implementation depends on a Unicode string type defined
elsewhere, so that doesn't count against it.
> That's requiring white-box testing, and putting the responsibility for
> quality on testing, rather than building it in. This is a TQM no-no.
> Typos rare? Who are you kidding?
Why does it require white-box testing? Blackbox should be fine. You aren't
looking for type errors in particular, after all.
> You will more quickly get a runtime error if you don't declare
> something. And much more certainly.
OK.
> The developer gets to choose by setting a pragma, or whatever.
That wouldn't work unless the pragma were global.
> You spend a little more time writing declarations, maybe 5% of your
> LOC, and you make it up several times over in testing, and you make it
> up 100 times over by not shipping bugs.
When you define an interface (or abstract class), write a type declaration,
write an overloaded method (*), or do a cast (*), you are servicing your
compilers type system. That would account for a lot more than 5% of my
C#/C++ code.
My intuition (supported by that article that I referenced) is that Python
programs have a lower defect rate than C++/Java/C# programs.
> The little Python I've written, I was writing assertions in functions
> to type-check things. I was told this was non-Python style. Well,
> that's fine for little hacks that I run myself, but not for stuff I'm
> going to ship.
Why? Do have have actual experience with Python programs with high defect
rates due to lack of type checking?
(*) sometimes there are other purposes for these constructs
Cheers,
Brian
Brian Quinlan
> declarations actually helps maintainibility across subsystem boundaries
> (component orientation). For example, here is my contract world, I
> won't break it, and if I do I'll release a new version so you can stick
> with the old version until you're ready to re-compile against the new
> version with incompatibilities statically pointed out at compile-time.
> You don't need to worry about any of my internal unit tests.
I would never care out YOUR unit tests; I care about mine. If I upgrade one
of your components and it breaks my unit tests then I would either use the
previous version or fix my code until it pases my unit tests again.
The downside of your contract is that I have to follow it strickly. This is
a real example that I recently encounted: I write Python bindings for a C++
XML parser. I want to be able to use a Python XML serialization library to
convert a DOM to an XML document. If the DOM were being used in C++/Java,
I'd have to satisfy an interface of over 100 methods. But since Python only
cares about methods that it actually uses, I only have to implement the 10
methods that are actually used by the serializer.
It also lets you do things that the designer of the library didn't
anticipate. Another example: you have a string pattern matching library
written in C++. The interface expects strings. You want to pass your larger
than memory sequences of DNA base pairs e.g. "ATGCD.....". You are screwed.
In Python, I would create my own object type that acts "close enough" to a
string that the library would accept it e.g. it would need to support
indexing, length reporting, etc.
> That's interesting. Is it the re-use of other classes (GUI frameworks),
> that makes C#/Java more preferable for GUI programs, whereas with
> server-side apps you are working in relatively clean/controlled
> environment... or what?
It's because the VS .NET IDE has an amazing GUI builder. If someone ever
finishes the Python .NET compiler then I'll use that.
Cheers,
Brian
Robert Klemme
"Brian Quinlan" <br...@sweetapp.com> schrieb im Newsbeitrag
news:d83d013e.03022...@posting.google.com...
> > IMHO ruby has a clear syntax, too. This is much easier to read and
less
> > cluttered than perl for example.
>
> Ruby is a nice language. I only have 2 criticisms:
> 1. immature libraries
This is because ruby is still quite new. Apart from that it has not much
to do with the cleanness of the syntax.
> 2. the use of Perl magic variables e.g. $_
I think they are less magic, they're simply global variables. Or did I
miss something? IMHO, it is ok to use them for small scripts since they
keep those scripts short and concise. But you can get away without using
them, which I recommend for larger projects.
robert
Anton Muhin
> You've got to be kidding. Forth is just a sequence of words. As such,
> that is easy, but to understand the structure, you have to know how
> the evaluation of each word transforms the stack. Given the words A B
> C D, if you don't know what they do, you are in the dark. A B and C
> could each deposit something on the stack that D consumes, so that
> it's like the Lisp expression (D A B C). Or maybe C operates on the
> results of A B, which is then fed to D, so that it's like (D (C A B)).
> Or maybe the sequence causes a stack underflow. Effectively, the
> second level of parsing, beyond just ``sequence of words'', is
> conflated into evaluation. The calling conventions---how much mut be
> put on a stack to satisfy a function---are under the program's
> control.
syntax). Defenitely there is a lot of trickery with : etc, but Lisp's
macros are not a piece of cake either.
> The structure of Haskell is probably readable once you study the
> grammar. I've spent only several hours studying Haskell, but got
> nowhere. To me, even small examples in that language look like the
> garbage characters that appear on the terminal when you have a noisy
> serial cable. It's an ill-designed, ad-hoc monstrosity designed by
> someone who thought that every programming language design problem can
> be solved by slapping on more syntax.
Quite different for me. I could read Haskell programs and write my own
in several hours. Lisp took much more time. Actually, for me Lisp code
looks much more "garbage characters that appear on the terminal when you
have a noisy serial cable. It's an ill-designed, ad-hoc monstrosity
designed by someone who thought that every programming language design
problem can be solved by slapping on more syntax.". Since I think Lisp
is great.
> But much of the structure of Lisp (though clearly not the semantics)
> was obvious to me from the first point of contact. What required study
> was the special notations: quote, backquote, # ,@ and so on. But even
> for these, it was immediately obvious that, syntactically, they were
> prefixes that apply somehow to the object that follows. When you can
> see how something hangs together without touching a reference manual,
> you can safely call it readable syntax.
See above.
Anton.
Nick Vargish
> Do they use Python? Yet, Google is not a transaction-based system
> handling real money or even guarantying much of anything to anybody.
Google is a business. The quality of their product directly affects
the success of that business. That makes their work commercial, does
it not?
Or are you simply changing your definitions to counter my points?
Nick
--
#include<stdio.h> /* SigMask 0.3 (sig.c) 19990429 PUBLIC DOMAIN "Compile Me" */
int main(c,v)char *v;{return !c?putchar(*v-1)&&main(0,v+ /* Tweaks welcomed. */
1):main(0,"Ojdl!Wbshjti!=obwAqbusjpu/ofu?\v\1");} /* build: cc -o sig sig.c */
Shayne Wissler
"Brian Quinlan" <br...@sweetapp.com> wrote in message
news:qKZ6a.337329$sV3.10...@news3.calgary.shaw.ca...
> > I think you're just used to your tool of preference, and the only other
> > kinds of tools you can compare to lack the nice features of Python
(e.g.,
> > C++), so it only seems that it's not important and/or bad to have typed
> > objects.
>
> What languages should I compare Python to? I am an proficient in Java, C++
> and C#. I used to be pretty good with Lisp and Basic.
I don't have any particular language in mind.
Shayne Wissler
Brian Quinlan
>
> I think they are less magic, they're simply global variables. Or did I
> miss something?
http://www.ruby-lang.org/en/man-1.4/variable.html#variables
They are variables that are set by a variety a things. For example, $\ is
the output separator for print and $! contains the information message from
the last exception.
> IMHO, it is ok to use them for small scripts since they
> keep those scripts short and concise. But you can get away without using
> them, which I recommend for larger projects.
The problem is that, if they are used (and if they are in the language, they
will be), then you will have to learn them to make sense of other people's
code. And I wouldn't look forward to memorizing the meanings of about 20
variables with names like $;.
Cheers,
Brian
JXStern
wrote:
>> Do they use Python? Yet, Google is not a transaction-based system
>> handling real money or even guarantying much of anything to anybody.
>
>Google is a business. The quality of their product directly affects
>the success of that business. That makes their work commercial, does
>it not?
>
>Or are you simply changing your definitions to counter my points?
Just analyzing the evidence, dude.
Are you saying that the production code for Google is written in
Python? Still haven't quite got even that much scoped out.
J.
Brian Quinlan
other
> > > kinds of tools you can compare to lack the nice features of Python
> > > (e.g., C++), so it only seems that it's not important and/or bad to
have
> > > typed objects.
> >
> > What languages should I compare Python to? I am an proficient in Java,
C++
> > and C#. I used to be pretty good with Lisp and Basic.
>
> I don't have any particular language in mind.
So you are saying that Python's dynamic typing is a weakness but you can't
point me to a language, with static typing, that is better?
Cheers,
Brian
JXStern
wrote:
>> Sample size small, average qualifications and expertise both low and
>> uncontrolled, many dropouts, ... and a toy problem. Whatever the
>> validity, it's entirely unclear that it scales to anything
>> interesting.
>
>OK, but it is some evidence to boster my claim that Python is a more
>productive language than C++. Is there any counter evidence?
Productive for toy problems does not necessarily equate to productive
for large problems. It's like the old argument that Basic is much
more "productive" than Pascal, because Basic came with a matrix
inversion operator, so long Pascal programs were just one easy to read
line in Basic. Or, the entire APL language, which was "write-only".
Programs could be one line long, but a week later, even their own
authors couldn't understand or work with them. Etc, etc, etc.
>> Including what for testing? I'd have to re-read the article to see
>> what they did about failing acceptance.
>
>Why would Python require more testing time? I would expect it to need less
>because you can more easily express the tests.
I would think the tests are basically external and independent of
language. Python needs more testing time, because by your own
recommendation, that's how you look for undeclared variables.
>> >2. Python programs tend to be 3x shorter than their Java/C++
>> > counterparts
>>
>> What language feature could possibly account for that - list datatypes
>> and string operators? Ah yes, remember the task.
>
>There is a lot more to Python than that but having string fundamental types
>is very important.
For this problem, string/list datatypes look very important. Please
nominate your favorite one or two features for general use, that you
think might explain program brevity.
>> What do you choose when you need to "quickly" complete something which
>> is going to be 10,000 LOC?
>
>I've written one 10,000+ LOC Python program in a solo development
>environment. I would estimate that the C version would be over 50,000 LOC.
Tell us what happened with the 10,000 LOC program. Is it in
production today, by anyone other than you?
>> That's requiring white-box testing, and putting the responsibility for
>> quality on testing, rather than building it in. This is a TQM no-no.
>> Typos rare? Who are you kidding?
>
>Why does it require white-box testing? Blackbox should be fine. You aren't
>looking for type errors in particular, after all.
Because a typo on an untested line would blow the program, and you
haven't necessarily even touched a line, without white box testing.
>> The developer gets to choose by setting a pragma, or whatever.
>
>That wouldn't work unless the pragma were global.
Quite. IDE option, however you want to do it. Or heck, make it local
to modules or procedures.
>> You spend a little more time writing declarations, maybe 5% of your
>> LOC, and you make it up several times over in testing, and you make it
>> up 100 times over by not shipping bugs.
>
>When you define an interface (or abstract class), write a type declaration,
>write an overloaded method (*), or do a cast (*), you are servicing your
>compilers type system. That would account for a lot more than 5% of my
>C#/C++ code.
Using built-in types is the major use, and avoiding accidental casts,
not specifying casts, is the major benefit. Function declarations
that specify types are not variable type declarations as such ...
well, I guess specifying the return type qualifies. OK, 6%.
>My intuition (supported by that article that I referenced) is that Python
>programs have a lower defect rate than C++/Java/C# programs.
Per line? Meaning what by defect? My intuition is that most
reasonable definitions of defects per line would be constant across
languages, anyway any language north of assembler, except that you'd
eliminate probably the most common single defect, undeclared
variables, if you don't count those caught at (pseudo-)compile time.
>> The little Python I've written, I was writing assertions in functions
>> to type-check things. I was told this was non-Python style. Well,
>> that's fine for little hacks that I run myself, but not for stuff I'm
>> going to ship.
>
>Why? Do have have actual experience with Python programs with high defect
>rates due to lack of type checking?
Because I spent sufficient time cursing at Python for not catching
typos, just as one would expect from basic language design principles,
as I have outlined here. The only worse experience I can recall in
recent times was writing Windows 2.x Petzold-style (message loop) code
in C, where it was all too easy to confuse handles and hdc's and lock
up the freakin' system, because both were simple int's.
Just watch over the shoulder of any Python programmer for an hour, and
count the errors due to variable name typos. Just because you're used
to it, doesn't mean it isn't happening constantly.
J.
Shayne Wissler
Well, no, that's not what I said. I said typing is a good feature, that
python would be *better* with it.
Shayne Wissler