Python less error-prone than Java

  • Thread starter Christoph Zwerschke
  • Start date
A

Alan Morgan

Ok, here the point was that Java has *explicit* static typing. SML is
not a procedural language and uses *implicit* static typing. Therefore
it shares some of the benefits of dynamically typed languages such as
Python. However, an SML version of the program would probably still have
the same bug as the Java version, right?


Java doesn't allow function overloading?

Brain fart. You said "function" and I read "operator".

Alan
 
C

Christoph Zwerschke

nikie said:
> Hm, then I probably didn't get your original point: I thought your
> argument was that a dynamically typed language was "safer" because it
> would choose the "right" type (in your example, an arbitrary-pecision
> integer) automatically.

No, my point was not to make a general statement. It just stumbled over
that example and said to myself "that wouldn't have happend with
Python." And I thought it might be interesting for people on c.l.p as
well. That was all.
> As you can see from the above sample, it
> sometimes picks the "wrong" type, too. Now you tell me that this
> doesn't count, because I should have told Python what type to use.

Yes. Python did not "pick" that type - you explicitely said that x
should an int by setting x = 10001.
> I mean, you could have told Java to used a 64-bit or arbitrary-length
> integer type instead of a 32-bit integer (which would actually be
> equivalent to the Python code), so it would do the same thing
> as the Python binary search implementation.

Right, but then Java would do all index operations in that type, even
for very small arrays when it's not necessary. That's why people
probably don't do it.
> The is OT, but what makes you think a C# decimal can't store 0.01?

A C# data type summary gave me the impression that it was just a more
accurate but still binary floating point type. But you're right, the
name "decimal" should have given me a clue that it uses base 10 ;-)

So sorry for the confusion. Forget what I wrote about float. I should
have corretly written that the equivalent to the C# statement

decimal x = 10001;

is the following Python statement

x = Decimal(10001)

If you do the equivalent thing, Python will give the same result as C#.
> All I wanted to point out is that bounded integers do have their
> advantages, because some people in this thread apparently have
> never stumbled over them.

Sure, I did not want to deny that. The main advantages are speed, and
dealing with hardware related issues. Your Distance function in C is of
course much faster than my Python implementation. Surely I wouldn't want
to write a device driver in Python.

-- Christoph
 
I

Ilpo =?iso-8859-1?Q?Nyyss=F6nen?=

Kaz Kylheku said:
Buggy library code is what prompted that article.

Yes, but it is an error type that happens very rarely still. And so it
seems that very few programs even notice that bug in that library.
Except when you feed those programs inputs which are converted to
integers which are then fed as domain values into some operation that
doesn't fit into the range type.

If the input value range is limited, you want to get an error, if out
of range value is given. If you want to handle unlimited values, you
really need to take a look that you can do it. Think for example
storing such value to a database.
... other than C and C++, where their equivalents just crash or stomp
over memory, but never mind; who uses those? ;)

It is not different. Your crash can tell you that it was a null
pointer. Your crash can tell you that you stomped over memory. You
just get the information about the error in different way.
Instead of this stupid idea of pointers or references having a null
value, you can make a null value which has its own type, and banish
null pointers.

Yes and I actually think that as bad thing. It is nice to be able to
tell the difference between null pointer and wrong type. Of course if
the error message tells you that you had null there, it is not a
problem, but what if you somehow lose the error message and get only
the exception class name? (Yes, you should always keep the message
too, but it does happen.)
 
?

=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=

Ilpo said:
Yes, but it is an error type that happens very rarely still. And so it
seems that very few programs even notice that bug in that library.

That's certainly the case. The bug went unnoticed in the Java library
for nearly a decade, despite Java being used fairly widely.

The OP's point is not that the bug might be "minor": the point is that
an algorithm who was studied hundreds of times in computer science
courses, repeated many times in the literature, and proven "correct"
many times, still is wrong, and that the error primarily arises from
using a type declaration.
If the input value range is limited, you want to get an error, if out
of range value is given. If you want to handle unlimited values, you
really need to take a look that you can do it. Think for example
storing such value to a database.

So the real design flaw in Java is that int addition doesn't raise
exceptions on overflow? That wouldn't have helped - the algorithm
still would have been wrong, and people still would have noticed
only when it happens (just as they get an exception now: array index
out of bounds)

Regards,
Martin
 
?

=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=

Christoph said:
Anyway, in Python, you would first define:

def wrap(x, at=1<<31):
if x < -at:
x += at*2
elif x >= at:
x -= at*2
return x

Then, the Python program would be as simple:

Distance = lambda t1,t0: wrap(t1-t0)

In Python 2.4 and later, you could write

def Distance(t1, t0, maxint=(1<<32)-1):
return (t1-t0) & maxint

Like your code, this also extends to 24-bit integers or 64-bit
integers.

Regards,
Martin
 
C

Christoph Zwerschke

Martin said:
In Python 2.4 and later, you could write

def Distance(t1, t0, maxint=(1<<32)-1):
return (t1-t0) & maxint

No, this function behaves differently. It never returns a negative
value. The only difference in Python 2.4 is that 1<<32 was 0 before.

-- Christoph
 
C

Christoph Zwerschke

Ilpo said:
It is not different. Your crash can tell you that it was a null
pointer. Your crash can tell you that you stomped over memory. You
just get the information about the error in different way.

Not all stomping over memory must result in a crash. You might just get
wrong results, and you don't notice it. Also, if you get such a crash
it's much harder to find out the reason. It may show off only later in a
different part of the program.

-- Chris
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,902
Latest member
Elena68X5

Latest Threads

Top