dynamic typing questions

J

Jason Tesser

I work for at a college where I am one of 2 full-time
developers and we are looking to program a new
software package fro the campus. This is a huge
project as it will include everything from
registration to
business office. We are considering useing Java or
Python. I for one don't like Java because I feel the
GUI is clunky. I also think that we could produce
quality programs faster in Python.

The other programmer here is very concerned about
dynamic typing though in Python. He feels like this
would be too much of a hinderance on us and too easy
for us to make a mistake and not catch it until
runtime making debugging harder.

OK what are your guys thoughts here? How have you all
overcome the lack of static typing? Is Python a
bad decision here? By the way we will be using
Postgres in the back if that matters to anyone.
 
G

Gustavo Campanelli

Jason said:
OK what are your guys thoughts here? How have you all
overcome the lack of static typing? Is Python a
bad decision here? By the way we will be using
Postgres in the back if that matters to anyone.

I have no problems with dynamic typing, but it seems that this comes as
a big problem to you. My advice, since you are two, is that you agree on
something that makes your life easier in the future, like to keep a
record of every declared variable, or that you agree on a naming policy,
like starting every int name with i (icounter) and every float with f
(fmeasure) while you get used to the dynamic typing. This way you'll
have an easier time catching and, more important, avoiding the errors.

But I think that once you get used to Python and it style, you won't
miss static typing at all.

Gedece
 
J

JCM

Jason Tesser said:
The other programmer here is very concerned about
dynamic typing though in Python. He feels like this
would be too much of a hinderance on us and too easy
for us to make a mistake and not catch it until
runtime making debugging harder.

I come from a mixed background and have worked on projects in both
statically and dynamically-typed languages. My only strong advice is
to avoid weakly-typed languages like C, so it's good to not hear you
asking about that one :)

It's true some errors which could have been caught at compile-time by
statically typed languages will not be caught until runtime in Python.
But the decreased development time you'll enjoy partly makes up for
this. To fully make up for it I suggest (as I'm sure will others)
robust unit-testing. Also, adding an occasional "assert type(x) ==
expected_type" might be helpful.
 
J

John Roth

Jason Tesser said:
I work for at a college where I am one of 2 full-time
developers and we are looking to program a new
software package fro the campus. This is a huge
project as it will include everything from
registration to
business office. We are considering useing Java or
Python. I for one don't like Java because I feel the
GUI is clunky. I also think that we could produce
quality programs faster in Python.

The other programmer here is very concerned about
dynamic typing though in Python. He feels like this
would be too much of a hinderance on us and too easy
for us to make a mistake and not catch it until
runtime making debugging harder.

OK what are your guys thoughts here? How have you all
overcome the lack of static typing? Is Python a
bad decision here? By the way we will be using
Postgres in the back if that matters to anyone.

Look into Test Driven Development (see Kent
Beck's book by that title.) As Jason says, unit testing
will pretty much eliminate any advantages of static typing,
leaving only the disadvantages.

Also, pervasive testing has so many other advantages
that I'm beginning to think that debuggers were the
single worst invention in history.

John Roth
 
D

Daniel Ehrenberg

Jason Tesser said:
I work for at a college where I am one of 2 full-time
developers and we are looking to program a new
software package fro the campus. This is a huge
project as it will include everything from
registration to
business office. We are considering useing Java or
Python. I for one don't like Java because I feel the
GUI is clunky. I also think that we could produce
quality programs faster in Python.

The other programmer here is very concerned about
dynamic typing though in Python. He feels like this
would be too much of a hinderance on us and too easy
for us to make a mistake and not catch it until
runtime making debugging harder.

OK what are your guys thoughts here? How have you all
overcome the lack of static typing? Is Python a
bad decision here? By the way we will be using
Postgres in the back if that matters to anyone.

Dynamic typing is usually considered an *advantage* of Python, not a
disadvantage. Usually, if you're keeping track of what the variables
mean, you can use them usefully without errors. The thing about
dynamic typing is that functions are more flexible, making something
that would cause an error in Java not cause one in Python. So even if
the error would be caught in Java, it would run fine in Python. the
distinction between certain types (such as number types) is weak in
Python, making everything more flexible, but it is still strongly
typed where appropriate (eg. numbers and strings). If you still need
something to make sure types are used correctly, try PyChecker.
Sometimes (rarely), it gives an error for type use when it would run
well, but it catches everything.

Daniel Ehrenberg
 
R

Rene Pijlman

John Roth:
I'm beginning to think that debuggers were the single worst invention in history.

Atomic bomb, MS-DOS, daylight saving time, C, ... are you sure?
 
S

Shalabh Chaturvedi

Jason Tesser wrote (relevant excerpts only):
We are considering useing Java or
Python.
The other programmer here is very concerned about
dynamic typing though in Python. He feels like this
would be too much of a hinderance on us and too easy
for us to make a mistake and not catch it until
runtime making debugging harder.

OK what are your guys thoughts here? How have you all
overcome the lack of static typing?

IMHO, the impediments introduced by static typing are not worth the benefit
of catching type errors at compile time. Further, you still have to do
testing to find other bugs.

The increased productivity due to dynamic typing in Python allows for more
testing time to catch _all_ errors (type or otherwise). Development +
testing time for a Python program usually turns out to be much less than
just development time for an equivalent Java program (for me, at least). An
interesting read is Guido van Rossum's interview at
http://artima.com/intv/strongweak.html

Also note that even in Java, static typing does not achieve much in many
cases (except requiring more keyboard typing), as illustrated in the
following example:

// myVector is a java.util.Vector, index is an int

String myStr = (String) myVector.get(index);

If the object in the vector is not a String, it is only at run time that the
error will be caught.

Admittedly, static typing allows the compiler to produce faster programs.
But the question isn't if it is fast. The question is if it is fast enough.
 
C

Carl Banks

Jason said:
OK what are your guys thoughts here? How have you all
overcome the lack of static typing? Is Python a
bad decision here? By the way we will be using
Postgres in the back if that matters to anyone.


Maybe try the confrontational approach, if all else fails:

Acknowledge that static typing is "cute." Then mercillessly press him
on how often it really helps, and how much time does it save relative
to Python.

Whenever he cites an advantage of static typing, ask him how often it
really helps. How often does the compiler really catch that, and is
this really something that Python won't catch at runtime?

If he cites the ability of the compiler to catch incorrectly passed
arguments, point out that Python can still catch these at run time,
probably as well as Java could. Remind him that static typing can
catch these only if the incorrect argument happens to have a different
type: static typing is a swiss cheese protection mechanism.

If he cites the ability to catch spelling errors: first point out that
that's unrelated to static typing. Some statically-typed languages
have this problem (Fortran). And a dynamically-typed language can
require declarations. But, even though Python doesn't, it's not that
serious a problem in Python. Unlike a certain other dynamically typed
(I guess) language beginning with P, variables just don't pop out of
nowhere if you just use them. So the only time Python can't catch a
spelling error is when it's on the left side of an assignment (or
imported, or whatever). If he says that's still worse than Java,
concede it. It's true after all. Then ask him how often that
happens, and how much time he thinks that will save compered to
Python.

If he says that compiler errors are easier to locate than runtime
errors, point out that Python, like Java, has a very good exception
handling mechanism that identifies the locus of errors. While you're
at it, ask him whether debugging run time errors was ever that bad.
After all, Java has those, too.


At the same time, pimp the advantages of dynamic typing.

Ask him if he's ever written a class, a union, or done some other
silly thing to define a variable that can have a "special" value.
Remind him that this isn't necessay in Python, thanks to dynamic
typing. (Incidentally, this happens to me a lot.)

Ask him how many times he's defined some ridiculous class hierarchy to
get some pathetic, contrived imitation of polymorphism. Point out
that, in Python, this isn't necessary. Things don't have to be
subclasses to be polymorphic. Subclasses can be used for what they
were intended for: inheritance.

Ask him how often he uses type casting (which should be a lot, since
he prefers Java). Remind him that every time he uses type casts he
defeats the point of static typing, and has to go though more effort
to do so.

Ask him if he's ever gotten a Runtime error in Java for a type casting
error. If no, or not often, ask him why he expects this so much in
Python. If yes, ask him if he felt annoyed that the Java compiler
wasn't able catch it for him, or happy that Java's runtime was up to
the task.


I believe there is very little practical advantage of static typing.
Most of the advantages are small, cute little things, but not things
that won't still be caught at runtime by Python. The wrong type is
almost certain to be caught by Python sooner or later.

And, in the end, I really don't think type mismatch errors are very
common (compared to other types of error).


Finally, if you still end up using Java, count your blessings. Java
is not that bad. You could be using C++ or Visual Basic.
 
A

Alexander Schmolck

John Roth said:
Also, pervasive testing has so many other advantages
that I'm beginning to think that debuggers were the
single worst invention in history.

Pervasive testing is much easier in an interactive enviroment with a good
debugger.

'as
 
J

John Roth

Alexander Schmolck said:
Pervasive testing is much easier in an interactive enviroment with a good
debugger.

It's much easier if you automate your tests, you write them
first and you write the code for each one as you write the test.

Then you don't need the debugger. Usually.

John Roth
 
D

Daniel Klein

If you believe that dynamic typing is a mistake then I have a bridge
in London to sell you. ;-)

Daniel Klein
 
A

Alexander Schmolck

John Roth said:
It's much easier if you automate your tests, you write them
first and you write the code for each one as you write the test.

Then you don't need the debugger.

Needs are relative. Does one need hot water?

Usually I *do* make use of the debugger during such test development with
`unittest`. I typically use something along the following lines::

import unittest
class PermeableTestCase2(unittest.TestCase, object):
def __call__(self, result=None):
if result is None: result = self.defaultTestResult()
result.startTest(self)
testMethod = getattr(self, self._TestCase__testMethodName)
self.setUp()
testMethod()
result.addSuccess(self)
self.tearDown()
result.stopTest(self)

TestCase = PermeableTestCase2
#TestCase = unittest.TestCase

class FooTest(TestCase): ...

When a test fails (assuming I'm running emacs/ipython with ``@pdb on``) this
will automatically visit the file and line where the test fails in emacs and
throw me into the debugger in ipython so that I can easily see *why* the test
fails (by examinging the local variables, typing in expressions to try out
things, going up and down the stack (which will automatically visit the right
files and locations in emacs) etc.).

I find that this makes any development of tests (whether ''test-driven'' or
not) much more pleasant and the development of tests that contain loops and/or
complex/random state bearable.

If you think that you develop your tests more effectively by not using
something like the above, I'd be really curious to hear details.


'as

BTW: Does anyone have an authorative opinion whether it is possible to fake
resumable exceptions in python/pdb? My biggest current python programming
annoyance is that I'm not able to manually fix things and continue if a
program dies after churning away for a couple of hours because of a bad format
string (Who said static typing didn't have *any* advantages)?
 
J

John Roth

Alexander Schmolck said:
When a test fails (assuming I'm running emacs/ipython with ``@pdb on``) this
will automatically visit the file and line where the test fails in emacs and
throw me into the debugger in ipython so that I can easily see *why* the test
fails (by examinging the local variables, typing in expressions to try out
things, going up and down the stack (which will automatically visit the right
files and locations in emacs) etc.).

I find that this makes any development of tests (whether ''test-driven'' or
not) much more pleasant and the development of tests that contain loops and/or
complex/random state bearable.

If you think that you develop your tests more effectively by not using
something like the above, I'd be really curious to hear details.

All I can say is that I use what I presume is the now-standard TDD
methodology: take real small steps so that there is no question about
what code caused the problem, and keep the code so simple that
it's not generally a problem to figure out what happened if a test does
fail.

The dogma is that if you're writing more than a dozen lines (and five
or six is average) for a failing test, then you're moving in steps that
are way too big. When I take bigger steps, I find I pay for it.
The time spent debugging is definitely super-linear in the number of
lines written between runs of the test suite.

And of course it's wise to keep your eye on the code coverage
metric.

John Roth
 
T

Terry Reedy

message
The other programmer here is very concerned about
dynamic typing though in Python. He feels like this
would be too much of a hinderance on us and too easy
for us to make a mistake and not catch it until
runtime making debugging harder.

One problem with static typing is that the type
you want is too often not one of the types you
have immediately available. It may be a subset or
union thereof. If log(-1.0) passes the compiler,
then you get a runtime crash that is at most as
graceful as Python's default traceback. If log(1)
does not pass the compiler (if it does not
autocast to float), then you are delayed until you
stick in the 'missing' decimal point.

The corresponding advantage of Python's dymanic
typing is that functions are generic; they work
with any data that works and is not specifically
excluded. C preprocessor text macros such as
(untested, written from years ago memory)

#define max(a,b) ((a) > (b) ? (a) : (b)) /* beware
of double side-effects */

that implement generic pseudofunctions testify to
the usefulness of this.

Terry J. Reedy
 
D

Dennis Lee Bieber

Daniel Klein fed this fish to the penguins on Saturday 20 December 2003
20:51 pm:
If you believe that dynamic typing is a mistake then I have a bridge
in London to sell you. ;-)
London Bridge has already been sold -- as I recall, it was marked,
dismantled, and shipped to some place in the south west US for
reassembly.

Tower Bridge, OTOH, is still there (and is the bridge most tourists
really mean by what they think is London Bridge).

--
 
D

Dave Benjamin

Daniel Klein fed this fish to the penguins on Saturday 20 December 2003
20:51 pm:

London Bridge has already been sold -- as I recall, it was marked,
dismantled, and shipped to some place in the south west US for
reassembly.

Lake Havasu City, Arizona. ;)

Dave
Phoenix, AZ
 
D

Dave Benjamin

The dogma is that if you're writing more than a dozen lines (and five
or six is average) for a failing test, then you're moving in steps that
are way too big. When I take bigger steps, I find I pay for it.
The time spent debugging is definitely super-linear in the number of
lines written between runs of the test suite.

It's more enjoyable all around to keep the tests and implentations small.

I've just barely attempted to pull off the TDD thing, but I was impressed at
the simple tests and short functions that came out of it. Everything felt
very orthogonal, and the code was easier to incorporate into a larger
program later on. I'm not totally sold on it yet (probably because I'm lazy)
but i'm impressed so far.

Part of why I think this happened is that simple tests trigger my laziness;
I don't want to have to write a lot of code just to do a little thing, and
that raises my standard for the straigtforwardness and ease-of-use I expect
in an interface. I become more user-centric.

I also think that the "refactor mercilessly" approach pushes a design toward
simpler, smaller, and more reusable units of code.

BTW, I had a hunch, and just as I expected, you're the guy that tipped me
off about TDD back in April. Thanks for that. =)

http://groups.google.com/[email protected]#link2

Peace,
Dave
 
D

Dennis Lee Bieber

Dave Benjamin fed this fish to the penguins on Wednesday 24 December
2003 00:26 am:

Lake Havasu City, Arizona. ;)
Next to lots of beach front property, I take it <G>

--
 
D

Dave Benjamin

Dave Benjamin fed this fish to the penguins on Wednesday 24 December
2003 00:26 am:
Next to lots of beach front property, I take it <G>

Yes, sir, we'd like the lake installed over here, please...
 

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,789
Messages
2,569,634
Members
45,342
Latest member
Sicuro

Latest Threads

Top