Evolution (or the lack thereof) and future of the OpenEdge ABL - Forum - OpenEdge Development - Progress Community

Evolution (or the lack thereof) and future of the OpenEdge ABL

 Forum

Evolution (or the lack thereof) and future of the OpenEdge ABL

  • With the CVP (Customer Validation Program) OpenEdge developers and users can be more involved in the evolution of the OpenEdge products.
    We get early access to test new features and are able to give feedback and direction to the items being worked on.
    Although better tooling, new product features, performance enhancements etc. are all nice, the main missing item being worked on is the ABL language...
    For years no new major features have been added.
    The last addition I can recall was enums.
    I would like to, once more, draw OpenEdge product managements attention to the importance of the language for us developers.
    Over the past years I've been adding feature requests to the community "Ideas" section, only to see my enthousiasm diminish year after year...

    My questions to Progress are:
    - What are the plans, if any, with the language?
    - What's on the roadmap?
    - Can we get some feedback, any feedback at all, to the items posted at community.progress.com/.../openedge

    Let me list just a few existing requests:
    - Generics community.progress.com/.../complete_oo_functionality_in_abl
    - Ability to override properties
    - Indexed properties
    - Remove the need to use procedures (where methods would be more appropriate) community.progress.com/.../remove_need_to_use_procedures_where_methods_would_be_more_appropriate
    - Extend reflection support
    - for annotations community.progress.com/.../reflection_-_support_for_annotations
    - to get initial value of variable/property community.progress.com/.../enhance_reflection_functionality_to_get_initial_value_of_variableproperty
    - Operator overloading community.progress.com/.../operator_overloading
    - Add ++/-- and +=/-= function community.progress.com/.../add_--_and_-_function
    - LOOKUP method on array (extent) community.progress.com/.../lookup_method_on_array_extent
    -> Not needed if Generics would be there...
    - Support for inner/nested classes community.progress.com/.../support_for_innernested_classes
    - Support for default method implementation in interfaces (controversial, I know...) community.progress.com/.../support_for_default_method_implementation_in_interfaces
    - INITIAL option supported for CLASS variables community.progress.com/.../initial_option_supported_for_class_variables
    - Support for named arguments / optional arguments community.progress.com/.../support_for_named_arguments__optional_arguments
    - Support for delegates + anonymous methods and/or lambda expressions community.progress.com/.../support_for_delegates__anonymous_methods_andor_lambda_expressions
    - Null conditional (Elvis) operator community.progress.com/.../null_conditional_operator

    Also, some feature requests were implemented but still not marked as such in the Ideas forum:
    - Add ability to pass datasets asynchronously community.progress.com/.../add_ability_to_pass_datasets_asynchronously
    - Allow EMPTY-TEMP-TABLE on temp-table handle (currently only possible on a buffer handle) community.progress.com/.../allow_empty-temp-table_on_temp-table_handle_currently_only_possible_on_a_buffer_handle
    Please mark these as "Complete"

    I would suggest to also take a look at languages like Kotlin and the features they have:
    - Smart casts kotlinlang.org/.../typecasts.html
    - First-class delegation kotlinlang.org/.../delegation.html

  • +1

    for the smart cast's it would be very nice if temp-tables could contain objects other than progress.lang.object and all the necessary casts would be done automatically. This would be particulary nice with enum objects if fill & save-changes would be capable of automattically mapping to the apprioprioate database datatypes.

    This is an example of idea I've been walking around with for quite some time, but I don't know if it would help posting it in the idea section.

  • +1 from here also. Lots of really good improvements listed there,

  • I would agree that the language has remained quite primitive.  Sometimes I think it may be deliberate.  If the ABL language actually did have all the things you mentioned then at some point Progress would be force to stop touting how "simple" it is (they used to say that even a line-of-business power-user could build an app with it).

    Additionally the language would eventually have to face off with the likes of Java or C# one day.  That might not go so well.  I think ABL is intended to be complementary to .Net or Java rather than go head-to-head with them.

    I don't want to hijack your thread, but one thing I've always hoped Progress would do (even more than extending OOABL) is to  cross-compile to another language or, better yet, compile itself into the bytecode of another runtime. It would be extremely helpful if we could compile to MSIL or Java bytecode, or even web assembly.  That would allow us to more easily integrate with the software from the other larger ecosystems.  All of them have *open* standards and the related communities are *huge* - and they are certainly big enough to where ABL could play along.  The advantage would be the *size* of the community (multiple languages, numerous libraries, ORM's to choose from, etc).  To me the ABL language is analogous to an ORM - it is good for interacting with relational databases but is quite limited in many other areas.  If it were part of another larger ecosystem, then the limitations of ABL would not *feel* quite as limiting - because we would be able to easily hop outside the walls of the ABL language and incorporate solutions from the rest of the community.  

    Again, I totally agree that the OOABL language needs a lot of TLC.  But Progress is "only" a two billion dollar company and they have lots of competing priorities.  And within this two billion dollar company, there is also a diversity of products.  Progress doesn't invest exclusively in OpenEdge.

  • Very valid points Lieven!!! And a few of those are really missing features that make it hard to "sell" OOABL to young developers and put the future of the community at risk!

    If I'd still be in charge of running PUG Challenges, I'd invite you to do a birds of a feather session on that subject at the October PUG Challenges.

    Sent from Nine

    Von: Lieven De Foor <bounce-lievendefoormipsbe@community.progress.com>
    Gesendet: Freitag, 2. August 2019 15:29
    An: TU.OE.Development@community.progress.com
    Betreff: [Technical Users - OE Development] Evolution (or the lack thereof) and future of the OpenEdge ABL

    Update from Progress Community
    Lieven De Foor

    With the CVP (Customer Validation Program) OpenEdge developers and users can be more involved in the evolution of the OpenEdge products.
    We get early access to test new features and are able to give feedback and direction to the items being worked on.
    Although better tooling, new product features, performance enhancements etc. are all nice, the main missing item being worked on is the ABL language...
    For years no new major features have been added.
    The last addition I can recall was enums.
    I would like to, once more, draw OpenEdge product managements attention to the importance of the language for us developers.
    Over the past years I've been adding feature requests to the community "Ideas" section, only to see my enthousiasm diminish year after year...

    My questions to Progress are:
    - What are the plans, if any, with the language?
    - What's on the roadmap?
    - Can we get some feedback, any feedback at all, to the items posted at community.progress.com/.../openedge

    Let me list just a few existing requests:
    - Generics community.progress.com/.../complete_oo_functionality_in_abl
    - Ability to override properties
    - Indexed properties
    - Remove the need to use procedures (where methods would be more appropriate) community.progress.com/.../remove_need_to_use_procedures_where_methods_would_be_more_appropriate
    - Extend reflection support
    - for annotations community.progress.com/.../reflection_-_support_for_annotations
    - to get initial value of variable/property community.progress.com/.../enhance_reflection_functionality_to_get_initial_value_of_variableproperty
    - Operator overloading community.progress.com/.../operator_overloading
    - Add ++/-- and +=/-= function community.progress.com/.../add_--_and_-_function
    - LOOKUP method on array (extent) community.progress.com/.../lookup_method_on_array_extent
    -> Not needed if Generics would be there...
    - Support for inner/nested classes community.progress.com/.../support_for_innernested_classes
    - Support for default method implementation in interfaces (controversial, I know...) community.progress.com/.../support_for_default_method_implementation_in_interfaces
    - INITIAL option supported for CLASS variables community.progress.com/.../initial_option_supported_for_class_variables
    - Support for named arguments / optional arguments community.progress.com/.../support_for_named_arguments__optional_arguments
    - Support for delegates + anonymous methods and/or lambda expressions community.progress.com/.../support_for_delegates__anonymous_methods_andor_lambda_expressions
    - Null conditional (Elvis) operator community.progress.com/.../null_conditional_operator

    Also, some feature requests were implemented but still not marked as such in the Ideas forum:
    - Add ability to pass datasets asynchronously community.progress.com/.../add_ability_to_pass_datasets_asynchronously
    - Allow EMPTY-TEMP-TABLE on temp-table handle (currently only possible on a buffer handle) community.progress.com/.../allow_empty-temp-table_on_temp-table_handle_currently_only_possible_on_a_buffer_handle
    Please mark these as "Complete"

    I would suggest to also take a look at languages like Kotlin and the features they have:
    - Smart casts kotlinlang.org/.../typecasts.html
    - First-class delegation kotlinlang.org/.../delegation.html

    View online

     

    You received this notification because you subscribed to the forum.  To stop receiving updates from only this thread, go here.

    Flag this post as spam/abuse.

    Architect of the SmartComponent Library and WinKit

    Consultingwerk Ltd.

  • Given how parts of the Ideas section are overrun by spambots (and have been for months, at least) I'm not sure if posting anything there would help.

    It's obvious that part of the site isn't properly maintained even without looking at the submitted content. (Which as pointed out, also are not updated when appropriate)

    That said, I could really do with support for named arguments, and with being able to use methods as callback handlers directly, without having to inject a persistent procedure just to route events back into the class.

    Especially when OpenEdge itself could supply an Interface types for the supported callbacks, so a) the built-in objects that use them doesn't need to consider multiple ABL types to know a handler is valid, and b) I don't have to maintain code templates with all the required signatures anymore...

  • Lieven, many of the things on your list seem like wonderful additions. But, at best, those features and others like them make the 4GL resemble inferior languages like Java and C# all the more. Those languages are immensely popular but have accomplished little to nothing toward making software development easier or software more reliable or easier to maintain. One might argue they have made things worse, but that is a topic for another day.

    The 4GL should strive to be BETTER than those langauges, not to be like them.

  • >> (Adding) those features and others like them make the 4GL resemble inferior languages like Java and C# all the more

    See? This enforces my reasoning that there may be a deliberate reason why ABL isn't evolving.  Any attempt to encroach on .Net and Java would probably end badly.  I'm just happy that we have OOABL (and S.E.H.) in the first place.

    @gus You aren't going give the developers in other communities any credit for "easy" development?  And no credit for creating "reliable" and "maintainable" software?  Even Progress OpenEdge products are packed *full* of Java for appserver, pasoe, pdsoe, sonic adapter, admin server, etc. Progress would never attempt to use ABL for these purposes.  Based on my nosey questions to them, I don't think Progress even uses ABL for it's own internal ERP nor for other applications.  Do you think Microsoft uses its own .Net?  Do you think Oracle ever uses Java?

    I would encourage you to go and google some of the sample code that demonstrates how to interact with a relational database from an ORM.  (Either Java or .Net).  You might be surprised how easy, reliable, and maintainable the code would look to you (maybe you would even find it familiar to ABL!)  

    You mentioned their popularity and it is worth pointing out the popularity ratings.  Some people might be surprised just how popular those other programming languages are these days ( see pypl.github.io/PYPL.html and www.tiobe.com/.../ ).  

    ABL certainly has a place, but I would certainly not use words like "superior" / "inferior".  There is a reason why there are dozens of modern languages for software developers to choose from.  Every one of them has a purpose.

  • I'm refraining from reacting to your reply as I can only consider it a way to provoke or stir things up...

  • I could provide an in-depth reaction to , but my time's better spent writing more wrapper code to cover up for the AVM's missing features that would make it possible to more easily write more maintainable code.

    I'll leave it at: The ABL is a language tailored to specific types of applications, where Java and .NET are much more general-purpose languages. In that regard, it's fine that ABL is more restricted in some ways and thus less complex. But that's no excuse for it not being feature-complete.

  • FYI, as per 's suggestion, we will look to provide a forum for this discussion at EMEA PUG Challenge in Barcelona.

  • Frank,

    I did not mean to imply that the 4GL does not need improvement. It certainly does. My point was that making it into a Java (or C#) clone is not the right thing to do. Anyone who wants to write in Java already has a fine way to do that.

  • Dear all,

    Our product team has been and is continuing to make improvements to ABL. Details of ongoing and future work can be discussed in CVP community.

    Thank you for your support,

    Oleg

  • Hi Oleg, thank you for your reaction.

    I've created a thread in the CVP forum as well, pointing to this one, but I could copy/paste the contents of the start post if that's more convenient.

    Would it be possible to get some feedback there as to what's being worked on or what's planned in the ABL (just the language)?

    Thanks

  • I agree on a lot of your points Lieven. The ones I don't think belong to a 4GL:

    • Add ++/-- and +=/-= function
    • Null conditional (Elvis) operator
    • anonymous methods and/or lambda expressions