D
dbeavon
Guest
Good answer. I think every ABL programmer should also learn another general-purpose, managed-memory language like Java or C#. This is not intended to be negative or provoke a flame war (although the question is almost begging for it 
. ABL is designed to make it easy to write business logic and do data access (CRUD apps). But its advantages - in trying to make certain things easy - can quickly become a hinderance. IE. It is well-suited to the set of purposes for which it was designed. But when I compare ABL to Java/C# I think of the quote "Everything Should Be Made as Simple as Possible, But Not Simpler". Sometimes ABL seems a bit overly simple". It seems more simple than it should be in order to build large, modern applications and services. Of course ABL is always getting better and we see more sophistication in the language over time (features like OO, SEH, etc). But it still lacks some common things that are needed, even in basic LOB applications. I wish they would do more with ... XML, multi-threading, regular ANSI isolation, separating DS/TT definitions (ie. "classes") from "instances" of those definitions, tooling for large solutions (it should be more feasible to build a large project in Eclipse), etc. (As a side, does everyone who programs in ABL have to roll their own XREF tooling? That still surprises me and I've been working with ABL for 15 years.) Final Note: Progress often relies on Java for a lot of its peripheral components (look for it in your running processes on a large Progress installation and you will see quite a bit of Java going on). Think of C# (.Net) as a platform that can take the place of Java for all the same types of purposes. C# (WPF) can be used to build large apps like Visual Studio. And Java can be used to build large apps like Eclipse. But ABL wouldn't play very well in these arenas because that's not what it is designed for.
Continue reading...
. ABL is designed to make it easy to write business logic and do data access (CRUD apps). But its advantages - in trying to make certain things easy - can quickly become a hinderance. IE. It is well-suited to the set of purposes for which it was designed. But when I compare ABL to Java/C# I think of the quote "Everything Should Be Made as Simple as Possible, But Not Simpler". Sometimes ABL seems a bit overly simple". It seems more simple than it should be in order to build large, modern applications and services. Of course ABL is always getting better and we see more sophistication in the language over time (features like OO, SEH, etc). But it still lacks some common things that are needed, even in basic LOB applications. I wish they would do more with ... XML, multi-threading, regular ANSI isolation, separating DS/TT definitions (ie. "classes") from "instances" of those definitions, tooling for large solutions (it should be more feasible to build a large project in Eclipse), etc. (As a side, does everyone who programs in ABL have to roll their own XREF tooling? That still surprises me and I've been working with ABL for 15 years.) Final Note: Progress often relies on Java for a lot of its peripheral components (look for it in your running processes on a large Progress installation and you will see quite a bit of Java going on). Think of C# (.Net) as a platform that can take the place of Java for all the same types of purposes. C# (WPF) can be used to build large apps like Visual Studio. And Java can be used to build large apps like Eclipse. But ABL wouldn't play very well in these arenas because that's not what it is designed for.Continue reading...