VB to Python migration

[Josh]

Magnus Lycka 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.

For a little background, this is an ERP program. It looks after 
accounting, customer orders, purchase orders, inventory, production 
planning/scheduling, and product development. It is an industry specific 
program, designed for the mattress manufacturing industry.

I'm not sure how many screens could be cut out. On the accounting side 
of the program, there are a number that could be cut down I think. Right 
now, Accounts Recievable and Accounts Payable are each separate sets of 
screens. On a rewrite, we could make classes that are generalized for 
accounts and then inherit these and modify them based on whether it's a 
debit or credit account. This is mostly an educated guess since I don't 
have a full understanding of the accounting side.

Other parts of the program I'm not so sure about. With proper OOP, I'm 
sure some more screens could be cut out, or standardized using 
inheritance and such.

>> 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
> their thinking.
> 
>> 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
> reasonable aspect.

I think in some ways, going with Python rather than just moving to 
VB.NET comes from a desire to change the architecture of the program. 
Going to VB.NET, we would be tempted to run the code through the upgrade 
wizard and just get things working. We wouldn't be forced to change the 
underlying architecture, we could just stay with the status quo.

Moving to Python would make us sit back and take a closer look at how 
things are done and make taking shortcuts harder.

>> 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.

I understand what you are saying, and I'm sure the tasks our program 
does could be made much cleaner. But, implementing an ERP which is 
basically what we have, is a large project and the users need (or maybe 
just want) access to lots of information.

>> 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
> a benefit.


>>> The really silly thing to do is to apply VB idioms on Python.

I completely agree with this point. We want to get away from the way 
that VB makes us think and therefore program. It's hard to implement OOP 
in a language that won't support inheritance or polymorphism except 
through the outrageous contortions, and then not even do it properly.