Python vs .Net

Bjorn Pettersen BPettersen at NAREX.com
Mon Jan 6 19:42:21 CET 2003


> From: Greg Brunet [mailto:gbrunet at nospamsempersoft.com] 
> 
> "Peter Hansen" <peter at engcorp.com> wrote in message 
> news:3E197F7C.D4549EC5 at engcorp.com...
> > Greg Brunet wrote:
> > >
> > > - VB.NET (as well as C##) are/can be very strongly statically
> > > typed - even more so than VB6.  I'm still trying to determine 
> > > if I like a strongly _dynamically_ typed language like Python.  
> > > I'm having a hard time understanding why it's not better to 
> > > know at compile time that ['foo' + 5] is an exception.  
> > > If I have to wait until runtime, then I
> > > would think that I need to be writing LOTS more error 
> > > checking code at all my function entry points, whereas with 
> > > strong static typing, I can catch all this at compile time.
> >
> > While the specific example you quote, where two statically defined
> > *constants* are being added, *could* be caught by the compiler, it's

> > pretty rare to be doing that anyway.  More likely you would 
> > be doing something like ['foo' + bar] where bar is bound to the 5. 
> > That would not be catchable until runtime, by definition.
> 
> Actually, it is catchable at compile time with a statically 
> typed lanugage.  If I have: '============== Dim sName as 
> String Dim nNumber as Integer Dim sResult as String

I think you're missing the point of dynamic typing. In a dynamically
typed language I can write a function, add, like:

  def add(a,b):
      return a + b

the result is to create a function that can operate on _any_ type of
objects that support the '+' operator. There is usually a strong urge
from programmers coming from statically typed languages to want to add
type information to this function or add run-time checks to ensure
they're only passed the right kind of data. In a dynamically typed
language this is at best counter productive and at worst simply wrong.
The problem, in my opinion, is that these programmers can't write such a
function in the languages they know so they're not thinking of problem
solving in terms of generic functions. (Languages with advanced type
systems, mostly functional langages, can determine the most generic type
for these functions although I wouldn't expect many C++ programmers to
know that <wink>).

This, I think, is one of the key points of Python. You don't write
generic functions because you're sloppy and don't care about the quality
of your input parameters, you write generic functions because they're
the most flexible way of designing a solution. When you're learning a
new language you're always much better off trying to embrace it and
develop solutions in terms of idiomatic usage rather than trying to
shoehorn your existing programming habits onto a language that doesn't
support it. When you have a good grasp of thinking in the new language
you'll be better able to judge the relative merits of the different
paradigms. (Of course, there are always the group of programmers that
can write Fortran in any language <wink>).

-- bjorn





More information about the Python-list mailing list