[Gambas-user] Migrating to Gambas

[John Anderson]

On 6/9/2021 10:58 PM, Christof Thalhofer wrote:
> Am 09.06.21 um 14:17 schrieb Bruce:
>
>> So I will repeat the question, why is this industry so psychologically
>> dependent on trying to turn something that does not work into something
>> else that probably wont work because they insist on re-using poorly
>> engineered code with myriads of known and yet to be discovered faults
>> that has been hacked at by a large farmyard full of script chickens ...
> Nice story, but: If one has *reliable working code* in *discontinued
> VB6* there is no reason to rewrite it from scratch instead of migrating
> it to Gambas and be as carefully as possible to keep the old work.
>
> For example: I have a large method which creates invoices automatically
> based on some data in the database. It started as a couple of macros in
> Microsoft Works(!), then was migrated to MS Access. In the first ten
> years it crashed a lot:
>
> New client with shipping address: Crash.
> New client with shipping address not in Germany: Crash.
> New foreign customer with shipping address in Germany: Crash.
> New client with "&" in it's name: Crash.
> New foreign client with a company and special tax circumstances: Crash.
>
> And so on and so forth...
>
> After about ten years, we had grazed the vast pasture of crash
> possibilities, the method has worked smoothly ever since and now it
> contains lots of fine distinctions (that might look a little twisted if
> you don't analyze exactly what they do).
>
> If anything, I only touch it very carefully with tweezers. I'd be crazy
> to throw it away and develop it new from scratch!
>
> This is what Joel Spolsky is talking about. When he says that the code
> is "tested", he means that it has been tested on the reality.
>
> Alles Gute
>
> Christof Thalhofer
>
I agree 100%.  In our case we are converting away from VB6 NOT because 
anything was wrong with VB6 code - it has served perfectly well for 
decades, and it is OO in a friendly way.  We're only changing anything 
because field customers don't want Windows based OS's on the factory 
floor any more.  We're on industrial WES7 now, which is still valid for 
a few more years - but after that there is little interest in Win10/Iot 
for many reasons.  And no we can't run the existing system in a VM or Wine.

So my conversion project is out of necessity, and not for any real 
perceived performance gain - because the equipment under the GUI control 
works as perfect and as fast as it ever will.  We want as few changes as 
possible in the existing source code - for reduced labor expense, 
reduced possibility of errors introduced, plus any major change could 
trigger a massive acceptance cycle testing as I've explained before, and 
that could take years.  A project of that size is not in the budget, nor 
it it practical.  The GUI interface has to work and look exactly the 
same as VB6 version...except without the "C:" drive.  We don't want the 
operators to really notice they aren't on Win98/XP/7 anymore.

I think in the whole time we ever encountered a true major bug problem 
in VB6 was with a third party spin button control in 2002. All the other 
changes to code were NOT VB6's fault, it was something like the customer 
had to go to a new product bar code format, or they wanted to connect to 
a different downstream test jig and needed wafer placement information 
in a different format, etc.  All code changes over time were feature 
additions, not bug patches.

In any CompSci language you can do the code correct or not - It's the 
same concept that a good or bad typewriter / notebook / word processor 
doesn't make or break a good or bad novelist.  It is the final outcome 
we're looking for: is the GUI rock solid and reliable.

 From what I see so far, Gambas is like the love child of VB6 and Java.  
It looks a lot like VB6 Daddy, but has mom Java's eyes.  So close to 
VB6, but some places frustratingly different - but that's just me... 
<Laughing>.  Gambas is a good product!

-J