What's better about Ruby than Python?

[Asun Friere]

Man, it's clear that I've got an entire hate group around here to
exterminate!

Doesn't that just mean a lot of people will be able to talk about you
behind your back without your ever realising? I was wondering why all
those people were making allegations about small children, and you
didn't defend yourself. I thought it was all true!

At any rate, welcome to my killfile.

Like he cares?

Congratulations, you've just managed to deprive yourself of the often
insightful contributions of a regular poster to this newsgroup.

I wonder if you wouldn't be better off simply not participating in
Usenet groups at all. You'll save significant amounts of diskspace
without that killfile of yours, not to mention keystrokes. But please
feel free to add me to your much vaunted killfile as well, that way
you don't have to listen one of the few people who, in this thread,
actually took your question seriously and gave a substantive answer.

Ah yes, back to substance. I forgot to mention that Ruby ranges seem
much more intuitive than Python slicing. But I think the confusion,
to the extent that confusion does exist, is because Python has one
foot in the C-like 'n-1 indexed array' camp (in relation to ordinary
indexing of elements), and one in the '0 is not an ordinal, but a
point of origin,' camp (in relation to splitting). :ducks.

 

[Istvan Albert]

You certainly are a waste of my time, Tom. Welcome to my killfile. I'd
like to think that if I'm a waste of your time, it's for different reasons
and not ones of my own designing.

For what is worth Brandon is a hard working troll.
I can respect that. Look at all of his responses,
and all the effort to reward those that do respond
to his questions.

And all that killfiling, it is a gimmick but it works,
is funny to see whether you make it or not. It makes you
read what he says next. Posting on the usenet is
a sort of jungle, getting read is surviving. And
no matter how, mocked or not, laughed at or ridiculed
Brandon's parasitic postings live on.

It is not that easy and it takes an appreciable mental
exercise to attempt to juggle or manipulate people.

Istvan.

 

[Andrew Dalke]

Alexander Schmolck:

No it isn't. Like every other language I know python sucks in a variety of
ways (only on the whole, much less so), but I don't claim I know how to fix
this with a macro system.

What about the other way around? Make a macro for Lisp or
Scheme which converts Python into the language then evals
the result?

Given how easy it is to parse Python (there are several Python
parsers for Python) and the number of people who have popped
up with Lisp background, I'm surprised no one has done that
for fun. After all, there is Python for C, Java, .Net, and for
Python (PyPy) and variations like Pyrex and Vyper. But
none for Lisp?

(I think I remember mention of one some years ago, .. I think
*I* posted that link to c.l.py, but I don't remember when and
can't find it via Google.)

But show me how to write something like CL's series package that way (or
better yet, something similar for transforming array and matrix manipulations
from some reader-friendly representation into something efficient).

The Boost code for C++ suggests a different way to do the latter.
(I don't think templates are the same as hygenic macros.)

Andrew
(e-mail address removed)

 

[Jack Diederich]

Well, yes, I propose that x.__class__ return the *new* definition of X (like
in ruby, for example). I don't think that necessarily involves rebinding
anything "automagical", depending on how the lookup of x.__class__ works.

Can you give my any reason why you would *not* want all instances to be
updated on class redefinition?

Python names aren't special in any way so making names special when associated
with a class as opposed to a function or variable would make it less
intuitive for users. Pyhon also doesn't have anonymous classes, so an odd
but perfectly OK program could be written

class Anon(Exception): pass
raise_this_later(Anon) # stores it for later

class Anon(Exception):
def __str__(self):
return "Slightly different exception"
raise_this_later(Anon)

Explicit is better than implicit requires that the programmer specifically
change all old 'Anon' classes into the new classes. Writing a metaclass
to do this explicitly for you just for all the classes that might be
redefined is also OK.

# completely untested, I haven't overidden __new__ in practice so that line
# might be a bit off.

class NamesMatter(type):
all_seen_classes = {}
all_seen_instances = []

def __init__(cls, name, bases, dict):
"""If a class name is reused rebind all the old instances to the new class"""
if (name in NamesMatter.all_seen_classes):
for (ob) in filter(lambda x:x.__class__ == NamesMatter.all_seen_classes[name]):
ob.__class__ = cls
NamesMatter.all_seen_classes[name] = cls
def remember_obs__new__(cls, **args, **opts):
"""A custom __new__ that records instances in a central place"""
self = object.__new__(cls)
NamesMatter.all_seen_instances.append(self)
return self
setattr(cls, '__new__', classmethod(remember_obs__new__))
return

# usage
class Anon(object): pass # a class that doesn't upgrade itself

class Upgrader(object):
__metaclass__ = NameMatter
"""Instances of this class will be upgraded to a new class if this name
is reused"""


-jackdied

 

[Michael Geary]

The major problem appears to be your mode of communication. At first I
took your questions seriously, then I began to think you were trolling
(and a rather clever troll at that), and finally I've come to the
conclusion that you're not trolling, rather merely arrogant and
abrasive. You seem to get a large number of people who perceive you as
a troll. While I no longer believe this to be true, the sheer number of
people in so many different newsgroups should perhaps indicate to you
that you need to take a break from your local D&D group and socialize a
bit. You are lacking some fundamental skills in this area. You're
clearly intelligent and have in fact brought up some interesting topics,
but your lack of tact tends to take them off-track rather quickly.

For instance, do you really think publicly announcing that someone is in
your killfile hurts their feelings or somehow vindicates you? That's
rather pathetic, but makes sense given the source. I'd venture that
mentality is most common at the pre-teen level of social interaction.

Cliff, welcome to Brandon's killfile. I'll buy you a beer as soon as I get
there. You may not have to wait long. ;-)

Brandon, you would do well to take a deep breath, read and understand
Cliff's message. You may not like it, but it's extremely perceptive, and it
would do you a world of good to take his advice to heart.

When you started the Python vs. Java thread a few days ago and the first
couple of people ragged on you, I stood up for you, saying that I found your
message interesting and thought-provoking. I deliberately chose not to
google your previous conversations, figuring that anybody deserves a fresh
start.

But my goodness! Now I can see what all the fuss was about. You even
killfiled Doug Tolton, who made some very insightful comments about the
benefits of macros today in this Ruby thread.

A single friend of my wife's recently moved to Tacoma, Washington, because
she wasn't satisfied with the quality of the people (read: men) she was
meeting here in San Jose. She was shocked--shocked!--to find that the people
in Tacoma were no different from the ones down here. I had to wonder if
there just might have been *something* in common between the people she met
in San Jose and the people she met in Tacoma.

Brandon, learn to roll with the punches and have some fun with the rest of
us. What good does it do *you* when you say to someone, "You said something
I don't like. You failed to satisfy my needs in this conversation. I will
never listen to anything you ever say again!"

Would you do that in a face to face conversation? I didn't think so. So try
this: delete that silly killfile, cultivate the sense of humor you've shown
in the rattlesnake thread--I knew you could do it!--and be willing to say,
"Folks, I know I've been a bit abrasive and antagonistic in the past, and I
apologize for that. I really would like to get a fresh start here and I'm
curious to hear your thoughts on these questions."

Fair enough?

-Mike

 

[Michele Simionato]

I want something like:

... def amethod(self): return 'just a method'
...
... def amethod(self): return 'ah, now THIS is better!'
...
'ah, now THIS is better!'

Yeah, I see what you mean. I have dreamed of redefining a base
classes and having all its children automatically updated. This
would be a potential source of confusion, however (i.e. I redefine my
class at line 1242 of my code and the behavior of all the classes defined
in the previous thousand of lines is magically altered, making harder
to understand what the program is doing).

Currently you can add methods to a base class instead, and it does work
under inheritance too:

You can also change the class of an instance:

However this does not work always in Python 2.3 (there is an issue
with "heap" classes, a limitation to avoid redefining the boolean type).

I guess I must be overlooking
something here, because to me it seems entirely obvious that there should be a
straightforward mechanism for updating all instances of a class when the class
is redefined.

Since I know of no such mechanism and python's current semantics seem pretty
moronic to me, I'm sure I must be missing something (python has an amazingly
low rate of "obviously stupid" design decisions, that still strike you as
stupid after you understood their rationale). So it's maybe about time
someone put me straight.

Regular instances are automatically updated when you modify their class;
however if I remember correctly I had problems updating classes which
metaclass was modified (don't remember what problem exactly).

Michele

 

[Lulu of the Lotus-Eaters]

|>The first surest sign that a post is a troll is if the author is:
|>|"Brandon J. Van Every" <[email protected]>

|Oh, come on, Brandon is *much* less of a troll than T*m*t*y R*e. Unlike
|the R**bot, we do some interesting topics out of Brandon, they're just
|written with such antagonism that I'd be hard-pressed to top them.

True enough, I was under-general in listing my "first sign." What I
meant was:

The first surest sign...is if the author is in the set {BJVE, ...}

Of course, my killfile pretty much gets rid of the main ones... I only
see the followups, not the original posts. But I think the R**bot has
gone away.

That said, I feel a little bad for Tim Rowe. He's posted many
interesting and relevant articles. But for the last year or so, my
finger is always halfway to the delete button before I realize that a
post is by this nice guy with an unfortunately similar name .

Yours, Lulu...

 

[Andrew Dalke]

John J. Lee

Greg Ewing has pointed out a similar trivial
wart: brackets and backslashes to get multiple-line statements are
superfluous in Python -- you could just as well have had:

for thing in things:
some_incredibly_long_name_so_that_i_can_reach_the_end_of_this =
line

where the indentation of 'line' indicates line continuation.

Hmm. Start with

for a in some, incredibly, long, list, so, it, hides, the, end,:
qwerty_etaoin_shrdlu_glub_glub()
g()

Drop the colon one line and it would then be legal to write

for a in some, incredibly, long, list, so, it, hides, the, end,
qwerty_etaoin_shrdlu_glub_glub():
g()

As it is now, you'll have to write

for a in (some, incredibly, long, list, so, it, hides, the, end,
qwerty_etaoin_shrdlu_glub_glub()):
g()

or perhaps the less recommended

for a in some, incredibly, long, list, so, it, hides, the, end, \
qwerty_etaoin_shrdlu_glub_glub():
g()

Both provide a little more clue that the expression goes on
into the next line.

Not really a counterpoint, just an observation.

the two languages are? If somebody sneakily switched Python and Ruby
in the middle of the night (so that suddenly many more people use
Ruby, and much more code was written in Ruby than in Python), you'd
stick with Ruby, wouldn't you?

I was in a field, bioinformatics, dominated by Perl code. (It
still is.) But I decided Python was better in various ways - easier
to read, easier to build larger data structures, and easier for
non-software developers (scientists) to use.

A few years ago I looked at Ruby. I think my criteria for
selecting Python over Perl is still true for Python over Ruby,
in that it has too many special characters (like @ and the
built-in regexpes), features (like continuations and code
blocks) which are hard to explain well (I didn't understand
continuations until the Houston IPC), and 'best practices'
(like modifying base classes like strings and numbers)
which aren't appropriate for large-scale software
development.

So the answer would likely still be yes.

I mostly agree, but I think you could be accused of spreading FUD
about this. Does anybody *really* choose to alter string-comparison
semantics under everybody else's nose in Ruby?? That would be like
doing

Good question, since I repeated it above.

In the into to Ruby docs (or the book?) it mentions that there
are no functions in Ruby, only methods, and that when you
wrote something which looks like a function it's really a
private method of the base Object. Eg, it does change
methods of the fundamental base class.

(I took it to mean that Ruby's claim to be unrepentantly OO
was overly strong.)

I don't have any experience programming Ruby to know
what people do for large projects. I will point out that
the Ruby book in one of the first few chapters says:

http://www.rubycentral.com/book/tut_classes.html

In Ruby, classes are never closed: you can always add
methods to an existing class. This applies to the classes
you write as well as the standard, built-in classes. All
you have to do is open up a class definition for an
existing class, and the new contents you specify will
be added to whatever's there.

and later on
http://www.rubycentral.com/book/ospace.html

You can add code to a running process. You can
redefine methods on the fly, change their scope from
public to private, and so on. You can even alter basic
types, such as Class and Object.

Once you get used to this flexibility, it is hard to go
back to a static language such as C++, or even to
a half-static language such as Java.

and I found a tutorial showing how to do the same thing
http://www.math.hokudai.ac.jp/~gotoken/ruby/ruby-uguide/uguide14.html

In subclass, we get changing behavior of the instances
by redefine the superclass methods.

(It appears this is a translation from a Japanese tutorial.)

Both are in introductory material, and neither make a
suggestion about its inappropriateness for anything other
than debugging.

import some_module

def evil_replacement_function(): return blah()

some_module.important_function = evil_replacement_function


in Python, wouldn't it?

And that is frowned upon, and as I recall there's some
thought to preventing that in "Python 3.0" for performance
reasons. Though I've needed to patch code that way.
(It may be that I misheard too.)

It isn't talked about in any of the introductory materials
for Python that I recall reading.

Andrew
(e-mail address removed)

 

[Gonçalo Rodrigues]

Well, yes, I propose that x.__class__ return the *new* definition of X (like
in ruby, for example). I don't think that necessarily involves rebinding
anything "automagical", depending on how the lookup of x.__class__ works.

Can you give my any reason why you would *not* want all instances to be
updated on class redefinition?

But in the example you gave you were not *redefining* the class
referenced by X! You are *rebinding* the name X to a different class,
two completely different things. So no, I do not want

rebinding the name X => Automagically change instances of X.__class__
to the new class

This strikes me as a very insane thing to do. That, or else I'm not
understanding a thing of what you are saying -- which given that it's
3am and I am tired, it's not that farfetched.

Um, didn't you read what I wrote or was I just unclear?

To recap: usually, if I change a class I'd like all pre-existing instances to
become updated (Let's say you develop your program with a running python
session; you notice a mistake in a method-definition but don't want to start
over from scratch; you just want to update the class definition and have this
update percolate to all the currently existing instances. This is an *very*
reasonable wish if it doesn't just take seconds to get to the current state by
rerunning everything, but possibly hours or days). AFAIK doing this in a
general and painfree fashion is pretty much impossible in python (you have to
first track down all instances -- not an easy task, as far as I can see and
then updating their .__class__ might not quite work as expected either as I've
already mentioned).

I think this sucks big time, because it greatly devalues the interactive
programming experience for certain tasks, IMHO, but maybe I'm just missing
something since typically nobody complains.

Um, you were unclear. I still can't understand why the following does
not work for you:
.... def amethod(self):
.... return "I am %r." % self
....
It seems to cover the use case you describe above.

There are other, more "violent" means of mucking with a class
hierarchy, such as rebinding __class__ or __bases__ directly but that
does not always work and is fraught with dangers.

With my best regards,
G. Rodrigues

 

[Andrew Dalke]

Pedro Werneck:

Well... I think you're overlooking the fact that you're not exactly
_redefining_ the class. You're creating an entirely new class
object and binding it to the same name, but the old class is still
lying there,

I'm pretty sure he knows that and simply disagrees with that
design choice, suggesting that a class def should augment a
class if it already exists.

I wonder ... Alexander? What should this do?

from Q import X

class X:
def amethod(self): return 'ah, now THIS is better!'

Should it refine the X in the local namespace or make a new
class?

I have wondered if

def X.amethod(self): return "...."

should be allowed, but no longer think it should.

OTOH, a proper reload, which updated all instance's __class__
to the newly reloaded class, would be nice. I've stumbled
over that many a time.

Andrew
(e-mail address removed)

 

[Ben Finney]

Bingo! Guilty as charged. And I get more and more abrasive the more
people call me a troll. As do most people who aren't actually
trolling.

Quite the opposite -- "get[ting] more and more abrasive the more people
call [one] a troll" is *exactly* how a troll acts.

People who aren't actually trolling will make efforts to depart from
troll-like behaviour when accused of it, to avoid confirming the
accusation.

 

[Brandon J. Van Every]

The major problem appears to be your mode of communication. At first
I took your questions seriously, then I began to think you were
trolling (and a rather clever troll at that), and finally I've come
to the conclusion that you're not trolling, rather merely arrogant and
abrasive.

Bingo! Guilty as charged. And I get more and more abrasive the more people
call me a troll. As do most people who aren't actually trolling.

I ask tough questions about Python vs. other languages and platforms. Some
people can't handle it. Maybe they'd handle it if I diplomatically sugar
coated it, but I'm not going to. Things to irritate the "Brandon's a troll"
crowd some more:

- Python is not a good language for low-level 3D graphics problems. C++ is
better.
- Python isn't a rapid prototyping godsend for every problem out there.
- GUI and tools support can end up being more important than language
niceties.
- Microsoft C# and .NET are strategic threats to Python's prosperity and
vitality, if not survival.
- Pythonistas should consider trying to eat Java's lunch, because they
aren't going to eat Microsoft's lunch.
- Ruby has some mindshare among people with knowledge of Python.
- Yet unnamed languages are capable of taking Python's place on the food
chain.
- You have to promote your language, grow its market share, to prevent that
from happening.

These analyses are called "sanity" in the Windows world. It's Reality On
The Ground. It's really odd to come to a developer community where people
are insular and freak out about these kinds of pronouncements. It makes
Windows people wonder if Python people are capable of industrial relevancy.
Fortunately, I was pointed to the marketing-python list and I've discovered
that not all Python crowds are the same.

The rest of you: wake up! Smell the Windows!

--
Cheers, www.3DProgrammer.com
Brandon Van Every Seattle, WA

20% of the world is real.
80% is gobbledygook we make up inside our own heads.

 

[Brandon J. Van Every]

For instance, do you really think publicly announcing that someone is
in your killfile hurts their feelings or somehow vindicates you?
That's rather pathetic, but makes sense given the source. I'd
venture that mentality is most common at the pre-teen level of social
interaction.

You and I have different social theories. My social theory is, people are
very stubborn. Nobody will engage in Right behavior the minute you tell
them to. But if I killfile people, and tell them why (i.e. "Because you are
a Troll Hunter, and such people are useless."), then someday they may wake
up and figure it out. It may be 6 months from now, it may be 2 years from
now. The point is to have a cumulative effect on people's newsgroup
behavior.

It also starts to sink in when people realize they've been killfiled for
years. People eventually wake up and mellow out.

Cliff, you aren't in my killfile. I don't have much problem with what you
wrote about me, because you wrote it tentatively, even if you strongly
suspected you'd reach certain conclusions. The point is to examine one's
perceptions, one's role, before running off and screaming, "So and so's a
troll!" There may be other explanations. Generally, it is broadening to
put yourself in someone else's shoes.

--
Cheers, www.3DProgrammer.com
Brandon Van Every Seattle, WA

20% of the world is real.
80% is gobbledygook we make up inside our own heads.

 

[Donn Cave]

"Troll" is really a function of the audience. These guys will
exist, there is this way of viewing the world as a dramatic
contest between the armies of Python etc.: You will lose, they
will eat your lunch, you're already dead and you don't know it,
bla bla. But it takes an audience that finds this sort of thing
in the least compelling, usually young males it seems.

I don't actually see much of that in the responses, just picking
a few at random. A discussion of language issues, like why Python
has no macros etc., not contentious though a bit boring because it
tends to be a rehash. Other than people using the newsgroup to
complain about Brandon posts, Brandon's abrasive style doesn't
seem to have much effect.

If there's anything about c.l.p. that makes any of this disagreeable,
it's the implicit awareness that someone might actually add macros,
etc., to Python. This means that you can't just let people blabber
on about it, stuff like that has to be nipped in the bud and all the
usual arguments have to be presented every damned time the subject
comes up. Or next thing you know, Guido will conduct a poll: should
there be macros.

Donn Cave, (e-mail address removed)

 

[Heiko Wundram]

This is why Ruby's solution is superior: "self" is a reserved word,
and so is the special character shortcut. There is no question as
to what is meant. It eliminates essentially futile arguements in the
same way that Python's indentation eliminates arguements about
the proper placement of braces.

I think you're not getting the main point in a difference between Ruby
and Python here, and why it makes (IMHO) no sense to have a default self
in a function:

class X:
def test(*args):
print args

X.test() # 1
x = X()
x.test() # 2
X.test(x) # 3

Run this, and for the first call you will get an empty tuple, while for
the second call, you will get a tuple with the first parameter set to a
class instance of X, and for the third call the same as for the second
call. Remember about method binding (method/function difference), and
the like.

I want to have class-functions which can be callable either as a
function of the class (doing something on input-data), or work directly
on the instance they are associated with. If you have a predeclared
self, only calls 2 and 3 would work, if the self parameter is just
another parameter for the function, I can miraculously call the function
just like it is (see call 1).

I find it reasonable enough to have a feature like this to not complain
about having to specify self as the first parameter, always.

Heiko.

 

[Brandon J. Van Every]

But my goodness! Now I can see what all the fuss was about. You even
killfiled Doug Tolton,

Is Doug Tolton pure? Let's see, what did I killfile him for... ah, here was
the first bit.

Ugh...he got me.

So at this point, Doug has already decided that I'm a troll. He hasn't
applied critical thinking, he's just running with the pack. I responded,
explaining myself, but didn't killfile him. Later on, Doug makes a post
that explicitly flames me and doesn't include any info about Python or Ruby
whatsoever. He said I was ranting, whining, and begging, and he wasn't
trying to be at all useful about it. So I killfiled him. Surprised?

who made some very insightful comments about
the benefits of macros today in this Ruby thread.

So what? Sometimes you forego information when the source is too much
trouble. Besides, if it's a really really really great point, someone else
will reply to it and I'll see an executive summary indirectly.

Brandon, learn to roll with the punches and have some fun with the
rest of us.

I'm a pugilist. If someone punches me, I'd sooner smash their face in and
be done with it. There are so many other people to talk to that don't take
jabs at you.

What good does it do *you* when you say to someone, "You
said something I don't like. You failed to satisfy my needs in this
conversation. I will never listen to anything you ever say again!"

Oh, I don't killfile people *forever*. The first reprieve generally comes
at system reinstall. When all the killfiles acidentally get wiped out, or I
change newsreaders, or something like that. Everybody gets a second chance
at that point. People who still insist on being trouble at that point, get
killfiled for many years. I've known a few, like 2 or 3. Even they mellow
out with age. But that can be as long as 5 years. At some point, such
people look back over those 5 years and realize I wasn't personally around
to be their whipping boy or irritant for most of that time. So, they
realize it was them, not me.

Would you do that in a face to face conversation? I didn't think so.

Most people don't have this much trouble face-to-face. There's so much
extra information: tone, facial expression, body posture, hand gestures.
It's easier for people to take comments in the manner they were intended,
and it's easier for people to see they're pissing someone else off and back
down. E-mail and newsgroups are inherently imperfect media, and I will not
try to change them.

So try this: delete that silly killfile, cultivate the sense of humor
you've shown in the rattlesnake thread--I knew you could do it!--and
be willing to say, "Folks, I know I've been a bit abrasive and
antagonistic in the past, and I apologize for that. I really would
like to get a fresh start here and I'm curious to hear your thoughts
on these questions."

No, I shall not. I acknowledge and own my abrasion, I don't apologize for
it. Nothing I say should be that tough for people to swallow. But, there
are always people who are emotional and reactive, who think something big is
at stake. I know these people are always out there... I recognize that I
reap what I sow. But I will continue to sow. Because I've tried the other
way, the polite way, the diplomatic way, and you know what? People flame
anyways. That has always been the pattern. No matter what you say,
*someone* has to make a problem out of it. And those people, they go in the
killfile and stay there.

Case in point: my first "What's better about Ruby than Python?" post. I
explicitly said, this is not a troll. Some chose to flame and accuse
anyways. Such people are useless, there is nothing you can do with them.

Fair enough?

My smiles are for those who smile. Or for those who frown, but realize
their frown is a mirror.

--
Cheers, www.3DProgrammer.com
Brandon Van Every Seattle, WA

20% of the world is real.
80% is gobbledygook we make up inside our own heads.

 

[Cliff Wells]

Bingo! Guilty as charged. And I get more and more abrasive the more people
call me a troll. As do most people who aren't actually trolling.

Quoting the Dalai Lama:
Conventional truth, conventional reality is a consensus reality,
something that people agree on. Events do not have a reality of their
own. All events depend on other events. Nothing (no person) has an
independent identity, there is no intrinsic reality. What is called
"reality" depends on the context of other factors.

While I don't necessarily consider the Dalai Lama an authority on all
(or even many) things, I think there is certainly a great amount of
truth to this observation. If the majority of people think you are
trolling, then, whether you intend to or not, perhaps you are.

If you were being truly pragmatic, as you claim, then you must surely
realize that offending people with an abrasive approach is
counter-productive. Especially when many of those people are central to
the Python community. By that I don't mean prolific posting (although
that is part of it), but rather the people who have some of the most
intimate knowledge of Python and some who actually contribute to its
development. You might think that killfiling those people will teach
them a lesson (it won't, they could probably care less), but I can
guarantee that if you do use Python you will suffer far more than they
from missing out on their knowledge of the tool you've chosen. If you
post a question regarding actual use of Python (versus rhetorical
questions about its utility or future) you have increased your chance of
not seeing the answer because you've killfiled the person with the
knowledge you are after.

I ask tough questions about Python vs. other languages and platforms. Some
people can't handle it. Maybe they'd handle it if I diplomatically sugar
coated it, but I'm not going to. Things to irritate the "Brandon's a troll"
crowd some more:

- Python is not a good language for low-level 3D graphics problems. C++ is
better.

This is a worthless assertion. I don't think anyone has suggested
otherwise, either in any of the threads you've started or at any other
time. You did assert it in an earlier thread, but it was apparently in
response to nothing.

- Python isn't a rapid prototyping godsend for every problem out there.

No, but for many if not most.

- GUI and tools support can end up being more important than language
niceties.

Absolutely. This is one of the main reasons languages like Ruby and
Haskell aren't in my toolkit. wxRuby appears to be in the pre-alpha
stages and wxHaskell doesn't exist at all. And this is just one thing.

- Microsoft C# and .NET are strategic threats to Python's prosperity and
vitality, if not survival.

This is certainly arguable. Java certainly hasn't stopped Python's
growth. There is little to support this claim other than fear or
admiration of Microsoft.

- Pythonistas should consider trying to eat Java's lunch, because they
aren't going to eat Microsoft's lunch.

IMHO, Python is set to become the Visual Basic of the open-source
world. RedHat uses it for many of its administrative tools and the RH
installer. It comes bundled with most open source operating systems.
Many open source applications are starting to use Python as an extension
and scripting language. Python on Win32 might struggle against MS
languages (whatever that means), but as Linux gains mindshare it carries
Python with it. It seems MacOSX might also become a "carrier" of
Python.

- Ruby has some mindshare among people with knowledge of Python.

Certainly. Your questions regarding this were something I had wondered
myself but didn't concern myself with due to Ruby's lack of
infrastructure (tools and libraries).

- Yet unnamed languages are capable of taking Python's place on the food
chain.

As with any other language. Of course languages aren't applications or
operating systems. The competition isn't quite the same in this arena.
For the most part, it doesn't matter if you write your application in
BrandonBasic of which you are the sole user and developer. What matters
is how your applications written in this unappreciated language perform.

- You have to promote your language, grow its market share, to prevent that
from happening.

Okay, this is where you lose me: why? Why should I care if other people
use Python? In my opinion, being in an exclusive group of developers
who use what I consider to be superior tools gives me a distinct
advantage. Why would I want that to change? I certainly recommend
Python to others, but that's just my nice side winning out. If someone

These analyses are called "sanity" in the Windows world. It's Reality On
The Ground. It's really odd to come to a developer community where people
are insular and freak out about these kinds of pronouncements. It makes
Windows people wonder if Python people are capable of industrial relevancy.

Probably these same people wondered the same about Linux advocates a few
years ago. In a few more years they'll wonder what happened to their
beloved behemoth (Windows).

Fortunately, I was pointed to the marketing-python list and I've discovered
that not all Python crowds are the same.

Part of the reason people respond to you so violently is because you
tend to make unsubstantiated and provocative claims and then accuse
people of being "knee-jerk reactionaries" when they dismiss them.

The rest of you: wake up! Smell the Windows!

Sorry, I haven't smelled that smell (except incidentally) since 1994
(Slackware 1.0). I expect to be smelling it less and less as time goes
on. However, this is a fine example of an unnecessarily inflammatory
statement.


Regards,
Cliff

 

[Brandon J. Van Every]

Never blame on malice what can be explained by stupidity.

What if stupidity fosters malice? To wit:

I don't care if you write troll posts maliciously or not, I do care
that you keep sending them.

The problem here is, they aren't troll posts. You just perceive them to be.
Why you do, you'd have to answer for yourself. But I will hazard to guess:
you don't like it when certain questions are asked. You think they are
illegitimate questions, and that nobody, rationally speaking, should ask
them. You think the questions will always cause trouble, that we can count
on this from what we know about newsgroup behaviors, so therefore the
questions should not be asked. In other words, you think you know best
about how discourse should properly proceed.

So how big is that RAID that holds your killfile?

Text is trivial to store on modern computers and I'm not in newsgroups
*that* much. My anti-spam file is a couple of orders magnitude bigger than
my killfile. Maybe 3 orders of magnitude. 4? I can't tell. Anyways, I
don't think it's worth trying to work out your perceptions, so welcome to my
killfile along with the rest.

I am starting to wonder, if the high number of kills I've gotten in c.l.p
says something about community cohesion? I mean, I get kills in *every*
group I spend any time in, but the speed and volume of kills I'm getting
here is novel. It's usually much more isolated and sporadic than this. I
hereby pronounce c.l.p, Second Order Magnitude of community cohesion. You
guys aren't all in the same pocket or parrots of each other, but there are c
learly some trends. For a First Order Magnitude community cohesion, check
out something really cranky and old guard like rec.arts.int-fiction. I
think they still think the Internet is a DARPA project! And despite years
of absence, I'm sure I'm still a favorite there. Smooches, any of that ilk
lurking about.

--
Cheers, www.3DProgrammer.com
Brandon Van Every Seattle, WA

20% of the world is real.
80% is gobbledygook we make up inside our own heads.

 

[Michael Geary]

Would you do that in a face to face conversation? I didn't think so.

Most people don't have this much trouble face-to-face. There's so much
extra information: tone, facial expression, body posture, hand gestures.
It's easier for people to take comments in the manner they were intended,
and it's easier for people to see they're pissing someone else off and back
down. E-mail and newsgroups are inherently imperfect media, and I will not
try to change them.

That's an excellent point that we would all do well to heed. (Myself
included.) Being half Italian, I have plenty of experience with heated
discussions conducted in total friendship. But that definitely works only in
person!

Personally, I think it's worth taking a little extra effort to try to
compensate for the limitations of the medium. If you know that people are
more likely to misunderstand your intentions, why egg them on?

You've certainly made some insightful comments here, such as the Reality On
The Ground list you just posted. It's unfortunate that the message has been
obscured by the tone of the conversation. (Not placing blame--it takes more
than one to tango.)

-Mike (Windows programmer for 17 years and Python newbie...)

 

[Brandon J. Van Every]

In the proposed scheme every module that wants to use custom syntax
has to say so, period. So there is no silent infestation (these
syntaxes can't be stealthily exported).

I wsan't talking about stealth, I was talking about developmental inertia.
The least common denominator is functionality turned ON in some root *.h
file, and everyone else inherits the functionality. Are you saying that
modules in Python don't inherit?

If you don't want the functionality to end up being "always ON" by faits
accompli, then you must ensure that functionality is irrevocably, "always
OFF." In other words, don't provide the functionality.

It would be
easy (from a technical perspective) for project managers (open source
or otherwise) to only allow certain, particularly trusted programers
to create such modules or ban them outright.

From a technical perspective. From a productivity, political, or business
perspective, you are asking the moon. People are going to do what works.
What works, is functionality turned ON at the least common denominator.
Nobody wants to chase the ON/OFF test issues. Nobody's going to change code
that was designed monolithically ON to something compartmentalized ON/OFF.

Just like you wouldn't allow every second rate programmer to write the
system-critical libraries everything is built upon, you wouldn't
allow just about anybody to create their own mini-languages without a
need.

Man, this isn't very real world as far as how sprawling projects evolve!

--
Cheers, www.3DProgrammer.com
Brandon Van Every Seattle, WA

20% of the world is real.
80% is gobbledygook we make up inside our own heads.