<brueckd at tbye.com> writes:
> On 31 Jul 2001, Christopher Barber wrote:
>
> > > On 30 Jul 2001, Christopher Barber wrote:
> > > > This is a bad example because the code is doing runtime, not
> > > > compile-time checking. I was talking about the advantages of
> > > > compile-time checking.
> > >
> > > ?? Please review the example - that's compile-time checking there.
> >
> > No it isn't! The (Integer) cast is not performed until run-time.
>
> Thank goodness! I'll just remove that there and ... doh! it won't even
> compile anymore. Hmm... there's actually a little of both there,
> compile-time _and_ runtime checking.
Yes, but the actual type error that we are interested in here is that the
program needed an integer but got a string instead. That particular type
error is not detected until runtime in the Java example you provided and that
is why it is not a relevant example. You are absolutely correct that using
statically typing does not ensure that all type errors will be detected at
compile time, but it does catch many.
> > > > Here is how this would be written in Curl:
> > > >
> > > > let v:{Array-of String} = {new {Array-of String}}
> > > > let s:String = "hi"
> > > > {v.append s}
> > > > let i:int = v[0] || ERROR: can't assign a String to an int
> > >
> > > But what benefit have I gained?
> >
> > You have detected a bug at compile-time instead of run-time and you didn't
> > have to write a unit-test to find it.
>
> Take off your Curl glasses for just a moment and think Pythonically - that
> is an error only because of the language-specific constraints - in Python
> it's neither an error nor a problem.
I used Curl as an example, not only because I know it well but because I know
that what could be done in Curl could also be added to Python.
As to the error, this would indeed be an error in Python as well but it would
happen later in the program when some code tries to use 'i' as an integer
instead of a string.
> Don't you think that it's possible that Python is
> taking care of many of the type-related problems for you?
Sure. By providing consistent dynamic typing and disallowing unsafe casts it
can be considered superior to C/C++
> > The language does not force you to specify types, this would also be legal,
> > but you would not see the problem until you actually executed the code:
>
> Again, it's a problem _created_ by the constraints of the language, and/or
> the division of labor between the language and the programmer. It doesn't
> apply here (since we're supposedly exploring the weaknesses that _Python_
> has without strict compile-time type checking.
I don't see why it doesn't apply. If I am forced to do more work because
Python doesn't do it for me, then why can't I consider that to be a weakness
in the language?
> > > The fact that the compiler can detect my breakage of the
> > > language-specific rules doesn't really advance the notion that
> > > strict compile-time checking is beneficial.
> >
> > Sure it does. You might not believe that it is worth the trouble, but it
> > clearly has some benefits.
>
> And those benefits are? I'm still waiting for anyone to be specific about
> these benefits.
Then you are not paying attention.
1) Static type declarations allow the compiler to catch some type errors
that would not otherwise be detected until run-time. There is no
question about this fact. You might not think the benefit is significant
enough to be worthwhile, but that is a different issue.
2) Static type declarations allow the programmer to clearly express
their intent. In this role they are only a shade better than comments.
3) Compile time type information is necessary to generate fast code. It
must either come from type declarations or must be inferred. Inferring
types in the absence of any static type declarations is difficult and
requires analysis of the entire program; this analysis is at best
O(n log n) but is more likely to be O(n^2) -- in other words it could
become too expensive for large programs.
> A few people have asserted that big Python programs would be unmanageable
> without this compile-time checking, but it seemed like they were speaking
> from other-language, and not Python, experience.
I was not one of those people. I have worked on a large project using almost
300k lines of Tcl code (a truly horrendous language) so I am quite sure that a
Python project of this side would be feasible. However, I would have concerns
about the performance and testability of such a large Python application.
> Python's features and overall simplicity tend to eliminate or
> significantly reduce whole classes of problems, including many
> type-related problems. _Some_ strictly-,statically-typed languages
> introduce artifical complexities that cause more problems than they
> solve.
I agree with this.
> > > What is a real world problem that would not have existed if Python had
> > > strict compile-time checking, and how common is such a problem?
> >
> > Here is a real-world problem: a developer wants to use a language with
> > compile-time type checking and rejects Python because it doesn't have it.
>
> This is pretty consistent with the whole body of arguments we've heard so
> far: this feature is beneficial in other languages, so if Python doesn't
> have it, Python is obviously lacking. To me that reasoning ignores the
> fact that maybe, just maybe, there exists more than one solution to the
> problem.
No, I was just trying to make a point that the Python audience is smaller than
it might otherwise be.
> As languages evolve we generally find it a bargain to exchange a little
> CPU for features that relieve developers of work and at the same time
> eliminate developers' bugs. By moving from assembly to C the number of
> bugs per _assembly_ line of code dropped dramatically. Is it too much to
> imagine that the same does not hold true when moving on up the language
> scale?
Not at all. The question is how many cycles are you willing to spend and when
are you willing to spend them (e.g. compile-time vs. run-time).
> > I actually used Python on a number of projects a couple of years ago and
> > did spend more time than I would have liked writing tests to detect type
> > consistency.
>
> Wonderful! Can you please post some examples? Was this proactive testing
> or was it triggered by problems you were seeing? If was the result of
> problems, what were they?
That was a couple of jobs ago and I don't have access to that code anymore.
One problem I remember having was that I was writing library code and had to
write explicit run-time type-checking code to check the types of incoming
arguments. It was not difficult to do, but it was extremely tedious. If I
could even have had the ability to put type declarations in function
signatures and have Python generate the run-time type checks I would have been
much happier.
I also found that I had to write longer unit tests for my Python code than for
my C++ code.
I am sorry that I cannot be more specific.
BTW, is there a code coverage measurement tool for Python yet?
- Christopher