VB to Python migration

[Josh]

We have a program written in VB6 (over 100,000 lines of code and 230 UI
screens) that we want to get out of VB and into a better language. The
program is over 10 years old and has already been ported from VB3 to
VB6, a job which took over two years. We would like to port it to
Python, but we need to continue to offer upgrades and fixes to the
current VB6 version. Does anybody know of ways we could go about
rewriting this, one screen at a time, in Python, and calling the screens
from the existing program?

We are also looking for a graphics toolkit to use. IronPython with it's
..NET bindings and ability to integrate with Visual Studio looks good,
but leaves that bad MS taste in the mouth.

We currently use a MS Access back end and need to migrate to a proper
SQL server. We need to leave options open for SQL Server (for customers
who want to use existing infrastructure) and something like MySQL or
PostgreSQL. But in the mean time, we need to be able to access an
MSAccess (Jet) database from Python.

Any answers/suggestions/pointers are greatly appreciated.

Thanks,

Josh Isted

 

[Nicolas Kassis]

We have a program written in VB6 (over 100,000 lines of code and
230 UI screens) that we want to get out of VB and into a better
language. The program is over 10 years old and has already been
ported from VB3 to VB6, a job which took over two years. We would
like to port it to Python, but we need to continue to offer
upgrades and fixes to the current VB6 version. Does anybody know of
ways we could go about rewriting this, one screen at a time, in
Python, and calling the screens from the existing program?

We are also looking for a graphics toolkit to use. IronPython with
it's .NET bindings and ability to integrate with Visual Studio
looks good, but leaves that bad MS taste in the mouth.

We currently use a MS Access back end and need to migrate to a
proper SQL server. We need to leave options open for SQL Server
(for customers who want to use existing infrastructure) and
something like MySQL or PostgreSQL. But in the mean time, we need
to be able to access an MSAccess (Jet) database from Python.

Any answers/suggestions/pointers are greatly appreciated.

Thanks,

Josh Isted

For the Database, you should use the SQLObject(sqlobject.org) module.

Nic

 

[Ravi Teja]

230 UI screens is a lot. An app of that nature is not something people
commonly do in Python (although I would be happy to see people show me
wrong). You are building a GUI app that likely need not run anywhere
except on Windows and perhaps most what of what is does is edit and
report on data from the database. This is the very task 4GL tools like
Visual Basic were created for.

VB6 has certainly been outdated for quite a while ago now and you
should probably make the switch but don't discount the tools that
exactly specialize in this domain such as Visual Studio.NET and Delphi.
Python is a great general purpose language but the above tools are
leaps and bounds ahead of the tools available to Python in this very
specific domain. Additionally your team already is familiar with the
RAD paradigm. As easy as Python is, it takes a while to develop
expertise in a new language and it's paradigms (especially when it is
such a leap - VB and Python are almost at the opposite ends of the
spectrum).

IronPython has a lot of promise but is not mature enough yet to bet a
project large enough to take 2 years (or more) to develop. At that
project size, it is not sane to attempt anything adventurous unless you
have have enough funds to buffer when things go wrong. I am not
recommending against Python, just to plan VERY VERY carefully on what
you embark on.

Start using Python gradually in your development. Refactor some
functionality into COM components for starters to simplify your VB
code. When Python is doing much of the heavy lifting, you are ready to
make the change. By the time you are ready to make the full switch, you
will know.

Personally, for a project like this, I would go with Borland Studio (it
has ECO which is a tremenduous advantage for data driven GUIs) and
supplement it with Boo (a Python like language for .NET).

 

[Steven D'Aprano]

We have a program written in VB6 (over 100,000 lines of code and 230 UI
screens) that we want to get out of VB and into a better language. The
program is over 10 years old and has already been ported from VB3 to
VB6, a job which took over two years. We would like to port it to
Python, but we need to continue to offer upgrades and fixes to the
current VB6 version. Does anybody know of ways we could go about
rewriting this, one screen at a time, in Python, and calling the screens
from the existing program?

I know little about VB, but if it can call external programs, then it
should be able to call a Python program from the command line.

[snip]

Any answers/suggestions/pointers are greatly appreciated.

I suggest you hire a couple of experienced Python developers, pick half a
dozen screens, say three simple screens and three complex ones, and build
them in Python. That will give you an idea of how much work is involved.
Don't get your VB developers to try to port it themselves, that's a recipe
for disaster: they will be trying to learn Python, and will end up writing
VB code in Python, which is sure to be slow, inefficient, bulky and buggy.

You may also like to think about using a web front end. If your GUI app
only uses simple controls like text fields and push buttons, a web front
end might simplify things a lot.

Good luck.

 

[Jon-Pierre Gentil]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Josh wrote this on Friday 27 January 2006 05:48 pm in

We have a program written in VB6 (over 100,000 lines of code and 230 UI
screens) that we want to get out of VB and into a better language. The
program is over 10 years old and has already been ported from VB3 to
VB6, a job which took over two years. We would like to port it to
Python, but we need to continue to offer upgrades and fixes to the
current VB6 version. Does anybody know of ways we could go about
rewriting this, one screen at a time, in Python, and calling the screens
from the existing program?

I would look into Qt, PyQt, and the Qt Designer. It'll provide one of the
easiest ways of porting your existing GUI dialogs into Python. Start
building and componentizing your code. In VB6, all classes are flat under
a single branch of a project tree, whereas in Python you'll likely
implement modules of similar functionality. Overall porting your
application will be a combination of rewriting, refactoring, and
copy-and-translate code. Good luck. It actually sounds like a fun
project to be on. I had a lot of VB6 experience back in "the day" and a
project like that would be a lot of fun to me.


- --
_________________________________________________________

Jon-Pierre Gentil KC9CAF PGP: 0x7E1CBA17
jabber: (e-mail address removed) web: www.sebistar.net
"If you think education is expensive, try ignorance."
_________________________________________________________
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iQIcBAEBCgAGBQJD2yoeAAoJEPtxPmpAsx/rdkkP/A8oGRQF2n7UqpbTHkuMIPT5
u0LFh75ry/6RiXpOa72iLkPb9giXp+pSGGlGbR7Sgdh5NmMnhd882SJknVP8vFta
wcbdwORilBjR4I4WsnN5o+fcUz8PPERj0yfYndEEC7SBQOOahcpX6FSd9gNjbe2s
MMDy5TqDE0kTP2PtGknncLB+v4XoFkUcZtFhVtKh29y0kORCJ1jIHq+O7vN9Wgwv
BrzNse44n/TSW8Z2iCX8h+tsCK0vSzqe6GJKA5IRHmUjoRWyiQH6LKboZcA8qNrA
JQlCa9deRSLWFWOIUsHIKBeGDmiO+E7E6g1jfADwQuS+TDW1yxV+1HwGR5LCQFgV
kXVEMDzyk1SIvAVEuXIefXuZQq9nafPhDx4qpnnxqK1HK1F97meYYm7/tAoHZGKM
6kJ9tq9P5I3TkFB9dRVuNftKkKZz8f6RCJFcsHvqOu2H94Fui5upUs3/royp8TVQ
CeY74vtlFXKkPGjt07RfJFMqxacGL3ONjgYdRluV5pkDeXoer65Vhqd7kHFlpVW0
Gilw4ITDEIlIuX+iOvSP5CBixBqwrvhARGYQxCMoiwtZjfbbGo0iKYHhx4/qAGAv
qoxY0Ae6D3mTTIRXiKrVBLlXgj3kQIqCzOuCPTEhN/ydY2WeKYlArBQAL42H7Rkv
atlNHGjEcMMTcHesfK0e
=b2Qh
-----END PGP SIGNATURE-----

 

[=?iso-8859-1?q?Luis_M._Gonz=E1lez?=]

I second the suggestion of using Boo for this case.
Why use Delphi or VB when you have a more "pythonic" first class .NET
language?
You already have a very good IDE for creating your project
(SharpDevelop), which is free, open source and already has the Boo
bindings included (download here the latest version:
http://build.sharpdevelop.net/BuildArtefacts/).

Boo is a perfect language for someone wanting to develop Windows GUI
apps because it has all the nice features and syntax of Python, while
being specifically created to run on the .NET framework.

However, if you still want to use pure Python, it won't take too long
to get what you need. Ironpython is in version 1.0 Beta 2, and moving
full steam towards a stable release.
I'm sure that soon it will be integrated to Visual Studio.

 

[DH]

see vb2py to help the conversion
http://vb2py.sourceforge.net/
or if you want to convert vb6 to vb.net instead, there are tools from
microsoft and others to help with that, such as:
http://www.microsoft.com/downloads/...A2-FC67-4509-BC10-60C5C039A272&displaylang=en

or if you want to start over from scratch, the other recommendations are
good, like pyqt and qt designer, or else do it as a web app instead of
desktop app if it just involves basic form controls.

 

[Thomas Ganss]

Josh schrieb:

You haven't specified where your main pains are.
Do you have at least rudimentary architecture ?
How often do you have code reviews / refactored your code ?
Have you been striving for good code ? Is it a total mess ?

Guessing only from the number of screens, you probably
have more than trivial amounts of data.

*Based on that assumption*, I'ld move the data FIRST.
Get rid of the JET engine! If you are certain you will
have to support SQL server, make it SQL server and
MSDE/new express version first. Only then (perhaps)
think about adding a totally free database engine.
If not, take your pick but *move the data*.

While you are on it, refactor the old code into something
at least resembling a 3 to 5 layered approach with COM.
Doesn't need to be perfect 100%, but more than 50%.

Then exchange the parts that benefit the most by
implementation inheritance, since VB's interface inheritance
is arguably the "best" technical reason for redundant code.

I'ld guess the business layer would be the next things to convert -
but if your VB-forms are mostly slightly augmented copies differing
only slightly, the GUI actually might benefit most from a rewrite,
if the business rules are written redundance poor.

One of the typical scenarios asking for GUI inheritance
is insurance - customer data is only specific for few fields
and even policy field groupings resemble each other across
similar policies. A "minmally redundant" business layer could
even in VB be implemented without too much sweat- for instance
by having methods overwritten in a inheritance based OOP -
design as name mangled methods on objects responsible across
similar problem domains, keeping the "common" methods clean.

Check your code with a critical eye -
even code forced to be totally OOP for

technical reason=langauge

can be written across a wide spectrum of quality.

If there is nothing which is good enogh to be converted last
or no segregation/layering at all in the current program,
(even if it came from the DOS dinosaurs, there were
"good coding practices" known - some of the old "libraries"
were better decoupled than modern day OOP class libraries.)
get rid of most of the people responsible and start only then.

my 0.02 EUR

thomas

 

[John M. Gabriele]

We have a program written in VB6 (over 100,000 lines of code and 230 UI
screens) that we want to get out of VB and into a better language. The
program is over 10 years old and has already been ported from VB3 to
VB6, a job which took over two years. We would like to port it to
Python, but we need to continue to offer upgrades and fixes to the
current VB6 version. Does anybody know of ways we could go about
rewriting this, one screen at a time, in Python, and calling the screens
from the existing program?

Dunno what you mean by "calling the screens" from the existing
program. (?)

Is your VB6 progam object-based? If so, it sounds like you might
have your work cut out for you in duplicating the classes in Python
(I've never used VB6 and don't even know if it's an OO language.).

I'd look into how you can start with unit tests + your classes
right from the start. And, it goes without saying to use version
control from the start (svn or, if you're adventurous, maybe bzr
(i.e. Bazaar-NG)).

We are also looking for a graphics toolkit to use.

You might take a peek at Python + PyGTK + Glade:
http://pygtk.org/ . Dunno the state of GTK on Windows,
but I've heard it's workable. No idea about Glade on
Windows.

Here's an article from 2001:
http://www.linuxjournal.com/article/4702
but if you look around there should be some newer tutorials
around.

[snip]

Any answers/suggestions/pointers are greatly appreciated.

As Steven suggested, I'd examine whether or not your app
might work as a web app. That completely frees you from Windows
altogether. Just make sure it runs alright with Firefox/Opera/
Safari.

---J

 

[Magnus Lycka]

230 UI screens is a lot. An app of that nature is not something people
commonly do in Python (although I would be happy to see people show me
wrong).

Maybe not, but I don't doubt that it's reasonable to replace a
VB app with 230 UI screens with Python code.

A code of that size is something that's grown over time, and if
it's rewritten, it seems likely that it will end up with fewer
screens without fewer features.

Besides, while VB makes it very easy to duplicate a lot of code,
and end up in a situation where you have to manually change things
230 times through the GUI if something changes in all screens, it's
very convenient to use inheritence for GUI development with e.g.
wxPython. I supect the screens have a lot in common, and that it
would be fairly clear how to build a class hierachy of that, and
avoid code duplication. The end result will be a more homogenous
application and a lower maintenance cost.

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

 

[Magnus Lycka]

We currently use a MS Access back end and need to migrate to a proper
SQL server. We need to leave options open for SQL Server (for customers
who want to use existing infrastructure) and something like MySQL or
PostgreSQL. But in the mean time, we need to be able to access an
MSAccess (Jet) database from Python.

mxODBC is probably the best way to talk to Jet in a way (DB API)
that makes it reasonably easy to port the data to another RDBMS.
Writing multi RDBMS applications is a whole chapter in itself,
if not a subject for a whole book.

Whether to use an ORM such as SQLObject on top of that is another
issue...

 

[Ravi Teja]

Maybe not, but I don't doubt that it's reasonable to replace a
VB app with 230 UI screens with Python code.

A code of that size is something that's grown over time, and if
it's rewritten, it seems likely that it will end up with fewer
screens without fewer features.

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.

Besides, while VB makes it very easy to duplicate a lot of code,
and end up in a situation where you have to manually change things
230 times through the GUI if something changes in all screens, it's
very convenient to use inheritence for GUI development with e.g.
wxPython. I supect the screens have a lot in common, and that it
would be fairly clear how to build a class hierachy of that, and
avoid code duplication. The end result will be a more homogenous
application and a lower maintenance cost.

You are comparing Python with VB 6. That's not what the OP is moving to
as an alternative. 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. For example, it's not just inheritance but visual
inheritance. It's not just a GUI but GUI with data bindings, with
sophisticated caching, paging etc. GUI Builders are far more
sophisticated and integrated than, say wxGlade.

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. 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. We would have the
same for Data GUIs if that was the case. We have people drooling over
TurboGears, not Dabo (apologies Dabo team).

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 ?

 

[Magnus Lycka]

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

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

 

[Josh]

Josh wrote:




For the Database, you should use the SQLObject(sqlobject.org) module.

Nic

Thanks for the info, I took a look at SQLObject, but I'm not sure if
that's the way we want to go quite yet. We have a lot of embedded SQL in
the program and it looks like we'd have to convert it all to SQLObject
object code, which would just add to the initial complexity of the
project. I'll keep this bookmarked for future reference but I don't
think it'll work at the moment.

Josh

 

[Josh]

I would look into Qt, PyQt, and the Qt Designer. It'll provide one of the
easiest ways of porting your existing GUI dialogs into Python. Start
building and componentizing your code. In VB6, all classes are flat under
a single branch of a project tree, whereas in Python you'll likely
implement modules of similar functionality. Overall porting your
application will be a combination of rewriting, refactoring, and
copy-and-translate code. Good luck. It actually sounds like a fun
project to be on. I had a lot of VB6 experience back in "the day" and a
project like that would be a lot of fun to me.

We had looked at QT a while ago, but not in relation to Python. We were
just looking at it in relation to rewriting in C++. We'll have to
revisit it, paying attention to PyQt.

It is a rather fun project to be on. It's such a gigantic program
though, it gets difficult to comprehend how long it's going to take to
make this transision. Whether it's to Python, or some other direction.

Josh

 

[Josh]

see vb2py to help the conversion
http://vb2py.sourceforge.net/
or if you want to convert vb6 to vb.net instead, there are tools from
microsoft and others to help with that, such as:
http://www.microsoft.com/downloads/...A2-FC67-4509-BC10-60C5C039A272&displaylang=en


or if you want to start over from scratch, the other recommendations are
good, like pyqt and qt designer, or else do it as a web app instead of
desktop app if it just involves basic form controls.

I have taken a quick look at vb2py, but I'm not sure if that's the way
we want to go. If we do move to Python, we want to take advantage of
features of the Python language, rather than just rewriting a VB app in
Python. It may be a quicker solution in the short term, but in the long
term, I think completely embracing Python from the beginning is the best
way to go.

I tried running the project through the conversion wizard in VB.NET
Express Edition recently just for the fun of it. I come up with 16498
messages at the end of the hour and a half conversion. That's Compile
and Design errors as well as Warnings. It'd take a while to understand
those errors, possibly correcting them in VB6 before trying to do
another conversion, and again, we wouldn't be taking advantage of the
strengths of the new language. Again, a possibility, but not "good"
solution.

The web app functionality is something we also want to be very
accomodating of. We are planning on rewriting in such a way that the
functionality of the screens (input processing, error trapping etc.) is
done is an extensibly manner. That would mean using the same code for
both hardcoded windows as well as web forms.

Thanks,
Josh

 

[Josh]

You haven't specified where your main pains are.
Do you have at least rudimentary architecture ?
How often do you have code reviews / refactored your code ?
Have you been striving for good code ? Is it a total mess ?

Umm... We have been striving for good code, but being a small place,
it's rather difficult. The software in question is basically an ERP
program for the mattress industry. The program started out as a project
for one company, with a single programmer, with plans to grow.

The program, I am sure, still has much code left from those first days
of coding. With customer demands for new features, we do our best to
keep everything extensible, and open, but once a piece of code is
written, it's very rare that it will be changed unless it is being debugged.

Guessing only from the number of screens, you probably
have more than trivial amounts of data.

You have guessed right. One of our largest customers is using an Access
database that is around 800Mb and they have licenses for about 20
concurrent users (of our program). I know this may not sound huge for
someone who works at Walmart head office, but it's been interesting to
get Jet to work well.

*Based on that assumption*, I'ld move the data FIRST.
Get rid of the JET engine! If you are certain you will
have to support SQL server, make it SQL server and
MSDE/new express version first. Only then (perhaps)
think about adding a totally free database engine.
If not, take your pick but *move the data*.

This is a very interesting thought. That would mean a whole bunch of
rewriting of the current codebase.

The thought had been to write the port in an extensible manner, allowing
Jet, but being written well enough to easily use other backends. We'll
have to see.

While you are on it, refactor the old code into something
at least resembling a 3 to 5 layered approach with COM.
Doesn't need to be perfect 100%, but more than 50%.

This makes sense, but OTOH, it might be more worth our time to properly
redesign in a more OOP friendly language.

Then exchange the parts that benefit the most by
implementation inheritance, since VB's interface inheritance
is arguably the "best" technical reason for redundant code.

I'ld guess the business layer would be the next things to convert -
but if your VB-forms are mostly slightly augmented copies differing
only slightly, the GUI actually might benefit most from a rewrite,
if the business rules are written redundance poor.

One of the typical scenarios asking for GUI inheritance
is insurance - customer data is only specific for few fields
and even policy field groupings resemble each other across
similar policies. A "minmally redundant" business layer could
even in VB be implemented without too much sweat- for instance
by having methods overwritten in a inheritance based OOP -
design as name mangled methods on objects responsible across
similar problem domains, keeping the "common" methods clean.

Unfortunately, there is little duplication across the different screens.
There definitely is some, like screens for picking a date range of a
report, with the reports being hardcoded (in our internal report writing
format) behind the print button on the screen. Here, the report should
be moved to a different module, or imported from a special format report
file, but the number of these types of screens are few and far between.

Check your code with a critical eye -
even code forced to be totally OOP for

technical reason=langauge

can be written across a wide spectrum of quality.

If there is nothing which is good enogh to be converted last
or no segregation/layering at all in the current program,
(even if it came from the DOS dinosaurs, there were
"good coding practices" known - some of the old "libraries"
were better decoupled than modern day OOP class libraries.)
get rid of most of the people responsible and start only then.

I think what needs to happen, is good coding guidelines put into place,
with a language that supports proper OOP. Inheritance doesn't even work
in VB, let alone polymorphism, unless you want to count passing Variants
and figuring out the types and then returning a variant.

my 0.02 EUR

Thanks for your thoughts. It gives me some things to think over.

 

[Josh]

> mxODBC is probably the best way to talk to Jet in a way (DB API)
that makes it reasonably easy to port the data to another RDBMS.
Writing multi RDBMS applications is a whole chapter in itself,
if not a subject for a whole book.

Whether to use an ORM such as SQLObject on top of that is another
issue...

mxODBC looks interesting. I'll need to research it some more.

Thanks,
Josh

 

[Josh]

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.

No, but it's what they've used and know. It's the reference for
their thinking.



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.

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.

I'm not 100% sure that the plethora of Python web kits is entirely
a benefit.

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.

 

[Josh]

I suggest you hire a couple of experienced Python developers, pick half a
dozen screens, say three simple screens and three complex ones, and build
them in Python. That will give you an idea of how much work is involved.
Don't get your VB developers to try to port it themselves, that's a recipe
for disaster: they will be trying to learn Python, and will end up writing
VB code in Python, which is sure to be slow, inefficient, bulky and buggy.

You may also like to think about using a web front end. If your GUI app
only uses simple controls like text fields and push buttons, a web front
end might simplify things a lot.

Good luck.

Point taken on VB coders writing Python. I think part of this though, is
having programmers who are willing to learn new paradigms. I agree that
there could be many teething problems, but knowing the team, I believe
that after doing a few modules/classes (2 or 3 months, maybe more) we
could work out the bugs, and go on to new problems.

Having worked out problems with the first classes, as long as there are
no major architectural problems, we could continue on with the rest of
the program. Once good headway on the project, come back to those first
converts and refactor them, using knowledge accumulated from the last 6
months in Python.

Maybe I'm just being overly optimistic, but I think the VB programmers
we have can make the jump to Python. Their first lines of Python will
just be VB in Python, but, once the power of Python becomes apparent,
there'll be no going back.

Josh