ABL vs C#

Posted by Tim Kuehn on 08-Dec-2015 13:19

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

All Replies

Posted by scott_auge on 08-Dec-2015 14:25

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!

Posted by Tim Kuehn on 08-Dec-2015 14:51

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

Posted by jmls on 08-Dec-2015 14:57

"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

Posted by scott_auge on 08-Dec-2015 14:58

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

Posted by Mike Fechner on 08-Dec-2015 15:04

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

Posted by Mike Fechner on 08-Dec-2015 15:09

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?

Posted by Tim Kuehn on 08-Dec-2015 15:14

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. :)

Posted by Mike Fechner on 08-Dec-2015 15:29

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.

Posted by Tim Kuehn on 08-Dec-2015 15:42

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

Posted by dbeavon on 08-Dec-2015 16:41

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.

Posted by Thomas Mercer-Hursh on 08-Dec-2015 16:52

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

Posted by Tim Kuehn on 08-Dec-2015 17:53

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

Posted by Tim Kuehn on 08-Dec-2015 17:56

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.

Posted by Jeff Ledbetter on 08-Dec-2015 19:30

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

Posted by Alon Blich on 09-Dec-2015 01:34

i've  only used a little c# writing a wrapper for a c++ project

but imho for writing apps, frameworks are the new programming languages using one language or another makes little or no difference.

regardless the ui has to be web.

Posted by agent_008_nl on 09-Dec-2015 02:04

Taking the original question to a broader level:

www.gov.uk/.../choosing-technology

Vendor lock-in is important to take into consideration.

--

Kind regards,

Stefan Houtzager

Houtzager ICT consultancy & development

www.linkedin.com/in/stefanhoutzager

Posted by Paul Mowat on 09-Dec-2015 02:51

I've had to in the past drop down into java or c# to accomplish things that couldn't be done in ABL. One such example is zipping up a file. A second such example is SFTP. So for me the extensive libraries of java and .net are a plus point for those languages.

Posted by Alon Blich on 09-Dec-2015 03:09

I decided to go the C/C++ route for low level operations because 1. it would be easy to integrate with progress and there won't be any need for another virtual machine. 2. i would say there just as much low level C/C++ libraries than any other language or more (GNU for example). 3. they're fast

although C/C++ libraries especially if they're open source are more cryptic compared to standard Java and .NET framework classes.

Posted by agent_008_nl on 09-Dec-2015 05:24

> MS is also making .net core available on linux

blogs.msdn.com/.../announcing-net-2015-preview-a-new-era-for-net.aspx

" .NET is entering a new era as it embraces open source as a core principle and enables .NET applications to run on multiple operating systems." (not about mono).

--

Kind regards,

Stefan Houtzager

Houtzager ICT consultancy & development

www.linkedin.com/in/stefanhoutzager

Posted by agent_008_nl on 09-Dec-2015 05:49

Db's you can connect to in .net (compare that with abl):

msdn.microsoft.com/.../dd363565.aspx

Posted by agent_008_nl on 09-Dec-2015 07:21

> The ABL is certainly a very intuitive language for business logic and that is a strenght.

"Intuition is a powerful tool that helps us navigate through life, but it can get in the way of more formal processes."

Besides at least object-orientation can hardly be called intuitive.

Posted by Tim Kuehn on 09-Dec-2015 09:06

[quote user="Paul Mowat"]

I've had to in the past drop down into java or c# to accomplish things that couldn't be done in ABL. One such example is zipping up a file. A second such example is SFTP. So for me the extensive libraries of java and .net are a plus point for those languages. [/quote]

I've had to do something similar in my work - and since the ABL can call .NET functionality, wouldn't that be a "plus" for the ABL? 

Posted by Tim Kuehn on 09-Dec-2015 09:06

Here's another question then - is there a way that C# and ABL can both be leveraged for their respective strengths? If so, what would such a structure look like?

Posted by Paul Mowat on 09-Dec-2015 09:18

It's definitely good that you can drop down to use some parts of the .Net framework.

For me though in a discussion of ABL vs C# the fact ABL has to hook into .NET to give it quite basic features available in most other programming languages is a negative for ABL.

Don't get me wrong I enjoy coding in ABL, but sometimes It just doesn't do what I want it to without having to find workarounds.

Posted by Marko Myllymäki on 09-Dec-2015 09:25

@Tim: you could build the UI with Visual Studio / C# and call business logic written in ABL in AppServer.

.NET OpenClient could be used for communication between UI and BL.

Posted by Alon Blich on 09-Dec-2015 11:30

why would you use c# for the ui??

the ui can be done using javascript/html/css with zero install and run everywhere including tablets, smartphones etc.. there's no advantages only disadvantages to using a fat client these days.

all the business logic can run on an appserver and the ui runs on the browser making ajax calls to the appserver. there's no need for any other middleware.

again, you cannot build an application without a framework.

Posted by Tim Kuehn on 09-Dec-2015 12:22

[quote user="Alon Blich"] why would you use c# for the ui?? [/quote]

In the context of my question - what would leverage the best of C# and ABL in an application? 

If a shop had lots of C# resources available and no JS resources, then it'd be understandable if they went with C# for the UI. 

Posted by Brian K. Maher on 09-Dec-2015 12:32

Keep in mind that .NET does not equal only C#.
 
C++ or VB are also common choices.

Posted by Marian Edu on 09-Dec-2015 13:00

right, didn't really understood why everyones keep on using .net controls from AVM (one virtual machine loading another) and build the UI in a Java based IDE (got lost on all those VM's already) while there is a far better IDE and tooling for .net and business logic is perfectly accessible through open client.

in fact, the better way will probably be a managed ado.net provider... we're considering doing this based on the JDBC driver we have for accessing 4gl business logic through open-client/appsrv but then again it will be hard to make anyone not follow the herd :)

Posted by agent_008_nl on 09-Dec-2015 14:12

Thumbs up for the first part of your message Marian. I'm more interested in a webui but that is not because of the "beauty" of ccs3/html5/ecma6.  No further comments on the backend, I've shared my thoughts already. Neither .net nor abl would be my choice. But it's very very difficult to choose, lots of considerations and how to value everything...

Posted by dbeavon on 09-Dec-2015 14:24

"...only disadvantages to using a fat client these days..."

In regards to building front-ends for our applications....  It is interesting to me that software developers spend all day long using rich/full client applications like Visual Studio or Eclipse (Excel, Outlook, etc)

Then some of us try *exclusively* pushing web-based front-ends on all our customers (javascript/html/css) .  How does that kind make any logical sense?

As long as I've been a software developer, I've heard that web-based front-ends are going to take over the world.  Its not happening.  In the past five years we've seen a lot of end-user mobile devices and, guess what, they normally work a lot better running native apps too!

If you are convinced that native apps are going away, then try googling Facebook's experience with HTML5.  Long story short - native apps are *not* going away and web apps are *not* taking over the world.  I think a developer should be open-minded about both.

Posted by Rom Elwell on 09-Dec-2015 14:34

dbeavon, Would you agree that to argue either extreme is just as limiting?  While your last statement suggests 'open-minded about both', I infer from the content prior to this statement that you are quite opposed to client-side web apps ('How does that kind make any logical sense' & 'Its not happening' and finally 'Long story short - ...').  With proper architecture and experience, I feel that a team can have success with developing a feature-rich client web app (even a fully-realized ERP client) built on HTML5/CSS3/JS.  

Posted by dbeavon on 09-Dec-2015 16:38

Yes, I think all types of apps have their place.   The lines are especially blurry now that web technologies are being used to build full client apps.

Here are some relatively new web technologies that I'm excited about : (https://angularjs.org and https://cordova.apache.org and http://www.typescriptlang.org and http://electron.atom.io )

Note that I was responding to the unthinkable idea that full client apps would have "only disadvantages" over web-based apps.  You are right to infer that, as a user, I would choose a classic "full client app" over a classic "web app" every time.  Of course if web technologies are used to built something that looks and acts like a full client app, then I won't complain a single bit.

(I get confused when I hear a web developer summarily dismissing the types of apps that they use themselves - every single day.  Instead of saying these things, go eat your own dogfood!)

Posted by agent_008_nl on 10-Dec-2015 00:46

Concerning the web frontend I think small libraries are the future. No angular (maybe 2.0 will be more interesting) or servoy f.e. Even 'giants' (like angular) are on the road to a more modular approach:

blog.wolksoftware.com/microlibraries-the-future-of-web-development

www.codemag.com/.../1501101

The telerik webui components are beauties as far as I have seen.

Posted by Marko Myllymäki on 10-Dec-2015 02:16

@dbeavon: I have exactly the same thoughts about native clients and web clients. The world is moving towards web-based frontends, but the native client is also needed and can not be forgotten. Maybe someday web-based UI is close enough to native UI in terms of usability, performance etc. but that day is not here yet. I had high hopes for Silverlight when it came out, but then Microsoft did the usual thing and changed their strategy completely.

Posted by Marian Edu on 10-Dec-2015 04:47

[quote user="agent_008_nl"]I'm more interested in a webui but that is not because of the "beauty" of ccs3/html5/ecma6.[/quote]

Stefan, was avoiding hijacking the thread here and only commented on the C# part :)

I do think web/mobile can't/shouldn't be ignored, also think native are here to stay (mobile or desktop) so beside mobile/web we should probably start looking at a Qt (http://qt.io) integration for our node.js appsrv (http://akera.io

Posted by egarcia on 10-Dec-2015 07:11

@MarianEdu

Ten years ago or so, I played with QT and GTK in a personal fun project to have a GUI for Linux and QTopia on the Zaurus 5500 that would connect to an OpenEdge backend.

It would be fun to see what new version of QT can do. (I wonder if they would add bindings for Swift.)

Posted by agent_008_nl on 10-Dec-2015 07:40

> Stefan, was avoiding hijacking the thread here and only commented on the C# part :)

> we should probably start looking at a Qt (http://qt.io) integration for our node.js appsrv (http://akera.io)

Funny Marian, so you found an excuse in my reaction to hijack yourself and promote your own business. No offense, just LOL.  :-)

Posted by Marian Edu on 10-Dec-2015 07:56

@Edsel

qt.io really looks impressive and they are addressing mobile as well it seems so worth spending some time in doing a data provider for it

@Stefan

sure thing, knowing you this thread will go on for quite some time so thought to throw in something about what we do... kind of the cheapest marketing option ;)

how's your 'micro' framework going, ready for the future already?

Posted by agent_008_nl on 10-Dec-2015 08:13

My web framework you mean (thumbs up for myself :-)? That's for learning purposes in the first place. No commercial plans, but who knows what it could bring. Got to make a living, less and less oe contractor jobs in Holland.

This thread is closed