Python vs. C++ Builder - speed of development
pu
I don't want to start a thread comparing the Python and C++ languages, but
one question bothers me. Using Python, you can of course develop very
quickly due to high level constructs and the absence of compilation. On the
other hand, so-called "builder IDEs" or "RAD-IDE" (i.e. Borland C++ builder,
Microsoft Visual C++) also promise to allow you to develop quickly, even in
a less high-level language.
Therefore, my question is:
Is, or under which circumstances is the time which can be gained by using a
RAD-IDE equivalent to the time gained by using Python directly?
-Patrick
Laura Creighton
My guess is 'never'. The problem with developing in C++ is not that
you don't have an IDE that makes development faster, but that in C++
there are so many ways to shoot yourself in the foot that you have
to spend forever re-reading your code to make sure that it doesn't
interact in nasty, horrible ways with other people's code. Or you
spend your life debugging other people's badly designed templates.
Or on the phone to Borland saying that you have found another bug in
the destructors ... or ....
I don't think that it is possible to write an IDE that makes me as
productive in C++ as I am in Python with ed(1). That is because almost
all my time spent in C++ come from some other place than actually writing
code from scratch. Other people's milage may vary.
Laura Creighton
Irmen de Jong
In my experience, tha "RAD" aspect of so-called RAD IDE's like the ones
you mention pretty much grinds to a halt once you:
- want a GUI that's different from the "straightforward" ones you can
create using the "RAD" tool
- discover that the real complexity / dynamism / changing requirements
is not in the GUI but in the logic.
I dare say that Python will prove the better. Even if you just use VI.
Irmen
Tim Lavoie
pu> Is, or under which circumstances is the time which can be
pu> gained by using a RAD-IDE equivalent to the time gained by
pu> using Python directly?
Never. It's not how long it takes to crank something out the first
time, but how long it takes to fix and modify it later. "Hello world"
with some arbitrary GUI builder might be similar for many choices of
tools. Doing something fussy, and changing it later, makes all the
difference.
For what it's worth, you do have some choices in Python regarding
tools to help programming too, say for creating GUIs and so
on. Depending on the sort of help you like in the tools, there are
probaby Python equivalents out there. As an example, check out Glade
for GUI creation. (http://glade.gnome.org/)
--
I finally went to the eye doctor. I got contacts. I only need them to
read, so I got flip-ups.
-- Steven Wright
Brandon Van Every
>> Patrick:
>>
>> Is, or under which circumstances is the time which can be gained by
>> using a RAD-IDE equivalent to the time gained by using Python
>> directly?
>
That's an extreme viewpoint.
> The problem with developing in C++ is not that
> you don't have an IDE that makes development faster, but that in C++
> there are so many ways to shoot yourself in the foot that you have
> to spend forever re-reading your code to make sure that it doesn't
> interact in nasty, horrible ways with other people's code.
Then don't interact with other people's code. Polymorphize your own tree
where you know what you're doing, and keep the interface that everyone else
sees very very simple. This is no different a problem of API speccing than
in any other language. C++ simply provides you more ways to be stupid.
Nothing's twisting your arm to be stupid however. You can count on other
people doing dumb things in their code, but if you're doing dumb things in
your own code, that's your fault. It's not that hard to ignore most of the
"features" of C++ and just use basic class hierarchies to get simple things
done.
> Or you spend your life debugging other people's badly designed templates.
Then don't use other people's templates.
> Or on the phone to Borland saying that you have found another bug in
> the destructors ... or ....
Then don't use Borland products. Granted I spend my time doing 3D graphics,
and I deliberately keep the OO aspect "lean and mean." But I've never
called Microsoft VC++ tech support for anything. Also I've restricted
myself to mature compiler products, I will *not* jump on the bandwagon of
whatever crap MS has just put out. Wait for a few service packs, let others
take the lumps before you switch over.
I think, to answer the original poster's question honestly, you have to
consider the complexity of what you're undertaking. You seem to be talking
about ridiculous, corporate-dysfunctional style complexity. Sure, you'll
have problems there with C++. But you will also have them with Python, for
different reasons. For instance, no type checking. The underlying problem
is the dysfunctional corporation. Change instead to a small team of
programmers who know how to "fly in formation" and the problems go away for
both languages.
> I don't think that it is possible to write an IDE that makes me as
> productive in C++ as I am in Python with ed(1).
I can never take people seriously who say things like this. You like ed
because you've invested lotsa time in ed. If you invested similar time in
any other tool, you would like it also. Why? Because if you like ed,
clearly you like what you know, not what is inherently a better paradigm for
text entry.
If you had said Emacs, I would take you half-seriously. If you said you had
a mouse-driven GUI for your Emacs, because you're not the kind of genius who
can remember every keystroke, you'd have my attention on issues of
productivity. There's nothing wrong with keyboard shortcuts, but users
should not be required to know them.
> That is because almost
> all my time spent in C++ come from some other place than actually
> writing code from scratch. Other people's milage may vary.
Find a different job then. Are you getting paid well for your C++
headaches? I wouldn't put up with it if it's as onerous as you make it
sound. Unless the money is really really good.
--
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 Van Every
>
> Is, or under which circumstances is the time which can be gained by
> using a RAD-IDE equivalent to the time gained by using Python
> directly?
Python doesn't provide a GUI directly. So first you need to ask yourself
what GUI toolkit you're using. Maybe it has a RAD-IDE and you can compare
apples to apples. If not, if you insist on comparing apples to oranges,
then the question is "When does hand-coding beat RAD-IDE?" It's not really
a Python question per se.
Hand-coding definitely beats RAD-IDE when you can narrow your application
GUI requirements to something trivial. For instance, a lot of game
developers try to get everything done with a simple display window and
trivial menus. By design, there's so little GUI to code that RAD-IDE is
pretty useless. It'll just auto-generate a lot of unreadable spaghetti that
gets in your way.
Hand-coding definitely beats RAD-IDE when you must have control of the
application's event loop, and the RAD-IDE in question chooses to get in the
way of your event control. RAD-IDE doesn't have to get in the way, but
often these products have come out of a "corporate schmuck" mentality that
they just wanna own everything and the user is only interested in banging
out zillions of inefficient widgets that are seldom used. This is the
perinneal "Should I use MFC for my game?" question. The answer is no, you
shouldn't. MFC's event control is a complete pain in the ass. It puts a
lot of things in your way and it's far more trouble than it's worth.
RAD-IDE definitely beats hand-coding when you must produce zillions and
zillions of widgets. This is a rapid prototyping mentality: you know you
need a *lot* of GUI elements, there is no way to simplify, you know you need
dozens and dozens on a given screen, and you have no idea how exactly it's
all going to come together. Doing stuff in text is kidding yourself, you
need WYSIWYG.
Between the extremes of "almost no widgets" and "zillions of widgets," you
have tradeoffs. Personally I find RAD-IDE generated code totally
unreadable, and I hate having inscrutible components in my apps. It all
depends on whether something saves pain and development time, either now or
later. Your mileage is going to vary with your problems.
John Ochiltree
problems, whereas with c++ I tend to concentrate more on structure and
architecture. However, that's not to say that my thinking is any more
abstract in either language.
I wonder if there's a way of measuring what language encourages which way of
thinking?
John Ochiltree
Létezõ
RAD-IDEs are for overcoming
some of the problems caused by
the inadequate logic of the language.
- Complex -
Peter Hansen
>
> Laura Creighton wrote:
> > My guess is 'never'.
>
> That's an extreme viewpoint.
> Then don't interact with other people's code. Polymorphize your own tree
> Then don't use other people's templates.
> Then don't use Borland products. Granted I spend my time doing 3D graphics,
[...]
> I can never take people seriously who say things like this. You like ed
> because you've invested lotsa time in ed.
> If you had said Emacs, I would take you half-seriously. If you said you had
> Find a different job then. Are you getting paid well for your C++
> headaches? I wouldn't put up with it if it's as onerous as you make it
> sound. Unless the money is really really good.
Heh heh.... it's generally a wise policy to read a newsgroup for a while
before your first post to it, to get to know the various people who are
regular
posters, and their styles and ideosyncracies... ;-)
-Peter
Brandon Van Every
Maybe instead you should be thinking about what your task is. There's
nothing wrong with thinking structurally and architecturally if those indeed
are your problems.
Python is a "glue" language, so I think you're implying that your problems
are more typically of a freeform nature. If you're really saying "no no, I
do structural/architectural stuff in both, and I love Python syntax and hate
C++ syntax!" well, all I can say is the C++ works just fine when you Keep It
Simple Stupid and use it all the time. I would like a few more editor
features for my function declarations, which seem a bit verbose, but it
hasn't been painful enough for me to go through the alternate pain of editor
evaluation.
Brandon Van Every
No, RAD-IDEs are WYSIWYG. When the need for WYSIWYG becomes your dominant
development need, when you need to lay out zillions of widgets, then you go
for an approach that brings you economies of scale. If you don't need that
many widgets, RAD-IDEs are a marginal gain.
Really, look at all the overstuffed functionality available in modern widget
sets and tell me that Python can somehow do a better job interfacing it all
than C++ can. It can't. It doesn't matter what language you pick, the
abstruseness is contained in the GUI spec not the language. Widgets are
inherently overcomplicated, they're general purpose GUI components that try
to please everybody.
Peter Hansen
>
> Python is a "glue" language, ...
Just checking here :-)... you're not saying Python is *only* a glue
language, right? Just that it *can be* used as a glue language when
you need such a thing?
-Peter
Laura Creighton
> >> Patrick:
> >>
> >> Is, or under which circumstances is the time which can be gained by
> >> using a RAD-IDE equivalent to the time gained by using Python
> >> directly?
> >
> > My guess is 'never'.
>
> That's an extreme viewpoint.
>
> > The problem with developing in C++ is not that
> > you don't have an IDE that makes development faster, but that in C++
> > there are so many ways to shoot yourself in the foot that you have
> > to spend forever re-reading your code to make sure that it doesn't
> > interact in nasty, horrible ways with other people's code.
>
> Then don't interact with other people's code.
Not an option. My job was interacting with other people's code.
> Polymorphize your own tree
> where you know what you're doing, and keep the interface that everyone else
> sees very very simple. This is no different a problem of API speccing than
> in any other language. C++ simply provides you more ways to be stupid.
> Nothing's twisting your arm to be stupid however. You can count on other
> people doing dumb things in their code, but if you're doing dumb things in
> your own code, that's your fault. It's not that hard to ignore most of the
> "features" of C++ and just use basic class hierarchies to get simple things
> done.
>
> > Or you spend your life debugging other people's badly designed templates.
>
> Then don't use other people's templates.
Also not an option. Debugging other peoples templates was the job.
>
> > Or on the phone to Borland saying that you have found another bug in
> > the destructors ... or ....
>
> Then don't use Borland products.
Also wasn't my decision, but I have found Borland to be the most
responsive of all C++ vendors. That is, it was _worth it_ to be
on the phone explaining bugs to Borland developers. They were
listening, anbd sending me test cases, and we were fixing things.
> Granted I spend my time doing 3D graphics,
> and I deliberately keep the OO aspect "lean and mean." But I've never
> called Microsoft VC++ tech support for anything.
I've never got them to fix anything myself.
> Also I've restricted
> myself to mature compiler products, I will *not* jump on the bandwagon of
> whatever crap MS has just put out. Wait for a few service packs, let others
> take the lumps before you switch over.
>
> I think, to answer the original poster's question honestly, you have to
> consider the complexity of what you're undertaking. You seem to be talking
> about ridiculous, corporate-dysfunctional style complexity. Sure, you'll
> have problems there with C++. But you will also have them with Python, for
> different reasons. For instance, no type checking. The underlying problem
> is the dysfunctional corporation. Change instead to a small team of
> programmers who know how to "fly in formation" and the problems go away for
> both languages.
>
> > I don't think that it is possible to write an IDE that makes me as
> > productive in C++ as I am in Python with ed(1).
>
> I can never take people seriously who say things like this. You like ed
> because you've invested lotsa time in ed. If you invested similar time in
> any other tool, you would like it also. Why? Because if you like ed,
> clearly you like what you know, not what is inherently a better paradigm for
> text entry.
You misunderstand. Ed is the most primative tool there is in which
you can get useful work done. It is as far away from an IDE as you
will get, which is why it is useful for his comparison. He wants to
know if a speed up in IDE will match the speedup you get in Python for
C++. And the answer is no. Because the time you spend in C++ is
not mostly spent inside your development environment. It is spent
outside, as you do something other than write code.
>
> If you had said Emacs, I would take you half-seriously.
This is what I develop in normally.
> If you said you had
> a mouse-driven GUI for your Emacs, because you're not the kind of genius who
> can remember every keystroke, you'd have my attention on issues of
> productivity. There's nothing wrong with keyboard shortcuts, but users
> should not be required to know them.
Typing 400 words a minute helps as well. I cannot do that yet, but
one person here at Strakt can. Utterly awesome. I thought that
200 words was good....
>
> > That is because almost
> > all my time spent in C++ come from some other place than actually
> > writing code from scratch. Other people's milage may vary.
>
> Find a different job then. Are you getting paid well for your C++
> headaches? I wouldn't put up with it if it's as onerous as you make it
> sound. Unless the money is really really good.
Last C++ job I had paid roughly $400 Euros an hour. And the reason
they paid me this was because indeed, it was as onerous as I made it
sound. This is what I was paid to do all day long.
You need to get over your notion that there cannot exist a person who
is excellent at something and who hates it at the same time.
>
> --
> 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.
>
> --
> http://mail.python.org/mailman/listinfo/python-list
Laura Creighton
Brandon J. Van Every
"away from the newsgroup" is accurate. Anyways...
> From: Laura Creighton [mailto:l...@strakt.com]
>
> Last C++ job I had paid roughly $400 Euros an hour. And the reason
> they paid me this was because indeed, it was as onerous as I made it
> sound. This is what I was paid to do all day long.
>
> You need to get over your notion that there cannot exist a person who
> is excellent at something and who hates it at the same time.
But your comparision regarding C++ usability is utterly unfair. You got
paid an exhorbitant amount of money to tackle really godawful C++
problems in a corporate dysfunctional environment. That is quite beyond
any language issue. To say that C++ RAD-IDE would "never" help anyone
based on your extreme case use is grossly misleading. A solo programmer
or a small team that knows how to "fly in formation" doesn't have your
corporate $400/hour idiocy problems to contend with.
Laura Creighton
> http://mail.python.org/mailman/listinfo/python-list
When I was working for the Canadian military, we got people working
on problems and then stuck them in machines which measured blood flow
in different regions of the brain. Neither python nor C++ were
invented then, but C and Lisp were.
Statistically, C problem solvers were way more active in the
language-processing-and symbol-manipulation areas of the brain then
they were in the parts of the brain associated with imagery, drawing,
and conceptualising. Lisp problem solvers were more balanced.
Certain individuals bucked the trend, however. Whether blood flow
actually measures 'something is going on' as opposed to 'something is
being attempted' was hotly debated at the time (mid 1980s).
Laura Creighton
Mongryong
team consists of hackers, it really doesn't matter what language you
use, it'll eventually end up a big mess.
You're knowledge of good software design doesn't change simply by
changing the language you use! It's the bad programmers that give
languages with good intentions a bad name. You can find lots of examples
of Python code that is just as bad or worst than some that you can find
in other languages.
Two people can write different code to do the same thing. Which is
better? The code that was written the fastest or the one that took the
time to do a great design such that it is easier to maintain and extend?
Personally, if I don't have a good understanding of the problem domain
for a project I'm working on, I wouldn't want to use a language like C
or C++ the first-time around. Python is great for this because it
allows me to understand the problem and to figure out what design
approaches will work. As others have stated, it lets you concentrate on
the problem. Similarly, graphic tools and RAD-IDES are great if you
know what you're doing.
In conclusion, the tools are only as good as the people who use them :)
Mitch Chapman
> Is, or under which circumstances is the time which can be gained by using a
> RAD-IDE equivalent to the time gained by using Python directly?
>
> -Patrick
As others have noted, it depends on what you're doing. If you're
building GUI apps in an environment where the APIs are cumbersome,
you're probably better off with an IDE to help generate the code /
UI.
But it doesn't have to be an exclusive choice between Python and
a RAD-IDE environment. For example, Python For Delphi (P4D) lets
you use Delphi (or C++Builder) to construct your user interface,
define basic user interactions, etc. while using Python for the bulk
of the application.
Where I work we've been using P4D for about a year and a half, with good
results. P4D encourages a clean split between View/Controller and
Model code. As a result, even though much of our core code was
developed specifically for our Windows-based applications, it also
runs on Linux. It runs on MacOSX, too, but that's because OSX is
Unix. (Ow. My head hurts.)
That's not to say P4D is perfect. Accessing Delphi services from
Python still requires a fair bit of bookkeeping code.
However, P4D's thorough exploitation of Delphi's (and C++Builder's)
variant type lets you manipulate Python objects from Object Pascal
(and C++) with almost no bookkeeping code or static type declarations.
Maybe it has to be experienced to be believed. It's pretty awesome.
The Python For Delphi homepage:
http://membres.lycos.fr/marat/delphi/python.htm
Some screenshots of stuff we've built using Python For Delphi:
http://www.bioreason.com/classpharmer.php
--
Mitch
Laura Creighton
> "away from the newsgroup" is accurate. Anyways...
I haven't. I just read python-list as a mailing list, so when I reply
you get a mail, also cc'd to the list. That then goes to the gateway.
If you want only to get the gatewayed version, let me know, I have
a config file which strips the people who 'only want it as news'
from my mailings as they go out.
>
> > From: Laura Creighton [mailto:l...@strakt.com]
> >
> > Last C++ job I had paid roughly $400 Euros an hour. And the reason
> > they paid me this was because indeed, it was as onerous as I made it
> > sound. This is what I was paid to do all day long.
> >
> > You need to get over your notion that there cannot exist a person who
> > is excellent at something and who hates it at the same time.
>
> But your comparision regarding C++ usability is utterly unfair. You got
> paid an exhorbitant amount of money to tackle really godawful C++
> problems in a corporate dysfunctional environment.
Actually, extremely well discplined military environment. But I have
worked in the other sort as well.
> That is quite beyond
> any language issue. To say that C++ RAD-IDE would "never" help anyone
> based on your extreme case use is grossly misleading.
You need to go read the original post again. His question was,
IF I GET A REALLY cool C++ RAD-IDE, which promises me the moon in
speedup and rapid development, will it be as fast as developing in
Python. He wants to know under what circumstances can you develop
as fast in C++ and a RAD-IDE as you can in a language that is good
for rapid development.
And I say, again, never. Because if you have to walk 10 kilometers
to the road and then get in a Volvo to drive 10 minutes to the beach,
it isn't going to matter if somebody says, 'use my Ferrari instead'.
The place you are spending your time when you are developing in C++
isn't in cranking out the lines of code. Unless you happen to have
a problem in the rare problem domain where C++ is the best suited language
for solving the problem, then trying to solve it in some language
that is better suited for rapid development will always be faster,
no matter how turbo-charged your C++ IDE is.
> A solo programmer
> or a small team that knows how to "fly in formation" doesn't have your
> corporate $400/hour idiocy problems to contend with.
And when we formed AB Strakt, one thing we agreed on was that we were
NOT going to develop in C++. We were that killer team, and we could
pick whatever language we chose. It wasn't C++, the language that all
of us were experienced with, and some of us were superbly experienced
with. We knew all of the strengths of C++. And, moreover, we knew
that we could get so much more work done if we picked a faster
language than C++ to develop in. We picked Python even though we had
to first learn the language from nothing but the online docs and
tutorials at python.org. We had never used it before. We just had it
recommended to us as _the_ rapid development language. This was
good advice. It was _still_ faster than developing in C++. And
when some people got impatient with that, we went and spent the money
on Wing IDE. If IDEs speed you up, Wing IDE will speed you up with
Python.
Laura Creighton
David M. Cook
> Is, or under which circumstances is the time which can be gained by using a
> RAD-IDE equivalent to the time gained by using Python directly?
"RAD-IDE" environments usually provide things like UI layout and boilerplate
generation. But UI layout is really a small part of the work on any app
(though one of the more tedious chores), and Python doesn't need all that
boilerplate that C++ does. That said, there are several RAD/IDEs for Python
such as Boa Constructor (for wxPython) and Eric (for PyQt).
I use pygtk with glade for layout and XEmacs for editing.
Dave Cook
Brandon Van Every
>
> Last C++ job I had paid roughly $400 Euros an hour. And the reason
> they paid me this was because indeed, it was as onerous as I made it
> sound. This is what I was paid to do all day long.
Don't conflate taking the worst pain the world has to offer for all case
uses. The simpler the individual / team coding practices, the more viable
C++ becomes.
Brandon Van Every
I see no primary purpose for Python's existence other than as a glue
language.
Brandon Van Every
>
> Two people can write different code to do the same thing. Which is
> better? The code that was written the fastest or the one that took
> the time to do a great design such that it is easier to maintain and
> extend?
That depends on how you're getting paid. :-) And how long the code is
meant to last. And how long the code actually lasts, despite what it was
meant to do. And who picks up the tab for that, again. :-)
It is not Pure. Purism in programming is to be avoided.
Erik Max Francis
> I see no primary purpose for Python's existence other than as a glue
> language.
It should be fairly obvious at this point that this guy is trolling.
Move on, nothing to see here.
--
Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/
__ San Jose, CA, USA / 37 20 N 121 53 W / &tSftDotIotE
/ \ Oh, what lies there are in kisses.
\__/ Heinrich Heine
Maths reference / http://www.alcyone.com/max/reference/maths/
A mathematics reference.
John Ochiltree
I think you misunderstand me. First of all, surely, for all of us our 'task'
is to supply computer solutions to problems no matter what languages we
principally work with.
The obvious difference between C++ and python is surface complexity. Python
allows you to 'see' the solution a lot faster; C++ - you have to mentally
filter out all the gumph that is not to do with the solution. For instance,
if I apply a pattern (an architectural feature) in either language I can
see how the pattern supports the solution faster and easier with Python
than I can with C++. I tend to use python to prototype and explore possible
solutions but if I need optimisation I do a thorough up front design based
on the prototype but using C++.
BTW, I use 'unittest' and 'cppunit' profusely no matter what language I'm
using. I use XEmacs as my editor and QDesigner for GUI building as I can
get it to generate C++ or Python.
I'm not sure I understand what you mean by a 'glue' language. I've yet to
come across a problem I couldn't solve with either language!
Regards
John Ochiltree
Alex Martelli
> Does the language really matter? If you have a poor design, and your
> team consists of hackers, it really doesn't matter what language you
> use, it'll eventually end up a big mess.
Yes, the language really DOES matter -- although it's not the ONLY
thing that matters, of course, not by a long shot. Analogy...:
"If your national entry to the Olympics 4x100m Relay Race consists
of four couch potatoes, it really doesn't matter what shoes you use,
it'll come in last". True: obviously, if you want your nation to
stand any chance for a medal in such competition, the team _must_
consist of well-trained athletes. But it would be the height of
madness to jump from this to wondering whether shoes really matter:
having your team run in hobnailed boots, or furry slippers, would
STILL be more or less a guarantee of defeat, if the other teams are
being more sensible about shoe choice.
> In conclusion, the tools are only as good as the people who use them :)
Again, this is like saying that shoes only run as fast as the
people who wear them. True, but it DOESN'T follow, by any means,
that choosing the most appropriate kind of shoes isn't important.
Alex
Alex Martelli
...
> Really, look at all the overstuffed functionality available in modern
> widget sets and tell me that Python can somehow do a better job
> interfacing it all than C++ can. It can't.
You assertion is simply false. I'm an expert in both C++ and Python,
and I have experimented writing GUI's with both Qt driven by C++, and
PyQt driven by Python: Python's productivity advantage for this task is
about a factor of two in my experience -- not as high as for most kind
of code (where factors of about four to ten are more common in my
observations) but high enough to matter.
If you generate your Qt or PyQt interface with WYSYWIG tools (Qt
Designer, BlackAdder, Eric, ...) then, since the tools look and feel
much the same, it makes no real difference what kind of code they
generate, of course -- until you start coding to make your GUI be
_alive_, i.e., do anything but look pretty on the screen, and then
Python's productivity advantage immediately kicks in again.
(Personally, I'm more productive CODING a GUI [even in C++ plus
Qt...] than PAINTING it [say with Qt Designer] -- but, that's just
me, I realize: I think verbally, not visually, to a far greater
extent than most people, so GUI painters and other tools that
force me to think visually almost inevitably slow me down -- and
indeed I'm almost the last person you should want to DESIGN a GUI
in the first place -- but, these are totally separate issues).
Alex
Erik Max Francis
> Yes, the language really DOES matter -- although it's not the ONLY
> thing that matters, of course, not by a long shot. Analogy...:
I think you're taking the original poster's comments too far. The point
is, it's possible to write lousy code in _any_ language, regardless of
how well-thought of it is or thought to be conducive to writing good
code.
There are certainly some languages that promote bad habits right up
front. Python isn't one of them. Sure, the choice of language does
play a part, but that doesn't mean that just because you're programming
in Python, that you're writing clean and clear code, anymore than _just
because_ you're writing code in "a language that's traditionally
associated with bad habits" (I won't bother listing any here), that it's
necessarily bad.
> Again, this is like saying that shoes only run as fast as the
> people who wear them. True, but it DOESN'T follow, by any means,
> that choosing the most appropriate kind of shoes isn't important.
But that's not what he said. He simply said that even good tools, in
the wrong hands, can be used poorly. You're taking the analogy to a
completely different level that he certainly never intended. Bad tools
can be used deftly by competent people. Even the best tools can be used
poorly by incompetent people.
I think your point is well-taken, but you're polarizing an argument far
beyond what was originally stated.
--
Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/
__ San Jose, CA, USA / 37 20 N 121 53 W / &tSftDotIotE
/ \ The color is red / Under my shoe
\__/ Neneh Cherry
CatCam / http://www.catcam.com/
What do your pets do all day while you're at work? Find out.
Alex Martelli
...
> You need to get over your notion that there cannot exist a person who
> is excellent at something and who hates it at the same time.
Amen, hallelujah. Sullivan *hated* writing operetta music, by all
accounts -- it was just something he HAD to do, to keep bread (and
caviar -- he had expensive tastes;-) on the table; what he LOVED
was writing pompous, "noble" music which (fortunately) nobody but
scholars remember any more -- while the Mikado, e.g., is immortal.
There's definitely a _correlation_ between loving something and being
good at it, but outliers on both sides of the "main sequence" are
just too frequent and obvious in both history and everyday life to
ignore them.
Alex
Alex Martelli
> Laura Creighton wrote:
>> That is because almost
>> all my time spent in C++ come from some other place than actually
>> writing code from scratch. Other people's milage may vary.
My own C++ experience was about 50-50 between "writing my own code"
(both "from scratch" and as changes to things I had previously
written) and helping colleagues with their code. Both tasks are
somewhat onerous with C++, though the second is even more so.
> Find a different job then.
I have -- mostly, with the company Laura co-founded, AB Strakt -- so
I can now code just about exclusively in Python, thanks be. So what?
That doesn't mean I shouldn't feel the pain of people who cannot yet
do so, and see if I can't help them enhance their quality of life by
doing more Pyton and less C++ (I'm not as extreme as Laura in claiming
the ideal quantity of C++ in the mix is zero: I'd guesstimate
"somewhere between 0 and 20%" depending on application area &c).
Human solidarity, an engineer's appreciation for using the RIGHT
tools, and an amateur economist's love of productivity increases
anywhere in the economy, all push me towards offering such help.
> Are you getting paid well for your C++
> headaches? I wouldn't put up with it if it's as onerous as you make it
> sound. Unless the money is really really good.
As Laura indicated, in her case you could probably use at least THREE
repetitions of "really"... in mine, just one "really" would be enough.
But, it only matters up to a point, particularly in the context of
this thread's subject. Hourly cost to hire a top-notch C++ or Python
programmer isn't all that different. The point is, rather, that for
Python coding you can expect higher productivity by a factor of, say,
two to ten; maintenance productivity is similar.
Other phases of software development also benefit, although to lesser
degrees and depending on using appropriate methodological approaches --
e.g., having iterative analysis and design based on rapid feedback
cycles with the customer (or whoevers stands for the customer) lets
you do faster and better design and analysis with Python, while
"waterfall" development would be just as much of a disaster in any
language, just about.
Alex
Michael Hudson
> Typing 400 words a minute helps as well. I cannot do that yet, but
> one person here at Strakt can. Utterly awesome. I thought that
> 200 words was good....
I think I can guess who that is :)
Cheers,
M.
--
> So what does "abc" / "ab" equal?
cheese
-- Steve Holden defends obscure semantics on comp.lang.python
Laura Creighton
>
> > Typing 400 words a minute helps as well. I cannot do that yet, but
> > one person here at Strakt can. Utterly awesome. I thought that
> > 200 words was good....
>
> I think I can guess who that is :)
>
> Cheers,
> M.
And I think you would be guessing the wrong name ....
Laura
Michael Hudson
Probably. How fast can Alex type then? It must be pretty fast.
Cheers,
M.
--
31. Simplicity does not precede complexity, but follows it.
-- Alan Perlis, http://www.cs.yale.edu/homes/perlis-alan/quotes.html
Cameron Laird
Laura Creighton <l...@strakt.com> wrote:
.
.
.
>Typing 400 words a minute helps as well. I cannot do that yet, but
>one person here at Strakt can. Utterly awesome. I thought that
>200 words was good....
.
.
I thought that Gregory Arakelian is recognized as the world record
holder at 158 wpm <URL: http://www.cciw.com/content/typing.html >.
While I suspect there are a handful of people who, in fact, surpass
his mark, I'm equally confident that no human has achieved 400 wpm.
--
Cameron Laird <Cam...@Lairds.com>
Business: http://www.Phaseit.net
Personal: http://phaseit.net/claird/home.html
Peter Hansen
>
> Peter Hansen wrote:
> > Brandon Van Every wrote:
> >>
> >> Python is a "glue" language, ...
> >
> > Just checking here :-)... you're not saying Python is *only* a glue
> > language, right? Just that it *can be* used as a glue language when
> > you need such a thing?
>
> I see no primary purpose for Python's existence other than as a glue
> language.
I would have responded at more length, but thankfully Erik Max Francis
posted first and pointed out the (what should have been to me) obvious:
you're trolling.
In any event, you would not be able to say that after visiting a
company (such as my current employer; contact me offline to arrange
a visit if you're in the Toronto area) which makes extensive use of
Python as far more than a glue language.
We write almost exclusively in Python, and include in the set of
applications which we write: factory test automation, web applications,
standalone GUI programs, embedded systems, and something else... let
me think what it could be.... oh yeah, *glue*.
But I'm now sure you're trolling (especially since we've never heard
you here before) so I doubt I'll respond to further posts.
-Peter
Dave Brueck
> In article <mailman.104379953...@python.org>,
> Laura Creighton <l...@strakt.com> wrote:
> .
> .
> .
> >Typing 400 words a minute helps as well. I cannot do that yet, but
> >one person here at Strakt can. Utterly awesome. I thought that
> >200 words was good....
> .
> .
> .
> I thought that Gregory Arakelian is recognized as the world record
> holder at 158 wpm <URL: http://www.cciw.com/content/typing.html >.
> While I suspect there are a handful of people who, in fact, surpass
> his mark, I'm equally confident that no human has achieved 400 wpm.
Obviously it's 400 *metric* words per minute. ;-)
-Dave
Alex Martelli
...
> I think your point is well-taken, but you're polarizing an argument far
> beyond what was originally stated.
I guess we'll have to agree to disagree. What was originally
STATED was, e.g., a rhetorical question "Does the language
really matter?" (and as a rhetorical question, it implies an
answer of "not really"). What was MEANT by this, I'm not very
interested in guessing -- I'm no mindreader, nor am I training
to become one.
In my experience, assertions about "language not really
mattering" (whether phrased openly, or as rhetorical questions)
are most often used by people who try to defend lousy languages
(or ones who try to sell silver-bullet languages, methodologies,
and the like).
Alex
Nomad
wrote:
>> Hi all,
>>
>> I don't want to start a thread comparing the Python and C++ languages, but
>> one question bothers me. Using Python, you can of course develop very
>> quickly due to high level constructs and the absence of compilation. On the
>> other hand, so-called "builder IDEs" or "RAD-IDE" (i.e. Borland C++ builder,
>> Microsoft Visual C++) also promise to allow you to develop quickly, even in
>> a less high-level language.
>>
>> Therefore, my question is:
>>
>> Is, or under which circumstances is the time which can be gained by using a
>> RAD-IDE equivalent to the time gained by using Python directly?
>>
>> -Patrick
>
>My guess is 'never'. The problem with developing in C++ is not that
>you don't have an IDE that makes development faster, but that in C++
>there are so many ways to shoot yourself in the foot that you have
>to spend forever re-reading your code to make sure that it doesn't
>interact in nasty, horrible ways with other people's code. Or you
>spend your life debugging other people's badly designed templates.
>Or on the phone to Borland saying that you have found another bug in
>the destructors ... or ....
>
>I don't think that it is possible to write an IDE that makes me as
>productive in C++ as I am in Python with ed(1). That is because almost
>all my time spent in C++ come from some other place than actually writing
>code from scratch. Other people's milage may vary.
>
>Laura Creighton
I have to agree with Laura except for one point (I couldn't resist it
really, and apologies to Bjarne):
C makes it easy to shoot yourself in the foot. However, with C++,
you're likely to blow off your whole leg.
;-)
--
Nomad
Wondering of the vast emptyness of the 'net
in search of something cool.
Mongryong
> you're likely to blow off your whole leg.
If you read the "is it a bug??" thread, its a perfect example of why
every language will shoot yourself in the foot if you don't understand
it. Python is no different.
Brandon Van Every
>
> C makes it easy to shoot yourself in the foot. However, with C++,
> you're likely to blow off your whole leg.
Ok, I have to ask for some apples to apples in the strategic comparison
dept. C++ has a bazillion users. Well, that's an exaggeration, but it has
the lion's share of the programmers. Enter Python, and "avant garde" Python
aficionados such as found in this forum. A tiny minority of early converts
who do not experience problems because they're all good engineers anyways.
When Python is finally used by every schmuck out there, to the same degree
that C++ is, I predict you'll see as many people blowing off their leg with
Python as with C++. At least in terms of rough orders of magnitude.
Python may a be a great productivity tool for the power programmer, but I
seriously doubt that it's any kind of magic bullet for the average engineer.
Brandon Van Every
> Brandon Van Every wrote:
>>
>> I see no primary purpose for Python's existence other than as a glue
>> language.
>
> I would have responded at more length, but thankfully Erik Max Francis
> posted first and pointed out the (what should have been to me)
> obvious: you're trolling.
Oh please fuck off. Erik Max Francis has been in my killfile for a long
time. And now you are too: I can't stand people who read someone else's
opinion and answer "You're trolling!" in order to shut it down.
Peter Hansen
>
> C++ has a bazillion users. Well, that's an exaggeration, but it has
> the lion's share of the programmers.
Depending on what the heck "lion's share" means, this is either
true at the present time, or patently false. Not really germane,
however, I suppose.
> Enter Python, and "avant garde" Python aficionados such as found in
> this forum.
Interesting adjective... you *are* trolling, aren't you? :-)
> A tiny minority of early converts
> who do not experience problems because they're all good engineers anyways.
> When Python is finally used by every schmuck out there, to the same degree
> that C++ is, I predict you'll see as many people blowing off their leg with
> Python as with C++. At least in terms of rough orders of magnitude.
You're overlooking the experience of those like Alex Martelli (and me,
and dozens of others) who have already used C++ extensively, and *are*
good engineers, as you suggest, and yet who have found far more fertile
ground for a wide range of problems in that baroque language than we
have in Python.
I don't think anyone who has programmed in both languages for years
would agree with your statement.
> Python may a be a great productivity tool for the power programmer, but I
> seriously doubt that it's any kind of magic bullet for the average engineer.
There is no magic bullet for the "average engineer". Remember what
Brooks said... he is still right.
-Peter
Peter Hansen
>
> Peter Hansen wrote:
> > Brandon Van Every wrote:
> >>
> >> I see no primary purpose for Python's existence other than as a glue
> >> language.
> >
> > I would have responded at more length, but thankfully Erik Max Francis
> > posted first and pointed out the (what should have been to me)
> > obvious: you're trolling.
>
> Oh please fuck off. Erik Max Francis has been in my killfile for a long
> time. And now you are too: I can't stand people who read someone else's
> opinion and answer "You're trolling!" in order to shut it down.
:-)
I needed a smile after this day at work. Thanks!
-Peter
Brandon Van Every
>
> The obvious difference between C++ and python is surface complexity.
I agree. C++ is unnecessarily verbose and picky.
> Python allows you to 'see' the solution a lot faster; C++ - you have
> to mentally filter out all the gumph that is not to do with the
> solution.
I disagree. 90% of the time I do not use the verbose / picky stuff. For
the kinds of 3D graphics problems I usually tackle, it isn't going to make
any difference whether the class methods are specified in Python or C++.
I do agree that when I *am* forced into the verbose / picky stuff that 10%
of the time, I lose disproportionate amounts of time mastering yet-another
language "feature" of C++. Consequently, I Keep It Simple Stupid 90% of the
time. That's how you survive in a C++ world. You either do things in a
very simple and straightforward way, or you get paid a lot of money by
someone else to deal with the headaches.
> For instance, if I apply a pattern (an architectural
> feature) in either language I can see how the pattern supports the
> solution faster and easier with Python than I can with C++.
For my particular case use, I do not believe in patterns. I believe in
mathematics. I care about things like "SphereArc" or "Trigrid." Not
"Abstract Factory" or "Singleton/Letter." I've got books on all that stuff,
and for what I do, it's rubbish.
> I tend to
> use python to prototype and explore possible solutions but if I need
> optimisation I do a thorough up front design based on the prototype
> but using C++.
I just code up an exceedingly minimal feature set in C++ to begin with. I
don't code things unless I absolutely know that I need them. I have a RISC
attitude towards coding, not a featuritis attitude. I am exceedingly
incremental and architectural about how I handle my own development. I can
do that because I'm the only one coding. In a customer environment where I
had to spew a lot of featuritis to please fools, I'd probably adopt
different tactics.
In my game development, I forsee a time when I'll need a more flexible,
experimental approach to coding. But right now I'm building the structural
foundation. C++ is the correct tool for my jobs right now.
Brandon Van Every
>
> You assertion is simply false. I'm an expert in both C++ and Python,
> and I have experimented writing GUI's with both Qt driven by C++, and
> PyQt driven by Python: Python's productivity advantage for this task
> is about a factor of two in my experience --
>
> Qt...] than PAINTING it [say with Qt Designer] --
>
> in the first place -- but, these are totally separate issues).
You're sending conflicting signals here. Maybe the middle ground is that
for your GUI design and coding style, Python is an advantage. For my GUI
design and coding style, perhaps not. I'm quite comfortable with designing
things visually, using pencil-and-paper as my prototype, and I don't often
design stuff I don't need. Maybe it's fair to say Python will help *some*
kinds of coders disproportionately, but not others?
This all sounds like an argument about spontaneous vs. architectural coding
styles.
Lulu of the Lotus-Eaters
|Oh please fuck off
*plonk*
--
Keeping medicines from the bloodstreams of the sick; food from the bellies
of the hungry; books from the hands of the uneducated; technology from the
underdeveloped; and putting advocates of freedom in prisons. Intellectual
property is to the 21st century what the slave trade was to the 16th.
John Ochiltree
Why do you bother to use c++ as you obviously don't care about reuse.
Patterns these days are essential to OO
Simon Wittber (Maptek)
>Brandon Van Every wrote:
>>I see no primary purpose for Python's existence other than as a glue
language.
An obvious troll. Appears to be a successful one too!
Erik Max Francis
> Oh please fuck off. Erik Max Francis has been in my killfile for a
> long
> time. And now you are too: I can't stand people who read someone
> else's
> opinion and answer "You're trolling!" in order to shut it down.
I rest my case. (Though I must say I'm impressed; he's claimed to have
killfiled me at least three times now. Usually he "forgets" so he can
get in one more jab and claims to killfile me again ... wait, he _did_
just get in one more job.)
Let's all go to comp.lang.perl (say) and claim that their language is
_only_ satisfactory as a glue language. Then let's call what we're
doing not trolling, just expressing our opinion. Mmhmm, right.
--
Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/
__ San Jose, CA, USA / 37 20 N 121 53 W / &tSftDotIotE
/ \ I can paint a portrait of myself / I will call me a black Mona Lisa
\__/ Lamya
CAGE / http://www.alcyone.com/pyos/cage/
A cellular automaton simulation system in Python.
Brandon Van Every
>
> Why do you bother to use c++ as you obviously don't care about reuse.
> Patterns these days are essential to OO
You need to realize that there can be OO and reuse without the "Patterns"
appearing in books like "Design Patterns." That book has absolutely nothing
of use to me on a day-to-day basis.
If you want to say that I use "mathematical patterns," fine. But I choose
to avoid the term "pattern" because it already has a common meaning to OO
people. And personally, I don't think there would be much point listing out
a whole pile of common "mathematical patterns." There are so many of them!
Math has an interesting property: there are lotsa ways to compute the same
thing. No point wrapping it up in the One True Pattern, you just have to
know how to do math.
Quite simply, we had functions and methods and classes and OO long before we
had patterns.
Brandon Van Every
A person of no use because he writes off anything aberrant as "troll."
Goodbye!
Man, I am so sick of Usenet. Why do I bother? Oh, I remember now... my
eyes are glazing over after all the C++ code I've been writing. I'm
laboring under the delusion that this "break" somehow helps.
John Ochiltree
You seem to be suggesting that when you discover a problem to be solved you
approach it from mathematical first principles? And what sort of
mathematical pattern could be useful in implementing a singleton for
instance (leaving aside the obvious distinction required between none and
unity)? Or the notion of the decorator, or abstract factory or just about
any common day to day programming problem? You also appear to think that
patterns provide some sort of direct solution. Implementation is mostly not
supplied (esp. in GoF) and you have to implement the pattern in whatever
language you're working in. The solution that a pattern provides is at the
design level, probably best illustrated by the UML's class and sequence
diagrams (amongst others). Or perhaps you have an aversion to acyclic
graphs as well?
John
Alex Martelli
> Alex Martelli wrote:
>>
>> You assertion is simply false. I'm an expert in both C++ and Python,
>> and I have experimented writing GUI's with both Qt driven by C++, and
>> PyQt driven by Python: Python's productivity advantage for this task
>> is about a factor of two in my experience --
>>
>> (Personally, I'm more productive CODING a GUI [even in C++ plus
>> Qt...] than PAINTING it [say with Qt Designer] --
>> indeed I'm almost the last person you should want to DESIGN a GUI
>> in the first place -- but, these are totally separate issues).
>
> You're sending conflicting signals here. Maybe the middle ground is that
> for your GUI design and coding style, Python is an advantage. For my GUI
> design and coding style, perhaps not. I'm quite comfortable with
> designing things visually, using pencil-and-paper as my prototype, and I
> don't often
> design stuff I don't need. Maybe it's fair to say Python will help *some*
> kinds of coders disproportionately, but not others?
Python will only help those coders who write code, when they write
code. It will help designers and analysts in as much as writing
code helps them: as I also indicated elsewhere, if you handcuff
yourself into a metodology where no code at all ever gets written,
then it does indeed make no difference whatsoever whether the code
that never eventuates is unwritten in Python, C++, or Intercal.
On GUI development specifically: those parts of your GUI that you
choose to have code-generated for you by some "GUI painter" program
take you just the same amount of time whatever language your GUI
painter code-generates into. It's only when you want to modify (or
enrich by inheritance, often a better choice) the generated code,
e.g. to make the GUI *DO* anything (whether directly related to
your appication, or indirectly as in a "proof of concept" prototype),
that the language used for the modifications or enrichment matters.
When it DOES matter, Python shines.
> This all sounds like an argument about spontaneous vs. architectural
> coding styles.
Your ears are playing you false. While Python supports "spontaneous"
(interactive, exploratory) coding PRETTY well (not QUITE as well -- in
terms of available environments as opposed to the language itself --
as languages that typically come with IDE's centered on the "workspace"
concept, such as APL, Smalltalk, Lisp; but definitely better than
e.g. Java, C++, Fortran), this does not imply it has any problem at
all with supporting "architectural" (systematic, goal-directed) coding.
I have noticed similar orders of magnitude in the productivity boost
that Python gives me (compared with, for example, C++ or Java) in
either case. For example, re-coding in Python -- with fixed design
and functionality -- a project already existing and working in other
languages, in order to use Python for all future developments. One
would normally "wrap" the existing, working code, rather than
re-code it, but the choice to re-code may be preferable when one
already knows that deep re-factorings and design and architectural
changes will soon be necessary. Anyway, such a re-coding is one
of the most "architectural, systematic" tasks one can imagine --
I've done it a reasonable amount of times, e.g. both ways between
C++ and Java -- and Python offers higher productivity for the task
than either C++ or Java, in my experience and observations.
Alex
Alex Martelli
...
> Python may a be a great productivity tool for the power programmer, but I
> seriously doubt that it's any kind of magic bullet for the average
> engineer.
Python is indeed a great productivity tool for excellent programmers,
raising their productivity (on some hypothetical scale) from, say,
100 to 300.
Python is ALSO a great productivity tool for average programmers,
raising their productivity (on the some hypothetical scale) from, say,
20 to 60.
Therefore, it IS indeed no magic bullet -- it doesn't make the
average programmer the equal of the excellent one -- but it would
still be a stupid choice to forego its advantages at any level.
Alex
Max M
> Man, I am so sick of Usenet. Why do I bother? Oh, I remember now... my
> eyes are glazing over after all the C++ code I've been writing. I'm
> laboring under the delusion that this "break" somehow helps.
Why don't you take the break at the company's water cooler instead?
--
hilsen/regards Max M Rasmussen, Denmark
http://www.futureport.dk/
Fremtiden, videnskab, skeptiscisme og transhumanisme
Ganesan R
> Simon Wittber (Maptek) wrote:
>> Hmmmmm...
>>
>>> Brandon Van Every wrote:
>>>> I see no primary purpose for Python's existence other than as a
>>>> glue language.
>>
>> An obvious troll. Appears to be a successful one too!
> A person of no use because he writes off anything aberrant as "troll."
> Goodbye!
> Man, I am so sick of Usenet. Why do I bother? Oh, I remember now... my
> eyes are glazing over after all the C++ code I've been writing. I'm
> laboring under the delusion that this "break" somehow helps.
Come on, what did you expect? Every one to applaud you? I have programmed in
C++ for over five years and in Java for the last year or two. I am a pretty
good Perl programmer too. I am recently into python and beginning to
appreciate the language a lot; especially in relation to Java. IMHO your
comment deserves the flames it got.
Ganesan
--
Ganesan R
pu
as the "original poster", my personal conclusion is that a C++RAD would be
more "productive" as Python with a GUI library
- if my application is supposed to do a lot of GUI stuff
- and when the application has a "basic" logical flow.
But Alex's arguments could be mine; I do not think graphically, so maybe it
would'nt even be the case for me.
Thanks for saving me 3000$ and for all your answers (well, for most of
them...)
;-)
Brandon Van Every
> IMHO your comment deserves the flames it got.
IMHO, people who gratuitously play "the troll card" in a debate should be
shot. Anyone who believes what they say and is prepared to argue the point
is not a troll.
Brandon Van Every
> Brandon Van Every wrote:
>
>> Man, I am so sick of Usenet. Why do I bother? Oh, I remember
>> now... my eyes are glazing over after all the C++ code I've been
>> writing. I'm laboring under the delusion that this "break" somehow
>> helps.
>
>
> Why don't you take the break at the company's water cooler instead?
Because I work at home. I suppose I could go around the corner to a coffee
shop.
Brandon Van Every
>
> You seem to be suggesting that when you discover a problem to be
> solved you approach it from mathematical first principles?
Yes... my problems right now are all 3D math problems, and need to get
solved by 3D math first principles.
> And what
> sort of mathematical pattern could be useful in implementing a
> singleton for instance (leaving aside the obvious distinction
> required between none and unity)?
This is backwards. We don't condition our implementations to fit abstract
patterns for their own sake! The abstract pattern is supposed to help me
with my implementation. For 3D math problems, it does not help.
> Or the notion of the decorator, or
> abstract factory or just about any common day to day programming
> problem?
You're missing the basic point: not everyone's day-to-day programming
problems are "Patterns" in the sense discussed by books like "Design
Patterns." My day-to-day problems are 3D math problems. They have
absolutely nothing to do with Patterns. Really! I end up thinking things
like "do I need a more abstract container for this thingy?" maybe once every
2 months. Day-to-day it's computation, correctness of test cases, and
optimization.
> You also appear to think that patterns provide some sort of
> direct solution. Implementation is mostly not supplied (esp. in GoF)
> and you have to implement the pattern in whatever language you're
> working in. The solution that a pattern provides is at the design
> level, probably best illustrated by the UML's class and sequence
> diagrams (amongst others).
I can only reiterate: there are many kinds of design that are *not*
Patterns.
> Or perhaps you have an aversion to acyclic graphs as well?
I don't *need* an acyclic graph right now. When I do need it, I am jolly
well not going to implement a general purpose, bloated,
solve-everyone's-problems kind of acyclic graph. I'm going to do something
rather domain specific for my game's AI. Why? Because we don't have the
computing horsepower to afford the recombinations of general purpose
approaches. When we do, in 20 years or so, maybe I'll use acyclic graph
patterns to solve some of my problems.
Brandon Van Every
>
> On GUI development specifically: those parts of your GUI that you
> choose to have code-generated for you by some "GUI painter" program
> take you just the same amount of time whatever language your GUI
> painter code-generates into. It's only when you want to modify (or
> enrich by inheritance, often a better choice) the generated code,
> e.g. to make the GUI *DO* anything (whether directly related to
> your appication, or indirectly as in a "proof of concept" prototype),
> that the language used for the modifications or enrichment matters.
> When it DOES matter, Python shines.
"Do anything" is an extreme formulation. More accurate might be:
1) does the GUI builder provide the hooks I need for my problem domain?
2) is my problem domain going to change much?
>> This all sounds like an argument about spontaneous vs. architectural
>> coding styles.
>
> Your ears are playing you false. While Python supports "spontaneous"
> (interactive, exploratory) coding PRETTY well (not QUITE as well -- in
> terms of available environments as opposed to the language itself --
> as languages that typically come with IDE's centered on the
> "workspace" concept, such as APL, Smalltalk, Lisp; but definitely
> better than
> e.g. Java, C++, Fortran), this does not imply it has any problem at
> all with supporting "architectural" (systematic, goal-directed)
> coding.
My contention is, if your approach is incremental and architectural, Python
does not offer any amazing payoff over C++. Python only gives you a big
value add when you're trying to be more spontaneous.
> I have noticed similar orders of magnitude in the productivity boost
> that Python gives me (compared with, for example, C++ or Java) in
> either case.
Expertise, quality / badness of the design you're working with, and your
level of control over the project are all factors here. It's hard to
compare apples to apples without looking at someone's project. I guess in
the end, you just try it out. I wonder if people evaluate their positive
experiences for the correct reasons though.
Alan Morgan
Brandon Van Every <vane...@3DProgrammer.com> wrote:
>Simon Wittber (Maptek) wrote:
>> Hmmmmm...
>>
>>> Brandon Van Every wrote:
>>>> I see no primary purpose for Python's existence other than as a
>>>> glue language.
>>
>> An obvious troll. Appears to be a successful one too!
>
>A person of no use because he writes off anything aberrant as "troll."
>Goodbye!
You are correct. We should have judged your arguments on their merits.
Wait a minute... you didn't *present* an argument. That explains it.
Alan
--
Defendit numerus
Brandon Van Every
>
> Python is ALSO a great productivity tool for average programmers,
> raising their productivity (on the some hypothetical scale) from, say,
> 20 to 60.
Why don't they just shoot themselves in the foot with all the new concerns,
until they've mastered the drill and hence have become better programmers?
Sounds like the progression might be more like 20, 25, 15, 10, 20, 25, 30,
60. Over that time period, how much better would they have gotten with C++?
> Therefore, it IS indeed no magic bullet -- it doesn't make the
> average programmer the equal of the excellent one -- but it would
> still be a stupid choice to forego its advantages at any level.
You would not inflict new tools on dummies needlessly. You have to allow
for training time to achieve benefits.
Alex Martelli
...
> Python
> does not offer any amazing payoff over C++. Python only gives you a big
> value add when you're trying to be more spontaneous.
Your contention is wrong as stated: _my_ approach IS "incremental and
architectural" more often than not, yet Python DOES enhance my
productivity enormously when compared with C++. I've been _the_
C++ expert for my former employer for many years, taught C++ to
all other colleagues, etc -- it's not an issue of mastery of C++,
either. It IS an issue of Python's magic.
>> I have noticed similar orders of magnitude in the productivity boost
>> that Python gives me (compared with, for example, C++ or Java) in
>> either case.
>
> Expertise, quality / badness of the design you're working with, and your
We're talking about the SAME designs (being transliterated for
example from Modula-2 to both C++ and Python; from C++ to both
Java and Python; etc). Expertise (at the time) higher with
C++ than with either Java or Python. So both factors are ruled out,
period -- and your contention remains simply wrong.
> level of control over the project are all factors here. It's hard to
Same level of control over the project in both cases: one was a
personal project (total control), another a proprietary protocol
of the firm (zero control) -- in both cases the design was just
being "transliterated" (possibly as a first step for FUTURE
changes and refactorings). Again, this factor is ruled out as
a possible explanation for any observed differences.
> compare apples to apples without looking at someone's project. I guess in
> the end, you just try it out. I wonder if people evaluate their positive
> experiences for the correct reasons though.
I'm careful to change just ONE factor when I try such things.
The ONE factor is: what language I'm transliterating into.
Other factors (the design, &c) are fixed.
Python proves very productive for this. Roughly: transliterating
into Java yielded about 20% overall productivity gain wrt C++ (main
gain: no worry about "who owns what" and when to delete what; main
offsetting factor: Java lacks templates) -- too small to matter.
Transliterating into Python yielded about twice the productivity
wrt C++ (main gains: no worry about who owns what, no casts
needed, nested functions, everything works "template-like", i.e.
with signature-based polymorphism, without all of the syntax
cruft; only small cost, since PyChecker didn't exist at the time,
having to run the unit tests even to catch typos -- but that one
didn't have a measurable impact, 'twas just a small annoyance).
A productivity gain by a factor of two is large enough to
matter. I have observed (under less strictly controlled
conditions) higher gains for "greenfield" projects, since
then the design can be more tailored to Python (appropriate
design patterns are for example quite different, depending
on what language you're targeting) _AND_ spiral/incremental
approaches are better supported.
Alex
Alex Martelli
> Alex Martelli wrote:
>>
>> Python is ALSO a great productivity tool for average programmers,
>> raising their productivity (on the some hypothetical scale) from, say,
>> 20 to 60.
>
> Why don't they just shoot themselves in the foot with all the new
> concerns, until they've mastered the drill and hence have become better
> programmers?
Because the "new concerns" are not necessarily major ones. One
can get started and be very productive with Python surprisingly
fast.
> Sounds like the progression might be more like 20, 25, 15,
> 10, 20, 25, 30,
> 60. Over that time period, how much better would they have gotten with
> C++?
Your ear is playing you false, again. The short time it takes
to become highly productive with Python does not afford any
substantial chance of becoming much better with C++: the
latter is just too complex for any _rapid_ improvement.
>> Therefore, it IS indeed no magic bullet -- it doesn't make the
>> average programmer the equal of the excellent one -- but it would
>> still be a stupid choice to forego its advantages at any level.
>
> You would not inflict new tools on dummies needlessly. You have to allow
> for training time to achieve benefits.
The key word that makes your statement irrelevant is "needlessly".
But let's start with "dummies" first: if they ARE dummies then
they should avoid C++ at almost any cost -- it's TOTALLY unsuitable
for programmers outside the top few centiles anyway (being in the
top few centiles is a necessary, but not a sufficient, condition
for being in one of the very few cases where C++ is advisable).
So, supposing they ARE about average among the people who possibly
SHOULD be programming in C++ -- making them two or three times
more productive is NOT needless: it's the kind of productivity
jump that can make the difference between a firm's success and
failure, indeed between a whole nation's impoverishment and
enrichment.
Alex
Mongryong
Let's end this silly thread since the original poster got their answer
(which was?? oh, to never ask another Python vs 'Some other language'
question ever again).
I've started a new thread: Python Success Stories or Nightmares
Let's put those BASc, MASc, Ph.d, or Highschool Diploma's to good use,
huh?
Greg Ewing (using news.cis.dfn.de)
> Erik Max Francis has been in my killfile for a long
> time. And now you are too: I can't stand people who read someone else's
> opinion and answer "You're trolling!" in order to shut it down.
And may people tend to lose interest in someone who
publically announces that they're putting someone
else in their kill file. :-)
Erik Max Francis
> Yes... my problems right now are all 3D math problems, and need to get
> solved by 3D math first principles.
It's highly (and I stress _highly_) unlikely that "all" your problems
are ones that have not been solved by someone else in the entire history
of mathematics. Whether you think there's value in finding solutions
yourself is a side point; you almost certainly are reinventing the wheel
to some degree.
--
Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/
__ San Jose, CA, USA / 37 20 N 121 53 W / &tSftDotIotE
/ \ The only way to get rid of a temptation is to yield to it.
\__/ Oscar Wilde
Bosskey.net: Quake III Arena / http://www.bosskey.net/q3a/
A personal guide to Quake III Arena.
Andy Freeman
> My contention is, if your approach is incremental and architectural, Python
> does not offer any amazing payoff over C++. Python only gives you a big
> value add when you're trying to be more spontaneous.
The point has been clear for some time. The problem is that the supporting
evidence seems to be "I think". Meanwhile, the folks saying that the point
is wrong have actual relevant experience.
Which should I prefer - theory or practice? Yes, theory can be better,
but not when the theory doesn't explain the practice.
For example "You only think that you're 4x as productive because ...".
-andy
Laura Creighton
> My contention is, if your approach is incremental and architectural, Python
> does not offer any amazing payoff over C++. Python only gives you a big
> value add when you're trying to be more spontaneous.
The point that some of us were trying to make is that developing in
C++ is _slow_. Now it may be that your heavy-duty graphics primatives
really do have to run like a bat out of hell. Thus, poor you, you so
need fast code running speed that it is worth it for you to put up
with slower code development speed.
Here is Paul Graham making the same point, but saying that it was
Lisp that made him productive. He thinks that it made him more
productive than Python would have, and that Python would make you
more productive than C++.
http://lib1.store.vip.sc5.yahoo.com/lib/paulgraham/sec.txt
And here he is again,
http://lib1.store.vip.sc5.yahoo.com/lib/paulgraham/bbnexcerpts.txt
swearing that it is because his approach is incremental and architectural
(well suited to Lisp because this is the way Lisp programmers
have been programming for 30 years) that he ran rings around his
competitors.
Laura
Tyler
> When I was working for the Canadian military, we got people working
> on problems and then stuck them in machines which measured blood flow
> in different regions of the brain. Neither python nor C++ were
> invented then, but C and Lisp were.
>
> Statistically, C problem solvers were way more active in the
> language-processing-and symbol-manipulation areas of the brain then
> they were in the parts of the brain associated with imagery, drawing,
> and conceptualising. Lisp problem solvers were more balanced.
As I recall, the rule of thumb is that equalizing blood flow
is a good thing.
But I wonder where you found all those people who could comfortably
program in both Lisp and C. If the subjects weren't at least bilingual
in coding, wouldn't you'd be potentially obscuring the data with
self-selection issues? That is, inadvertently selecting programmer
subjects whose problem set preferences led to their preference for
C, say, and measuring a given blood flow difference because that
was just the way a subject used the brain in programming in general.
This reminds of the anecdotal correspondence of programming with
musicians. Ah, so many variables, so little time...
Tyler
Alex Martelli
...
> Which should I prefer - theory or practice? Yes, theory can be better,
In theory, theory is preferable, but, in practice, I'd prefer practice.
Alex
Laura Creighton
> 006.pyt...@python.org>...
>
> > When I was working for the Canadian military, we got people working
> > on problems and then stuck them in machines which measured blood flow
> > in different regions of the brain. Neither python nor C++ were
> > invented then, but C and Lisp were.
> >
> > Statistically, C problem solvers were way more active in the
> > language-processing-and symbol-manipulation areas of the brain then
> > they were in the parts of the brain associated with imagery, drawing,
> > and conceptualising. Lisp problem solvers were more balanced.
>
> As I recall, the rule of thumb is that equalizing blood flow
> is a good thing.
>
> But I wonder where you found all those people who could comfortably
> program in both Lisp and C. If the subjects weren't at least bilingual
> in coding, wouldn't you'd be potentially obscuring the data with
> self-selection issues? That is, inadvertently selecting programmer
> subjects whose problem set preferences led to their preference for
> C, say, and measuring a given blood flow difference because that
> was just the way a subject used the brain in programming in general.
Indeed. But it was also working with people who had never programmed
in any language before. This is the nice thing about having a group
of soldiers around. You can order them to do things they wouldn't do
on their own and see how they do it. But the methodological problems
still abounded.
Once we apparantly found a difference between French Canadian thinking
and English Canadian thinking, when it came to thinking about parsing.
But I always had a deep suspicion that all we were finding out was
that there was one wonderful course in parsing taught at the
University of Montreal.
>
> This reminds of the anecdotal correspondence of programming with
> musicians. Ah, so many variables, so little time...
Alas. I hope the Buddhists and Hindus are correct. One lifetime isn't
enough.
>
> Tyler
> --
> http://mail.python.org/mailman/listinfo/python-list
Laura
Nick Vargish
> Because I work at home. I suppose I could go around the corner to a coffee
> shop.
Probably not a bad idea... Preferrably one _without_ an 802.11 access
point.
Just for sanity's sake,
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?','')
Jack Diederich
+1 QOTW
Nick Vargish
> +1 QOTW
What about:
"The difference between theory and practice is larger in practice
than in theory."
Mongryong
> > > In theory, theory is preferable, but, in practice, I'd prefer practice.
> > +1 QOTW
>
> What about:
>
> "The difference between theory and practice is larger in practice
> than in theory."
>
"The theory is only as good as the people who [try to] apply them."
Theory is based on idealistic parameters. In an perfect world, it's
100% accurate. In the real world, it's the basis for applying practical
solutions without having to prune the entire solution space. That's the
difference between a University computer science student and a local
college programmer graduate.
Nick Vargish
> In the real world, it's the basis for applying practical solutions
> without having to prune the entire solution space. That's the
> difference between a University computer science student and a local
> college programmer graduate.
I'm confused, which is which again?
I didn't take any formal programming courses after High School, but
judging by some of the people I've worked with who have CompSci
degrees... Well, let's just say I could have done much worse than
Philosophy.
Chad Netzer
That is, of course, because theory and practice are actually equal, in
theory, but in practice, they are not.
(this could become like a chain letter)
--
Bay Area Python Interest Group - http://www.baypiggies.net/
Chad Netzer
(any opinion expressed is my own and not NASA's or my employer's)
Mongryong
> I didn't take any formal programming courses after High School,
with a Computer Science degree....ah, everybody would have a true
Unix-like machine with Python already installed on it...
Have respect for the research work (theories) of others who have helped
computing get to where it is today.
Brandon Van Every
> "Brandon Van Every" <vane...@3DProgrammer.com> writes:
>
>> Because I work at home. I suppose I could go around the corner to a
>> coffee shop.
>
> Probably not a bad idea... Preferrably one _without_ an 802.11 access
> point.
>
> Just for sanity's sake,
I intensely dislike Internet cafes. If I go to a cafe, it's because I want
to interact with *people*. Yet here are all these boobs staring at these
screens. I can do that sort of antisocial thing at home, much more cheaply!
Brandon Van Every
>
> Wait a minute... you didn't *present* an argument. That explains it.
Goodbye, Alan.
Brandon Van Every
> So both factors are ruled out,
> period -- and your contention remains simply wrong.
I will take your data point under advisement, and compare it to my
experiences when someday I finally get to the "Python" stage of my game
project. Right now I'm still in the C++ / math / 3D engine stage. I really
do feel that most of my time right now is spent on design, and that no
language would allow me to code any more rapidly than any other. C++ just
doesn't represent significant overhead for my current case use.
Admittedly, I did just kill a whole pile of "const" declarations for a
container class because it was proving to be far more trouble than it was
worth. I'd gone back and forth on that issue 2 or 3 times, changed a whole
bunch of declarations in a whole bunch of files 2 or 3 times. Finally
decided that any perceived efficiency or safety that const might provide was
not worth it. My one really huge gripe about C++ is how badly it handles
constness for array construction. Sure if you do enough "placement new" you
can solve it, but what a pain in the ass.
If you Keep It Simple Stupid in C++, it ain't that bad.
> Transliterating into Python yielded about twice the productivity
> wrt C++ (main gains: no worry about who owns what, no casts
> needed, nested functions, everything works "template-like", i.e.
> with signature-based polymorphism, without all of the syntax
> cruft; only small cost, since PyChecker didn't exist at the time,
> having to run the unit tests even to catch typos -- but that one
> didn't have a measurable impact, 'twas just a small annoyance).
You're naming a whole bunch of language features that I simply don't use. I
know *how* to use them, I simply choose not to. I avoid unnecessary
complexity, and I'm doing solo development. Maybe it's fairer to say that
Python yields more advantages in a cooperative environment. Whereas if you
can be your own Code Nazi, C++ can work fine.
Brandon Van Every
> "Brandon Van Every" <vane...@3DProgrammer.com> wrote in message
> news:<a2h_9.5383$Wu1.4...@newsread1.prod.itd.earthlink.net>...
>> My contention is, if your approach is incremental and architectural,
>> Python
>> does not offer any amazing payoff over C++. Python only gives you a
>> big
>> value add when you're trying to be more spontaneous.
>
> The point has been clear for some time. The problem is that the
> supporting
> evidence seems to be "I think". Meanwhile, the folks saying that the
> point is wrong have actual relevant experience.
I don't have the Python experience. I do have the C++ experience. You
guys' talk of the horror and gloom and doom of C++ sounds like another
planet to me. So clearly I'm having some kind of experience in C++ that you
are not having. What it sounds like, is you guys blow your legs off with
all the fancy C++ stuff, because you're in group environments where people
don't know how to Keep It Simple Stupid.
Brandon Van Every
> "Brandon Van Every" <vane...@3DProgrammer.com> wrote in message
> news:<a2h_9. 5383$Wu1.4...@newsread1.prod.itd.earthlink.net>...
>> My contention is, if your approach is incremental and architectural,
>> Python
>> does not offer any amazing payoff over C++. Python only gives you a
>> big
>> value add when you're trying to be more spontaneous.
>
> The point that some of us were trying to make is that developing in
> C++ is _slow_.
C++ is not the bottleneck of my current development. At this stage I spend
far, far more time figuring out how to objectify various 3D mathematical
constructs. I would have the same problems of mathematical decomposition in
any language. Development is slow for *that* reason, not C++.
> Now it may be that your heavy-duty graphics primatives
> really do have to run like a bat out of hell.
I'm not doing significant optimization at this point. Mainly the approaches
have to be simple, correct, numerically accurate, and amenable to
optimization later.
> Here is Paul Graham making the same point, but saying that it was
> Lisp that made him productive.
Lisp sounds like a bad fit to my current problems. I'm dealing with simple
geometric relationships, not complicated ones. If I had a lot of very
complicated, freeform geometic relationships to deal with, Lisp would be
more attractive.
Brandon Van Every
>>> In theory, theory is preferable, but, in practice, I'd prefer
>>> practice. +1 QOTW
>
> What about:
>
> "The difference between theory and practice is larger in practice
> than in theory."
I like the symmetry of it. Pragmatists will say that it's a knock on
theory, but if you read carefully, it's just as valid a statement from the
theorist's point of view! In other words, the pragmatists make too much of
the practical concerns.
Brandon Van Every
> On Fri, 2003-01-31 at 15:52, Nick Vargish wrote:
>> I didn't take any formal programming courses after High School,
> Imagine what the world would be like had Bill Gates actually graduated
> with a Computer Science degree....ah, everybody would have a true
> Unix-like machine with Python already installed on it...
No, you wouldn't. People who don't give a crap about degrees get things
done. That's why Microsoft is the business juggernaut that it is. People
at Microsoft know that technology isn't the dominant component, business is.
The university guy is Linus Torvaldis. Linux has the market growth pattern
of an engineer-centric product.
Brandon Van Every
>
> Your ear is playing you false, again. The short time it takes
> to become highly productive with Python does not afford any
> substantial chance of becoming much better with C++: the
> latter is just too complex for any _rapid_ improvement.
Ok, here's how my life went. In May 1992 I graduated from university. In
January 1993 I sat down with a 486 Linux PC and learned C++. It took me a
year. By the end of that time, I'd done every single abstruse thing
possible with C++. Really ridiculous multiple inheritance templates with
cyclical virtual base classes and whatnot. So, having spent the time up
front, C++ hasn't been a big deal for me for 10 years. Recently I brushed
up on some of the "new" ANSI C++ stuff. A small pile of additional things I
don't need much. I don't have a single funky_cast operator in my entire
code base now, although I had 1 or 2 over the past 6 months.
So, how much time do you have to put into Python before you've mastered
*every* aspect of the language? I do mean "every." Less than a year? 6
months? 3 months? Be honest.
> indeed between a whole nation's impoverishment and enrichment.
I hate to break it to you, but gratuitous complexity *maintains*
relationships of power. Consider lawyers, for instance. On the open
market, my C++ skills are worth more money to more people than your Python
skills. It's going to be quite some time before that picture changes.
Brandon Van Every
>
> Alas. I hope the Buddhists and Hindus are correct. One lifetime
> isn't enough.
I think one of the main challenges of life - particularly poignant to a
coder - is not to get bogged down in intractable complexity. Really, you
could clean your house every day. You could plan where every atom of dust
is supposed to go. But that merely creates a lot of labor for you.
Similarly, it is not important to try to correlate bloodflow in the brain
with programming style. Nor to get bogged down in how every brick in the
apartment building across the street is slightly different from every other
brick. It's actually pretty amazing that living organisms negotiate all
this complexity so deftly. Why shouldn't a snail, for instance, become
infinitely confused about available food sources? Because then it would
die.
holger krekel
> Mongryong wrote:
> > On Fri, 2003-01-31 at 15:52, Nick Vargish wrote:
> >> I didn't take any formal programming courses after High School,
> > Imagine what the world would be like had Bill Gates actually graduated
> > with a Computer Science degree....ah, everybody would have a true
> > Unix-like machine with Python already installed on it...
>
> No, you wouldn't. People who don't give a crap about degrees get things
> done. That's why Microsoft is the business juggernaut that it is. People
> at Microsoft know that technology isn't the dominant component, business is.
> The university guy is Linus Torvaldis. Linux has the market growth pattern
> of an engineer-centric product.
But market growth is not the end to it all. Of course you would
contradict business-wise :-)
holger
Martin Maney
>> > In theory, theory is preferable, but, in practice, I'd prefer practice.
>> +1 QOTW
>
> What about:
>
> "The difference between theory and practice is larger in practice
> than in theory."
In theory there is no difference between theory and practice; in
practice there is.
I believe this is Feynman's formulation of this widely-expressed idea.
Erik Max Francis
> I don't have the Python experience.
Well, then, maybe you shouldn't make blanket statements about it only
being good for a glue language (blanket statements which anyone who
_does_ have the Python experience will immediately recognize as
blatantly false).
--
Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/
__ San Jose, CA, USA / 37 20 N 121 53 W / &tSftDotIotE
/ \ It is much safer to obey than to rule.
\__/ Thomas a Kempis
Sade Deluxe / http://www.sadedeluxe.com/
The ultimate Sade encyclopedia.
Laura Creighton
> > indeed between a whole nation's impoverishment and enrichment.
>
> I hate to break it to you, but gratuitous complexity *maintains*
> relationships of power. Consider lawyers, for instance. On the open
> market, my C++ skills are worth more money to more people than your Python
> skills. It's going to be quite some time before that picture changes.
>
> --
> 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.
I think you are confusing 'getting paid' with 'creating wealth'.
Laura Creighton
Laura Creighton
> >
> > Alas. I hope the Buddhists and Hindus are correct. One lifetime
> > isn't enough.
>
> I think one of the main challenges of life - particularly poignant to a
> coder - is not to get bogged down in intractable complexity. Really, you
> could clean your house every day. You could plan where every atom of dust
> is supposed to go.
And my brain just went 'where every atom of dust goes'. *ping* cool
problem in fluid dynamics (one of my chief joys in life). Next time
I clean house, which I don't find particularily pleasant, because it is
tedious, I am going to think about the airflow I am generating and its
effect on dust-mote propegation. Thank you. You have just made my life
more pleasant.
> But that merely creates a lot of labor for you.
We are so different as people. I don't find 'avoiding labour' a
reasonable end in itself. I cannot tell the difference between that
and sheer laziness. 'Labour saving' strikes me as all well and good
when it frees up your labour, and most especially your time to do
something that you would rather be doing, but not because labour
is something inherantly evil that needs avoiding.
> Similarly, it is not important to try to correlate bloodflow in the brain
> with programming style.
You don't see the joy in this? Or the utility? You have some definition
of 'important' and these do not fit. Where do those of us who walk around
with other definitions of 'important' fit?
> Nor to get bogged down in how every brick in the
> apartment building across the street is slightly different from every other
> brick.
Actually, this is the subject of one chapter in David Pye's 'the
Nature and Art of Workmanship', one of my most favourite books. David
Pye was a professor of Furniture Design and (also) Architecture.
Irregularity in construction components is part of what makes certain
buildings 'beautiful' while others, made of more regular components,
look 'ugly as sin'. But just making things different will not do
either. It is a very wonderful, beautiful, joyful problem in
architecture, and one that has terrific parellels in other acts of
creation.
> It's actually pretty amazing that living organisms negotiate all
> this complexity so deftly. Why shouldn't a snail, for instance, become
> infinitely confused about available food sources? Because then it would
> die.
It is dying anyway, Brandon. That is the tragedy that started this
note. The question is 'did it live its life well, by its own lights'?
I am not certain that the question has meaning for a snail. I know
it has meaning for a man.
Laura Creighton
>
> --
> 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.
>
Alex Martelli
...
>> > indeed between a whole nation's impoverishment and enrichment.
>>
>> I hate to break it to you, but gratuitous complexity *maintains*
>> relationships of power. Consider lawyers, for instance. On the open
>> market, my C++ skills are worth more money to more people than your
>> Python
>> skills. It's going to be quite some time before that picture changes.
> I think you are confusing 'getting paid' with 'creating wealth'.
I think Laura is right on the spot, as usual. Let me elaborate
in my own usual (i.e. verbose :-) way.
David Ricardo's "The Principles of Political Economy and Taxation"
(not a _pleasant_ read IMHO -- I find Ricardo's style ponderous, the
very opposite from the delightful, sparking English of e.g. Adam
Smith -- but deep and important) goes into that quite well, IMHO.
The whole book is available online, by the way:
http://www.socsci.mcmaster.ca/~econ/ugcm/3ll3/ricardo/prin/
You'll find the distinctions between "value" on one side, and "wealth"
or "riches" on the other (essentially the former meaning "value for
exchange", the second "value for use") debated throughout the history of
economics -- and often in much more brilliant language -- but never, IMHO,
with deeper insight than Ricardo exhibits. Chapter 20 of the book
is entirely about this issue, and one key paragraph is:
"""
It is through confounding the ideas of value and wealth, or riches that
it has been asserted, that by diminishing the quantity of commodities,
that is to say of the necessaries, conveniences, and enjoyments of
human life, riches may be increased.
"""
I'm talking about "riches" aka "wealth" in Ricardo's terms -- the
abundance of necessaries, coveniences and enjoyments of human life --
and specifically about those of a *whole nation*.
Brandon seems to think that there is some relevance to this that,
by creating or maintaining some scarcity, certain individuals can
be enabled to capture more "value" ("more money"). Either he has
not studied Ricardo, or he thinks _I_ haven't...
One of Ricardo's examples discusses the possibility of a scarcity
of *water* -- in his times (1820's) a paradox, today anything but
(usable water IS scarce and costly in many places in the world).
If you could create or maintain a scarcity of water, and control
some of that scarce and therefore valuable resource, you, as an
individual, might well profit for it, by diverting larger slices
of the nation's wealth into your pockets; but the nation's wealth
as a whole would inevitably diminish. You'd get a larger slice
(possibly even larger in absolute terms) of a diminishing cake.
Similarly, professionals since age immemorables have striven and
often succeeded in creating an artificial scarcity of their own
services by restricting entry and practice into the profession
(invariably with the noblest of motives, of course -- ensuring
the public's safety, the quality of professional services, and
so on -- it is, no doubt, just a side effect that this kind of
barriers to entry increases the income of those already in...;-).
Much the same goes for "programming productivity" -- it can be
made artificially scarce, temporarily enriching those who can
command it to the (greater) detriment of everybody else, and
that will invariably be done for the noblest of motives.
Some of us are keener on *growing the pie* for everybody, than
on appropriating larger slices thereof. Admittedly, such an
attitude is easier to hold when one has already enough saved
resources set aside to live comfortably, and/or absolutely no
doubt that, whenever more income should be needed, it will be
relatively trivial to obtain it (perhaps by doing some spell at
an unpleasant but highly remunerated skill one has).
But, it IS a choice each person needs to make on their own. If
you want to artificially maintain scarcity, impoverish everybody
but possibly enrich yourself, then high-productivity tools such
as Python may be seen as a threat to your prospects -- this may
explain why some people get so venomonous in their attacks against
such tools. If you prefer to increase wealth and reduce poverty
all around, then you should know that increasing the productivity
of all factors of production (labour first and foremost) is really
the only way -- thus, technological developments that lead to
higher productivity, and in particular high-productivity tools
such as Python, should be welcome, embraced, and evangelized.
What kind of world we are going live in, will be in part determined
by the choices made by everybody along this particular axis.
Perhaps a more interesting question would be, what social
arrangements (enforceable by law) would help Adam Smith's
"Invisible Hand" work more expeditiously in ensuring that the
wealth-increasing technologies are ALSO value-increasing in
the not-too-long run (in the long run, we're all dead...:-).
Here, I know Laura and I partly differ. I agree with Smith
that what allows some groups to capture wealth by impoverishing
everybody are mostly social arrangements that interfere with
the free market: intellectual property laws, limited-liability
corporations (allowing the creation of lumbering giants that
can and do use all sort of tricks to maintain their privileged
position to everybody's detriment), legal sanction of the status
of privileged professional groups and castes. What we think
of, today, as a "free market", is anything BUT, and rereading
Smith (besides being utterly pleasant;-) is a helpful reminder
of that. Others may believe that the best answer to the
inevitable distortions of markets by such laws and regulations
is, _MORE_ laws and regulations (the latter, by some unexplained
magic, will NOT be captured and exploited by special interests
and lobbying groups as all the previous ones have always been;-).
But, this is admittedly quite a different issue, anyway.
Alex
Alex Martelli
...
> really do feel that most of my time right now is spent on design, and that
> no
> language would allow me to code any more rapidly than any other. C++ just
Python has the potential to make your design more productive, too.
Whenever you have to choose between (algorithms, data structures,
or more generally "approaches") A, B and C, Python makes it quite
feasible to code them all and then choose between them on the basis
of actual experience, rather than mere theories.
> If you Keep It Simple Stupid in C++, it ain't that bad.
But you can't keep C++ all that "simple", really.
>> Transliterating into Python yielded about twice the productivity
>> wrt C++ (main gains: no worry about who owns what, no casts
>> needed, nested functions, everything works "template-like", i.e.
...
> You're naming a whole bunch of language features that I simply don't use.
You cannot "simply not use" ``worry about who owns what'' in C++.
SOME object X has to hold THE owning-pointer (e.g. auto_ptr) to
another object Y, while other pointers to Y don't "own" it -- you
have to KNOW when Y gets freed; or else you get to reimplement
reference counting and/or other approaches to garbage collection,
infrastructure which Python gives you in a much better developed
and usable state.
Of course you don't use nested functions in C++ -- it does not
support them. That's a _handicap_ of C++, by the way. Being
able to keep a function exactly where it should be (including
nesting inside another function) is a Python advantage, and such
extra power does not come from increasing complication -- the
very opposite: it comes from increasing SIMPLICITY by dropping
arbitrary limitations that C++ chooses to impose on you.
If you don't use templates in C++, that's your loss -- they're
(semantically, not syntactically -- C++'s syntax is a mess
anyway) among C++'s best features. And I do *NOT* believe you
do not use any casts in your C++ code, _particularly_ if you
make no use of templates. The point is, in Python you get
signature-based polymorphism for free (unless you choose to
handicap yourself by doing typetesting...), with all of the
advantages and none of the hassles it has in C++.
> complexity, and I'm doing solo development. Maybe it's fairer to say that
> Python yields more advantages in a cooperative environment. Whereas if
I would accept, as a working hypothesis, that Python has even
more advantage for larger projects, requiring cooperation of
various people, than for solo ones (but I have no numbers to
support or test that working hypotesis: productivity of a
group depends on so many factors, including many that are not
strictly technical, that studying the effects on it of a single
technology choice becomes very hard indeed). But even "just"
the factor-of-two advantage you can count on as a minimum is
still nothing to sneer at; any FURTHER productivity increase
when a project grows to "group" scale should then be seen as
just further inducements.
Alex
Alex Martelli
...
> want
> to interact with *people*. Yet here are all these boobs staring at these
> screens. I can do that sort of antisocial thing at home, much more
Internet cafes (and other places supplying internet access, such
as libraries, games venues, &c, depending on local mores) are lifesavers
when you're traveling, and are staying at a hotel that doesn't make
internet access available to guests; I travel enough that this is
very important to me. When I'm in my home town, such internet
access CAN sometimes be useful in an emergency (when the phone
and cable companies, or the electricity one, manage to mess things
up for a day or two in my neighbourhood, I can go to such a downtown
cafe or the like for emergency net connectivity).
Alex
John Ochiltree
Alex Martelli wrote:
Alex
This is the most wonderfully off topic post I've come across. You are a
genius to get from a debate about C++ & Python to a debate on value. I
salute you.
BTW I think Marx deals with the topic with far greater clarity than Ricardo
or Smith, though Smith's Law of the Cartel is not to be sniffed at.
Maestro
John
Jack Diederich
<snipped elaboration of the same>
> Alex
> This is the most wonderfully off topic post I've come across. You are a
> genius to get from a debate about C++ & Python to a debate on value. I
> salute you.
>
> BTW I think Marx deals with the topic with far greater clarity than Ricardo
> or Smith, though Smith's Law of the Cartel is not to be sniffed at.
re: value and welath
I largely agree. There is a difference between intrinsic value (above 'value')
and commercial value (above 'wealth'). This difference varries from person
to person, if a person 'values' a BigMac at $100 then they must cackle every
time they pay $2 for one at McDonalds. It would be too expensive for McDonalds
to figure out how much each guy in line would pay for a burger, so by trial
and error they found they make the most money by asking $2 for it.
Some people 'value' it at $100 and gleefully pay $2.
Some people 'value' it at $1 and just don't buy it at all.
Marx's labour theory of value tried to set an absolute scientific standard
[Marx considered himself a scientist] by stating that something was worth
excatly the amount of _human_ labor put into it. He hedged this a bit
by saying the most efficient amount of human labor, so you couldn't spend
a year making a loaf of bread and say it was worth a year's wages.
One wonders how you 'value' a painting with this system.
Marx's labour theory of value was complete and utter crap, which _NO ONE_,
not even modern day Marxists believe strictly [teenagers and undergrads don't
count in 'no one']. Poke around the web if you want to find how people have
tried to update it to keep it alive.
(People do still believe other things Marx wrote with only minor alterations)
There are two ways to deal with the disparity between commercial value and
intrinsic value. One, let some people get a deal (the $100 big mac guy)
and let others (the $1 guy) forgoe the big mac. We call this Capitalism.
The other is for a governing body to set the commercial value to what they
determine the instric value is. We call this Socialism, Marx's recomendation
to the government for determining the intrinsic value is stated above.
Both have big problems when it comes to government. Governments are always
gamed by some people for their own benefit. For Socialism this is striaght
forward, the government determines the intrinsic value so just get them to
make a favorable determination for you. Or if you are in the government
sell a favorable determination. For Capitalsim, the government doesn't set
prices directly so you need to game the government differently. This leads
to ...
re: cornering the market
Hayek wrote really good stuff about artificial scarcity. In a nutshell the
only way to permenantly (where permenant just means a long time) make something
scarce is to regulate it via government. Usually a law will be passed for
consumer safety or because of a 'market failure' ('market failure' just means
a politician thinks he could have done things better) and a profession will
be regulated. After a few years the members of a profession end up completely
controlling the government regulating body and make their members happy by
making the profession artificially scarce.
Trucking, Doctors, Teachers, Lawyers, and Copyright are all good examples of this.
[speaking for the US, your country may vary]
Short of government intervention where they threaten to put people in jail
for violating the cartel, it is very hard to keep up artificial scarcity
for any long period of time. The diamond cartel is arguably the exception,
but they have so many governments in their pocket it gets fuzzy. They also
bought up or paid off _every single diamond mine in the world_ which is
something not many industries can do. They're due for a fall soon, if
someone put together a few million in consumer education money to run some
ads DaBeers would be screwed. If you plan on doing this please let me know
so I can buy stock in Emeralds & Rubies.
-jackdied
ps, just google for any of the above topics. Opinions and flamewars on all
this stuff abounds on the web.
Michele Simionato
> <snip>
> So, how much time do you have to put into Python before you've mastered
> *every* aspect of the language? I do mean "every." Less than a year? 6
> months? 3 months? Be honest.
Being honest, I would say that one cannot *never* claim having
mastered
*every* aspect of Python (or any other serious programming language).
I think that Guido himself would not claim he masters *every* aspect
of
Python.
Having said that, I think what *really* matters is the time needed to
have a
working knowledge of the language, i.e. to be able to have your job
done.
I would say the time needed to have a working knowledge of Python is
is *much* smaller than the corresponding time for C++. Much, much
smaller.
How much smaller depends on the person and on the job you have to do,
but I think a *very* conservative estimate is at least half the time.
Also, I would not be surprised to hear somebody claiming he can learn
Python
five-six times faster than C++.
I would be curious to hear from others about their experience in
learning times for the two languages.
Best regards,
Michele