[Gambas-user] Migrating to Gambas
johna at starflightinc.com
Thu Jun 10 18:31:22 CEST 2021
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!
More information about the User