Tcl vs. Python for Scripting C Statistical Library
John Barnard
I'm currently trying to choose between Tcl and Python for scripting a
library/program of statistical functions that are written in C. An
interface language/environment, which is written completely in C but
utilizes some UNIX libraries (e.g., curses and termcap), already
exists on SunOS. However, I would like a scripting interface that is
more portable (to Win 95/NT and MacOS), easily allows a GUI and
plotting, interfaces easily with C, C++, and Java, and is well
documented. Both Tcl and Python meet the majority of my desires. I'm
leaning towards Tcl but have noticed that most scripting interfaces to
numerical/scientific functions/applications are written in Python. Is
this mainly because Python's syntax is more familiar to those who
program numerical routines (e.g., Python's supports 2-way and higher
arrays while Tcl does not). Has anyone written a Tcl interface to a
numerically oriented library/application?
Although I haven't done any programming in Python and very little in
Tcl, I have done a fair amount of research on the strengths and
weaknesses of the two languages (read Brent Welch's book on TCL and
"Tcl/Tk Tools", explored the major TCL web sites and Python web
sites). However, I haven't seen any direct comparisons between the
latest Tcl (8.0 or 8.1) and the latest Python (1.5) for scripting
numerical applications. Does anyone have any general thoughts? In
addition, it would be helpful in making my scripting language choice
if I could get feedback on the following topics:
(1) Speed of Tcl vs Python. In particular, speed comparisons for loops.
(2) Matrix syntax in Tcl and linking to matrix/vector-like C
structures -- Python seems to have a big advantage here over Tcl
-- e.g., I would like to be able to use A[1:5][2:3] type notation
to subset a matrix and A * B notation for matrix multiplication
(3) 2-D graph generation -- interfacing to gnuplot and/or using BLT.
(4) Using Tcl as a parser -- my guess is that numerical users would
prefer a more C-like interface language. Is is easy/efficient to
write a parser for such a language in Tcl?
(5) Calling Java from Tcl or Python.
Thanks for any assistance,
John Barnard
Assistant Professor
Department of Statistics
Harvard University
Phone: (617) 495-1603
Fax: (617) 496-8057
Email: bar...@stat.harvard.edu
Steven D. Majewski
Tcl is a simpler, minimal language.
If most of your app is written in C and you just need to wrap a
programming language around it, then Tcl provides the bare
necessities: parsing, assignment/binding of variables, control
structues. You'll probably find Tcl simpler and easier to understand
and embed and interface to your C modules. Also: if you want to
invent your own syntax, Tcl imposes fewer constraints.
If you want to write a large part of the application in the target
language, then Python provides more for you to use -- it's a more
"full featured" programming language. If fact, with the numerical
extensions, you may not even have to write any C code at all.
Tools like SWIG <http://www.swig.org/> even out some of the job of
interfacing to native libraries.
Both Tcl and Python have early versions of rewrites in Java
( JACL and JPython ) as well as experiments in combining a JVM
with the original C implementations. ( But if you want to add
your C libraries to the Java VM, then be warned that dealing with
Native Code from Java the "standard" way is more complicated than
either Python or Tcl. ( There is a Java module for SWIG, but I
haven't used it and I don't know how functional it is at the present. )
[ See the www.python.org & sunscript.sun.com web sites for more info.]
If you're doing statistics, you might also take a look at XlispStat
<http://www.stat.umn.edu/~luke/xls/xlsinfo/xlsinfo.html> - a
statistics package written in a Lisp implementation enhanced with
graphics, vector arithmatic, and some matrix and statistical functions
in the native code library.
The latest version has a new shared library system and a SWIG-like
automated wrapper writer
http://www.stat.umn.edu/~luke/xls/projects/wrappers/wrappers.html
[ Example: the following wrapper definition:
(wrap:c-lines "extern double fred;"
"int cfrog (int, int);")
(wrap:c-variable "fred" :flonum (:get get-fred) (:set set-fred))
(wrap:c-function frog "cfrog" (:integer :integer) :integer)
will, when run thru make-wrappers, produce a C source file with
all of the glue code to provide a lisp callable interface to
set/get the global value 'fred' and to call the function cfrog. ]
The interactive statistical graphics in XlispStat are more
mature and higher level than what's available for Python or Tcl,
however, the disadvantage is that higher-level graphics aren't
accessable at lower levels, and if you want to do something it
wasn't designed to do, it is difficult. ( However, what it was
designed to do, it does very well: you can generate 3-d spinning
plots, link data points in several plots ( so if you select the
outlier points in one graph, you can see those points selected
in other graphs. ). But, for example, if you want to put a GIF
image in the background behind your data plots, you have to do
some magic beneath the high-level graphics level. )
---| Steven D. Majewski (804-982-0831) <sd...@Virginia.EDU> |---
---| Department of Molecular Physiology and Biological Physics |---
---| University of Virginia Health Sciences Center |---
---| P.O. Box 10011 Charlottesville, VA 22906-0011 |---
All power corrupts and obsolete power corrupts obsoletely." - Ted Nelson
Douglas Ridgway
John Barnard (bar...@hustat.harvard.edu) wrote:
: I'm currently trying to choose between Tcl and Python for scripting a
: library/program of statistical functions that are written in C.
: Has anyone written a Tcl interface to a
: numerically oriented library/application?
I use Tcl for interface and scripting of my numerical applications.
I write a simulation as a Tcl extension, so essentially all calculations
are done in C. Tcl scripts are used to run parameter sets, and do
plotting or light data analysis (eg, straight line fit).
: (1) Speed of Tcl vs Python. In particular, speed comparisons for loops.
Don't know. The expensive parts of my work happen in C.
: (2) Matrix syntax in Tcl and linking to matrix/vector-like C
: structures -- Python seems to have a big advantage here over Tcl
: -- e.g., I would like to be able to use A[1:5][2:3] type notation
: to subset a matrix and A * B notation for matrix multiplication
I don't link data back and forth: a simulation is a command which has
various parameters, and produces a result. I tend to use lists or
lists of lists for multidimensional data, and defined a multidimensional
lindex command to ease access.
I believe it's also possible to extend eg Matlab, so that one can have
one's C code integrated with native Matlab commands. This way you
use an ``extension language'' which is already specialized for your
domain. (Octave is a Matlab clone, I don't know about how easily it
can be extended.) I dislike proprietary systems, however.
There is also a matrix extension to Tcl, but I haven't tried it.
: (3) 2-D graph generation -- interfacing to gnuplot and/or using BLT.
I had my own peculiar ideas about how this should be done, so I wrote my
own. (Eg, I wanted log-log plots to be simply a special case of an
arbitrary transformation, so I could do plots with hyperbolically spaced
ticks as well.) It's pure Tcl/Tk. I should really clean it up and release
it, but I haven't found the time. There's also a package called emu_graph.
: (4) Using Tcl as a parser -- my guess is that numerical users would
: prefer a more C-like interface language. Is is easy/efficient to
: write a parser for such a language in Tcl?
I'm a numerical user, and find Tcl to be ok. But I don't do much computing
in Tcl itself, mostly in extensions. Tcl is for interactive work, scripting,
and UI.
: (5) Calling Java from Tcl or Python.
Never tried it.
doug.
Cameron Laird
In article <ydxvhtr...@hustat.harvard.edu>,
John Barnard <bar...@hustat.harvard.edu> wrote:
.
.
.
>documented. Both Tcl and Python meet the majority of my desires. I'm
>leaning towards Tcl but have noticed that most scripting interfaces to
>numerical/scientific functions/applications are written in Python. Is
>this mainly because Python's syntax is more familiar to those who
>program numerical routines (e.g., Python's supports 2-way and higher
Maybe. Yes. It's not certain. That
is, I can confirm that scientists and
other-than-software engineers are more
likely to feel comfortable with Python,
in which they can write
variance = sum_of_squares - n * average * average
By the way, it *is* part of Tcl to
command
set result($i, $j) [expr $scale * $normalize($i, $j)]
for example. Is that what you mean by
"2-way and higher arrays"?
>numerically oriented library/application?
>
>Although I haven't done any programming in Python and very little in
>Tcl, I have done a fair amount of research on the strengths and
>weaknesses of the two languages (read Brent Welch's book on TCL and
>"Tcl/Tk Tools", explored the major TCL web sites and Python web
>sites). However, I haven't seen any direct comparisons between the
For more on the two languages, perhaps <URL:
http://starbase.neosoft.com/~claird/comp.lang.misc/portable_scripting.html>
will interest you.
>latest Tcl (8.0 or 8.1) and the latest Python (1.5) for scripting
>numerical applications. Does anyone have any general thoughts? In
General thoughts: you're going to be
sooooo happy you're doing this. Script-
ing the interfaces to scientific
applications of this kind are an enormous
win. Before you go any farther in your
decisions, by the way, please look into
SWIG <URL:
http://www.cs.utah.edu/~beazley/SWIG>.
>addition, it would be helpful in making my scripting language choice
>if I could get feedback on the following topics:
>
>(1) Speed of Tcl vs Python. In particular, speed comparisons for loops.
Python's faster--with few exceptions.
This is secondary, though. The biggest
consequence of the scripting you're do-
ing will be that users' productivity will
explode. The computational speed of
looping in Tcl vs. Python might be incon-
sequential.
>(2) Matrix syntax in Tcl and linking to matrix/vector-like C
> structures -- Python seems to have a big advantage here over Tcl
> -- e.g., I would like to be able to use A[1:5][2:3] type notation
> to subset a matrix and A * B notation for matrix multiplication
Tcl advocates say at this point, "No
problem; it's easy to extend the expr
command, for example, to accomodate
those kinds of notations." Python
people then reply, "It's already
built in to Python--you can get
straight to work, instead of extending
expr."
>(3) 2-D graph generation -- interfacing to gnuplot and/or using BLT.
>(4) Using Tcl as a parser -- my guess is that numerical users would
> prefer a more C-like interface language. Is is easy/efficient to
> write a parser for such a language in Tcl?
Tcl's great for parsers. I much prefer
it, for example, to lex-yacc.
Sometimes Tcl charms numerical users,
and they take to Tcl itself as the
interface language it was written to
be. Sometimes they get caught up in
resentment at the '$' in $variable, and
just stay unhappy.
Such users are typically comfortable
with Python from the start.
>(5) Calling Java from Tcl or Python.
Both Tcl and Python are good, and
rapidly getting better. I have a very
rough impression that JPython is a bit
ahead on platform-independence, for
example, while the Tcl Blend crew seems
to have more resources to respond to
particular faults.
.
.
.
Will you be reporting back to the
group(s) your experiences?
--
Cameron Laird http://starbase.neosoft.com/~claird/home.html
cla...@NeoSoft.com +1 713 996 8546 FAX
Robin Friedrich
John please have mercy on your future user community and choose Python.
They will be exerting as much or more effort on your system as you will and
it is only far to consider their productivity. Cameron's example:
variance = sum_of_squares - n * average * average
vs.
set result($i, $j) [expr $scale * $normalize($i, $j)]
is blatant evidence. Your average user of this statistical package will
thank you for the former and curse you for the later. It would be one
thing if you were doing this for a folks already indoctrinated into the tcl
mystique, but I don't think that's the case here.
I know I'm being harsh but tcl has been really getting on my nerves lately
as people promote it as the ultimate scripting language. I know this will
probably start another flame war but please resist. :-{0
Cameron Laird
In article <X7MUZDAF...@jessikat.demon.co.uk>,
Robin Becker <ro...@jessikat.demon.co.uk> wrote:
.
.
.
>>it is only far to consider their productivity. Cameron's example:
>>
>> variance = sum_of_squares - n * average * average
>wrong it's not good numerically.
.
.
.
I apologize for inspiring your curse. Let
me partially undo my damage, and note that
I should have written either
sample_variance = (sum_of_squares / n) - average * average
or
second_central_moment = sum_of_squares - n * average * average
or ... Mr. Becker is, of course, correct
in asserting that, in general, these formu-
lations do not specify optimal computational
schemes.
James Logajan
Robin Friedrich (Robin.F...@pdq.net) wrote:
: I know I'm being harsh but tcl has been really getting on my nerves lately
: as people promote it as the ultimate scripting language. I know this will
: probably start another flame war but please resist. :-{0
Well, it may be a bit inflammatory to cross-post these language comparisons,
fact and opinions not withstanding. Better to reply via e-mail methinks.
Or maybe not...
If someone is expert at tcl, they should program in tcl and should not have
to suffer the insult implied by these language comparisons. On the other
hand, if the potential for scripting language expertise is lying dormant
within oneself and needs to find expression, then I strongly advise that
one seek out and learn Python, and not waste time on tcl, Perl, or even
Java. One may, after a while, seek out and study these other languages
as one might study Latin or ancient Greek, but only after one has mastered
the most modern and productive tool.
P.S. I am not one who believes computer languages are subjective. I believe
that there exists an objective and measurable superiority of one computer
language over another in the same way that doing math with Arabic numerials
is measurably superior to doing math with Roman numerals.
Copyleft IIMM (or is it MCMIIC ?? Darn, can't remember the rules!)
Robin Becker
In article <3501DC3F...@pdq.net>, Robin Friedrich
<Robin.F...@pdq.net> writes
>John please have mercy on your future user community and choose Python.
>They will be exerting as much or more effort on your system as you will and
>
> variance = sum_of_squares - n * average * average
I would curse anybody who proposed this formula :) apart from being
wrong it's not good numerically.
Seriously there are good and bad ways to do numerics; the correct way to
calculate variance has been the subject of much discussion and probably
the best way computes variance in a single pass using the recursive
definition.
I use Tcl and have been trying to use Python. I hate and love things
about both. My principle beef with python is the use of invisible
structuring ie white space counts. Would it really have made that much
difference to the language to have a statement terminator? An occasional
missed ';' might bemuse some users, but a tab instead of a space causes
me real pain. On the other hand Tcl's syntax is absolutely gothic, but
it has Tk and is very easy to get into on the extension front.
These are just programming languages not religions.
>
>vs.
>
> set result($i, $j) [expr $scale * $normalize($i, $j)]
>
>is blatant evidence. Your average user of this statistical package will
>thank you for the former and curse you for the later. It would be one
>thing if you were doing this for a folks already indoctrinated into the tcl
>mystique, but I don't think that's the case here.
>
>I know I'm being harsh but tcl has been really getting on my nerves lately
>as people promote it as the ultimate scripting language. I know this will
>probably start another flame war but please resist. :-{0
>
>
I would curse anybody who proposed
--
Robin Becker
Andrew Kuchling
James Logajan writes:
>P.S. I am not one who believes computer languages are subjective. I believe
>that there exists an objective and measurable superiority of one computer
>language over another in the same way that doing math with Arabic numerials
>is measurably superior to doing math with Roman numerals.
And I'd violently disagree with that; in computing there are
far too many claims of objective superiority that are just
rationalizations for the claimant's preferences. It's fine if you
just happen to prefer Python's syntax, or Perl's syntax, or Lispish
syntax, but attempts to prove one syntax *objectively* better are
invariably bogus.
A.M. Kuchling http://starship.skyport.net/crew/amk/
"There is no disputing about tastes," says the old saw. In my experience there
is little else.
-- Robertson Davies, _Marchbanks' Almanac_ (1967)
Cameron Laird
In article <1998030803...@newcnri.CNRI.Reston.Va.US>,
Andrew Kuchling <akuc...@CNRI.Reston.Va.US> wrote:
>James Logajan writes:
>>P.S. I am not one who believes computer languages are subjective. I believe
>>that there exists an objective and measurable superiority of one computer
>>language over another in the same way that doing math with Arabic numerials
>>is measurably superior to doing math with Roman numerals.
>
> And I'd violently disagree with that; in computing there are
>far too many claims of objective superiority that are just
>rationalizations for the claimant's preferences. It's fine if you
>just happen to prefer Python's syntax, or Perl's syntax, or Lispish
>syntax, but attempts to prove one syntax *objectively* better are
>invariably bogus.
.
.
I take it, Andrew, that
[A]ttempts to prove one syntax *objectively*
better are invariably bogus
is a claim you assert to have a, well, objective status.
Am I reading that correctly?
Bemusedly,
Paul Prescod
Robin Becker wrote:
>
> An occasional
> missed ';' might bemuse some users, but a tab instead of a space causes
> me real pain.
For whatever reason, I never have that problem. How is your editor set
up? If it displays a tab as 8 spaces, then a tab instead of space should
do exactly what it "looks like" it would do.
> On the other hand Tcl's syntax is absolutely gothic, but
> it has Tk and is very easy to get into on the extension front.
Python has TK also. I also found Python easy to get into on the
extension front. My concern about TCL on that front was it seemed like
you had to implement a mini-parser to implement any kind of hierarchial
data structure. Was I wrong on that point?
Paul Prescod - http://itrc.uwaterloo.ca/~papresco
"Scarcely a discussion goes on, between linguistic groups or regions or
even within cities and towns, which is not a struggle between competing
myths of victimization."
- John Ralston Saul, "Reflections on a Siamese Twin"
Donal K. Fellows
In article <jameslE...@netcom.com>, James Logajan
<jam...@netcom.com> writes
>Copyleft IIMM (or is it MCMIIC ?? Darn, can't remember the rules!)
I think that MCMXCVIII is correct (though it does depend on the period,
as the rules themselves have changed over time. At one point something
more like MDCCCCLXXXXVIII would have been the case, assuming that the
higher order letters were in use at that point. The rules are complex,
nay, arcane.) The use of a double I prefix is certainly wrong, and even
if it was correct, IIMM would instead be MIIM. But it isn't.
Donal.
--
Donal K. Fellows (at work) Email: fell...@cs.man.ac.uk Tel: +441612756137
(at home) Email: do...@ugglan.demon.co.uk Tel: +441274401017
"Where do you want to hug a software engineer today?"
Donal K. Fellows
>>as people promote it as the ultimate scripting language. I know this will
>>probably start another flame war but please resist. :-{0
>
>I would curse anybody who proposed
I am reminded of the Curse of Dogbert... :^)
Lyn A Headley
>>>>> "Robin" == Robin Becker <ro...@jessikat.demon.co.uk> writes:
Robin> I use Tcl and have been trying to use Python. I hate and
Robin> love things about both. My principle beef with python is
Robin> the use of invisible structuring ie white space
Robin> counts. Would it really have made that much difference to
Robin> the language to have a statement terminator? An occasional
I don't think this makes sense. The issue of white-space
"structuring" is one of statement *grouping*, not statement
termination. If python's statement terminator were ';' instead of
newline, that wouldn't change anything about its use of indentation.
It would just make blocks look like this:
if foo:
foo1();
foo2();
foo3();
instead of
if foo:
foo1()
foo2()
foo3()
--
Lyn Headley
remove the word "bogus" from my address for the real one.
Andrew Dalke
In article <jameslE...@netcom.com>, James Logajan
<jam...@netcom.com> writes
>Copyleft IIMM (or is it MCMIIC ?? Darn, can't remember the rules!)
Donal K. Fellows <do...@ugglan.demon.co.uk> offered
> I think that MCMXCVIII is correct
I want to offer my own, non-newsgroup related opionion about something
I am not certain about! How ... USENET! :)
I think 1998 is written MXMCII. I've been looking for a movie ad with
a copyright date on it (since they are usually in roman numerals) but
haven't had luck. (Of course, nothing's to say they're right either.)
Andrew
da...@mag.com
Konrad Hinsen
da...@ks.uiuc.edu (Andrew Dalke) writes:
> Donal K. Fellows <do...@ugglan.demon.co.uk> offered
> > I think that MCMXCVIII is correct
>
> I want to offer my own, non-newsgroup related opionion about something
> I am not certain about! How ... USENET! :)
>
> I think 1998 is written MXMCII. I've been looking for a movie ad with
> a copyright date on it (since they are usually in roman numerals) but
> haven't had luck. (Of course, nothing's to say they're right either.)
Aren't movie ads wrong by definition? ;-)
As Donal pointed out, the rules changed over time, so there is not one
definite answer. But some constructions are definitely impossible. For
example, only one letter can be subtracted by writing it to the left
of a larger one - so something like MIIM or IIMM is not possible.
Moreover, the two neighbours in a subtraction differ at most by a factor
of 10, which is why 99 is not written as IC but as XCIX. Therefore
I agree with Donal that 1998 should be written as MCMXCVIII.
If these rules seem arbitrary, consider that originally only addition
was used. The subtraction rule was introduced as a shorthand and was
applied in such a way that it could cause only local changes.
Back to Python: is there a "roman numerals" module anywhere?
--
-------------------------------------------------------------------------------
Konrad Hinsen | E-Mail: hin...@ibs.ibs.fr
Laboratoire de Dynamique Moleculaire | Tel.: +33-4.76.88.99.28
Institut de Biologie Structurale | Fax: +33-4.76.88.54.94
41, av. des Martyrs | Deutsch/Esperanto/English/
38027 Grenoble Cedex 1, France | Nederlands/Francais
-------------------------------------------------------------------------------
Fredrik Lundh
Here's one (which seems to agree with your definition, btw).
>>> print roman.roman(1998)
MCMXCVIII
M.-A. Lemburg
Fredrik Lundh wrote:
>
> >Back to Python: is there a "roman numerals" module anywhere?
>
> Here's one (which seems to agree with your definition, btw).
> ---------------------------------------------------------------
>
> Name: roman.py
> Part 1.2 Type: unspecified type (application/octet-stream)
> Encoding: 7bit
Wow, that's just about the slickest algorithm I've ever seen for
converting integers to roman numerals !
Just one thing: posting it as octet-stream makes this a
little difficult to see...
--
Marc-Andre Lemburg
James Bailie
da...@ks.uiuc.edu (Andrew Dalke) wrote:
> I think 1998 is written MXMCII. I've been looking for a movie ad with
1998 = MXMXCVIII
James Bailie
-------------
http://www.wwdc.com/~jbailie
Robin Becker
In article <wr3k9a4...@harper.uchicago.edu>, Lyn A Headley
<lahe...@boguscs.uchicago.edu> writes
if foo:
foo1();
foo2();
foo3();
--
Robin Becker
Nick Seidenman
On 9 Mar 1998, James Bailie wrote:
> da...@ks.uiuc.edu (Andrew Dalke) wrote:
>
> > I think 1998 is written MXMCII. I've been looking for a movie ad with
>
> 1998 = MXMXCVIII
Don't think so.
M -> one thousand
CM -> 900 (one hundred shy of one thousand)
XC -> 90 (ten shy of one hundred)
VIII 8 (5 + 3)
MCMXCVIII
The Romans had no (or at least a very context-bound) concept of
place-value. When doing that "shy of" trick, you are allowed the
following: CM (900), CD (400), XC (90), XL (40), IX (9), IV (4)
------------------------------------
Nick Seidenman
http://www.safari.net/~nicks/
Gordon McMillan
Robin Becker said
> > Robin> I use Tcl and have been trying to use Python. I hate and
> > Robin> love things about both. My principle beef with python is
> > Robin> the use of invisible structuring ie white space
> > Robin> counts. Would it really have made that much difference to
> > Robin> the language to have a statement terminator? An occasional
> >
[and in reply to a snipped response, said]
> This would be my version
> if foo:
> foo1();
> foo2();
> foo3();
> fi
I vaguely recall that I found this "strange" at first, but now I
can't recall why.
Look at the options to indent. How many have to do with the indenting
of the actual code? (very few). How many have to do with the
placement of the block delimiting characters? (scads - most of them
wrong <grin> ).
But for whatever reason, about half the people I've tried to
introduce to Python have said "no block delimiters? No way...".
Maybe Python needs a ".bpy" (block delimited) source file type, which
gets on-the-fly translated to ".py" before being compiled. I'd never
use it, but it might widen the audience. ('Course then we'd need
another newsgroup just for arguing about the proper aesthetics for
block delimiting...)
- Gordon
Craig Dickson
Lyn A Headley <lahe...@boguscs.uchicago.edu> wrote:
>>>>>> "Robin" == Robin Becker <ro...@jessikat.demon.co.uk> writes:
>
> Robin> I use Tcl and have been trying to use Python. I hate and
> Robin> love things about both. My principle beef with python is
> Robin> the use of invisible structuring ie white space
> Robin> counts. Would it really have made that much difference to
> Robin> the language to have a statement terminator? An occasional
>
>I don't think this makes sense. The issue of white-space
>"structuring" is one of statement *grouping*, not statement
>termination.
Not entirely, because an unescaped newline does terminate a statement.
After getting over the initial shock of seeing a modern language that cares
about whitespace, I found that I actually like Python's use of it. C
programmers can spend years arguing over where the curly-braces should go,
and C code written without indentation is a pain to read. (More generally,
improperly indented C can confuse someone trying to read it.) Python neatly
side-steps these issues by making indentation part of the syntax.
But the lack of a statement terminator annoys me, because I find it very
error-prone (and visually ugly) to have to escape newlines in the middle of
a complex expression that doesn't comfortably fit on a single line:
if this_function(argument) < 0 or that_function(argument) < 0 or \
some_variable < some_other_variable:
Same goes for complicated function invocations, etc. I would prefer that
the language recognized some non-whitespace-based way of terminating
statements (e.g. a semicolon). Whitespace could still be used to determine
code structure by looking only at the leading whitespace of a statement's
first line. In the case of the "if" statement, it's pretty trivial, since
the test condition has to end with a colon.
So to my way of thinking, the following should be valid Python code:
this_variable = 0
if this_function() < 0 or
that_function() < 0:
for i in
range(11):
this_variable = this_variable
+ i;
which would be equivalent to:
this_variable = 0
if this_function < 0 or that_function < 0:
for i in range(11):
this_variable = this_variable + i
However, I am not in favor of having to explicitly close statement blocks,
such as by an "endif" or "fi". Indentation does that job quite nicely.
Craig
Fredrik Lundh
> But for whatever reason, about half the people I've tried to
> introduce to Python have said "no block delimiters? No way...".
(Strangely enough, hardly any of the (mostly professional, mostly
multilingual) programmers I've introduced Python to has even
commented on that. And if someone still complains about the
lack of block delimiters after a few days with Python and a Python-
aware editor, there's probably something else that's wrong with
them...)
> Maybe Python needs a ".bpy" (block delimited) source file type, which
> gets on-the-fly translated to ".py" before being compiled. I'd never
> use it, but it might widen the audience.
In fact, Python already supports block delimiters:
if foo: #{
foo1();
foo2();
foo3();
#}
Inspired by Larry Wall, Guido also made sure that the ending delimiter
could be written in various other ways, such as #end if. Anything to
empower the newbies, you know. But real Python programmers tend
to omit both semicolons and curly braces, of course. And don't expect
to get any help from me if you use them; I'm filtering away all messages
containing such code (also inspired by the Perlers...)
For more info on this, see the Tools/scripts/pindent.py script included
in the source distribution.
Fredrik Lundh
I wrote:
>In fact, Python already supports block delimiters:
Make that "visible block delimiters". Here's the grammar
for a block of statements:
simple_stmt | NEWLINE INDENT stmt+ DEDENT
Obviously, DEDENT and INDENT are block delimiters; it's just
that some people seem to have problems seeing them...
Cheers /F
Fredrik Lundh
> if this_function(argument) < 0 or that_function(argument) < 0 or \
> some_variable < some_other_variable:
You can use parenthesis instead:
if (this_function(argument) < 0 or that_function(argument) < 0 or
some_variable < some_other_variable):
Also works for function calls:
result = this_function(
first_argument,
second_argument,
that_function(third_argument),
12
)
Cheers /F
Donald Beaudry
c...@shell3.ba.best.com (Craig Dickson) wrote,
> But the lack of a statement terminator annoys me, because I find it very
> error-prone (and visually ugly) to have to escape newlines in the middle of
> a complex expression that doesn't comfortably fit on a single line:
>
> some_variable < some_other_variable:
Try this instead:
if (this_function(argument) < 0 or that_function(argument) < 0 or
some_variable < some_other_variable):
As long as you have an open paren (or paren like thing), you no longer
need to escape the newline. Often this just happens naturally, but when
it doesnt, I simply add an extra set of parens.
--
Donald Beaudry Silicon Graphics
Debuggers/SSO 1 Cabot Road
do...@sgi.com Hudson, MA 01749
...So much code, so little time...
Robin Becker
In message <1998030919...@pb.twinoaks.net>, Gordon McMillan
<gm...@hypernet.com> writes
>Robin Becker said
>
>> > Robin> I use Tcl and have been trying to use Python. I hate and
>> > Robin> love things about both. My principle beef with python is
>> > Robin> the use of invisible structuring ie white space
>> > Robin> counts. Would it really have made that much difference to
>> > Robin> the language to have a statement terminator? An occasional
>> >
>> This would be my version
>> if foo:
>> foo1();
>> foo2();
>> foo3();
>> fi
>
>I vaguely recall that I found this "strange" at first, but now I
>can't recall why.
>
>Look at the options to indent. How many have to do with the indenting
>of the actual code? (very few). How many have to do with the
>placement of the block delimiting characters? (scads - most of them
>wrong <grin> ).
>
>introduce to Python have said "no block delimiters? No way...".
>
>gets on-the-fly translated to ".py" before being compiled. I'd never
>another newsgroup just for arguing about the proper aesthetics for
>block delimiting...)
>
>- Gordon
--
Robin Becker
Craig Dickson
Donald Beaudry <do...@sgi.com> wrote:
>c...@shell3.ba.best.com (Craig Dickson) wrote,
>> But the lack of a statement terminator annoys me, because I find it very
>> error-prone (and visually ugly) to have to escape newlines in the middle of
>> a complex expression that doesn't comfortably fit on a single line:
>>
>> if this_function(argument) < 0 or that_function(argument) < 0 or \
>> some_variable < some_other_variable:
>
>Try this instead:
>
> if (this_function(argument) < 0 or that_function(argument) < 0 or
> some_variable < some_other_variable):
>
>As long as you have an open paren (or paren like thing), you no longer
>need to escape the newline. Often this just happens naturally, but when
>it doesnt, I simply add an extra set of parens.
That works for an if statement, but not for some others. For instance:
for (i in
range(11)):
generates an error, whereas
for i in \
range(11):
works.
Craig
Roman Milner
>>>>> "FL" == Fredrik Lundh <fre...@pythonware.com> writes:
FL> [1 <text/plain; iso-8859-1 (7bit)>]
>> Back to Python: is there a "roman numerals" module anywhere?
FL> Here's one (which seems to agree with your definition, btw).
>>>> print roman.roman(1998)
FL> MCMXCVIII
Cool. Is there anyway I can override roman.salary?
^Roman
--
How come the dove gets to be the peace symbol? How about the pillow? It
has more feathers than the dove, and it doesn't have that dangerous
beak.
--- Deep Thoughts by Jack Handey
--------------
Roman Milner ro...@austin.ibm.com
jer...@cnri.reston.va.us
It may be useful to look the proceedings of the Python and Tcl conferences for
more information about these languages. We had a session devoted to
scientific computing at the last Python conference (and also had a paper about
JPython).
Here are URLs:
http://www.python.org/workshops/1997-10/proceedings/
http://www.usenix.org/publications/library/proceedings/
Jeremy
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/ Now offering spam-free web-based newsreading
Garrett G. Hodgson
Gordon McMillan wrote:
> [and in reply to a snipped response, said]
> > This would be my version
> > if foo:
> > foo1();
> > foo2();
> > foo3();
> > fi
>
> I vaguely recall that I found this "strange" at first, but now I
> can't recall why.
when i first heard of it, a year or so before i started using python,
i thought it very odd, as well.
> Look at the options to indent. How many have to do with the indenting
> of the actual code? (very few). How many have to do with the
> placement of the block delimiting characters? (scads - most of them
> wrong <grin> ).
>
> But for whatever reason, about half the people I've tried to
> introduce to Python have said "no block delimiters? No way...".
i wonder if somewhere in the collective unconscious people are
still afraid of the Bad Old Days of fortran (columns 80, 5, and ?).
they seem to assume this is a restriction on coding style.
in some sense, it is, but pretty much everyone indents code
nowadays, and those that don't shouldn't touch computers anyway.
personally, i *really* like the (relative) absence of noise characters
in python code. after the first few decades, one gets awful tired of
semicolons and curly braces and the various other cruft that gets in
the way of the real code.
--
Garry Hodgson sometimes we ride on your horses
Software Innovation Services sometimes we walk alone
AT&T Labs sometimes the songs that we hear
ga...@sage.att.com are just songs of our own
Donal K. Fellows
In article <twvhtoc...@lmspc1.ibs.fr>,
Konrad Hinsen <hin...@ibs.ibs.fr> wrote:
[ Much elided ]
> Therefore I agree with Donal that 1998 should be written as
> MCMXCVIII.
I suddenly remembered where I learnt the rules - in the UK equivalent
of fourth grade. I will admit to having originally only ever known
them in a read-only fashion - it wasn't until 1990 that I realised
that you couldn't do MXM :^)
Donal.
--
Donal K. Fellows http://r8h.cs.man.ac.uk:8000/ fell...@cs.man.ac.uk
Department of Computer Science, University of Manchester, U.K. +44-161-275-6137
--
Never underestimate the power of the penguin...
Dieter Maurer
"Fredrik Lundh" <fre...@pythonware.com> writes:
>
> > But for whatever reason, about half the people I've tried to
> > introduce to Python have said "no block delimiters? No way...".
>
> multilingual) programmers I've introduced Python to has even
> commented on that. And if someone still complains about the
> lack of block delimiters after a few days with Python and a Python-
> aware editor, there's probably something else that's wrong with
> them...)
However, I think Python, too, has some weaknesses:
* the use of whitespace to express structuring
(which makes it very difficult to move code pieces, i.e. for
interactive testing and function development)
* a weak interactive parser, which needs empty lines beside
whitespace to recognize block structuring (which again makes
it difficult to move pieces of code from a script file
for interactive execution and testing).
* the two(three) level name hierarchy
* a minimal, not extensible syntax
For me, the advantages of Python are overwhelming, however:
* support for object oriented programming with (multiple) inheritance
* "mathematical" expressions and assignments
(i.e. "x= 2*a+b" rather than "set x [expr 2 * $a + b]")
* clearer, function like syntax
(in Tcl, I always fought with the level of quoting (i.e.
'"..."' versus '{...}' versus '[list ...]' and once in a while
I was very surprised that in this particular circumstance
and additional '{...}' was necessary)
* Python's module concept easier to use than Tcl's packages
* much more efficient (this may no longer be true;
my comparison was for Python 1.4 versus Tcl 7.5 (where
(almost) everything was a string and handling of lists was
*VERY* inefficient; this has changed with Tcl 8))
* easier to learn
* binary '0' did not pose a problem (this was a problem
for Tcl 7.5 -- it is no longer, however)
- Dieter
Moinak Ghosh
James Logajan wrote:
>
> Robin Friedrich (Robin.F...@pdq.net) wrote:
> : I know I'm being harsh but tcl has been really getting on my nerves
Hi James,
I am Really, Really Rattled by your comments.
On Tcl I do support your view. Pure Tcl does not scale well to
large projects, But Again you can use [incr Tcl] which is an
excellent OOP for Tcl.
But I take a very strong exception to your poorly researched view
against Java. You CANNOT compare Java with Tcl, Perl, Python ..blah..
blah..blah. Java is definitely Not a scripting language. It has
been designed from the ground up to be a full-fledged language
providing all the good features of numerous other langs like
C,C++,Fortran,Pascal...
Scripting tools (tcl,perl,python...) are at a much higher level of
abstraction than proper languages, and are designed for writing
short programs.
Tcl's central idea was to provide a scripting interface to a core
extensible library of C procedures.
Python, as far as I have read is pretty good, but again it depends
on Tk for the GUI !!
But I surely cannot accept your views on Java. Please EDUCATE YOURSELF
before passing such comments.
Sorry for being so harsh.
Moinak...
Cameron Laird
In article <3506FA...@cisco.com>, Moinak Ghosh <moi...@cisco.com> wrote:
>James Logajan wrote:
.
.
.
>But I take a very strong exception to your poorly researched view
>against Java. You CANNOT compare Java with Tcl, Perl, Python ..blah..
>blah..blah. Java is definitely Not a scripting language. It has
>been designed from the ground up to be a full-fledged language
>providing all the good features of numerous other langs like
>C,C++,Fortran,Pascal...
>
>Scripting tools (tcl,perl,python...) are at a much higher level of
>abstraction than proper languages, and are designed for writing
>short programs.
>
>Tcl's central idea was to provide a scripting interface to a core
>extensible library of C procedures.
>
>Python, as far as I have read is pretty good, but again it depends
>on Tk for the GUI !!
>
>But I surely cannot accept your views on Java. Please EDUCATE YOURSELF
>before passing such comments.
.
.
Mr. Logajan is, from all the evidence available
to me, well-educated about Java and even other
subjects.
I will not attempt to persuade you about the
validity of comparing Java and Python. What
might interest you, though, are the first two
entries at <URL:
http://www.python.org/workshops/1997-10/proceedings/>,
which describe realizations of the *complemen-
tarity* of these two languages.
--
Cameron Laird http://starbase.neosoft.com/~claird/home.html
cla...@NeoSoft.com +1 713 996 8546 FAX
Ed Phillips
On Wed, 11 Mar 1998, Moinak Ghosh wrote:
> Date: Wed, 11 Mar 1998 20:57:25 +0000
> From: Moinak Ghosh <moi...@cisco.com>
> To: pytho...@cwi.nl
> Subject: Re: Tcl vs. Python for Scripting C Statistical Library
> Newsgroups: comp.lang.tcl,comp.lang.python
>
> James Logajan wrote:
> >
> > Robin Friedrich (Robin.F...@pdq.net) wrote:
> > : I know I'm being harsh but tcl has been really getting on my nerves
>
> Hi James,
>
> I am Really, Really Rattled by your comments.
>
> On Tcl I do support your view. Pure Tcl does not scale well to
> large projects, But Again you can use [incr Tcl] which is an
> excellent OOP for Tcl.
>
> But I take a very strong exception to your poorly researched view
> against Java. You CANNOT compare Java with Tcl, Perl, Python ..blah..
> blah..blah. Java is definitely Not a scripting language. It has
> been designed from the ground up to be a full-fledged language
> providing all the good features of numerous other langs like
> C,C++,Fortran,Pascal...
>
> Scripting tools (tcl,perl,python...) are at a much higher level of
> abstraction than proper languages, and are designed for writing
> short programs.
I don't know that "proper language" has anything to do with this....
hehehe... Python _is_ a programming language IMHO. What does Java have
that Python doesn't? It's easily extended like Tcl, Perl, etc., which
IMHO doesn't make it a "scripting tool". It has data types, control
structures, variables, a compiler, an interpreter (like Java's VM)... why
is Python _not_ a language? ...... But this is all philosophy - BLAH!
>
> Tcl's central idea was to provide a scripting interface to a core
> extensible library of C procedures.
Tcl, by design, as you say, doesn't even attempt to be a "language". It's
just a simplified interface to a bunch of C routines.
>
> Python, as far as I have read is pretty good, but again it depends on Tk
> for the GUI !!
No it does not. It's just that nobody is willing to do the work that Sun
did to make Tk provide a GUI for both Windows and X Windows (and Mac?). I
personally don't use the Tcl module for Python... because I'm trying to
get away from the limitations of Tcl as far as speed/size goes (and size
of the executable - has anyone looked at the size of python with the
compiled-in _tkinter stuff - ~2MB on Solaris 2.5.1 - GEEEZ!)
>
> But I surely cannot accept your views on Java. Please EDUCATE YOURSELF
> before passing such comments.
Java is a "proper language"... ;-) It's a shame the even Sun can't make a
VM that will work consistently.... ;-)
>
> Sorry for being so harsh.
> Moinak...
>
Another wonderful debate... ;-)
Ed
+----------------------------------------------------------------------+
|Ed Phillips <e...@udel.edu> University of Delaware (302) 831-6082 |
|Systems Programmer II, Network and Systems Services |
|finger -l e...@polycut.nss.udel.edu for PGP public key |
+----------------------------------------------------------------------+
Craig Dickson
Moinak Ghosh <moi...@cisco.com> wrote:
>But I take a very strong exception to your poorly researched view
>against Java. You CANNOT compare Java with Tcl, Perl, Python ..blah..
>blah..blah. Java is definitely Not a scripting language. It has
>been designed from the ground up to be a full-fledged language
>providing all the good features of numerous other langs like
>C,C++,Fortran,Pascal...
To the contrary, I agree with Alexander Stepanov that Java throws out all
the best parts of C++ (templates, for example) and substitutes the overly
strict Smalltalkish rule that "everything is an object whether you like it
or not".
Before telling anyone that Java is a "real" or "full-fledged" language, I
suggest you attempt to write a single implementation of even a simple
function like max(a,b) in such a way that it can be used with any class
whose instances can be sensibly compared using the < operator, regardless
of inheritance. In C this is trivial (using the preprocessor); in C++ it is
trivial (using a global function template); in Python it is trivial. I
don't know how it can be done in Java.
Craig
Mike Pelletier
[Shamelessly chopped quotes:]
Craig Dickson wrote in message <6e6ieb$527$1...@shell3.ba.best.com>...
>Moinak Ghosh <moi...@cisco.com> wrote:
>>You CANNOT compare Java ... Python ...
>>Java is definitely Not a scripting language. It has
>>been designed from the ground up to be a full-fledged language...
>To the contrary...Java throws out all
>the best parts of C++...and substitutes the overly
>strict Smalltalkish rule...
Besides that, I rather thought Python WAS designed from the ground up to
be a full-fledged language. I don't see why they cannot be compared, so
long as you compare them under the same conditions.
Mike.
Steven D. Majewski
On Wed, 11 Mar 1998, Moinak Ghosh wrote:
> Python, as far as I have read is pretty good, but again it depends
> on Tk for the GUI !!
Not true at all!
Most of my Python GUI programming has been with QuickDraw and the
MacOS Toolbox. You can program in Python using Tk, Amulet, X toolkit,
Motif, MFC, AWT, WxWindows ... and more.
Tk is just the current most popular cross platform GUI for Python.
( And maybe by the time the next JFC adds support for the 2d and 3d
graphics APIs to all of the SWING framework, that may become the
most popular option. It will sure beat trying to layer BLT, OpenGL,
and a couple of other kits on top of Tk to get the same functionality. )
For some of the Unix specific options, See Cameron Laird and Kathryn
Soraiz's article in sunworld:
"GUI toolkits: What are your options?
An overview of today's best-bet GUI toolkits"
<http://www.sun.com/sunworldonline/swol-03-1998/swol-03-gui.html>
For Python specific into, look on http://www.python.org/
---| Steven D. Majewski (804-982-0831) <sd...@Virginia.EDU> |---
---| Department of Molecular Physiology and Biological Physics |---
---| University of Virginia Health Sciences Center |---
---| P.O. Box 10011 Charlottesville, VA 22906-0011 |---
All power corrupts and obsolete power corrupts obsoletely." - Ted Nelson
Paul Prescod
To me, Java is Python with static type checking. The distance between
them is really not that far, compared to their shared distance from,
say, C, C++ or TCL. I tend to think that someone who really likes one
and not the other has probably not given the other a good try (or else
they really hate static type checking or the lack thereof). I think a
disproportionate chunk of the Java-haters come from platforms where JVMs
are poorly implemented.
Paul Prescod - http://itrc.uwaterloo.ca/~papresco
Can we afford to feed that army,
while so many children are naked and hungry?
Can we afford to remain passive,
while that soldier-army is growing so massive?
- "Gabby" Barbadian Calpysonian in "Boots"
Steve Bellenot
In article <6e6ieb$527$1...@shell3.ba.best.com>,
Craig Dickson <c...@shell3.ba.best.com> wrote:
>Moinak Ghosh <moi...@cisco.com> wrote:
>
>To the contrary, I agree with Alexander Stepanov that Java throws out all
>the best parts of C++ (templates, for example) and substitutes the overly
>strict Smalltalkish rule that "everything is an object whether you like it
>or not".
>
>Before telling anyone that Java is a "real" or "full-fledged" language, I
>suggest you attempt to write a single implementation of even a simple
>function like max(a,b) in such a way that it can be used with any class
>whose instances can be sensibly compared using the < operator, regardless
>of inheritance. In C this is trivial (using the preprocessor); in C++ it is
>trivial (using a global function template); in Python it is trivial. I
>don't know how it can be done in Java.
>
>Craig
Templates are not that hot. They suffer less than the C #define macro's
but still subject to the header problem. Namely they can be compiled
many different times with different flags, but are often linked only
once. (Which one do you get?)
I also fail to see how writing an operator< for every class is any
better than writing a max function for every class. Operator< can
itself be a `bad choice' either do to speed, or do to the fact that
the underlining class really does not have an order.
But I would agree that neither C/C++/Java are scripting languages.
--
bell...@math.fsu.edu http://www.math.fsu.edu/~bellenot (850)644-7189 (4053fax)
Martin Holz
bell...@math.fsu.edu (Steve Bellenot) writes:
> I also fail to see how writing an operator< for every class is any
> better than writing a max function for every class. Operator< can
> itself be a `bad choice' either do to speed, or do to the fact that
> the underlining class really does not have an order.
The max example might be to simple, but I don't want to rewrite
a sorting algorithm for every class.
Martin
Craig Dickson
Steve Bellenot <bell...@math.fsu.edu> wrote:
>Craig Dickson <c...@shell3.ba.best.com> wrote:
>
>>To the contrary, I agree with Alexander Stepanov that Java throws out all
>>the best parts of C++ (templates, for example) and substitutes the overly
>>strict Smalltalkish rule that "everything is an object whether you like it
>>or not".
>>
>>Before telling anyone that Java is a "real" or "full-fledged" language, I
>>suggest you attempt to write a single implementation of even a simple
>>function like max(a,b) in such a way that it can be used with any class
>>whose instances can be sensibly compared using the < operator, regardless
>>of inheritance. In C this is trivial (using the preprocessor); in C++ it is
>>trivial (using a global function template); in Python it is trivial. I
>>don't know how it can be done in Java.
>
>Templates are not that hot. They suffer less than the C #define macro's
>but still subject to the header problem. Namely they can be compiled
>many different times with different flags, but are often linked only
>once. (Which one do you get?)
Well, I've been bitten in C/C++ by linking with libraries that were
compiled with different flags (structure packing being a particularly nasty
one). So this isn't a problem specific to templates or even to things
contained in headers as such. And I certainly don't claim that C or C++ are
perfect. But assuming you can standardize your compiler flags so that you
don't shoot yourself in the foot that way, templates can be wonderfully
useful.
>I also fail to see how writing an operator< for every class is any
>better than writing a max function for every class.
Well, max() is a very simple example. The point is that if you can't
implement even a simple algorithm in a fully generic way, then you have
no hope at all of doing it for a more complex algorithm that might,
conceptually, be equally general.
>Operator< can
>itself be a `bad choice' either do to speed,
I don't follow you there. Overloaded operators in C++ are no less efficient
than any other virtual function. Or are you getting at something else?
>or do to the fact that
>the underlining class really does not have an order.
In which case you wouldn't want to do max() on it, would you? But that's
why I defined the problem as "in such a way that it can be used with any
class whose instances can be sensibly compared using the < operator" --
if it isn't orderable, that won't be the case.
Craig
Craig Dickson
Paul Prescod <papr...@technologist.com> wrote:
>To me, Java is Python with static type checking.
Well, it depends what you choose to focus on as being the important
characteristics of a language. Java subscribes to the "everything is
an object whether you like it or not" philosophy, which Python does not.
Python is dynamically typed, which Java is not. And so on.
Craig
Steven D. Majewski
You got this backwards.
In Python, everything is an object -- even integers.
( All objects are not implemented as members of Classes though. )
In Java, there are a few primitive types that aren't objects but
are unwrapped values. There are object wrappers for those primitive
objects in case you need to pass a value to a function designed to
handle any object. ( Python has similar wrappers, but that's because
all objects in Python are not implemented with Classes. )
Maybe what you meant is: In Java, all functions are methods, whether
you like it or not.
[ There are lots of other differences, however many of the significant
ones can be traced to support for static type checking. ]
Paul Prescod
On 11 Mar 1998, Craig Dickson wrote:
> Paul Prescod <papr...@technologist.com> wrote:
>
> >To me, Java is Python with static type checking.
>
> Well, it depends what you choose to focus on as being the important
> characteristics of a language. Java subscribes to the "everything is
> an object whether you like it or not" philosophy, which Python does not.
That's true. But professional programmers can move between one mode and
the other easily. The underlying concepts don't change. We're not
jumping from Pascal to Lisp! *Newbies* should definately stick to Python.
> Python is dynamically typed, which Java is not. And so on.
That's what I said is the big difference. (Primarily)static type checking
or completely dynamic type checking. One is definately more flexible. The
other is surely more safe. I don't believe either is "superior."
Paul Prescod
James Logajan
Moinak Ghosh (moi...@cisco.com) wrote:
: But I take a very strong exception to your poorly researched view
: against Java. You CANNOT compare Java with Tcl, Perl, Python ..blah..
: been designed from the ground up to be a full-fledged language
: C,C++,Fortran,Pascal...
As has been pointed out, Python is more than a scripting language. In
point of fact, Python and Java often compete for the same mind-share. In that
sense they can and must be compared (which I had to do, by the way). As
a conscientious engineer I felt it was important to review all the viable
options. Tcl, Perl, Python, Java, and Lua all happened to be valid options
for the project I am working on. (I was not the sole arbiter of the language
choice. We actually are using Java for some parts, but that was advocated by
management).
: Scripting tools (tcl,perl,python...) are at a much higher level of
: abstraction than proper languages, and are designed for writing
: short programs.
I've written long 'C' programs and now many thousands of lines of Python;
each has their place. Both are full languages, as are the others. Both
complement each other well.
: But I surely cannot accept your views on Java. Please EDUCATE YOURSELF
: before passing such comments.
I still would recommend Python over Java as the better OOP language. If I
need efficient computation speed, I would recommend 'C' or even in rare
cases assembly. I would recommend Java and C++ to those who need to fill
out their resumes. (I have done some C++ and only a handful of Java programs).
: Sorry for being so harsh.
Sorry if I ticked you off. Odd though, but my mention of Java was tacked
on as an afterthought...didn't think it would generate such a strong
reaction.
Fredrik Lundh
>But I take a very strong exception to your poorly researched view
>against Java. You CANNOT compare Java with Tcl, Perl, Python ..blah..
>blah..blah.
Of course we can compare Java with Tcl, Perl, and Python.
And of course we should.
(Who are you? The Java Inquisition? Or one of the Java free-
dom fighters from the Java Lobby? If so, please go back to
www.javalobby.org).
> Java is definitely Not a scripting language.
So? Python is definitely Not a scripting language either.
>Scripting tools (tcl,perl,python...) are at a much higher level of
>abstraction than proper languages, and are designed for writing
>short programs.
Nonsense. (and what on earth is a "proper" computer language?)
>Tcl's central idea was to provide a scripting interface to a core
>extensible library of C procedures.
Nonsense. Change "central" to "original". There's much more to
both Tcl 8.0 and Itcl.
>Python, as far as I have read is pretty good
Sure is. But why don't you try it, instead of just reading about it?
> but again it depends on Tk for the GUI !!
Nonsense. You can use virtually any GUI with Python (including AWT).
>But I surely cannot accept your views on Java. Please EDUCATE YOURSELF
>before passing such comments.
Yeah, good idea. Why don't you educate yourself. Here are some
resources: www.python.org, sunscript.sun.com, www.scriptics.com,
www.perl.org. You sure have a lot to learn about the world outside
Java.
Besides, this is comp.lang.python. There are other forums for
the discussion of why, when, and whether Java will rule the world.
/F
Donal K. Fellows
In article <6e712s$2ov$1...@shell3.ba.best.com>,
Craig Dickson <c...@shell3.ba.best.com> wrote:
> Steve Bellenot <bell...@math.fsu.edu> wrote:
>> Templates are not that hot. They suffer less than the C #define macro's
>> but still subject to the header problem. Namely they can be compiled
>> many different times with different flags, but are often linked only
>> once. (Which one do you get?)
>
> Well, I've been bitten in C/C++ by linking with libraries that were
> compiled with different flags (structure packing being a
> particularly nasty one). So this isn't a problem specific to
> templates or even to things contained in headers as such. And I
> certainly don't claim that C or C++ are perfect. But assuming you
> can standardize your compiler flags so that you don't shoot yourself
> in the foot that way, templates can be wonderfully useful.
Templates are certainly a good idea. I'm not quite so sure about the
execution, but that (as always) is a separate matter. I've certainly
been bitten by the problem of casting generic pointers to the wrong
actual type enough times that having the compiler catch that is very
useful indeed[*]. Inefficiencies with the scheme are irritating, but
let me get my code right first. Go-faster stripes are secondary...
That said, I fail to see what relevance this has to either Tcl or
Python. :^)
Donal.
[* "Why is that pointer pointing to meaningless gibberish and causing
segmentation violations?" is not among my most favourite
questions... ]
Konrad Hinsen
oer...@vb.pbz (Brent Burton) writes:
> Is it correct to say that for the "decrementing values" (so to speak),
> like I before V or X, X before L or C, etc, that the rule is the
> decrementing number should be the same magnitude or one less than the
> number it is subtracted from? "I" has the same magnitude as V, and is
> one less than X, for instance. If this rule is true, it would allow
Right. After all, the Romans did use the decimal system for numbers,
so such a rule is reasonable.
For the full story of Roman (and other) numerals, check the excellent
book by George Ifrah (the original French title is "Histoire Universelle
des Chiffres", but there is probably an English translation).
> On a similar note, since we can't put bars over the ASCII characters,
> what ASCII representations are used for large numbers greater than MMM?
I suppose the problem hasn't occured yet!
--
-------------------------------------------------------------------------------
Konrad Hinsen | E-Mail: hin...@ibs.ibs.fr
Laboratoire de Dynamique Moleculaire | Tel.: +33-4.76.88.99.28
Institut de Biologie Structurale | Fax: +33-4.76.88.54.94
41, av. des Martyrs | Deutsch/Esperanto/English/
38027 Grenoble Cedex 1, France | Nederlands/Francais
-------------------------------------------------------------------------------
lvi...@cas.org
According to James Bailie <jba...@wwdc.com>:
:da...@ks.uiuc.edu (Andrew Dalke) wrote:
:
:> I think 1998 is written MXMCII. I've been looking for a movie ad with
:
:1998 = MXMXCVIII
The way we learned in school was:
M = 1000
C = 100
X = 10
V = 5
I = 1
1998 = 1000 + (1000-100) + (100-10) + (5+1+1+1)
= M CM XC VIII
MCMXCVIII
The following shell program, that I ran across on the net a LONG time ago,
converts arabic to roman numerals:
#! /bin/sh
# Purpose: convert arabic number to roman numeral
if [ "$#" -eq 0 ] ; then
echo "USAGE: $0 arabic_number " >&2
exit 1
fi
cat << EOF | nroff
.pl 1
.af a I
.nr a $1
\na
EOF
exit 0
.nr a 1990
--
<URL:mailto:lvi...@cas.org> Quote: In heaven, there is no panic,
<*> O- <URL:http://www.teraform.com/%7Elvirden/> only planning.
Unless explicitly stated to the contrary, nothing in this posting
should be construed as representing my employer's opinions.
Steve Bellenot
In article <wi7ogzd...@mailhost.zib.de>, Martin Holz <ho...@zib.de> wrote:
>bell...@math.fsu.edu (Steve Bellenot) writes:
>> I also fail to see how writing an operator< for every class is any
>> itself be a `bad choice' either do to speed, or do to the fact that
>> the underlining class really does not have an order.
>
>a sorting algorithm for every class.
>
>Martin
>
This is getting way off topic, but sorting is another bad example. The
C solution `qsort' has existed for years before c++. Besides the
same sorting algorithm does not work for every situation.
Craig Dickson
Thomas <nou...@nohost.nodomain> wrote:
>This is how you would express that in Java:
>
>interface Comparator {
> boolean less(Object a,Object b);
>}
>
>class Max {
> Comparator comparator;
> Max(Comparator comparator) {
> this.comparator = comparator;
> }
> Object max(Object a,Object b) {
> if(comparator.less(a,b)) return b;
> else return a;
> }
>}
Paul Prescod offered a very similar solution to me in email. It doesn't
fulfill the requirements. First off, it will only work for classes that
inherit the Comparator interface, which means it won't work for any class
that comes from outside your development group, and won't work for
primitive types. (Not surprisingly, while your solution and his are
functionally equivalent, they are not compatible; his classes and methods
were named differently. This, to me, is the big advantage of operator
overloading -- it provides you with standardized terms for a variety of
common operations that can be overridden as needed in any class.)
The problem, conceptually, is quite simple; max() is a function that is
meaningful for any orderable class, and I want a single (at the source
code level, at least), type-safe implementation that will work for any
such class. The above doesn't cut it. A C++ global template can do it
trivially, requiring only that all orderable classes implement the
comparison operators (which they ought to):
template <class T>
inline bool max(const T& a, const T& b) {
return a < b ? b : a;
}
A lot less code than your Java solution, no?
>still, there are some specialized uses for which C++
>templates are really the only way to go, but at a big cost in language
>complexity and code size.
Language complexity, yes. The code size argument against templates isn't
really valid, though. You can waste a lot of code space by implementing
templates poorly, but when done properly, code replication is minimal and
limited to the code that really is dependent on the template parameters.
That this discussion is occuring in the Python and Tcl newsgroups is a
wonderful demonstration of topic drift. May I suggest that anyone who
wants to continue this do so in email? I'm happy to debate Java vs. C++,
but not here.
Craig
Steve Bellenot
In article <6e712s$2ov$1...@shell3.ba.best.com>,
Craig Dickson <c...@shell3.ba.best.com> wrote:
>Steve Bellenot <bell...@math.fsu.edu> wrote:
>
>>Templates are not that hot. They suffer less than the C #define macro's
>>but still subject to the header problem. Namely they can be compiled
>>many different times with different flags, but are often linked only
>>once. (Which one do you get?)
>
>Well, I've been bitten in C/C++ by linking with libraries that were
>compiled with different flags (structure packing being a particularly nasty
>one). So this isn't a problem specific to templates or even to things
>contained in headers as such. And I certainly don't claim that C or C++ are
>perfect. But assuming you can standardize your compiler flags so that you
>don't shoot yourself in the foot that way, templates can be wonderfully
>useful.
It is not just the compiler flags, but also which #defines one includes
for example NDEBUG if one uses asserts.
Saying templates can be useful is true, but they also can be a curse. Many
template libraries I have played with turned out not very portable. I have
often seen code that would have been better without templates. The design
was wrong cause this container class supported this operation.
>
>>Operator< can
>>itself be a `bad choice' either do to speed,
>
>I don't follow you there. Overloaded operators in C++ are no less efficient
>than any other virtual function. Or are you getting at something else?
Often a < b can be expensive, and is followed by a test a > b. A comparison
function like that used by qsort can be twice as fast.
>
>>or do to the fact that
>>the underlining class really does not have an order.
>
>In which case you wouldn't want to do max() on it, would you? But that's
>why I defined the problem as "in such a way that it can be used with any
>class whose instances can be sensibly compared using the < operator" --
>if it isn't orderable, that won't be the case.
There are three problems here you are missing. The first one is some
containers require an operator< even if it is meaningless. The second
one is more serious, many classes have several natural orders. Thirdly some
classes have a operator< which is not a total order and hence your
max function produces what?
>
>Craig
Lyn A Headley
>>>>> "Fredrik" == Fredrik Lundh <fre...@pythonware.com> writes:
>> Java is definitely Not a scripting language.
Fredrik> So? Python is definitely Not a scripting language
Fredrik> either.
<rant>
I hate the term "scripting language". Originally, it had a pretty
clear and accurate meaning, which was applied to languages like Basic,
AWK, and Perl4, languages meant for quick, throw away hacks with few
abstraction capabilities. Then Ousterhout came along and perverted it
with his "white paper," (more like brown paper if you ask me) in which
the world was a simple place filled with either scripting or systems
languages. In so doing, he conflated in many people's minds the
notion of a nasty, one-shot language with that of an extension
language, (which, surprise surprise, happens to describe tcl quite
accurately) two _very_ different concepts. This unfortunate
juxtaposition has done a lot of damage to the idea of extension
languages as *real* programming languages (Yes frederik, there is such
a thing as a real language and it doesn't include Basic, Awk, Perl4,
bin/sh, Javascript, or much of Tcl). For this reason, I will never
refer to Python, Lua, Scheme, Perl5, or others of their ilk as
scripting languages. I urge others to do the same.
</rant>
On the other hand, I don't really know what to call languages like
Python and Perl. They are certainly not just Extension languages
(unlike say Lua and Guile). I think a new term is in order.
suggestions, anyone?
>> Scripting tools (tcl,perl,python...) are at a much higher level
>> of abstraction than proper languages, and are designed for
>> writing short programs.
tcl's idea of abstraction is quoting.
--
Lyn Headley
remove the word "bogus" from my address for the real one.
Gordon McMillan
Thomas wrote:
[snip]
> This looks much worse in a simple example like this than it is in a
> real program. Is this perfect? No, but if you want a language that
> is simultaneously simple, expressive, and object-oriented, you have
> to make some compromises somewhere. Scheme, CommonLisp, Smalltalk,
> SML, Ada, Python, C, and C++ all make different compromises in this
> area. Having used all of them, I find Java's compromise quite good
> for many applications; still, there are some specialized uses for
> which C++ templates are really the only way to go, but at a big cost
> in language complexity and code size.
Most of my income is derived from C++, C or Java. When Java first
came out, I loved it 'cause I could churn it out 4 or 5 times faster
than C++. I loved it so much I wrote a book on it (what a sucker -
3 month's income down the tubes).
Then I discovered Python, which I can churn out 4 or 5 times faster
than Java.
So at this point, I prototype anything I'm going to do in Python.
(Takes no longer and is a lot more certain than drawing OMT or UML
diagrams). It's then only marginally harder to translate to C++ than
to translate to Java. And I get all the advantages of C++ - speed &
control.
Granted, I don't get a GUI. But I get to use the platform's GUI
fully, instead of a grossly limited one.
I don't get cross-platform, but I have only once had a requirement of
cross-platform, and it still took 3 separate (Java) versions before
it would run most places.
To my mind, Java is a very poor compromise. It largely subverts the
dynamic binding through static type checking. It takes a lot more
code to do dynamic binding in C++, but you _can_ tell the C++
compiler to shut up and get out of the way. You can only do that in
Java by using JNI (or one of the MS alternatives) and C or C++ (or
Python). And then it's not cross-platform, (or Java).
I don't hate Java at all. I learned some stylistic things in Java
that I now apply to C++. Generally the class libraries are quite
elegant. But I can't think of any language features, (useful to me in
my work) that I can't do better or faster in C++ or Python, (or best
yet, a combination).
- Gordon
Fredrik Lundh
>I hate the term "scripting language".
Me too! ;-)
>For this reason, I will never refer to Python, Lua, Scheme,
>Perl5, or others of their ilk as scripting languages. I urge
>others to do the same.
I think the following is a pretty accurate description of what
scripting really is:
"Unlike mainstream component programming, scripts usually do no
introduce new components but simply 'wire' existing ones. Scripts can
be seen as introducing behaviour but no new state. /.../ Of course,
there is nothing to stop a 'scripting' language from introducing persistent
state -- it then simply turns into a normal programming language"
-- Clemes Szyperski, in "Component Software"
And as for Python, why not ask its designer?
"Python is not just a script language! If all you need is scripts, Tcl
would be a better choice. Python is a real programming language,
but concise enough to use for ad-hoc programming such as scripts.
When you write your scripts in Python, you don't have to recode
them in a real language when they get larger. Python is really
sitting halfway between script languages like sh and compiled
language like C."
-- Guido van Rossum, "Why Python" (on pytho...@cwi.nl,
December 1991
>On the other hand, I don't really know what to call languages like
>Python and Perl. They are certainly not just Extension languages
>(unlike say Lua and Guile). I think a new term is in order.
>suggestions, anyone?
I usually use the term "cool" (for Python, not that sure about Perl ;-)
Cheers /F
fre...@pythonware.com
http://www.pythonware.com
Aaron Watters
From: Paul Prescod <papr...@technologist.com>Date:
1998/03/11
>To me, Java is Python with static type checking.
Since I haven't put my foot in it and pissed of Jim H and Steve M for a
while
let me also point out that Python also runs better on more platforms and
faster
too. I don't mean on stupid benchmarks: I mean on real programs. Of
course
Jim H's translation of Python to java may give similar performance (when
he
catches up) because jpython does a lot of hard work for the programmer
but I assert that the easy way to write a difficult app in Python
frequently runs faster than the easy way to write a difficult app in
Java (if there is
an easy way ;) ). For example I have a couple reports that gadfly/SQL
is 10x faster
than the only remotely comparable database engine for Java, and that, I
assume,
is without kjbuckets installed. By this metric Python is arguably
faster than C
too, since I also have reports that gadfly is faster than Postgres. And
gadfly
isn't even that many lines of code (not that there wasn't a lot of
effort, thought, and
months of work scattered over 4 years involved, mind you). This is not
to mention
a much more complete and standard implementation of SQL ;).
[Caveat: the other engines mentioned may well handle larger data sets
(better),
but if your db is not huge gadfly may be faster, and a lot of
interesting
databases are not huge.]
So, if you want to get work done in a timely manner I suggest Python.
(maybe jpython, if it has to run in an applet). -- Aaron Watters
[donning my asbestos longjohns]
http://starship.skyport.net/crew/aaron_watters/bplustree/term.cgi?214160
===
"...my advisor had jokingly reassured me about my
doctoral research by saying, 'Everything will turn out fine unless you
find something totally ridiculous, like the halo of the Galaxy rotating
backward.' But that is exactly what I found..." --The other Steve
Majewski
(I assume).
gopher://minerva.acc.virginia.edu/0R0-7536-/news/prour/MARCH%201998/astronomer
Mike Pelletier
Lyn A Headley wrote in message ...
>On the other hand, I don't really know what to call languages like
>Python and Perl. They are certainly not just Extension languages
>(unlike say Lua and Guile). I think a new term is in order.
>suggestions, anyone?
"Very High Level" programming language? I think there's a precedent for
that in microchips...
>Lyn Headley
>remove the word "bogus" from my address for the real one.
Mike.
Amit Patel
Steven D. Majewski <sd...@virginia.edu> wrote:
|
| On 11 Mar 1998, Craig Dickson wrote:
|
| > Paul Prescod <papr...@technologist.com> wrote:
| >
| >
| > characteristics of a language. Java subscribes to the "everything is
| > an object whether you like it or not" philosophy, which Python does not.
|
| In Python, everything is an object -- even integers.
| ( All objects are not implemented as members of Classes though. )
Can you tell me what criteria you use to classify "everything" as an
object? I can't figure out how Python integers are objects but Java
integers are not. They seem the same to me, but there must be
something I'm not looking at...
- Amit
garry hodgson
Moinak Ghosh wrote:
> But I take a very strong exception to your poorly researched view
> against Java. You CANNOT compare Java with Tcl, Perl, Python ..blah..
> blah..blah. Java is definitely Not a scripting language.
true.
> It has
> been designed from the ground up to be a full-fledged language
> providing all the good features of numerous other langs like
> C,C++,Fortran,Pascal...
hardly "all". in fact, it omits several key features, which really
cripple it. lack of multiple inheritance and any sort of
metaprogramming
support spring to mind. they are starting to add ugliness to
its pristine core to get themselves out of the corners they've painted
themselves into. witness "inner classes". ugh.
> Scripting tools (tcl,perl,python...) are at a much higher level of
> abstraction
true.
> than proper languages,
"proper languages?" be serious.
> and are designed for writing short programs.
not so.
> Python, as far as I have read is pretty good, but again it depends
> on Tk for the GUI !!
no, it allows one to use Tk for a GUI, along with a wealth of other
choices.
> But I surely cannot accept your views on Java. Please EDUCATE YOURSELF
> before passing such comments.
indeed, education is often in order.
--
Garry Hodgson Sometimes we ride on your horses
ga...@sage.att.com Sometimes we walk alone
Software Innovation Services Sometimes the songs that we hear
AT&T Labs Are just songs of our own
garry hodgson
Paul Prescod wrote:
> To me, Java is Python with static type checking.
and without multiple inheritance or metaprogramming support.
> The distance between
> them is really not that far, compared to their shared distance from,
> say, C, C++ or TCL.
i dunno, that's a lot of dimensions to measure distance along.
java is pretty close to c++ lite.
> I tend to think that someone who really likes one
> and not the other has probably not given the other a good try
not in my case. i've used both a great deal. java drives me nuts with
the hoops one must jump through to get around what they lost from c++.
(never mind the abysmal toolkits...don't get me started.)
> (or else they really hate static type checking or the lack thereof).
nope again. i'm quite comfortable with this, from *many* years of c++.
> I think a
> disproportionate chunk of the Java-haters come from platforms where JVMs
> are poorly implemented.
if this includes pc and sun and sgi and linux, i guess you've got me
pegged.
or perhaps it's the language, not the implementation.
Gordon McMillan
In article <3506FA...@cisco.com>, moi...@cisco.com says...
[snip]
>But I take a very strong exception to your poorly researched view
>against Java. You CANNOT compare Java with Tcl, Perl, Python ..blah..
>blah..blah. Java is definitely Not a scripting language.
Sorry. Can't resist.
From Object Magazine Online's interview with James Gosling
(http://www.objectmagaine.com/):
JG (speaking of Java): "...This is a language that, looked at one way, is a
small, interpreted scripting language and can be treated that way. But it can
^^^^^^^^^
also be treated as a full-scale, full-application, general purpose
programming language." (Emphasis mine, of course).
--
- Gordon McMillan
McMillan Enterprises, Inc. | http://www.mcmillan-inc.com/
Tim Peters
[Amit Patel <am...@Xenon.Stanford.EDU>]
> ...
> Can you tell me what criteria you use to classify
> "everything" as an object? I can't figure out how
> Python integers are objects but Java integers are
> not. They seem the same to me, but there must
> be something I'm not looking at...
Go at it from the other direction, Amit: what can you do with objects
that you can't do with non-objects? Well, in Java, surely anything that
*is* an object can be assigned to an Object, right? In Java,
Object o = 42;
yields a compilation error (specifically "Incompatible type for
declaration. Can't convert int to java.lang.Object." under Sun's JDK
1.1.5). You won't find a similar restriction in Python. Along the same
lines, Java ints cannot be used as Vector elements (but Python ints can
be used as Python array elements), or as keys or values in Hashtables
(but can in Python's dicts). Etc. That's why the java.lang.Integer
class exists: so that you can wrap a raw int in an instance and treat
it like a "real object" when you need to. I don't think it's possible
to program in Java for more than a week without bumping into the
"non-objectness" of the primitive built-in types repeatedly! Java is
like C++, and unlike Python, in this respect, although C++'s templates
hide most of the clumsy consequences in common cases (e.g., a
Vector<class T> template can be instantiated as Vector<int> despite that
C++ ints are not C++ objects and are not instances of a C++ class ...).
In Python you never bump into this; e.g., even this works:
>>> sys.getrefcount(42)
3
That doesn't necessarily imply that 42 is an object in Python, but if
you can't find anything you can do with a Python object that you can't
do with a Python 42 (and you can't, btw), then in what comprehensible
sense are Python ints *not* objects <0.9 wink>?
but-the-*real*-reason-we-say-python-ints-are-objects-
is-that-we've-looked-at-the-implementation-and-
sure-enough-they-are-ly y'rs - tim
Donal K. Fellows
In article <6ea6rd$5gp$1...@news0-alterdial.uu.net>,
Gordon McMillan <gm...@hypernet.com> wrote:
> From Object Magazine Online's interview with James Gosling
> (http://www.objectmagaine.com/):
>
> JG (speaking of Java): "...This is a language that, looked at one way, is a
> small, interpreted scripting language and can be treated that way. But it can
> ^^^^^^^^^
> also be treated as a full-scale, full-application, general purpose
> programming language." (Emphasis mine, of course).
I don't think I agree with him, and I suspect that a lot of people
round here agree with me on that. I mean, who thinks that you need to
have a separate compile (and link?) stage in a scripting language?
Having them as optional is one thing, but...
Donal.
Paul Prescod
garry hodgson wrote:
>
> Paul Prescod wrote:
>
> > To me, Java is Python with static type checking.
>
> and without multiple inheritance or metaprogramming support.
Java and Python support meta-programming to the same level. In either
you can write programs to write programs. Admittedly Python has its
compiler "built-in" whereas in Java you would have to redistribute the
sun class files. The former is what I would expect from a dynamically
typed language and the latter is more than I get from any other
statically typed language I can practically use (and certainly better
than C++!).
Anyhow, I think what you mean is not metaprogramming, but meta-class
programming. I also think Java supports as reasonable a subset of
meta-class programming as you can expect for a statically typed language
(and a hell of a lot more than C++!). It has class objects and you can
pass them around as first class objects as you can in Python (but cannot
in C++).
Yes, Python supports multiple inheritance better than Java. Java's
multiple inheritance is restricted to a safe, understandable subset
(interface inheritance). Python provides plenty of opportunity to shoot
yourself in the foot. The former is what I expect from a statically
typed language and the latter is what I expect from a dynamically typed
language. C++ stands alone as a statically typed language that goes out
of its way to make it easy to shoot yourself in the foot.
> i dunno, that's a lot of dimensions to measure distance along.
> java is pretty close to c++ lite.
Java's runtime model (GC, bytecode, reflection, virtual-by-default,
pointer safety) is much closer to Python's. Essentially what it has in
common with C++ is superficial syntax and static type checking. Garbage
collection and pointer safety make such a HUGE difference to how I code,
that I would rather write 100,000 lines of either Java or Python than
10,000 lines of C++. Those two features essentially separate languages
that belong in the early 70s from those designed for the next century.
Plus, I learned the essentials of both Java and Python over two
weekends, whereas there are still nooks and crannies of C++ that I dare
not explore after programming in it for years. Java and Python share a
commitment to simplicity. That doesn't make Java "C++-lite", but rather
"C++ sane."
In my experience, if I code slower in Java than in Python, it is because
of the static type checking (and theoretically that is supposed to help
me in the long term...I don't know if it does). If I code slower in C++
it is because links take decades, the compiler is slow because C++
parsing is nigh-impossible, I'm trying to figure out how to keep track
of what parts of my parse tree I am done with and must essentially
implement garbage collection, my program is crashing in the "<<"
operator because a bug in an unrelated library overwrote a random
section of heap, the wrong virtual function is getting called because
C++'s rules are inscrutable and the syntax is dangerous, I need to look
up the rules for "virtual, multiple, abstract base class constructors"
(egad!), I'm having problems linking to a library because there is no
standard name mangling and object model, and so forth. I could go on for
days.
On the other hand, I don't know whether static type checking or dynamic
type checking will win out, so I continue to use both Java and Python
and experiment. I am confident that the Next Big Language will look like
one or the other of these two languages more than like C++, unless we
define "Big" by size of specification.
That all said, Java *does* need generics. I appreciate, however, that
the designers are stopping to think something through rather than taking
Bjarney's approach of throwing in whatever occurs to him first. And of
course there will always be a place in the world for pointer-unsafe
languages -- and ANSI C does a good job in that regard. There is even an
OOP subset of C++ that is reasonable.
Paul Prescod - http://itrc.uwaterloo.ca/~papresco
"A writer is also a citizen, a political animal, whether he likes it or
not. But I do not accept that that means a writer has a greater
obligation
to society than a musician or a mason or a teacher. Everyone has
a citizen's commitment." - Wole Soyinka, Africa's first Nobel Laureate
Michael Spalinski
> >On the other hand, I don't really know what to call languages like
> >Python and Perl. They are certainly not just Extension languages
> >(unlike say Lua and Guile). I think a new term is in order.
> >suggestions, anyone?
Actually, neither Lua nor Guile are 'just extension languages', I would say
they are more or less in the same category as Python, i.e. cool (although
not as cool as Python).
--
M.
Gordon McMillan
[Off topic...]
Garry Hodgson wrote:
[snip - speaking of Java]
> ... they are starting to add
> ugliness to its pristine core to get themselves out of the corners
> they've painted themselves into. witness "inner classes". ugh.
While I generally agree, inner classes are IMHO a necessity when
dealing with the new event model. Otherwise a project would have a
gazillion 6 line files in order to implement all the Listeners...
But it's converging on the complexity of C++, without the power...
- Gordon
Gordon McMillan
Donal Fellows wrote:
> Gordon McMillan <gm...@hypernet.com> wrote:
> > From Object Magazine Online's interview with James Gosling
> > (http://www.objectmagaine.com/):
> >
> > JG (speaking of Java): "...This is a language that, looked at one way, is a
> > small, interpreted scripting language and can be treated that way. But it can
> > ^^^^^^^^^
> > also be treated as a full-scale, full-application, general purpose
> > programming language." (Emphasis mine, of course).
>
> I don't think I agree with him, and I suspect that a lot of people
> round here agree with me on that. I mean, who thinks that you need
> to have a separate compile (and link?) stage in a scripting
> language? Having them as optional is one thing, but...
That was just one of large number of guffaw producing comments Mr.
Gosling made in the interview. The one's he makes about the
"problems" with C++ are to be expected, but for the "author" of the
language to make this characterization of the language...
Actually, what's truly amusing is that the only environment in which
I would consider this statement to have _some_ truth, is MS's
COM-extended Java.
And, of course, Mark / Greg's Python extensions blow it away there,
too.
- Gordon
Gordon McMillan
[Tim Peters innocently inquired]
[in reply to a question re non-objects in Python vs Java]
> ...what can you do with
> objects that you can't do with non-objects?
Well, <harumph> Mr. Peters, <harumph> in Python the set of
non-objects is the (trivial) subset of the set of objects, therefor
one can (trivially) do anything with a non-object that you can do
with an object.
Conversely, since the set of non-objects is empty, the set of results
of doing what you can with objects to non-objects is also empty.
Therefor, Python exposes the Godelian property that both of the
following statements are true:
You can do anything with a non-object that you can do with an object.
You can do nothing with a non-object (that you can do with an
object).
In Java, of course, the set of non-objects is disjoint from the set
of objects, so there exists a non-trivial subset of the-things-you-
can-do-with-objects that can't be done with non-objects.
From which we can (as pompously as possible) conclude that Java does
not encompass the Archimedian Postulate, and therefor Python is a few
thousand years more advanced.
Which is a much better argument than the curly braces thing, if you
ask me.
just-warming-up-for-the-day-when-theres-a-c.l.p.advocacy'ly yrs
- Gordon
Kevin J. Butler
"Tim Peters" <tim...@email.msn.com> writes:
> In Python you never bump into this; e.g., even this works:
>
> >>> sys.getrefcount(42)
> 3
I just had to try this out, and was surprised:
[c:\]python
Python 1.4 (Dec 9 1996) [MSC 32 bit (Intel)]
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>> import sys
>>> sys.getrefcount( 0 )
10
>>> sys.getrefcount( 1 )
5
>>> sys.getrefcount( 2 )
5
>>> sys.getrefcount( 3 )
3
Now, I can see that when you call getrefcount, the parser puts the
0 into a PyObject, and that function calls other functions
which politely increment the ref count, etc.
But why would the answer be different for 0, 1, 2, and 3?
> but-the-*real*-reason-we-say-python-ints-are-objects-
> is-that-we've-looked-at-the-implementation-and-
> sure-enough-they-are-ly y'rs - tim
:-)
kb
--
Kevin Butler but...@byu.edu 8-)
A pun a day keeps the doctor away...and everyone else, too.
http://students.cs.byu.edu/~butler/homepage.html (updated 10/18/96)
Barry A. Warsaw
I think the thing that trips people up with Python is the difference
between something being an object and being an instance.
-Barry
Steven D. Majewski
I agree with almost everything Tim wrote, especially:
> but-the-*real*-reason-we-say-python-ints-are-objects-
> is-that-we've-looked-at-the-implementation-and-
> sure-enough-they-are-ly y'rs - tim
except perhaps, if I'm in a quibbling mood, with this:
> In Python you never bump into this; e.g., even this works:
>
> >>> sys.getrefcount(42)
> 3
>
> That doesn't necessarily imply that 42 is an object in Python, [...]
since that does expose, without peeking at the source code, the
fact that Python integers have an internal state. If it wasn't
for that fact that syntatically, integer methods are disguised
by operator syntax, I could claim that it's obvious that they are
objects. ( Admittedly, as it is, only a Lisper is likely to make some
guesses about the hidden mechanisms and jump straight to that conclusion.)
---| Steven D. Majewski (804-982-0831) <sd...@Virginia.EDU> |---
---| Department of Molecular Physiology and Biological Physics |---
---| University of Virginia Health Sciences Center |---
---| P.O. Box 10011 Charlottesville, VA 22906-0011 |---
All power corrupts and obsolete power corrupts obsoletely." - Ted Nelson
Steven D. Majewski
On Thu, 12 Mar 1998, Aaron Watters wrote:
> Since I haven't put my foot in it and pissed of Jim H and Steve M for a
> while let me also point out that Python also runs better on more
> platforms and faster too. I don't mean on stupid benchmarks: I mean on
> real programs. [ ... ]
> So, if you want to get work done in a timely manner I suggest Python.
> (maybe jpython, if it has to run in an applet). -- Aaron Watters
>
> [donning my asbestos longjohns]
> http://starship.skyport.net/crew/aaron_watters/bplustree/term.cgi?214160
I don't particularly disagree with your assessment, Aaron.
I think Java has great PROMISE, but it's not all there yet.
I think Java may solve the sort of problem that
"Kevin J. Butler" <but...@whip.cs.byu.edu> complained about:
| The problem is the difficulty of releasing software which uses those
| extensions. Its bad enough convincing people they need
| to install a new programming language to use program I write,
| but telling them they need to:
|
| a) install Tcl/Tk
| b) install Python
| c) install win32 extensions
| d) install various non-standard python extensions
|
| is getting a bit painful.
Java *promises* a higher level of functionality in the basic libraries --
at least when we finally see the 2d and 3d graphics and sound APIs
delivered. ( Python+Tk+BLT+PMW+OpenGL+... is *not* yet the standard
distribution, and takes some effort to support on several platforms -
and you can't assume everyone has it or can get it in that configuration.)
[ Java performanc is not wonderful, but I'm waiting for the next
version of Metrowerks CodeWarrior, which will have a beta of their
native code compilers. ]
But for applications that I need now, I'm using Lisp ( XlispStat )
or Python ( plus some custom C extensions to do low level device
twiddling. BTW: interfacing random C code to XlispStat or Python is
much easier that to Java, using the standard Java native code
methods. On the Mac JDirect ( which is different than MS J/Direct )
is easier to interface, but it doesn't give you the same C level
access to Java objects that you have with the XlispStat or Python
libraries. )
As an experiment, I did the same simple graphics app in Wish(Tcl/Tk),
Python+Tkinter and Java:
Wish was the fastest ( and shortest in source code ) to complete.
[ However, when I started to think about extending it to do a
bit more, I quickly ran into limitations of Wish. ( I'm being
specific by saying "Wish" -- this is not what the Tcl/Tk crowd
would consider a limitation -- all I had to do was rebuild Wish
with some extra extensions in C, but I was trying to see what I
could do "out of the box". I needed a 'random' function to
turn it into a game and this was not included in Wish. ) ]
Python took just a bit longer. The source code was longer and there
was a little more effort translating Tk to Tkinter. ( I actually
did two Python versions -- a procedural style one and an OO style
one. The OO one took a bit longer that the former. )
Java took the longest. It was the longest source code.
It was the language and graphics library I was least familiar with.
But I think the biggest difference was not being able to
test things interactively from an interpreter. ( Of course, once
you're very familiar with the library and language, that testing
isn't as necessary, and having a nice IDE to work from minimized
the pain. )
Python was the clear winner in my little personal test, however, the
Java version was easier than I had thought it would be.
> ===
> "...my advisor had jokingly reassured me about my
> doctoral research by saying, 'Everything will turn out fine unless you
> find something totally ridiculous, like the halo of the Galaxy rotating
> backward.' But that is exactly what I found..." --The other Steve
> Majewski
> (I assume).
> gopher://minerva.acc.virginia.edu/0R0-7536-/news/prour/MARCH%201998/astronomer
>
You assume correctly: That's Steven **R.** Majewski
Steven D. Majewski
On Thu, 12 Mar 1998, Lyn A Headley <rant>-ed:
> I hate the term "scripting language". Originally, it had a pretty
> clear and accurate meaning, which was applied to languages like Basic,
> AWK, and Perl4, languages meant for quick, throw away hacks with few
> abstraction capabilities. Then Ousterhout came along and perverted it
> with his "white paper," (more like brown paper if you ask me) in which
> the world was a simple place filled with either scripting or systems
> languages. In so doing, he conflated in many people's minds the
> notion of a nasty, one-shot language with that of an extension
> language, (which, surprise surprise, happens to describe tcl quite
> accurately) two _very_ different concepts. This unfortunate
> juxtaposition has done a lot of damage to the idea of extension
> languages as *real* programming languages (Yes frederik, there is such
> a thing as a real language and it doesn't include Basic, Awk, Perl4,
> bin/sh, Javascript, or much of Tcl). For this reason, I will never
> refer to Python, Lua, Scheme, Perl5, or others of their ilk as
> scripting languages. I urge others to do the same.
Yeah! J-O's forced dichotomy of scripting vs systems languages was
one of the half dozen things that most irritated me about that paper!
How about a trichotomy:
Systems Languages: low level access to the machine. something you
can use to write operating systems, garbage collectors, device
driver, virtual machines and interpreters/run-time for other
higher level languages. ( C, C++, BLISS, assembler, ... )
[ Some systems languages have sufficient abstraction capabilities,
that with a good library, you can almost build a new higher
level language: FORTH, Macro Assemblers with a lot of work,
C++ with a lot of discipline... ]
Application Languages: higher level (closer to application problem
domain than to machine level), often hides memory management
and hardware.
Scripting Languages: ( I accept the original minimal definition )
A higher level language meant to be used to write small, quick,
and simple scripts that combine existing components which are
usually written in another language ( csh, ksh, tcl, AppleScript )
[ Of all the languages I've used, the one that was the best at
cutting across the categories and being very good at all of the
above was FORTH. ]
Paul Prescod
Gordon McMillan wrote:
>
> But it's converging on the complexity of C++, without the power...
"Converging" is an ambiguous word. Java is getting more complex. C++ has
stopped getting more complex (for now). But Java is nowhere near as
complex as C++. In fact, Java is about as complex as Python, IMO, except
that Java requires more to *get started* (e.g. an understanding of OOP,
static type checking, etc.) whereas Python allows you to learn it as you
go along. Neither are as complicated as C++ with its multiple, repeated,
abstract, virtual base class constructor invocation rules, its
"overloaded new operator" and so on.
Paul Prescod - http://itrc.uwaterloo.ca/~papresco
"A writer is also a citizen, a political animal, whether he likes it or
not. But I do not accept that a writer has a greater obligation
Brian Lloyd
Kevin J. Butler wrote:
> >>> sys.getrefcount( 0 )
> 10
> >>> sys.getrefcount( 1 )
> 5
> >>> sys.getrefcount( 2 )
> 5
> >>> sys.getrefcount( 3 )
> 3
>
> Now, I can see that when you call getrefcount, the parser puts the
> 0 into a PyObject, and that function calls other functions
> which politely increment the ref count, etc.
>
> But why would the answer be different for 0, 1, 2, and 3?
I believe that this is due to the way that python shares small ints
for performance...
>>> sys.getrefcount(3)
6
>>> sys.getrefcount(3)
6
>>> x=3
>>> sys.getrefcount(3)
7
--
Give me ambiguity or give me something else
Brian Lloyd Digital Creations
br...@digicool.com 540.371.6909
Steven D. Majewski
On Fri, 13 Mar 1998, Paul Prescod wrote:
> Gordon McMillan wrote:
> >
> > But it's converging on the complexity of C++, without the power...
>
> "Converging" is an ambiguous word. Java is getting more complex. C++ has
> stopped getting more complex (for now). But Java is nowhere near as
> complex as C++. In fact, Java is about as complex as Python, IMO, except
> that Java requires more to *get started* (e.g. an understanding of OOP,
> static type checking, etc.) whereas Python allows you to learn it as you
> go along. Neither are as complicated as C++ with its multiple, repeated,
> abstract, virtual base class constructor invocation rules, its
> "overloaded new operator" and so on.
I agree, Paul.
And just in case, in my previous post, if I went too far in stressing
the PROMISE of Java in the near future, vs. the reality of Python right
now as a solution, I would also note that Java is, _right_now_, a
more portable solution than C++. Most of the Java platform differences
I've run into a slight variations in the behavior of classes on
different platforms. On C++, the problem is more likely to be that
the code just plain won't compile and link on another system. As the
C++ standards have finally settled down and compilers are catching
up, I expect this will not be a problem within the next year.
( About the same period of time that I expect Java to have shaken
out most of it's implementation problems. )
Amit Patel
Tim Peters <tim...@email.msn.com> wrote:
| Go at it from the other direction, Amit: what can you do with objects
| that you can't do with non-objects? Well, in Java, surely anything that
| *is* an object can be assigned to an Object, right? In Java,
|
| Object o = 42;
|
| yields a compilation error (specifically "Incompatible type for
| declaration. Can't convert int to java.lang.Object." under Sun's JDK
| 1.1.5). You won't find a similar restriction in Python.
I attribute this to the lack of a static type system in Python.
Scheme for example has no objects yet there is no such restriction.
| Along the same
| lines, Java ints cannot be used as Vector elements (but Python ints can
| be used as Python array elements), or as keys or values in Hashtables
| (but can in Python's dicts). Etc.
This also seems like a restriction resulting from the type system.
For example in Scheme you can put any value into a vector, and it has
nothing to do with OOP. (I don't think Scheme has any standard
hashtables so I can't comment on that.)
| That's why the java.lang.Integer
| class exists: so that you can wrap a raw int in an instance and treat
| it like a "real object" when you need to. I don't think it's possible
| to program in Java for more than a week without bumping into the
| "non-objectness" of the primitive built-in types repeatedly! Java is
| like C++, and unlike Python, in this respect, although C++'s templates
| hide most of the clumsy consequences in common cases (e.g., a
| Vector<class T> template can be instantiated as Vector<int> despite that
| C++ ints are not C++ objects and are not instances of a C++ class ...).
It seems that C++ template syntax uses "class T" where they should
have used "type T", but there's this reluctance among the C++
standards people to add new keywords.
Again, Java and C++ are similar in the respect that they both have a
static type system and Python and Scheme do not.
| In Python you never bump into this; e.g., even this works:
|
| >>> sys.getrefcount(42)
| 3
|
| That doesn't necessarily imply that 42 is an object in Python, but if
| you can't find anything you can do with a Python object that you can't
| do with a Python 42 (and you can't, btw), then in what comprehensible
| sense are Python ints *not* objects <0.9 wink>?
Well I don't seem to be able to do 42.__methods__, 42.__members__,
42.__dict__, etc. It's not allowed in the syntax. 42 doesn't seem to
have any methods. 42 doesn't seem to have any internal state; only
its identity (a simple value, not an object) has any meaning.
I could call everything an 'object' (as is done in Scheme, a non OO
language) but that doesn't really mean anything to me.
| but-the-*real*-reason-we-say-python-ints-are-objects-
| is-that-we've-looked-at-the-implementation-and-
| sure-enough-they-are-ly y'rs - tim
I think that could be considered a good reason, but I'm not convinced
that using objects internally makes it an object externally, in the
same sense that not using objects internally doesn't mean you can't
have objects externally. :-)
- Amit
Amit Patel
Okay, silly question time!
Suppose I took out all the class mechanisms in Python.
Would it still be an object oriented language? If yes, would you
consider the original Lisp to be object oriented? If no, are ints
still objects in this non object oriented language?
- Amit
garry hodgson
Gordon McMillan wrote:
> [Off topic...]
> Garry Hodgson wrote:
> [snip - speaking of Java]
> > ... they are starting to add
> > ugliness to its pristine core to get themselves out of the corners
> > they've painted themselves into. witness "inner classes". ugh.
>
> While I generally agree, inner classes are IMHO a necessity when
> dealing with the new event model. Otherwise a project would have a
> gazillion 6 line files in order to implement all the Listeners...
agreed. that was my point.
> But it's converging on the complexity of C++, without the power...
nicely put.
garry hodgson
wheee! must've hit a nerve...
incidentally, several of your comments regarding C++ make it seem
as though you think i'm defending it. in fact, i long ago decided
that it was much too complex for its (or my) own good. and i like
some of the simplifications java has made, like unifying the
pointer/reference split, and adding gc. but some other removals
cause me endless grief. for a while, i assumed it was just that i
hadn't learned the new, more effective ways of solving problems within
the new paradigm. i eventually realized the problem was java, not me.
Paul Prescod wrote:
>
> garry hodgson wrote:
> >
> > Paul Prescod wrote:
> >
> > > To me, Java is Python with static type checking.
> >
> > and without multiple inheritance or metaprogramming support.
>
> Java and Python support meta-programming to the same level. In either
> you can write programs to write programs.
i can do that in assembler, too.
> Anyhow, I think what you mean is not metaprogramming, but meta-class
> programming.
i think you're right, my terminology was incorrect. i was referring
primarily to the lack of generics.
> Yes, Python supports multiple inheritance better than Java. Java's
> multiple inheritance is restricted to a safe, understandable subset
> (interface inheritance).
more like single inheritance plus interfaces. this is not useful
to me. i'm interested in code reuse. this isn't it.
> Python provides plenty of opportunity to shoot
> yourself in the foot. The former is what I expect from a statically
> typed language and the latter is what I expect from a dynamically typed
> language. C++ stands alone as a statically typed language that goes out
> of its way to make it easy to shoot yourself in the foot.
i long ago stopped shooting myself in the foot, in c++, java or python.
my problem with c++ was not misfires, but the previously unseen nooks
and
crannies of the language that i'd occasionally stumble into. picked up
a few bruises that way.
> > i dunno, that's a lot of dimensions to measure distance along.
> > java is pretty close to c++ lite.
>
> Java's runtime model (GC, bytecode, reflection, virtual-by-default,
> pointer safety) is much closer to Python's.
you are correct, of course. i was referring to usage, not runtime.
specifically, the interpreted vs. compiled models, and being to read
the executable.
> Essentially what it has in common with C++ is superficial syntax
> and static type checking.
that syntax goes a lot deeper than superficial.
> Garbage
> collection and pointer safety make such a HUGE difference to how I code,
i do like gc, but doing the ref/unref pairs was not such a big deal.
and i just never had much trouble with rogue pointers.
> that I would rather write 100,000 lines of either Java or Python than
> 10,000 lines of C++. Those two features essentially separate languages
> that belong in the early 70s from those designed for the next century.
i'll buy that.
> Plus, I learned the essentials of both Java and Python over two
> weekends, whereas there are still nooks and crannies of C++ that I dare
> not explore after programming in it for years. Java and Python share a
> commitment to simplicity.
i assume you made it a point to forget everything you knew about c++ and
oo first, to make the experiment fair?
> Java and Python share a commitment to simplicity.
oversimplicity in java's case.
> That doesn't make Java "C++-lite", but rather "C++ sane."
nope. adding GC and pointer safety made it sane.
deleting multiple inheritance and generics made it lite.
> If I code slower in C++
> it is because links take decades, the compiler is slow because C++
> parsing is nigh-impossible, I'm trying to figure out how to keep track
> of what parts of my parse tree I am done with and must essentially
> implement garbage collection, my program is crashing in the "<<"
> operator because a bug in an unrelated library overwrote a random
> section of heap, the wrong virtual function is getting called because
> C++'s rules are inscrutable and the syntax is dangerous, I need to look
> up the rules for "virtual, multiple, abstract base class constructors"
> (egad!), I'm having problems linking to a library because there is no
> standard name mangling and object model, and so forth. I could go on for
> days.
i think you have :-)
much of what you've described here is lousy implementation.
that has, indeed, been a problem. the decision to compile down to
C was a great idea, in that it made the language spread quickly.
but it lasted way too long, causing many of the problems you cite.
on the other hand, the java compilers i've used (on pc, sun, and sgi)
are abysmally slow. and its insistence on where i need to put my
files, and when they'll be compiled, makes for some major headaches
in group projects.
> I am confident that the Next Big Language will look like
> one or the other of these two languages more than like C++, unless we
> define "Big" by size of specification.
by most measures, VB is the next Big Language, and we're all pissing in
the wind.
sigh.
> That all said, Java *does* need generics. I appreciate, however, that
> the designers are stopping to think something through rather than taking
> Bjarney's approach of throwing in whatever occurs to him first.
cheap shot.
Gordon McMillan
Amit Patel wrote:
> Tim Peters <tim...@email.msn.com> wrote:
> | Go at it from the other direction, Amit: what can you do with objects
> | that you can't do with non-objects? Well, in Java, surely anything that
> | *is* an object can be assigned to an Object, right? In Java,
> |
> | Object o = 42;
> |
> | yields a compilation error (specifically "Incompatible type for
> | declaration. Can't convert int to java.lang.Object." under Sun's JDK
> | 1.1.5). You won't find a similar restriction in Python.
>
> I attribute this to the lack of a static type system in Python.
> Scheme for example has no objects yet there is no such restriction.
Well, Python has a type system. Whether it's static or not is
immaterial. However, the word changes meaning between Python and
just about any other language.
In Java, " A a = new A();" yields an object of a different (Java)
type than "B b = new B();".
In Python, both a and b (adjusting for syntax) have the same (Python)
type, ("instance").. So you can't really compare what Java calls a
type with what Python calls a type.
But there's (in Java) a fundamental difference in behavior between
"the primitive types" and "object types". That's not true in Python.
In Python-ese, saying "everything is an object" does not mean that
one is claiming that everything is an instance of a class.
I was once lectured (by no less than Mr. Peter Van der Linden his
self), that "Java always passes by value. If it's a primitive, it's
the value of the primitive. If it's a reference, it's the value of
the reference." (When I pointed out he was confusing the hell out of
newbies, he found a different way to put it).
But extending this same kind of over-generalization to Python, one
could claim that Python always passes by reference, even for things
like ints. If you pass a 3, you are NOT putting 0x03 on the stack. In
Java, you are.
> I could call everything an 'object' (as is done in Scheme, a non OO
> language) but that doesn't really mean anything to me.
Hmmm, didn't you just say:
> I attribute this to the lack of a static type system in Python.
> Scheme for example has no objects yet there is no such restriction.
Oh, I see, you want "object" to mean the first O in OO (whatever that
means), and "type" to mean....??
- Gordon
Gordon McMillan
> Gordon McMillan wrote:
> >
> > But it's converging on the complexity of C++, without the power...
>
> has stopped getting more complex (for now). But Java is nowhere near
> as complex as C++.
If you limit C++ to the roughly Java-esque subset, (no const, no
multiple inheritance, no operator overloading), the syntax is only
slightly more complex. You'll have to use (someone elses) templates
to get type safe collections. For the equivalent of "interfaces"
you'll either need to write templates, or use multiple inheritance,
both of which are a bit more difficult and good deal more powerful.
You probably won't get a free standard library with the same range,
but last time I looked, there were still some class methods in java.*
that were unimplemented, even though not so described in the docs.
I've never had that problem with Rogue Wave.
Let's see. Class.forName() is a little harder, but MFC comes with
that. C++ doesn't have a standard threading package. But Javasoft is
tooting the horn for 1.2 'cause now threads will work. On Solaris.
And so on...
> In fact, Java is about as complex as Python, IMO,
> except that Java requires more to *get started* (e.g. an
> understanding of OOP, static type checking, etc.) whereas Python
> allows you to learn it as you go along. Neither are as complicated
> as C++ with its multiple, repeated, abstract, virtual base class
> constructor invocation rules, its "overloaded new operator" and so
> on.
After 1.5 years of Python, I'm still discovering richness (and still
unable to understand what the hell Jim Fulton is talking about).
After 6 years of C++ I'm still getting comfortable with things like
multiple inheritance and some of the things you can do with
templates.
I was bored after a year of Java.
I don't really dislike Java as much as this probably sounds. There
are many many much worse languages. And there's certainly an elegance
to the class libraries. But the fact that there are advanced features
of C++ that are difficult to use makes no basis for comparison to
Java which prevents you from even trying the same thing.
One says, "Here's your motorcycle. Try to stay alive." The other
says "Please have a seat at the dinner table, fasten your
seatbelt and keep goggles on at all times."
As far as that goes, I find Python more like C++. GvR may be BDFL,
but he's not Mr. Mom.
- Gordon
Tim Peters
[Tim Peters <tim...@email.msn.com>]
| Go at it from the other direction, Amit: what can you do with objects
| that you can't do with non-objects? Well, in Java, surely anything
that
| *is* an object can be assigned to an Object, right? In Java,
|
| Object o = 42;
|
| yields a compilation error (specifically "Incompatible type for
| declaration. Can't convert int to java.lang.Object." under Sun's JDK
| 1.1.5). You won't find a similar restriction in Python.
[Amit Patel <am...@Xenon.Stanford.EDU>]
> I attribute this to the lack of a static type system in Python.
Then you simply misunderstand Java's type system -- declarations, or
lack thereof, have nothing to do with this (& if you're not talking
about type declarations, I have no idea what you mean by a "static" type
system). Chapter 4 of "The Java(tm) Language Specification" will clear
up the confusion.
> Scheme for example has no objects yet
> there is no such restriction.
Each language uses "object" to mean anything it wants. 90% of your
arguments appear, to me, to demonstrate just that you don't accept the
various meanings ascribed to the word "object" by various languages.
That's fine, if that's all you're trying to say -- but over time you'll
find it's a futile position <wink>.
| Along the same lines, Java ints cannot be used as Vector
| elements (but Python ints can be used as Python array
| elements), or as keys or values in Hashtables (but can in
| Python's dicts). Etc.
> This also seems like a restriction resulting from the
> type system.
Now that the adjective "static" has been dropped, yes, of course: in
Java's type system, ints are not Objects (that's *their* definition --
read their spec if you don't believe me), and Vectors (etc) are
constrained to hold only Objects. So, yes, it is entirely a result of
Java's type system. *Python's* type system is different, and in that
ints *are* objects (and read the Python spec if you don't believe me
<wink -- but an argument not based on section 3.1 of the Python
Reference Manual is just blowing in the wind ...>).
| For example in Scheme you can put any value into
| a vector, and it has nothing to do with OOP.
I don't believe anyone claimed it did. What I gave you were examples
where Java ints do not act like Java objects, but where Python ints do
act like Python objects, where "int" and "object" have the meanings
given to them by their respective defining documents. Scheme can define
an int to be a rutabaga, and a vector to be a whale's spout, and if it's
OK by them to stuff a rutabaga in a whale's blow hole, I have no
objection. I.e., the short answer to your original question (remember
what it was <wink>?) is "because that's the way the languages defined
the terms".
| ...
| It seems that C++ template syntax uses "class T" where
| they should have used "type T", but there's this reluctance
| among the C++ standards people to add new keywords.
Agreed on both.
} Again, Java and C++ are similar in the respect that they
| both have a static type system and Python and Scheme
| do not.
But declarations don't enter into it. It would have been possible to
define a declaration-free Java in which ints still couldn't be used in
object contexts (in fact, that's the way it would *have* to be, unless
they also changed Java's type system -- a language's type system exists
and has crucial meaning whether or not a language offers a declaration
syntax for it). And if you plow thru DejaNews you'll find many old
discussions about adding declaration syntax to Python, but you won't
find anyone objecting on the grounds that as soon as they can say, e.g.
"var int i", they'll suddenly lose the ability to use i as a dict key.
The type system is fundamental; declaration syntax (or absence thereof)
is secondary, very much the tail on a non-wagging dog.
| In Python you never bump into this; e.g., even this works:
|
| >>> sys.getrefcount(42)
| 3
> Well I don't seem to be able to do 42.__methods__,
> 42.__members__, 42.__dict__, etc. It's not allowed
> in the syntax.
But you can first do
i = 42
and *then* do i.__methods__ etc. Whether something is an object is not
a syntactic property. The *syntax* restriction you bumped into here has
to do with making it possible for the parser to easily distinguish
between base-10 integer literals and floating-point literals. Change
bases to avoid this formal parsing difficulty and the syntax error goes
away; e.g., these variations are not syntax errors:
0x2a.__methods__
052.__members__
42..__dict__
Something else to ponder: if the int 42 is not an object, how do you
explain the output of this snippet?:
print id(42), id(0x2a), id(052)
> ... 42 doesn't seem to have any internal state;
The string "42" appearing in source code does not, any more than the
string "[3, 4]" in source code does. After "i = 42" is compiled and
executed, though, i does denote an object, which in Python happens to be
both an immutable and attributeless object; its internal state is
precisely the integer whose value is 42. Because it's immutable you
can't *change* its state, but that doesn't mean it isn't there.
> I could call everything an 'object' (as is done in Scheme,
> a non OO language) but that doesn't really mean anything
> to me.
It's not all semantic games, Amit. Objects have consequences. E.g.,
the useless Python loop
i = 0
while i < 100000:
i = i + 1
is likely to run much slower under your Python interpreter than the
equivalent Java loop under your Java interpreter, mostly *because* ints
are objects in Python but not in Java. This isn't a necessary property
of either implementation, but in the absence of strong optimization it's
very likely to hold true. Adding static declarations to Python wouldn't
be enough to eliminate the "object overhead", either (hint: that's
exactly why ints are not objects in Java, even though Java *does* have
static type declarations; the non-objectness that appears in Java is an
efficiency gimmick).
> ... but I'm not convinced that using objects internally
> makes it an object externally, in the same sense that
> not using objects internally doesn't mean you can't
> have objects externally. :-)
Until you define what *you* mean by "makes it an object externally",
nobody can scratch your itch. Python and Java already defined what they
mean.
and-they-both-got-it-exactly-right<wink>-ly y'rs - tim
Guido van Rossum
Gordon McMillan:
> I was once lectured (by no less than Mr. Peter Van der Linden his
> self), that "Java always passes by value. If it's a primitive, it's
> the value of the primitive. If it's a reference, it's the value of
> the reference." (When I pointed out he was confusing the hell out of
> newbies, he found a different way to put it).
>
> But extending this same kind of over-generalization to Python, one
> could claim that Python always passes by reference, even for things
> like ints. If you pass a 3, you are NOT putting 0x03 on the stack. In
> Java, you are.
No -- in Python, you are passing everything by value too. You are
passing the value of the reference to the object. Parameter passing
for Python objects works exactly as for Java objects, but it is even
simpler because there are no non-objects in Python. In Python, 3 is
an object but it is still passed by value. Passing by reference
(i.e. pascal VAR parameters) would mean that the address of a
*variable* in the calling function were passed. Neither Java nor
Python ever does this.
What's confusing for the newbies in Python is that if you pass a list
or dictionary, the callee can modify it, while if you pass a number or
string, they can't. This is because they don't see the difference
between
a = a+1
which binds a new (reference) value to the name a, and
a.append(1)
which does not change the binding of the name a -- it modifies the
object that a references.
The fun thing is that *superficially* types like numbers behave like
call-by-value but types like lists behave like call-by-reference, just
like you generally want them to. But that's really just because the
latter are mutable and the former aren't -- not because the parameter
transfer mechanism or the assignment semantics are any different.
Somehow this really helps to make Python easy to learn and easy to use
-- you don't need to understand the precise semantics right away,
because things mostly behave according to common sense. But for some
people this makes them think that the semantics are similar to those
of another language they know, and by the time they find out that
that's not true, they have dug themselves so deeply in the wrong
semantic model that it's hard to help them out.
--Guido van Rossum (home page: http://www.python.org/~guido/)
Gordon McMillan
Guido -
> Gordon McMillan:
>
> > I was once lectured (by no less than Mr. Peter Van der Linden his
> > self), that "Java always passes by value. If it's a primitive, it's
> > the value of the primitive. If it's a reference, it's the value of
> > the reference." (When I pointed out he was confusing the hell out of
> > newbies, he found a different way to put it).
> >
> > But extending this same kind of over-generalization to Python, one
> > could claim that Python always passes by reference, even for things
> > like ints. If you pass a 3, you are NOT putting 0x03 on the stack. In
> > Java, you are.
>
> No -- in Python, you are passing everything by value too. You are
> passing the value of the reference to the object. Parameter passing
> for Python objects works exactly as for Java objects, but it is even
> simpler because there are no non-objects in Python. In Python, 3 is
> an object but it is still passed by value. Passing by reference
> (i.e. pascal VAR parameters) would mean that the address of a
> *variable* in the calling function were passed. Neither Java nor
> Python ever does this.
I knew this statement was technically incorrect when I wrote it (and
should have qualified it more). The problem with the correct
statement is that one first has to realize that the statements:
A a = new A(); //Java
a = A() #Python
do not yield objects "a" but object references "a". Once one has
that, one can work one's way thru the deceptively simple statement
that <language-x> "always passes by value".
Now, in the couple of Java 1.0 implementations that I managed to
break into, that "object reference" was, in fact, either a
pointer to the object, or a pointer to a smart pointer to the
object. And the fact that
foo(Object a) {
a = something_else;
...
}
didn't work "as expected" is really not surprising, snce it's
(pretending that Java isn't interpreted):
phony_underlying_foo(Java_object *a)
not
phony_underlying_foo(Java_object **a)
All of which really is to say that the terms "by value" and "by
reference" aren't really all that meaningful outside whichever
language you're talking about. So, when explaining to newbies, you
have to guess what they think those terms mean...
> But
> for some people this makes them think that the semantics are similar
> to those of another language they know, and by the time they find
> out that that's not true, they have dug themselves so deeply in the
> wrong semantic model that it's hard to help them out.
... and someone obviously had preconceptions about what "type" and
"object" should mean. Since he seemed to know Java, I was (clumsily)
trying to point out that what he'd find being passed in "foo(3)" is,
in fact, different between the 2 languages. But having put my foot in
it, I'll try to think of a better approach.
- Gordon
Edward C. Jones
Guido van Rossum wrote:
>
> What's confusing for the newbies in Python is that if you pass a list
> or dictionary, the callee can modify it, while if you pass a number or
> string, they can't. This is because they don't see the difference
> between
>
> a = a+1
>
> which binds a new (reference) value to the name a, and
>
> a.append(1)
The semantics of assignment was the most difficult problem I had
when I was a Python newbie.
I am not convinced that I understand it yet. Has this been very
carefully explained in the tutorial and the language reference
documents? No explanation of this can be presented in too
elementary a manner. I suggest the old teaching trick of
representing a location in memory as a open top box which
contains a value. The box has a label on it which is its address.
--------
|\ 3 |\
| --------
\ | |
\| 129|
--------
Memory location 129 contains the value 3.
Steve Odendahl
garry hodgson <garry-...@sage.att.com> wrote:
{Snipped to save space]
>on the other hand, the java compilers i've used (on pc, sun, and sgi)
>are abysmally slow. and its insistence on where i need to put my
>files, and when they'll be compiled, makes for some major headaches
>in group projects.
The java compiler I use on an NT box is the fastest (measured
subjectively) I've ever used for any language. This has encouraged
(for me) a development style that feels about 2/3 of the way along the
continuum from (for example) C++ to (for example) Python. (I hope you
will excuse me for metaphorically suggesting the difference between
the two is due to variance in a single real parameter.) I am not
proposing, however, to say if this is a Good Thing (at least not until
things cool off a little :-)
The second point is well taken.
>> I am confident that the Next Big Language will look like
>> one or the other of these two languages more than like C++, unless we
>> define "Big" by size of specification.
>by most measures, VB is the next Big Language, and we're all pissing in
>the wind.
>sigh.
>> That all said, Java *does* need generics. I appreciate, however, that
>> the designers are stopping to think something through rather than taking
>> Bjarney's approach of throwing in whatever occurs to him first.
>cheap shot.
>--
>Garry Hodgson Sometimes we ride on your horses
>ga...@sage.att.com Sometimes we walk alone
>Software Innovation Services Sometimes the songs that we hear
>AT&T Labs Are just songs of our own
Steve O.
Vunetix, Inc.
Guido van Rossum
[me]
> > What's confusing for the newbies in Python is that if you pass a list
> > or dictionary, the callee can modify it, while if you pass a number or
> > string, they can't. This is because they don't see the difference
> > between
> >
> > a = a+1
> >
> > which binds a new (reference) value to the name a, and
> >
> > a.append(1)
[Edward C Jones]
> The semantics of assignment was the most difficult problem I had
> when I was a Python newbie.
> I am not convinced that I understand it yet. Has this been very
> carefully explained in the tutorial and the language reference
> documents? No explanation of this can be presented in too
> elementary a manner. I suggest the old teaching trick of
> representing a location in memory as a open top box which
> contains a value. The box has a label on it which is its address.
>
> --------
> |\ 3 |\
> | --------
> \ | |
> \| 129|
> --------
>
> Memory location 129 contains the value 3.
Interesting challence. Let's see if I can still do ASCII art...
Example one (a bit expanded to show context):
a = 1
a = a + 2
Because Python is object-oriented, I'll have to invent some graphical
conventions. I'll represent a variable as a box with two
compartments: a name, and a pointer to an object. I'll represent the
object as a box with a value in it. After the first statement (a = 1)
we have:
+----------+ +-----+
| | | | |
| a | ------------>| 1 |
| | | | |
+----------+ +-----+
(Sorry, a 3D look is too much for my ASCII art abilities :-)
And after the second statement (a = a + 2) we might have:
+----------+ +-----+
| | | | |
| a | ---\ | 1 |
| | | \ | |
+----------+ \ +-----+
\
\ +-----+
\ | |
\-->| 3 |
| |
+-----+
(If there are no other references to the box containing the number 1,
it will actually be thrown away, so the space it occupies can be
reused for another box.)
And now for example two (also a bit expanded, to show context):
a = [1, 2, 3]
a.append(4)
After the first line (a = [1,2,3]) we have:
+----------+ +-----+-----+-----+
| | | | | | |
| a | ------------>| | | | | | |
| | | | | | | | | |
+----------+ +--|--+--|--+--|--+
| | |
v v v
+---+ +---+ +---+
| | | | | |
| 1 | | 2 | | 3 |
| | | | | |
+---+ +---+ +---+
(No, the integer boxes haven't shrunk -- they're just farther away :-)
And after the second line (a = [1,2,3]) we see:
+----------+ +-----+-----+-----+-----+
| | | | | | | |
| a | ------------>| | | | | | | | |
| | | | | | | | | | | |
+----------+ +--|--+--|--+--|--+--|--+
| | | |
v v v v
+---+ +---+ +---+ +---+
| | | | | | | |
| 1 | | 2 | | 3 | | 4 |
| | | | | | | |
+---+ +---+ +---+ +---+
See the difference? In the first example, the pointer from the "a"
variable binding (== "box with a name on it") was changed to point to
another object; in the second example, the pointer from a wasn't
changed, but the box that it points to was expanded.
An important concept that isn't really captured too well graphically:
some boxes are *immutable*, meaning that their contents can never
change. In the example this applies to the boxes representing
numbers. Other boxes are *mutable*, meaning that their contents is
allowed to change over their lifetime. This applies to the box
representing the list in the example. Whether a box is mutable or
immutable is a property of the box' type. For example, all numbers,
strings and tuples are immutable; lists and dictionaries are mutable.
If you liked this approach, I'll promise to do another one where I
explain what happens when you do things like
a = [1,2,3]
b = a
b.append(4) # Surprise: this affects a, too
Guido van Rossum
I should add that Programming Python by Mark Lutz, on pages 109-110,
has graphics similar to mine explaining the difference between
x.append(4) and x = x + [4].
Cameron Laird
In article <35091ADD...@technologist.com>,
Paul Prescod <papr...@technologist.com> wrote:
.
.
.
>common with C++ is superficial syntax and static type checking. Garbage
>collection and pointer safety make such a HUGE difference to how I code,
>10,000 lines of C++. Those two features essentially separate languages
>that belong in the early 70s from those designed for the next century.
.
.
So, Paul, have you tried any of the garbage-collecting
C++s? Do you run with Purify or Insure when you code
C++?
I agree that those stuck inside C/C++ typically don't
realize until afterward how much they invest in memory
management.
--
Cameron Laird http://starbase.neosoft.com/~claird/home.html
cla...@NeoSoft.com +1 713 996 8546 FAX
Cameron Laird
In article <Pine.A32.3.96.980313...@elvis.med.Virginia.EDU>,
Steven D. Majewski <sd...@virginia.edu> wrote:
.
[remarks too concise
to summarize]
.
.
> [ However, when I started to think about extending it to do a
> bit more, I quickly ran into limitations of Wish. ( I'm being
> specific by saying "Wish" -- this is not what the Tcl/Tk crowd
> would consider a limitation -- all I had to do was rebuild Wish
> with some extra extensions in C, but I was trying to see what I
> could do "out of the box". I needed a 'random' function to
> turn it into a game and this was not included in Wish. ) ]
.
.
Your general characterization of Tcl/Tk is apt.
In the particular case of "random", there have
been plenty of "pure Tcl" (no need for a C-coded
extension) implementations floating about for
years. The core Tcl distribution received a
rand() over a year ago. If you're working
with Wish8.0, it's in there.
Many people have trouble finding it, though,
for reasons that are characteristic of Tcl. Tcl
does arithmetic through its expr command. rand()
is a function which expr recognizes. This is
unfortunate, because people don't make the con-
nection that they have to look at the expr
documentation to learn about numerics. Also,
reliance on expr leaves Tclers writing
set y [expr $m * $x + $b]
where Pythonians assign
y = m * x + b
However, this is also an advantage, from the Tcl
perspective, because it means arithmetic is as
fully available for introspection as any other
operation in Tcl. It's easy, and common, to
tinker with expr to extend its functionality.
Doing so risks no contamination of other parts
of the language.
Paul Prescod
Guido van Rossum wrote:
>
> I should add that Programming Python by Mark Lutz, on pages 109-110,
> has graphics similar to mine explaining the difference between
> x.append(4) and x = x + [4].
This would all be easier to understand if number objects were mutable.
a=3
a.increment()
print a => "4"
b=3
print b => "4"
Forth allows you to change the definition of the variables named "1",
"2" and so forth. (my Forth terminology is poor...you get my meaning).
If Python allowed this it would appeal more to Forth programmers.
Paul Prescod - http://itrc.uwaterloo.ca/~papresco
"You have the wrong number."
"Eh? Isn't that the Odeon?"
"No, this is the Great Theater of Life. Admission is free, but the
taxation is mortal. You come when you can, and leave when you must. The
show is continuous. Good-night." -- Robertson Davies, "The Cunning Man"
Fredrik Lundh
>Forth allows you to change the definition of the variables named "1",
>"2" and so forth. (my Forth terminology is poor...you get my meaning).
So does Tcl... ;-)
Cheers /F
>From: someone
>Newsgroup: comp.lang.tcl
>Subject: BUG: tcl8.*, 10 as int and double, simpler test case
>
>Here is a simpler test case for the previously reported bug.
>No extension is needed and "for" loops are not involved.
>
>This script:
>
> puts [format {%d} [expr 10]]
> puts [format {%f} 10]
> puts [format {%d} [expr 10]]
>
>produces this error:
>
> 10
> 10.000000
> expected integer but got "10.0"
> while executing
> "format {%d} [expr 10]"
> (file "./bug.tcl" line 7)
>
>The problem is somehow caused by the Tcl_GetDoubleFromObj()
>which is used by "format {%f}"
Paul Prescod
garry hodgson wrote:
>
> i think you're right, my terminology was incorrect. i was referring
> primarily to the lack of generics.
I admit that this is a problem in Java. It's easy to work around,
however, and C++'s solution is so sub-optimal as to be (IMO) hardly
better than nothing at all.
Essentially you can do generic programming in Java in much the same way
you do in Python, but because of the static type checking you have to
insert many casts. Sometimes I actually want those casts (for safety)
and the Java code actually turns out to be more compact and readable
than the Python equivalent.
> i long ago stopped shooting myself in the foot, in c++, java or python.
Do you work on a team?
> > Plus, I learned the essentials of both Java and Python over two
> > weekends, whereas there are still nooks and crannies of C++ that I dare
> > not explore after programming in it for years. Java and Python share a
> > commitment to simplicity.
>
> i assume you made it a point to forget everything you knew about c++ and
> oo first, to make the experiment fair?
No. I didn't claim that I could learn Java or Python in a weekend with
no OO or C++ background. I claimed that *right now* I can program in
them more reliably despite having used them for a much shorter period.
Stefan Franke
On Sat, 14 Mar 1998 16:35:04 GMT, Guido van Rossum <gu...@CNRI.Reston.Va.US>
wrote:
[...]
>[Edward C Jones]
>> The semantics of assignment was the most difficult problem I had
>> when I was a Python newbie.
>> I am not convinced that I understand it yet. Has this been very
>> carefully explained in the tutorial and the language reference
>> documents? No explanation of this can be presented in too
>> elementary a manner. I suggest the old teaching trick of
>If you liked this approach, I'll promise to do another one where I
>explain what happens when you do things like
>
> a = [1,2,3]
> b = a
> b.append(4) # Surprise: this affects a, too
>
understand when I started with Python is that this assignment semantics
also applies to parameter passing and return values. In C++, assignment
and copying or initialising via constructor are different things (the latter is
implicitly used for parameter passing), and can be overloaded differently
(heaven or horror?). In Python, there is only these special kind of assignment -
binding a name to new values, of which some (the mutables) could be changed
afterwards using methods.
So, this has the same effect as the above example:
a = [1,2,3]
f(a) # Works like b = a to the formal parameter b in f
def f(b):
b.append(4) # Surprise: this affects a, too
You can't call this 'Call By Value', because [1,2,3] is not a unique value
inside the scope of f, neither 'Call By Reference', because the binding of a
couldn't be changed inside f. Rather it's just the prolongation of the binding
concept to formal parameters (hope my English is not too offroad here ;-).
Call By Reference/Value are concepts of a view, where names are abstractions
of fixed memory locations, this doesn't apply here any more.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
stefan franke email fra...@iti.informatik.tu-darmstadt.de
please remove the phrase "antispam." from my reply address
bitte den text "antispam." aus der antwortadresse entfernen
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Tim Peters
[Steven D. Majewski <sd...@virginia.edu>]
> ...
> And just in case, in my previous post, if I went too far
> in stressing the PROMISE of Java in the near future, vs.
> the reality of Python right now as a solution, I would
> also note that Java is, _right_now_, a more portable
> solution than C++. Most of the Java platform differences
> on different platforms.
That matches my experience, *provided that* you leave out the AWT
entirely. I have honest-to-god had fewer problems porting badly written
50,000-line Fortran packages across radically different architectures,
than I've had trying to get a 2,000-line non-trivial yet 100% Pure Java
1.1 AWT program to run even close to the same way (not to mention *at
all* -- still core dumps under Solaris) on two Pentium machines running
different yet up-to-date JVMs.
But leave out the AWT, and I confess I like Java a lot. Not as much as
Python, but more than C++. To me, Python is a cashew, Java is an
almond, and C++ is a soggy 5-pound peanut <wink>.
> On C++, the problem is more likely to be that the
> code just plain won't compile and link on another
> system. As the C++ standards have finally settled
> down and compilers are catching up, I expect this
> will not be a problem within the next year.
Ya, but will it run <0.5 wink>? I've completely given up trying to use
non-trivial static initializers in C++, and any use of templates that
doesn't fully resolve, in the header file, to trivial inline functions
or trivial inline redirections to methods of a void*-slinging base
class. The expertise needed to get this kind of stuff to run portably
at all is daunting; the expertise needed to get it running both portably
and *slickly* is conspicuous by absence (in practice -- it's easy to
find people who *say* they can do it <0.1 wink>).
thank-god-in-two-years-nt-will-be-the-only-os-left<wink>-ly y'rs - tim
Tim Peters
[Thomas <nou...@nohost.nodomain>]
> ... [stuff about ints in Python & Java] ...
> ... magic like this [auto-conversion between boxed
> and unboxed ints] is convenient for wizards but can
> have dire consequences for a mainstream language.
>> You won't find a similar restriction in Python.
> No, but I won't find unboxed integers either. For a
> scripting language, I can live without unboxed integers.
> For a general purpose programming language on
> standard workstations, I can't. Fortunately, with JPython
> and Java, I can have both, living happily side-by-side.
The original msg was an attempt to answer Amit's question about why we
say ints are objects in Python but not objects in Java. That's all I
was addressing. But because you know the answer to *that* one so
thoroughly, I suspect you decided the msg was really about something
*interesting* <wink>.
I made no claims about which way was better, although in fact I agree
that each language did what was best for *it*. However, given the level
of compiler expertise, and cash to pay for it <0.5 wink>, Java turned
out to attract, I'm not sure they really bought much by making the
boxed/unboxed distinction for the primitive types. I.e., the language
only needs to act "as if" the spec were telling the truth, and in most
common speed-or-space-critical situations, where "int" (etc) is declared
up-front and not hiding behind an Object pointer, a reasonably ambitious
optimizer can get rid of the box without the user being able to tell the
difference. E.g., there's almost never a case where a loop-local int
index variable needs to get wrapped in an object to fulfill the spec's
promise that it always *appears* to be so wrapped.
But there are many details that need to be worked out exactly right, and
if I were them I probably would have punted on that too at first. Then
again, I probably would have figured there were better uses for my time
than working out the tedious "definite assignment" rules too <0.6 wink>.
have-to-give-jpython-a-whirl-one-of-these-weekends!-ly y'rs - tim