Python vs .Net

[Greg Brunet]

"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

    sResult = sName + nNumber
'==============

Then, if I have 'Option Strict On' the compiler will throw an error:
-------------
Option Strict On disallows implicit conversions from 'String' to
'Double'.
-------------

If I have 'Option Strict Off' then at Runtime, I'll get:
-------------
An unhandled exception of type 'System.InvalidCastException' occurred in
microsoft.visualbasic.dll
Additional information: Cast from string "foo" to type 'Double' is not
valid.
-------------

If I change the assignment statement to:
'==============
    sResult = sName & nNumber
'==============
Then VB performs the conversion for me with no complaints.  This is
actually what I used to do in my VB6 code, but I've now changed my style
to use Option Strict and specfically perform the casts in my code, like
this:

'==============
     sResult = sName + CStr(nNumber)
'==============

The net result of this is that the program does exactly what I think it
is going to do, and the compiler tells me if I haven't been clear enough
in my intentions.  This obviously extends to function call paremeters,
etc.

(BTW - if I want dynamic typing in VB, I can have that too.  Just make
all my variable definitions "Object", and viola, dynamic typing (along
with the need to write the appropriate run-time error-checking code to
handle all of the issues that I would otherwise address at compile time
<vbg>).

> You are wrong about needing to write LOTS more error checking code
> at your function entry points, though.  What you need to do is
> write LOTS of unit tests, and acceptance tests, to catch these
> problems before you release.  But you do that anyway (right? ;-) )
> since the minimal checking your VB.NET compiler does cannot possibly
> catch the majority of problems in your code...

Well - it's confession time about my dirty little secret - no I don't
write all the unit tests and acceptance tests that I probably should in
order to catch all the problems in the applications I write - 1000
lashes with a wet noodle for me.  However, I don't see the need to
increase the amount these tests in order to catch stuff that the
compiler can otherwise find for me (when statically typed).  Also, I (1)
wonder how many folks really do this to the necessary degree in the all
of their apps (I haven't seen this kind or degree in test code in the
Python code that I've reviewed so far, and (2) unit testing something
for different conditions DOES NOT relieve you of the need to add error
checking code, and I have seen virtually none of the error checking code
I would expect in the stuff I've reviewed.  Does all your code check to
make sure that you are passed an integer instead of a float or a string?

Even better - in VB, I can do stuff like:
'==============
    Public Enum eUserLevel
        UserNone = 0
        UserEntry = 1
        UserReview = 2
        UserBilling = 3
        UserLayout = 4
        UserAdmin = 5
    End Enum

    Private Function Login(ByVal sName as string, ByVal sPassword as
string, ByVal UserLevel As eUserLevel) As Boolean
:
'==============

and it will do even tighter checking for me - that it is passed a
UserLevel instead of just a plain Integer.  This helps not only catches
incorrect function calls at compile time - it also helps document what's
happening in the code itself.  Now I'm not holding my breath waiting for
Guido to make Python a statically typed language (even optionally), but
I still don't get why dynamic typing is 'a good thing'.

I sometimes can't believe that I'm actually using Basic (cough, snort,
gag) to develop apps with, but I think that over the years, VB has
become a pretty decent tool.  Do I think that Python holds even more
promise, especially with its cross platform support? Yes - which is why
I'm looking at it.  But do I buy into the argument that all aspects of
it - particularly dynamic typing - are superior - no - at least not yet.

--
Greg