ABL vs C# - Forum - OpenEdge General - Progress Community
 Forum

ABL vs C#

  • For those who know C# and ABL - how would you compare the languages and their relative strengths and weaknesses? 

  • OS:  ABL can be used on multiple OSes.  C# officially is for one - Microsoft.

    Wordiness: C# is far more "wordy" than ABL (wordy being need to know more to be functional in the language.)

    DB: C# is wanting to use SQL, so connection to almost any database, Microsoft or not.  ABL - in the end with Data Servers the same, but have to pay for data servers.

    It's a start!

    Scott Augé
    President
    Amduus Information Works, Inc.
    Technical Services for Business and Government
    http://www.amduus.com/cms

  • Speaking of "wordiness", I ran into a C# installation that uses Entity Framework, and when I investigated the framework, the number of switches and levers one had to know about was dumbfounding.

    With ABL - its "Set and forget" - for a while. :)

    en.wikipedia.org/.../Entity_Framework

  • "OS:  ABL can be used on multiple OSes.  C# officially is for one - Microsoft"

    not true : mono (http://www.monodevelop.com/)  has had c# running on linux and mac OS for ages. MS is also making .net core available on linux

  • I said "officially" - it is also available on Linux too.

    Scott Augé
    President
    Amduus Information Works, Inc.
    Technical Services for Business and Government
    http://www.amduus.com/cms

  • What is unofficial in mono? It's part of the mukti platform strategy of two serious vendors. Microsoft and Xamarin. Officially. The days of Mono as only a hackers playground are.over. since years...

    Architect of the SmartComponent Library and WinKit

    Consultingwerk Ltd.

  • Tim EF is off topic in an ABL vs. C# debate as its not part of the language. Or are you trying to have a debate about frameworks too?

    And you say that late ABL features like the DATA-SOURCE are simple? Have no keywords, attributes, events that are complex but essential?

    What are you trying to find out? What's the bottom of the question? Or is it already Friday?

    Architect of the SmartComponent Library and WinKit

    Consultingwerk Ltd.

  • I'm looking for a broad-strokes, general comparison of the overall environments to gain some general knowledge. I run into C# shops & developers on a regular basis, and I don't know enough about the C# environment to comment about how much easier their life could be. :)

  • You'd better have a powerful framework in your backpack to survive.

    Basic C# is a simple OO and control language. And beautiful. It grew complex with recent versions. Language features like LINQ make code hard to read. The code that uses this. But there is for instance no legacy with two different ways of handling errors.

    On the big picture, Visual Studio, the .NET framework and nuget are productivity boosters.

    Whenever I had to have a "why ABL" debate with C# fanatics, I was glad to have my framework with me to survive.

    The ABL is certainly a very intuitive language for business logic and that is a strenght. But in a layered context you need a framework and tools to help developers. The .NET ecosystem - out of the box - plays in another league there.

    Architect of the SmartComponent Library and WinKit

    Consultingwerk Ltd.

  • So the big advantage isn't the language so much as the library base, frameworks, and support tools?

  • 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.

  • As a side, does everyone who programs in ABL have to roll their own XREF tooling?

    Why roll your own when there is an open source implementation which covers a lot more than XREF?

    http://www.oehive.org/abl2db

    Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice  http://www.cintegrity.com

  • (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.) 

    That just goes to show the state of open source in the ABL world - I built and released an XREF to TT converter back in the early/mid 2000's.  Outside of people asking for something like that and disappearing afterwards, that's been it. So its no surprise that people keep reinventing this particular wheel. 

    Hopefully TMH et al's effort'll gain some traction and put this particular issue to bed - permanently.

  • I wish they would do more with ... separating DS/TT definitions (ie. "classes") from "instances" of those definitions

    I've got something in the works along those lines in a "for fun" project I've been working on.

  • We've gained a good bit of traction with our XREF "tooling".

    Jeff Ledbetter

    Roundtable Product Architect

    www.roundtable-software.com