Can Python replace Visual Basic? Should it?...and generalities : )

[Brad Bollenbach]

This reply is interesting, but still contains a lot of the "I've started
invistigating Python and these are the things I like about it" comments,
which I was hoping to avoid.

[snip]

>   A Python "OCX" control needs to be written.  This control
>   would simply encapsulate Python for us Visual Basic idiots.
>   This way we could 'pop in the control in our VB project and
>   start using Python for parts of the program.

That's a neat idea. I hope someone smarter than me decides to do it. :)

>   At first, this control could be non-visual.  The OCX would
>   have to expose through IDispatch the objects managed within
>   the embedded python system. Then, it  would be cool if it
>   became a wxWindows frame, so that small client areas could
>   be re-written in Python, etc.  For extra bonus points,
>   the visual control would allow OCX components to be dropped.
>
>   Eventually the VB programmer could 'drop the VB shell after
>   their entire program is re-written.  In the corporate world,
>   it will be damn near impossible to get funding for re-writing
>   a program in Python.  However, it is very possible to have
>   this conversion be INCREMENTAL, one sub-routine at a time!
>   In short, a complete re-write is just too high of risk for
>   most corporate progammers to do...

"Damn near impossible", but not "impossible". I know, because where I work,
we ARE almost done a complete rewrite of an app that was written in
Powerbuilder 4.x (the exact version, I'm not sure), now being completely
rewritten (with a totally new database) in Powerbuilder 6.5.1. To give you
an idea of the size of the app, there are 200+ stored procs behind it, and
about 30,000-40,000 lines of Powerscript code (but that's totally ballpark,
I'm just guessing). And with the dime-a-dozen comments that keep saying how
ridiculously simple Python is, you'd think that maybe we should have chosen
Python instead of a newer version of Powerbuilder?! Hmm...the more I think
about it, the more I think we chose the right tool for the job.

But then, as seems to be often the case, people seem to blur the
differentiation between "easy programming languages" and "easy programming
tasks". How many people have written 30,000 lines out of _any_ programming
language and still refer to it as being simple to work with?

As, you mentioned in a reply to the other thread of this thread (heh),
coding really is the most insignificant part of a large programming project
in a coporate environment. In theory at least, you should have a clear idea
of what you're going to do before you do it, in which case the coding
(almost irregardless of the language) is often times just grunt work.