S
Stefan Marquardt
Guest
I think that OpenEdge has many good features but the language itself is too slow. I raised often the same problem, objects are slow, simple I = I + 1 and string concatenation is a catastrophe. I am working in a mixed team, my colleagues are using C# and they are using the cpu power, I can't. ABL GUI is useful for displaying data, some calculation but the rest has to be done on the appserver. If you need hardware support you are forced to write assemblies in C# because they are using multi-threading. Years ago, as I used OEA the first time (10.2A in Paris), I can't get Mikes presentation out of my head where he was so happy that OE has now a possibility to resize windows and a useful flow control, I head the first contact with the bridge. 10.2A was very painful and with 10.2B it made sense to use it. During this time I joined a German PUG meeting and a member company presented a fully new developed solution based on ABL.NET. I had the chance to join one year later the next meeting again and we got the same presentation, only with the latest output after one year developing time. But what happend?! I noticed that they buried ABL in the frontend and switched to C#, only the background was still using the "big ABL experience", that was the main point for the frontend last year too. I asked them what happened and I was told: They realized that a modern concept wasn't possible because the UI was too slow and had limitations. If nothing will change it looks like that ABL UI could be a dead end in this kind of implementation. It's nice to have the ability to use the same code from lightyears ago, this was still the killer argument. But meanwhile UI changed in windows to WPF, none of my colleagues is using winforms anymore. I don't think that WPF will be introduced in ABL, but perhaps it will be buried too like Silverlight and HTML5 and winforms are still there? I think that Progress could make a hard break to something new without 100% compatibility with old code. Make something new with a new compiler. Another option could be something like integrating OE into MS VisualStudio and provide a good and easy data and appserver access. Deliver an entity framework OE database provider and a ABL compatibility class like MS did with the first VB.NET version to help users to convert old VB6 code into the new world of .NET Then we could switch to C# with all language components. It could be that I wrote nonsense but when I understood Mikes comment correct, the client is only fast with data when using datasets and temp-table. My colleagues do not use this technology anymore since entity frameworks are available. It's not perfect but objects are much better in the UI and compatible to every control and with ABL a performance nightmare. My 2 cents.
Continue reading...
Continue reading...