Leaving the magic development community #csharp


Gijs van Ballegooijen
 

Hi,

As a long time magic developer I am now leaving the magic development. I'm transferring my development projects to my successors and they decided to migrate the magic projects using the firefly migration engine. All further development is now done in C#.

Thanks for all the support in the last 20 years or so.

Wish you all the best,

Gijs van Ballegooijen.


Todd Baremore
 

Gijs,

Hate to see you leave.  Thank you for contributions over the years. 

Can you share your successor's reason(s) for moving to C#?
Todd
On 7/18/2022 3:51 AM, Gijs van Ballegooijen wrote:

Hi,

As a long time magic developer I am now leaving the magic development. I'm transferring my development projects to my successors and they decided to migrate the magic projects using the firefly migration engine. All further development is now done in C#.

Thanks for all the support in the last 20 years or so.

Wish you all the best,

Gijs van Ballegooijen.


Gijs van Ballegooijen
 

Hi Todd,

The main reason was the more flexible development options. Especially for integration with external systems using JSON and Web API endpoints. Also easier integration of devExpress controls was mentioned. Another reason was the move from bTrieve to SQL server. You can include this migration into the full migration project and it turned out to cause few to no problems at all. The full bTrieve data were moved to SQL server in a matter of hours and after setting a switch in the systems source, the company used SQL server instead of bTrieve.

For one customer it also was because they expected to more easily hire C# developers instead of Magic developers. This was a little disappointing because the first new developer they hired refused to learn the firefly framework and insisted on developing plain C# programs. This developer quit from the project:-).


Harry Kleinsmit
 

Hi Todd,

I'm one of the "successor's" of Gijs. As you might know I've been programming in Magic for almost 40 years and over the years I saw Magic change from DOS to Windows to using Handlers instead of the RM. All innovations that made Magic one of the fastest programming tools in the world. But the last years I found the new features of Magic more 'catching up with other main stream programming languages' then 'innovative', like for instance the (half backed) JSON support in the latest 4.8.1 version. Perhaps this has something to do with MSE moving all Magic development and support overseas? It felt to me that Magic became less and less important to MSE than their integration tools. Next to the reasons Gijs already mentioned, like better integration and an easy move to SQL, there are many more that made me, and another collegae, decide to take the plunge and try something new. Of course the grass was not that much greener on the other side (C#) but there were enough advantages for us to continue on this track. To mention a few: Better performance, step by step debugging, full control over all source code including the Firefly framework (which compares to the 'Magic engine' including recompute), build in profiler to easily improve performance issues, move code to your table or model so you only have to program it once, no toolkit or runtime fees, MUCH better support (days/weeks instead of months/years) and free during the migration, can build your own tools because EVERYTHING (table definitions, models, menus, etc.) is accessible from your own programs, many samples (on stackoverflow) which you can simply copy to your code, create branches in TFS for each change request and move these separately to your project when done, being able to SEE these changes in a readable form, add color skins, add data change logging with only a few lines of code in each table definition, very quick search (and replace), etc. too many pro's to mention! The downsides are: Some things are done quicker/easier in Magic but the learning curve is not that steep, if even an old geezer like me can do it. Overall I would say that the performance in programming speed is about equal. Mostly you copy program's, that look like what you want to build new, anyway. When is the last time any of us build a 1:N with subforms from scratch? Also the Visual Studio might sometimes have some hick-ups, just like the Magic toolkit (often) crashes (for me anyway with XPA 3.2c, which I'm still using for one (last) customer). In case you didn't know this yet: Perfect software doesn't exist. Even Microsoft has monthly updates and there are probably more programmers working there then that there Magic programmers in the whole world. Talking about MS updates: With the new Visual Studio 2022 it is possible to change the source, while the runtime is running, and see your changes immediately. Try doing that in XPA !

Best regards,
Harry Kleinsmit.


On Mon, Jul 18, 2022 at 12:51 AM, Gijs van Ballegooijen wrote:
Hi,

As a long time magic developer I am now leaving the magic development. I'm transferring my development projects to my successors and they decided to migrate the magic projects using the firefly migration engine. All further development is now done in C#.

Thanks for all the support in the last 20 years or so.

Wish you all the best,

Gijs van Ballegooijen.


Frank Van Herreweghe
 

Wow, my first reply in many many years…

We had the same problem, new c# developers running away… even before they did 1 day of work :-s
The firefly-way of working is very good as a starting point for magic developers. But we are trying to take the next step and going all the way. But if you have 4O years of Magic code you can’t convert that all to full .net code with use of f.e. devexpress and entity framework in a few days. That’s a process of several years.
But it’s with that vision that we finally can hire real .Net-developers and they work on the new modules (which we can access from within firefly) while the old magic guys are maintaining the firefly-code and are writing new firefly code because we currently have too many projects ongoing.

Best regards,
Frank Van Herreweghe

On 21 Jul 2022, at 11:25, Gijs van Ballegooijen <gijsvb@...> wrote:

Hi Todd,

The main reason was the more flexible development options. Especially for integration with external systems using JSON and Web API endpoints. Also easier integration of devExpress controls was mentioned. Another reason was the move from bTrieve to SQL server. You can include this migration into the full migration project and it turned out to cause few to no problems at all. The full bTrieve data were moved to SQL server in a matter of hours and after setting a switch in the systems source, the company used SQL server instead of bTrieve.

For one customer it also was because they expected to more easily hire C# developers instead of Magic developers. This was a little disappointing because the first new developer they hired refused to learn the firefly framework and insisted on developing plain C# programs. This developer quit from the project:-).


Keith Canniff
 

As many of you know, I also experienced the migration of an application from Magic to C# via Firefly. I would agree with what Harry has stated below. When I left that company, I would say that I could program almost as fast in Firefly’s C# as I could in Magic…almost (really not fair since my C# experience was about 2 years vs. 36 years in Magic)

 

Yes there are some real advantages with the C# version. Mostly because you have access to the “Magic Engine” code. If you want to add a new function, you can add it (not a udf). If you want to change how locking works, you can change it (although in most cases this is solved by Firefly based on an issue from their user group).

 

Some of the biggest advantages that I saw

  1. The PSQL to MSSQL migration was stunning, both code and data. Migrating gigs of PSQL data to MSSQL in a matter of minutes. And the application worked almost without modification
  2. The ability of merging the Firefly/Magic engine with traditional C# code. Yes you can imbed straight C# processes in the middle of the Firefly/Magic cycles. This makes traditional C# developers happy when they don’t like the Firefly/Magic engine flow.
  3. The ability to add application logic in a data definition. So if you always needed data from another table (like entering a zip/postal code and getting back the city and state), your you needed a total for calculations that is not a stored column, you can add them to the data definition and every time you use it, the other pieces just “happen”.

 

And yes, you get JSON support (although it’s through the NewtonSoft library), but it handles the serialization/deserialization flawlessly.

 

I could go on and on. I will tell you that if you hire C# developers, you’re going to find some that will just leave because they can’t handle the Firefly/Magic engine (rather than just embracing it as another library can or don’t have to use.. Can’t tell you how many times I would use a Magic function or a C# function, depending on the situation. One would just be easier to use than the other but you have both available). So the idea that it will be easier to find developers is not as easy as they would think.

 

From my standpoint, if you just had a standalone system that doesn’t need to interact with external systems, then Magic is still better. But if you’re going to be integrating with a lot of external objects/systems (and don’t want to spend the money on XPI), then Firefly’s C# is certainly a viable option.

 

Keith

 

From: main@magicu-l.groups.io <main@magicu-l.groups.io> On Behalf Of Harry Kleinsmit
Sent: Thursday, July 21, 2022 10:22 AM
To: main@magicu-l.groups.io
Subject: Re: [magicu-l] Leaving the magic development community #csharp

 

Hi Todd,

I'm one of the "successor's" of Gijs. As you might know I've been programming in Magic for almost 40 years and over the years I saw Magic change from DOS to Windows to using Handlers instead of the RM. All innovations that made Magic one of the fastest programming tools in the world. But the last years I found the new features of Magic more 'catching up with other main stream programming languages' then 'innovative', like for instance the (half backed) JSON support in the latest 4.8.1 version. Perhaps this has something to do with MSE moving all Magic development and support overseas? It felt to me that Magic became less and less important to MSE than their integration tools. Next to the reasons Gijs already mentioned, like better integration and an easy move to SQL, there are many more that made me, and another collegae, decide to take the plunge and try something new. Of course the grass was not that much greener on the other side (C#) but there were enough advantages for us to continue on this track. To mention a few: Better performance, step by step debugging, full control over all source code including the Firefly framework (which compares to the 'Magic engine' including recompute), build in profiler to easily improve performance issues, move code to your table or model so you only have to program it once, no toolkit or runtime fees, MUCH better support (days/weeks instead of months/years) and free during the migration, can build your own tools because EVERYTHING (table definitions, models, menus, etc.) is accessible from your own programs, many samples (on stackoverflow) which you can simply copy to your code, create branches in TFS for each change request and move these separately to your project when done, being able to SEE these changes in a readable form, add color skins, add data change logging with only a few lines of code in each table definition, very quick search (and replace), etc. too many pro's to mention! The downsides are: Some things are done quicker/easier in Magic but the learning curve is not that steep, if even an old geezer like me can do it. Overall I would say that the performance in programming speed is about equal. Mostly you copy program's, that look like what you want to build new, anyway. When is the last time any of us build a 1:N with subforms from scratch? Also the Visual Studio might sometimes have some hick-ups, just like the Magic toolkit (often) crashes (for me anyway with XPA 3.2c, which I'm still using for one (last) customer). In case you didn't know this yet: Perfect software doesn't exist. Even Microsoft has monthly updates and there are probably more programmers working there then that there Magic programmers in the whole world. Talking about MS updates: With the new Visual Studio 2022 it is possible to change the source, while the runtime is running, and see your changes immediately. Try doing that in XPA !

Best regards,
Harry Kleinsmit.

On Mon, Jul 18, 2022 at 12:51 AM, Gijs van Ballegooijen wrote:

Hi,

As a long time magic developer I am now leaving the magic development. I'm transferring my development projects to my successors and they decided to migrate the magic projects using the firefly migration engine. All further development is now done in C#.

Thanks for all the support in the last 20 years or so.

Wish you all the best,

Gijs van Ballegooijen.


JK Heydt
 

I just completed a band new standalone system in Magic that includes complex interaction with external systems. It only took me two years from concept to revenue generation and I am competing successfully with all major vertical systems in the market (see www.haultrackusa.com). I can't imagine anyone doing something like this as quickly or efficiently without Magic. 

Keep the faith!
John


Mike Moore
 

John, thanks for sharing your faith-inspiring XPA testimony!





From:        "JK Heydt" <john@...>
To:        main@magicu-l.groups.io
Date:        07/22/2022 04:31 AM
Subject:        Re: [magicu-l] Leaving the magic development community #csharp
Sent by:        main@magicu-l.groups.io




I just completed a band new standalone system in Magic that includes complex interaction with external systems. It only took me two years from concept to revenue generation and I am competing successfully with all major vertical systems in the market (see www.haultrackusa.com). I can't imagine anyone doing something like this as quickly or efficiently without Magic.

Keep the faith!
John