VB to Python migration
lycka at carmen.se
Mon Jan 30 10:50:44 EST 2006
Ravi Teja wrote:
> Rewrites are always good and result in smaller code base if features
> are not added. However, I doubt that will make the screens fewer. Lines
> of code? Certainly.
That depends on whether you just refactor the implementation
of if you look at the problem domain with a different perspective
than you had the first time around. Obviously, I don't know anything
about this particular system, but with 230 screen it seems like
some things could be generalized. I suspect a much smaller number
of slightly context sensitive screens would suffice... My gut
tells me that if I looked at the system, I'd find lots of screens
that were basically the same, just slightly different... Whether
to use the same actual screen and perhaps let it be modified in runtime
due to some data driven approach or share most code in base classes
and have small modules with the specialized behaviour is something
to argue about in some design meetings. I'll leave that to the guys
who have to do it.
> You are comparing Python with VB 6. That's not what the OP is moving to
> as an alternative.
No, but it's what they've used and know. It's the reference for
> It's .NET. VB 6 has been out of development since 8
> years? Its not something to be compared to anymore. .NET on the other
> hand has all the advantages of Python accessible toolkits for this task
> and then some.
But as indicated by the OP, there might be reasons not to
sit down in that warm and soft lap from Redmond once more...
I assume they don't consider Python as a chance to avoid having
to really understand OO, or to be able to stay with the current
code base. Avoiding vendor lock-in is a very reasonable aspect,
and making it easier to port to non-windows platforms is also a
> I am not saying Python is unfit for 230 screens. Just that I have not
> seen anyone build such a thing and better write about it.
Right, and this is interesting. After about 25 years of
programming I'm still not sure whether I should be impressed
or worried when I hear people describing systems with
hundreds of screens and hundreds of database tables.
I've worked with systems like that, and while I'm sure there
are situations where such big systems are really warranted,
the systems of this size that I saw could probably have been
shrunk to a quarter of their size if proper software development
practices had been used.
> People on the
> other hand have build web sites with such volume. Result? We have a ton
> of web application frameworks to address such needs.
I'm not 100% sure that the plethora of Python web kits is entirely
>>The really silly thing to do is to apply VB idioms on Python.
> It is. But that's what people do on their first few projects and it's
> perfectly natural. Didn't you :-) ?
No, I had used Python for years the first time I had to code VB.
I'm sure I wrote stupid code, but most of my awkward programming
experiences have been when I had to code Perl or VB6 after long
periods when I had only written Python and C++.
More information about the Python-list