What's better about Ruby than Python?

[David Mertz]

|Anyway, I still don't see a compelling reason why class statements
|couldn't/shouldn't be mutating, rather than rebinding. Is there one?

I don't think there is any reason why the statement 'class' COULD NOT do
what you describe. But doing so seems much less Pythonic to me.

In Python, there are a bunch of statements or patterns that ALWAYS and
ONLY binds names. Having something that sometimes binds names, and
other times mutates objects... and you cannot tell the difference
without finding something that may be far away in the code.... well,
that's not how Pythonistas like to think about code.

In the first appendix to my book (<http://gnosis.cx/TPiP> for the free
version) I make quite a point of explaining what Python does without the
sort of "convenient fiction" that most intros/summaries use. That is,
usually the difference between binding a name and assigning a value is
sort of brushed over, I guess so previous C, Pascal, Perl, Basic, etc.
programmers won't get freaked out. I know Alexander already knows
this... but heck, why miss some self-aggrandizement?

Yours, David...

X-Shameless-Plug: Buy Text Processing in Python: http://tinyurl.com/jskh

 

[Jacek Generowicz]

this one?

"Why numbering should start at zero"
http://www.cs.utexas.edu/users/EWD/ewd08xx/EWD831.PDF

Bingo !

Thanks.

 

[Doug Tolton]

Doug Tolton

For that domain. And rarely does the author of a package,
much less a macro, understand "the domain as understood by other
people" vs. personal understanding.

It depends what you are talking about. If you are talking about
making some large cross industry library I might be inclined to agree,
but when it comes to building good high level abstractions within a
company, this argument doesn't make sense. Any feature has to be used
in the proper context for it to be useful, Macros are also this way.

This topic has come up before. Laura Creighton made several
comments on macros, the most notable of which is:

lac:
] Writing your own Lisp Macro System is better than sex. I
] _know_ -- 18 year old me turned down _lots_ of opportunities
] for sex to go hack on her macro system. Thus if we introduce
] this to the language, I think that it is _inevitable_ that we will
] fragment the Python community into a plethora of mutually
] unintelligble dialects. I don't want this. Thus I don't want a
] macro facility in the language _because_ it would be so cool.

I just don't find that argument compelling. By that logic we should
write the most restrictive language possible on the most restrictive
platform possible (ie VB on Windows) because allowing choice is
clearly a bad thing.

Don't introduce a feature because it would be so cool that everyone
would use it? That's just plain weird.

The Python Core language would still always be controlled by Guido,
but I don't see the problem with a community of people writing cool
macro's for python.

Linux is based on this concept of allowing people to extend the
system, it doesn't seem to have suffered from it.

That doesn't mean it *shouldn't* be available [in Python].
Python is Open Source, how would someone writing a
Macro lock you in? Just don't use the macro.

Another writing from Laura seems relevant:
http://mail.python.org/pipermail/python-list/2001-May/042102.html

My interepretation - I don't customize my apps, nor even
my .cshrc (except for one alias (alias ls 'ls -l \!* | grep ^d')
an 'unset noclobber', 'set ignoreeof', and the PATH and
LD_LIBRARY_PATH - and I wish I didn't need those)
I don't, because I don't like to think. At least not spend my
time puzzling out slight changes. I like my changes either
none or a lot, that is, use Python as-is or write a converter
(or use another language).

Same argument as above, I don't agree with this logic. Python is a
great language, that doesn't mean it couldn't be better though. If
that were the case development would be cease.

Why do we allow people to write functions even, I mean you have to
learn the syntax for calling them, what the variables are and what
they do. Bah, we should make everyone use only built in functions, if
they want a different one, use a different language. What? It makes
no sense to me.

That's not the argument against them. It's that they are too useful,
each person makes their own dialect, the community breaks down
as the different branches do their own thing, and one person's so-
called "Python" code looks different than another's.

So don't allow people to customize the system huh? They why is Python
Open Source? That's the *entire* point of Open Source, so that people
can tweak and customize to their own environment. Do you have any
specific examples that are comparable where customization broke a
community down? This sounds like baseless hypothetical speculation to
me.

I know I am nowhere near as good a language designer as Guido,
Larry Wall, Matz, and the others, though I think I'm pretty decent.
I don't have the essential hubris to say that I know better how
to tweak Python-the-language to fit my own domain.

You are saying you don't know how to tweak a language to fit it your
specific domain better than a general puprose language? And you are
saying you are a pretty good language designer? If you don't know
your specific domain well enough to adapt a general purpose language
to it better than it is already written there are several
possibilities:
1) You don't know your domain that well
2) You work in a very general purpose domain
3) You aren't a very good language designer

Designing a good language is all about designing the right high level
abstractions. Even a medium skilled designer should be able to design
a language that maps better to their specific domain than a general
purpose domain (actually implementing is of course a vastly different
story). The whole point of Macro's though is to allow you to leverage
the facilities the language provides while at the same time abstacting
the common idioms.

You confuse two meanings of the word 'macro' here.
Any assembly language worth its salt has "macros", which
are pre-assembled sets of code. Use the macro and it
generates the code. But you can't use those macros to
rewrite the actual language like you can with hygenic
macros. It doesn't have the proper tail-biting recursive nature.

I am not talking about Assembly Macros. I was comparing hygenic
macros to the ability to make useful high level abstractions. Python
is an abstraction of Machine Language whereas Macros would allow you
to abstract Python.

You are in essence saying that Python is perfect, that no one could
make a more useful abstraction than it already has, and that saying
that one could do so is hubristic. I reject your argument and your
logic as specious. I think what makes Python so useful is the high
level abstractions it offers. The fact that it let's me do things
that *I* know are right for my domain. That it doesn't make the
assumption that Guido knows best for my domain (because I guarantee
you I know my domain better than Guido does). Python doesn't treat me
like the idiot programmer who can't be given a powerful tool because
it might hurt me. Ultimately this is the basis of Java / C# / Visual
Basic. Don't give the programmer room, he might hurt himself, or
abuse something. That paradigm is filled, there are many languages
that restrict programmers because they might misuse a feature, or they
are just too dumb to get it right. I say fine, leave the languages
like Java / C# / VB to those people, but let's make Python a language
that allows people the room to do it the way it needs to be done, not
so much the way Guido or whoever thinks it should be done.

Just my 2p



Doug Tolton
(format t "~a@~a~a.~a" "dtolton" "ya" "hoo" "com")

 

[Alexander Schmolck]

|Anyway, I still don't see a compelling reason why class statements
|couldn't/shouldn't be mutating, rather than rebinding. Is there one?

I don't think there is any reason why the statement 'class' COULD NOT do
what you describe. But doing so seems much less Pythonic to me.

In Python, there are a bunch of statements or patterns that ALWAYS and
ONLY binds names. Having something that sometimes binds names, and
other times mutates objects... and you cannot tell the difference
without finding something that may be far away in the code.... well,
that's not how Pythonistas like to think about code.

I agree this argument has merrit but I'm not sure I find it completely
compelling.

What's worse, looking at the top of a file and thinking "Ah so that's what
class Foo does" and

a) overlooking that somewhere below a 2nd class Foo gets created (and one
assumes both with instances that insidously claim to be 'Foos').
b) overlooking that somewhere below a 2nd class Foo gets mutated (and thus all
prexisting instances of it)

?

I think we'd agree that both options are generally undesirable (so one could
conceivably even make class statments with the same name in module scope raise
an exception and have the user jump through some hoops if he *really* wants
something along those lines, like having to define Foo #2 in a function and
have it returned).

But at least for b) I can think of one use-case I find rather compelling,
namely interactive development. I'd also think that the nasty surprise in a)
might well be worse than in b), because at least all instances that claim to
be Foos will behave the same.

As I said, I'm not hung up on this since admittedly b) isn't necessary for
convinient interactive development, which is what I'm really keen on. It just
means that one could paste/send code directly to the shell to achieve the
desired effect, but as long as there is *one general way* to mutate classes,
the IDE/editor etc. could just be made to do the extra work of silently
inserting the required python code for class mutation before sending to the
shell.


'as

 

[Doug Tolton]

Doug Tolton wrote:
...

"No programmer is an island"! It's not sufficient that *I* do not use
macros -- I must also somehow ensure that none of my colleagues does,
none of my clients which I consult for, nobody who posts code asking
for my help to c.l.py or python-help -- how can I possibly ensure all
of this except by ensuring that macros ARE NOT IN PYTHON?! "Slow" has
nothing to do with it: I just don't want to find myself trying to debug
or provide help on a language which I cannot possibly know because it
depends on what macros somebody's defined somewhere out of sight. Not
to mention that I'd have to let somebody else write the second edition
of the Nutshell -- if Python had macros, I would have to cover them in
"Python in a Nutshell".

Sadly, I would say that is something that would sway me. I love my
Python in a Nutshell book. I have that baby on my desk and I refer to
it *daily*. Although I'd say that's more extortion than a winning
argument!!

I just don't see Macros as the huge threat you do. As someone
mentioned in a previous post, the option would require to do declare
explicitly that you are using Macros. Why is that such a *huge*
issue? Why is it that the very *existence* of a Macro in a program
would offend your sensibilities?

They don't change the underlying language, they just add a

They may not change the "underlying" language but they sure allow anybody
to change the language that is actually IN USE. That is definitely NOT
what I want in a language for writing production-level applications.

I tend to disagree on this point. I like the idea of being able to
treat commonly reused idioms as if they are a part of the language.

I dearly hope that, if and when somebody gives in to the urge of adding
macros to Python, they will have the decency to FORK it, and use an
easily distinguishable name for the forked Python-with-macros language,
say "Monty". This way I can keep editing future editions of "Python in
a Nutshell" and let somebody else write "Monty in a Nutshell" without
any qualms -- and I can keep programming applications in Python, helping
people with Python, consulting about Python, and let somebody else worry
about the "useful abstaction" fragmentation of "Monty". If that "useful
abstaction" enters the Python mainstream instead, I guess the forking
can only be the last-ditch refuge for those of us (often ones who've seen
powerful macros work in practice to fragment language communities and
end up with "every programmer a different language"... do NOT assume that
fear and loathing for powerful macro systems comes from LACK of experience
with them, see also the Laura Creighton posts whose URLs have already
been posted on this thread...) who'd much rather NOT have them. But maybe
moving over to Ruby might be less painful than such a fork (assuming THAT
language can forever stay free of powerful macro systems, of course).

That certainly is one way for it to happen. I must say I certainly am
suprised at your vehemence. I don't think the natural state of human
beings is singular in purpose or design. I think the natural state of
humans is to fracture into competing camps / factions. *Every* human
system of any size has factions of some sort or another. I think the
power of Unix / Linux in general has been in working to allow these
factions to Co-exists peacefully. By trying to prevent factioning
within the community, I think you will ultimately only be successful
in driving people with different viewpoints out of the community.

I have nothing against macros *IN GENERAL*. I just don't want them *in
my general-purpose language of choice for the purpose of application
programming*: they add NOWHERE NEAR ENOUGH PRODUCTIVITY, in application
programming, to even START making up for the risks of "divergence" of
dialects between individuals, groups, and firms. If I was focused on
some other field than application programming, such as experimental
explorations, tinkering, framework-writing, etc, I might well feel quite
otherwise. But application programming is where the big, gaping hole
of demand in this world is -- it's the need Python is most perfectly
suited to fulfil -- and I think it's the strength it should keep focus
and iinvestments on.

Again, I disagree. It appears to me as though you've had some near
death experience with Macros that left a sore taste in your mouth.
Could you elaborate some on what your experience has been that turned
you so definitively sour on Macros?

Alex

Doug Tolton
(format t "~a@~a~a.~a" "dtolton" "ya" "hoo" "com")

 

[Aahz]

I just don't find that argument compelling. By that logic we should
write the most restrictive language possible on the most restrictive
platform possible (ie VB on Windows) because allowing choice is
clearly a bad thing.

It's all about maintaining balance. After all, Python forces you to
format your code in a specific way rather than allowing the freedom of
C/C++ or Perl.

Don't introduce a feature because it would be so cool that everyone
would use it? That's just plain weird.

The Python Core language would still always be controlled by Guido,
but I don't see the problem with a community of people writing cool
macro's for python.

Guido's mantra is readability. If you can come up with a concrete
suggestion for a macro system that won't affect Python's readability,
please propose a PEP. Otherwise, there's not much use arguing about it,
because people won't pay attention.

 

[John J. Lee]

Dangerously close to my name -- I hope it's not a typo and meant to
/be/ my name!

Rest assured, *definitely* no relation.


John

 

[Aahz]

Rest assured, *definitely* no relation.

No relation to what?

 

[Andrew Dalke]

Doug Tolton:

It depends what you are talking about. If you are talking about
making some large cross industry library I might be inclined to agree,
but when it comes to building good high level abstractions within a
company, this argument doesn't make sense. Any feature has to be used
in the proper context for it to be useful, Macros are also this way.

As a consultant, I don't have the luxury of staying inside a singular
code base. By your logic, I would need to learn each different
high level abstraction done at my clients' sites. And given the usual
software engineering experience a chemist or biologist has, those
are unlikely to be good.

I just don't find that argument compelling. By that logic we should
write the most restrictive language possible on the most restrictive
platform possible (ie VB on Windows) because allowing choice is
clearly a bad thing.

The inference is that programming language abstractions should
not be more attractive than sex. Classes, functions, and modules
are not. Arguing as you do is an all-or-nothing approach which
overly polarizes the discussion.

Linux is based on this concept of allowing people to extend the
system, it doesn't seem to have suffered from it.

I don't use Linus's kernel. The machine I have with Linux on it
runs a modified version distributed by a company and with all
the other parts needed to make a useful environment for my
work. And I loath the times I need to recompile the kernel,
even though I actually have done kernel mods on Minix in OS
class back in school.

In a similar vein, the different distributions once upon a time were
very divergent on where files were placed, how startup scripts
worked, which libraries were included, and how things were
configured in general (eg, which libc to use?). If I wanted to
distributed precompiled binaries, I was in a bind because I
would need to ship all the variations, even though it's just for
"Linux".

There's more consensus now on, but it took a lot of time.

In short, my comment is that Linux does allow the diversity,
it did cause problems, and people now decide that that
diversity isn't worth it, at least for most uses. For me as an
applications developer, that diversity just makes my life more
complicated.

Same argument as above, I don't agree with this logic. Python is a
great language, that doesn't mean it couldn't be better though. If
that were the case development would be cease.

What if Python had a marker so people could tell the intepreter that
the next few lines are Lisp code, or Perl, or Tcl, or any other language.
Would the result be more flexible? Yes? More powerful? Yes.
Better? I think not.

Why do we allow people to write functions even, I mean you have to
learn the syntax for calling them, what the variables are and what
they do. Bah, we should make everyone use only built in functions, if
they want a different one, use a different language. What? It makes
no sense to me.

Your argument of an extreme has no weight because it's different
than what I'm saying.

Extra power and flexibility can have bad effects, not just on the
language but on the community built around the language. Software
development is rarely a singleton affair, so a good language should
also optimize the ability for different people to use each others'
libraries.

Functions and modules and objects, based on experience, promote
code sharing. Macros, with their implicit encouragement of domain
specific dialect creation, do not.

So don't allow people to customize the system huh? They why is Python
Open Source? That's the *entire* point of Open Source, so that people
can tweak and customize to their own environment.

Err, no. I use open source because it's cheap, because the tools
are of good quality, because if something breaks I can track down
the problem, and as a risk management bonus, if the project ever
dies, I can still maintain things on my own.

I never, ever, ever, want to get into the case where I'm maintaining
my own private, modified version of Python.

Do you have any
specific examples that are comparable where customization broke a
community down? This sounds like baseless hypothetical speculation to
me.

Lisp.

A language which allows very smart people the flexibility to
customize the language, means there will be many different flavors,
which don't all taste well together.

A few years ago I tested out a Lisp library. It didn't work
on the Lisp system I had handy, because the package system
was different. There was a comment in the code which said
"change this if you are using XYZ Lisp", which I did, but that
that's a barrier to use if I ever saw one.

You are saying you don't know how to tweak a language to fit it your
specific domain better than a general puprose language? And you are
saying you are a pretty good language designer? If you don't know
your specific domain well enough to adapt a general purpose language
to it better than it is already written there are several
possibilities:
1) You don't know your domain that well
2) You work in a very general purpose domain
3) You aren't a very good language designer

4) a small change in a language to better fit my needs has
subtle and far-reaching consequences down the line. Instead,
when I do need a language variation, I write a new one
designed for that domain, and not tweak Python.

Designing a good language is all about designing the right high level
abstractions. Even a medium skilled designer should be able to design
a language that maps better to their specific domain than a general
purpose domain (actually implementing is of course a vastly different
story).

But if Python is HERE ............................... and my domain is HERE
I'm not going to try to force them together.

You are in essence saying that Python is perfect, that no one could
make a more useful abstraction than it already has, and that saying
that one could do so is hubristic.

I looked up 'hubris' just now. It's the wrong word for me to use.

http://dictionary.reference.com/search?q=hubris
hubris: Overbearing pride or presumption; arrogance

I don't mean 'overbearing', I mean perhaps 'confidence'.
'arrogance' is also the wrong word. Something without the
negative overtones.

Andrew
(e-mail address removed)

 

[Alex Martelli]

I agree this argument has merrit but I'm not sure I find it completely
compelling.

The counter-arguments you present in the following do not affect Mertz's
argument in the least, and thus cannot indicate why you don't find it
completely compelling. To rephrase David's argument: simplicity suggests
that a 'class' statement should always have the same fundamental semantics.
Since it SOMETIMES needs to bind a name, therefore, letting it ALWAYS
bind a name -- rather than sometimes yes, sometimes no, depending on
context -- is the only Pythonic approach. In other words,

class X: ...

ALWAYS means the same as:

X = <some metaclass>('X', (), <some dict>)

(for appropriate values of <some metaclass> and <some dict>) -- no ifs,
no buts. Can't be simpler. In particular, it's a LOT simpler than the
alternative semantics of

if <name X already defined in this scope>:
...something...
else:
...something totally different...

and I don't see you addressing this claim of greater simplicity in the
rest of your post. So, since you say you DON'T agree with this, could
you perhaps elaborate?


Now, regarding the rest of your post:

What's worse, looking at the top of a file and thinking "Ah so that's what
class Foo does" and

a) overlooking that somewhere below a 2nd class Foo gets created (and one
assumes both with instances that insidously claim to be 'Foos').
b) overlooking that somewhere below a 2nd class Foo gets mutated (and thus
all
prexisting instances of it)

?

I think we'd agree that both options are generally undesirable (so one

It's definitely undesirable to totally overlook either a rebinding or
a name, OR a mutation of a mutable object -- it makes no difference if
you're overlooking these crucial things for a class, a function, or what.
So, if you believe such distractions are frequent:

could conceivably even make class statments with the same name in module
scope raise an exception and have the user jump through some hoops if he
*really* wants something along those lines, like having to define Foo #2
in a function and have it returned).

....you're basically making a case for functional programming (perhaps of
the "single-assignment" variety): no object ever mutates, and each name
is bound ONCE only -- no rebinding. Undoubtedly such languages do in
fact eliminate the mistake of somebody thinking that...:

x = [1, 2, 3]
...much code overlooked...
if len(x) > 3:
<code the guy thinks will never execute>

in that either a rebinding of name x, such as
x = [6, 7, 4, 3]
or a mutation of the object, such as
x.append(23)
could in fact cause the code guarded by that 'if' to execute.

On the other hand, many people believe that functional programming is
hard -- that mutating data and rebinding names leads to a much easier
and free-flowing "style". Python (like most mainstream languages)
definitely accepts the "many people"'s opinion, and does allow mutation
of mutable objects (such as lists, clases, &c) and rebinding of names.
So does Ruby, etc, etc. It WOULD seriously and deleteriously impact
the concept of *FIRST-CLASSNESS OF ALL OBJECTS*, of course, if it was
any harder to rebind a name that happens to be bound to a class object
at some point, that one which happens instead to be bound to a list,
a function, or what-have-you; *THAT* wishy-washy choice would be a
terrible language design, while both Python's current design AND that
of (e.g.) Erlang are quite self-consistent even though opposites.

But this has nothing to do with any presumed desirability of statements
that do quite different things depending on what names happen to
be bound at the time said statements execute, of course.

But at least for b) I can think of one use-case I find rather compelling,
namely interactive development. I'd also think that the nasty surprise in
a) might well be worse than in b), because at least all instances that
claim to be Foos will behave the same.

Not really, unless you want to remove the limitation about "same scope"
too -- and get into a REAL mess. Each Foo can STILL refer to a
totally different object, just in different scopes, e.g.:

def aFoo(x):
if x%2:
class Foo:
def __str__(self): return 'odd!'
else:
class Foo:
def __str__(self): return 'even!'
return Foo()

someFoos = [aFoo(x) for x in range(8)]
for foo in someFoos:
print foo.__class__, foo

There -- how would you complicate the semantics of the class statement
in order to ensure the property you assert holds, namely "all instances
that claim to be Foos will behave the same"?! No, unless you redesign
and complicate the whole language to VASTLY deeper extent there is just
no way to ensure THAT. And as you go on to admit, that "one use-case"
is anything BUT "compelling" anyway -- modifying existing class objects
is quite sufficient to support an interactive environment that works
the way you'd like, if anybody's interested in doing so.


Alex

 

[Alex Martelli]

Doug Tolton wrote:
...

Linux is based on this concept of allowing people to extend the
system, it doesn't seem to have suffered from it.

Linus Thorvalds sits at the center and rejects a LOT of proposed
modifications to the kernel -- everybody's free to distribute such
patches separately, but they're NOT part of Linux. You can do
exactly the same with Python: send patches to Guido, have him
reject them, distribute them separately with no claim they're part
of Python (e.g., Stackless is in exactly this situation).

Powerful macros in Python would *BYPASS* the crucial filtering
role of the chief architect -- Linus or Guido in these cases. And
here's where the "attractive nuisance" side of powerful macros,
the allure that would make oodles of youngsters flock to them,
amplifies their danger: as it's much easier -- and satisfying to
many -- to "play the amateur language designer" by coding macros,
rather than (e.g.) to write device drivers for Linux, the flood
would quite likely be huge.

Same argument as above, I don't agree with this logic. Python is a
great language, that doesn't mean it couldn't be better though. If
that were the case development would be cease.

But WHO will make it better: Guido, whose skill as a language
designer is proven, or a hundred authors of sets of macros? It
is just too easy to "play language designer" -- far more people
will do it than are actually GOOD at language design.

Why do we allow people to write functions even, I mean you have to

Because "once and only once" is the mantra of programming: in a
language that lacks user-written functions or procedures, application
programmers have to copy-and-paste code, a horrid way to program.

learn the syntax for calling them, what the variables are and what
they do. Bah, we should make everyone use only built in functions, if
they want a different one, use a different language. What? It makes
no sense to me.

It doesn't, because the number of different SYNTAX FORMS needed for
powerful expression is incredibly tiny (so that even Python, which is
a small language, can easily afford redundance there!) while the
number of different COMPUTATIONS (functions and procedures) needed for
even a small application exceeds the numbers that can be reasonably
provided as built-ins. In other words, it makes no sense because you
are comparing, not even apples and oranges, but rather cantaloupes and
termites -- completely different things.

So don't allow people to customize the system huh? They why is Python
Open Source? That's the *entire* point of Open Source, so that people
can tweak and customize to their own environment. Do you have any

People can "tweak and customize" "their own environment" in Windows,
too (ever seen TweakUI and friends?!), so if your point was well taken
open-source would not exist. Since it does, it proves your point is
deeply mistaken.

Designing a good language is all about designing the right high level
abstractions. Even a medium skilled designer should be able to design
a language that maps better to their specific domain than a general

I entirely, utterly, totally and completely disagree with this point.

This is like saying that even a medium skilled musician should be
able to write music that plays better to their specific audience than
great music written by a genius who's never personally met any of
the people in the audience: it's just completely false. I want to
use a language designed by a genius, and I want to listen to music
written by Bach, Haendel, Mozart, and the like.

Moreover, judging by the way BY FAR most languages around are in
fact designed, it's abundantly clear that "medium skilled language
designers" are a VERY scarce breed indeed. And yet with powerful
macros everybody and their cousin WILL play the amateur language
designer. No thanks. If you want Dylan, Common Lisp, or Scheme,
you know where to find them. Please leave *ONE* language alone,
with the integrity and conceptual beauty AND usefulness that can
only come from having *ONE* designer -- a genius-level one --
firmly at the helm.

abuse something. That paradigm is filled, there are many languages
that restrict programmers because they might misuse a feature, or they
are just too dumb to get it right. I say fine, leave the languages
like Java / C# / VB to those people, but let's make Python a language
that allows people the room to do it the way it needs to be done, not
so much the way Guido or whoever thinks it should be done.

Let's leave Python as *ONE* language, WITHIN which everything does
work as you say -- not a *MYRIAD* subtly incompatible languages, each
partly designed by a different guys, mostly mediocre at language
design. Just as many languages are overly restrictive, so many
others are overly permissive (see the above mentioned examples)
thanks to powerful macro systems. PLEASE leave Python alone at the
SWEET SPOT, at JUST THE RIGHT COMPROMISE -- neither too permissive
nor too restrictive. GvR's genius (and/or luck) made it that way;
don't branch the language into a zillion mediocre ones.


Alex

 

[Alex Martelli]

I agree. In C++, where you see a book section heading like "Feature
X, Feature Y and Feature Z", it means that X, Y and Z have some
horrendous interactions that you have to commit to memory. In Python,
it means that X, Y and Z are so simple they all fit in one section ;-)

I do wonder if the tight constraint on C++ of being C+extra bits was
ever really justified.

I think it was: it allowed C++ to enter into MANY places that just
wouldn't have given it a thought otherwise, and to popularize OO
in this -- albeit indirect -- way.


Alex

 

[Andrew Dalke]

Doug Tolton:

explicitly that you are using Macros. Why is that such a *huge*
issue? Why is it that the very *existence* of a Macro in a program
would offend your sensibilities?

Since you reject the reasons both Alex and I give against macros,
it's kinda hard to come up with another one which you will accept.

I tend to disagree on this point. I like the idea of being able to
treat commonly reused idioms as if they are a part of the language.

A basic idea of Python is that Python is not enough for everything.
I need to write some extensions for Python in C.

If you accept that Python is not a language unto itself, then you
open yourself to the idea that if you want a new idiom you could
add it to your implementation of Python. If you really, really think
that list.sort() should return the sorted list, then it's an easy change
to the C code. If you want a if-the-else expression, then you can
get the patch for just that from sourceforge and apply it to your
copy.

C, then, is CPython's macro language.

Why not take that approach? If your idiom is that commonly
used, won't be be worth your while?

I don't think the natural state of human
beings is singular in purpose or design. I think the natural state of
humans is to fracture into competing camps / factions. *Every* human
system of any size has factions of some sort or another. I think the
power of Unix / Linux in general has been in working to allow these
factions to Co-exists peacefully. By trying to prevent factioning
within the community, I think you will ultimately only be successful
in driving people with different viewpoints out of the community.

The 'natural' size of those groups is a tribe, with about 30-50 people.
Humans lived that way for a long, long time. As I understand it, the
hunter/gatherer cultures were pretty violent. If you aren't a relative
you're the enemy.

That changed, and we developed ways to live together, though we
are no longer free to kill people who diss us. Restrictions have proved
helpful.

But computers are different in some respect. There is great freedom,
because there are few negative consequences. (Negative for life or
death, that is.) People are free to band together in small groups,
forgetting that by doing so they ignore certain advantages of scale.

Unix was definitely one of those, despite your assertion. Or have
you forgotten the Unix wars of the 80s? Linux as well, unless you've
forgotten the huge number of Linux distribution companies in the mid-
90s? (I remember the confusion of having to select from Slackware
vs. RedHat vs. ...)

Not having to choose, and depending on certain assumptions, lets
you focus on new things instead of having to think about the basics
all the time.

Of course it's wrong to ignore the basics. But computers are
wonderful (just like math) precisely because it is still possible for
a few people or even one to explore new or forgotten paths.
If you want macros, there's Lisp or Scheme or Dylan. If you want
other idioms, you could add them yourself. And if they are
useful enough, others will (slowly, all too slowly) use them.

Personally, I am rather annoyed that there hasn't been the next
great language. Back in the 80s and 90s I learned quite a few
languages: BASIC -> Pascal -> C -> "unix" (shell&awk&...) ->
Tcl -> Perl -> Python. Each one seemed more and more
powerful and flexible and usable. But I've not seen any new
language since 1995 (when I looked at Python) to tweak my
interest.

I will grant that Lisp or Scheme is the end-all and be-all of
languages. Where's the language between those and Python?

Again, I disagree. It appears to me as though you've had some near
death experience with Macros that left a sore taste in your mouth.
Could you elaborate some on what your experience has been that turned
you so definitively sour on Macros?

Or rather, it appears that Alex has observed problems with macros
(possibly in his projects, possibly from learning about other's
experiences) and decided that the advantages are not worth it.
That doesn't mean he himself needed a near-death experience.

It is possible to have a well-formed opinion that grabbing a live
power line which fell during a storm is a bad idea without having
done it before. That's another one of those things that let us have
a multi-billion population civilization

Andrew
(e-mail address removed)

 

[Chris Reedy]

Sadly, I would say that is something that would sway me. I love my
Python in a Nutshell book. I have that baby on my desk and I refer to
it *daily*. Although I'd say that's more extortion than a winning
argument!!

I just don't see Macros as the huge threat you do. As someone
mentioned in a previous post, the option would require to do declare
explicitly that you are using Macros. Why is that such a *huge*
issue? Why is it that the very *existence* of a Macro in a program
would offend your sensibilities?

I'm curious. Why do you feel such a need for macros? With metaclasses,
etc., etc., what significant advantage would macros buy you? Do you have
any examples where you think you could make a significantly crisper and
easier to read and understand program with macros than without.

Chris

 

[Andrew Dalke]

Doug Tolton:

You are saying you don't know how to tweak a language to fit it your
specific domain better than a general puprose language? And you are
saying you are a pretty good language designer?

I've been thinking about that.

Any language designer can design a language.

A good designer can add useful features.

A great designer knows when to keep features out of
the language.


I maintain that I am a good language designer, but not a
great one. There are enough average or mediocre designers
(law of large numbers almost guarantees a bell curve) that
I prefer ways to keep them from meddling into what I do.
Only somewhat facetiously: "Go play somewhere else
and don't bother me until you've learned something."

Facetious because anyone who knows me knows that
I enjoy explaining how things work and how they got to
be that way. It's the inability to get into another's shoes -
to understand view different than one's own - which annoys
me the most. A deficiency sadly typical of all too many
enthusiastic new language designers.

Andrew
(e-mail address removed)

 

[Andrew Dalke]

Alex:

Similarly, you do not tend to see in the
Linux community people who are convinced with sufficiently high
intensity that case sensitivity in a filesystem is idiocy (I do believe
that, but not intensely enough to drop Linux's other advantages.

And fewer who accept, much less understand, Jef Raskin's views
against a hierarchical file system at all. LEAP-LEAP!

To put it another way: I _DO_ have a different viewpoint from the
majority of Python users regarding case sensitivity -- I think it's
a wart in the language.

While I agree that the file system should be case insensitive but
case preserving (making internationalization all that more fun),
I confess to being fond of the

atom = Atom()

idiom. I know it breaks down, eg, for a function which returns
a newly created class, but it's too ingrained in me.

OTOH, I just thought about it some more. It's rare that I
only make a single instance, so

atom1 = Atom()
atom2 = Atom()
new_atom = Atom()

are more common than the 'atom =' version. I'll think
about it as I write new code.

Andrew
(e-mail address removed)

 

[Cliff Wells]

I entirely, utterly, totally and completely disagree with this point.

This is like saying that even a medium skilled musician should be
able to write music that plays better to their specific audience than
great music written by a genius who's never personally met any of
the people in the audience: it's just completely false. I want to
use a language designed by a genius, and I want to listen to music
written by Bach, Haendel, Mozart, and the like.

I was with you until this point. Your preference for music written by
geniuses only says that you are part of that audience for that type of
music; it says nothing about whether Mozart would play well to the
audience in a mosh pit. I don't think it invalidates your point about
programming languages, it's just a bad (in fact, incorrect) example.

Regards,

 

[John J. Lee]

No relation to what?

T*m*t*y R*e.

Did I miss something?


John

 

[Kenny Tilton]

.....


I'm curious. Why do you feel such a need for macros? With metaclasses,
etc., etc., what significant advantage would macros buy you? Do you have
any examples where you think you could make a significantly crisper and
easier to read and understand program with macros than without.

This macro:

(defmacro c? (&body code)
`(let ((cache :unbound))
(lambda (self)
(declare (ignorable self))
(if (eq cache :unbound)
(setf cache (progn ,@code))
cache))))

Let's me write this (for some slot of an instance):

(c? (+ 10 (left self))) ;; self ala smalltalk

Instead of this:

(let ((cache :unbound))
(lambda (self)
(declare (ignorable self))
(if (eq cache :unbound)
(setf cache (+ 10 (left self)))
cache)))

The above macro is a toy version of the real thing, which expands to this:

(make-c-dependent
:code '((+ 10 (left self)))
:rule (lambda (c &aux (self (c-model c)))
(declare (ignorable self c))
(+ 10 (left self))))

Clearly (c? (+ 10 (left self))) is more readable; all the dataflow
wiring is hidden. And the application is more maintainable should I
decide to change the implementation of my dataflow hack.

This kinda thing is when Lispniks use macros, to silently wrap code with
infrastructure necessary to satisfy some frequently arising requirement.

Especially cool above is that I capture the code in symbolic form in a
separate slot for debugging purposes, as well as hand it to the compiler
as the body of the lambda function. Took me way too long to think of
that when I had no idea what lambda was backtracing. But as soon as I
changed the macro, every (c? ) form (and there are hundreds) was debuggable.

I think macros are no harder to learn than an API, and most Lispniks
won't stray to any language that lacks procedural macros (ie, they are
useful), so maybe it comes down to what someone else said in this
thread: Python is not trying to be everything. Fair enough. Let Python
be Python, let Lisp be Lisp.

ie, If someone wants macros, they probably would also like special
variables and closures and lexical scope and multi-methods and they may
as well get it over with and learn Lisp and stop trying make Python more
than it wants to be.


--

kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Career highlights? I had two. I got an intentional walk from
Sandy Koufax and I got out of a rundown against the Mets."
-- Bob Uecker

 

[Aahz]

T*m*t*y R*e.
Did I miss something?

Yes, you did, but don't worry about it -- I delight in obscure jokes.