Considering migrating to Python from Visual Basic 6 for engineering applications

[Chris Angelico]

On Thu, Feb 18, 2016 at 7:17 PM,  <wrong.address.1 at gmail.com> wrote:
> Thanks to all of you who have responded. One point two of you ask me is why I want to shift from Visual Basic.
>
> Most of my software is in VB6 (and VB3), and converting to VB.net is not very pleasant. I have learnt enough VB.net to manage most of the things I will need, but it always gives me a feeling that it is not meant for the kind of things I am doing. And you never know when Microsoft will kick us out of VB.net also. For the sake of keeping software compatible with new versions of Windows, you need to keep changing things in the software, which takes too much time. You might ask if it is really necessary to move from VB6 to VB.net because Microsoft will still not be able to kill VB6 very soon, thanks to VBA used in Excel. If my reasoning is wrong, please correct me. I am just an engineer, not a good programmer.
>

Very fair point. And I fully support your move, here. Just make sure
you start on the latest Python (currently that's 3.5), and you should
have no difficulty moving forward in versions; as someone who started
writing Python 3 code back when 3.3 was the newest and latest thing, I
can attest that it's been easy to migrate 3.2->3.3->3.4->3.5->3.6;
there are very few things that get broken by the upgrade, and they're
mostly things that would have been bad code in the older version
anyway.

>> The basic python language and its libraries are completely cross-platform (Linux, OS-X, Windows, iOS, and Android).  The same source code will run on all of them.  However, because it is an Interpreted language, the step to a bundled, self-contained image is platform dependent. There python compliers (as opposed to interpreters) for some, but not all platforms, and there is a very active JiT compiler project that would fall somewhere in between.
>>
>
> OK. This is clear to me now. It is like needing different Fortran compilers for different operating systems, but Fortran code does not need much modifications (except file names/paths, etc.).
>

Something like that. There are a lot of little traps you can fall into
(as you say, file names can be different, especially system ones) that
stop your code from running correctly on all platforms, but porting a
Python script from Linux to Windows or vice versa is a matter of
testing it on the new platform and seeing what breaks, not completely
rewriting it in a new language.

>> > Could someone kindly tell me advantages and disadvantages of Python?
>>
>> If you are completely satisfied with VB, there is no reason to change (other than the enjoyable exercise of learning a new and more powerful language).
>>
>
> Will VB6 run on Windows 11? Or can I compile VB6 on Windows 11. We can't know. But there will be easy ways to run Python on any Windows version or Linux or whatever.
>

There will indeed. That's the advantage of a fully open system - even
if a nuclear meltdown kills all the Python core devs in one stroke (we
really shouldn't have had PyCon Chernobyl), anyone in the world can
pick up the source code and keep going with it. And Microsoft, despite
having a strongly anti-freedom history, has come far more on board of
recent years; as I understand it, Steve Dower has been spending
company time improving Python (notably in the area of Windows
installers and such). The future of open source software is pretty
secure, and the future of openly-developed languages even more so,
because CPython isn't the only way to run your Python code.

One Python advantage that you may or may not be aware of is its
extensibility. To an extent that I haven't seen since working with
REXX on OS/2, there is a thriving community building Python packages,
many of which (about 75K!) are listed on PyPI [1]. Got this
proprietary database that you need to get info from? Check PyPI -
chances are someone's written a connector for it, so you can perform
queries on it as if it had native support in the language. Once you
install something using "pip" [2], you can import it into your script
the exact same way that you would import something from the standard
library - making PyPI kinda like the "extended library" for the
language. The barrier to entry is low, though, so you do sometimes
have to wade through a bunch of stagnant or expired projects to find
the gems you want. But there's so much good stuff there that it's well
worth the effort.

ChrisA

[1] https://pypi.python.org/pypi
[2] No, not the chipmunk from Enchanted.