[Gambas-user] Migrating to Gambas

[Bruce]

On 10/6/21 3:28 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
> 
Christof, I fully accept that and agree, you would be mad to muck with 
stuff that works. However, are you saying a) you migrated it after those 
10 years or are b) still using the MSA application? (Just to clear my 
understanding.)

A bit further down he says

"Back to that two page function. Yes, I know, it’s just a simple 
function to display a window, but it has grown little hairs and stuff on 
it and nobody knows why. Well, I’ll tell you why: those are bug fixes. 
One of them fixes that bug that Nancy had when she tried to install the 
thing on a computer that didn’t have Internet Explorer. Another one 
fixes that bug that occurs in low memory conditions. Another one fixes 
that bug that occurred when the file is on a floppy disk and the user 
yanks out the disk in the middle. That LoadLibrary call is ugly but it 
makes the code work on old versions of Windows 95."

That is the stuff I am talking about. Apart from maybe "that bug that 
occurs in low memory conditions" those bugs no longer exist in the known 
universe! Spending time "migrating" the remediant code is almost 
assuredly a waste of time. Better to understand (for want of a better 
word) the algorithm of the original code and code it.
Maybe you CAN paste the source code and delete vast chunks of 
workarounds and patches that no longer apply and then start testing, 
fixing, re-testing the new Gambas version. Maybe that DOES give you a 
"quickstart" into the Gambas version.

Maybe. But my experience differs.

And one was a very similar case to yours, a "large" MSA code set, 4 
"main" applications and from memory about 6-8 "library" applications. (I 
cant recall what they were called in MSA.) Anyway, we gave up on the 
whole "migrate" approach after a few weeks as, wait for it, there was 
stuff in the MSA code and forms that Gambas could not do. The typical 
one was comboboxes with keys that were driven by static metadata in the 
database that specified the key-value pairs and various attributes 
pertaining to those values. Easy example "Error", key="ERR", 
background=red. The MSA code "custom" control took care of all of that. 
Guess what! To this day I have not been able to get Gambas/QT controls 
to emulate that behavior in a ComboBox. Another example was the 
Security/Authorisation code, which HAD to be re-written to the adoption 
of postgres as the underlying database. Another was a "state machine" 
thing that most assuredly need never have been done in the first place, 
messy, buggy and totally lacking in any added value within the MSA code 
base anyhow. I think it was done when "state machines" were the 
buzz-word of the week. (Someone here was talking about these recently I 
think.)

Anyway, the net result was that we excised almost ALL of the fancy code 
from the MSA base which left about 20% of the code - could have written 
it from scratch in Gambas using proper OO techniques in about half the 
time.

As always YMMV!

regards
bruce