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

Posted by Lieven De Foor on 02-Aug-2019 13:27

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

All Replies

Posted by cverbiest on 02-Aug-2019 13:51

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

Posted by James Palmer on 02-Aug-2019 13:58

+1 from here also. Lots of really good improvements listed there, [mention:04e040a388574bee96c841b1935762a5:e9ed411860ed4f2ba0265705b8793d05]

Posted by dbeavon on 02-Aug-2019 14:13

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.

Posted by Mike Fechner on 02-Aug-2019 14:22

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.

Posted by frank.meulblok on 02-Aug-2019 14:27

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 [mention:04e040a388574bee96c841b1935762a5:e9ed411860ed4f2ba0265705b8793d05] 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...

Posted by gus bjorklund on 02-Aug-2019 14:28

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.

Posted by dbeavon on 02-Aug-2019 14:57

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

Posted by Lieven De Foor on 02-Aug-2019 15:08

I'm refraining from reacting to your reply [mention:22b0915eb76243a69eb580cf41e9ee92:e9ed411860ed4f2ba0265705b8793d05] as I can only consider it a way to provoke or stir things up...

Posted by frank.meulblok on 02-Aug-2019 15:37

I could provide an in-depth reaction to [mention:22b0915eb76243a69eb580cf41e9ee92:e9ed411860ed4f2ba0265705b8793d05] , 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.

Posted by James Palmer on 02-Aug-2019 15:45

FYI, as per [mention:6e3b17cb0ff148039a2aabb4c7834ce4:e9ed411860ed4f2ba0265705b8793d05] 's suggestion, we will look to provide a forum for this discussion at EMEA PUG Challenge in Barcelona.

Posted by gus bjorklund on 02-Aug-2019 15:50

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.

Posted by Oleg Kupershmidt on 02-Aug-2019 18:28

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

Posted by Lieven De Foor on 05-Aug-2019 07:36

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

Posted by Richard.Kelters on 05-Aug-2019 08:20

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

Posted by Lieven De Foor on 05-Aug-2019 09:53

One could argue that ABL doesn't need functional programming concepts like anonymous methods/lambda expressions.

Yet we can already specify an event handler, which is in effect passing a reference to a method, to an Event:Subscribe() call. So some of it is already there (and might even get used in its current form to achieve something similar, now that I think about it...)

++/+= etc. are just, in my view, syntactic sugar, just like the Elvis operator, to write shorter code:

IF VALID-OBJECT(MyObject) THEN MyObject:DoSomething().

vs

MyObject?:DoSomething().

I would expect these to be reasonably easy to implement (but please correct me if I'm wrong)

Posted by Peter Judge on 05-Aug-2019 14:26

Having typed too many IF VALID-OBJECT statements I'd vote for Elvis :)
 

Posted by doavandoorn on 06-Aug-2019 08:02

Around 10 years Progress forgets it has a product like OpenEdge. Then suddenly for a few years so much new functionality comes into the ABL that it was hard to keep up with. And now the last two years the ABL looks forgotten again.

I support Lievens' statement.

Like people in previous posts who would like the (horrible) Elvis operator. The first annoying thing that comes to mind also has to do with shorter code. I would like have to possibility to NEW an object when defining it.

Instead of:

DEFINE VARIABLE oSomeObject AS Com.Package.SubPackage.Class NO-UNDO.

oSomeObject = NEW Com.Package.SubPackage.Class ().

I would like:

DEFINE VARIABLE oSomeObject AS NEW Com.Package.SubPackage.Class() NO-UNDO.

Posted by goo on 06-Aug-2019 08:48

This one I really do not agree. I like to differ between define and use, clean code.

Posted by Rutger Olthuis on 06-Aug-2019 08:54

@goo you don't have to use a certain feature. I would love to be able to work with variable scoping in blocks like java, would also love to be able to initiate an object during it's definition (imho it's cleaner but that's personal). And yeah ++ operators would make my code a lot cleaner too.

Posted by Håvard Danielsen on 06-Aug-2019 12:24

I spent close to 10 years alternating between ABL and Java programming and found the variable definition syntax and variable scoping in the ABL being the ABL's biggest obstacle ... by far. (Other than that I think the drawbacks and benefits mostly evens out.)  Even if you strive to make methods small there are many cases where the variable definition is or has to be added out of sight. Even if it "just" takes seconds to navigate up and down it adds up and severely affects overall efficiency and productivity.  

The variable syntax is particularly problematic and verbose for class/object definitions where you very often just want to define and new the variable and you also really don't want the scope outside the block it is used.  

--

Since it would require entirely new syntax and scoping I would make the syntax similar to  ABL function and method parameter definitions and  other OO languages and omit the "define variable" and make no-undo default.  .

Myclass myclass = new MyClass().

--

I did ask language development about the feasibility of doing this a long time ago and got a rather strange and scared look and decided to not mention it again...  On the other hand the language is block oriented and we already handle different scoping of parameters versus variables, so it may not be impossible...  

I suspect this will not get a lot of votes from ABL-only programmers, but it would be important to be able to attract those young developers as mentioned above in this thread..    

Posted by Richard.Kelters on 06-Aug-2019 13:54

To make a little more 4GL maybe

VARIABLE SomeClass AS SomeClass = NEW SomeClass().

Block scoping is something I've wanted once in while too!

Posted by Matt Baker on 06-Aug-2019 14:05

Why not cut it down even more to what other languages are doing. Specificaly python, javascript, java, C# and probably others.

var myobj = new Someclass().

var myint = 3.

var mystr = "somestring".

var something = myobj:GetSomething().

The compiler detects the resulting data type of the expression for the right side of the assignment and use that as the type of the variable from that point on in the code forward.  No need for the extra "variable" and "as someclass".  In addition, if "GetSomething()" is modified to return something else, I don't have to rewrite my variable definition.

Posted by Lieven De Foor on 06-Aug-2019 14:53

Yes, type inference (not to be mistaken with dynamic typing, let's not go there...) would be nice indeed.

Posted by onnodehaan on 06-Aug-2019 15:20

Hi Guys,

The thing that bothers me most is that even the simple

and small improvements are not done.

The language could be made a lot better with simple changes to the syntax.

ABL has almost come to a stand-still compared to other languages, it feels. Which i find sad, because it forces people to look for alternatives.

Posted by onnodehaan on 06-Aug-2019 15:20

Hi Guys,

The thing that bothers me most is that even the simple

and small improvements are not done.

The language could be made a lot better with simple changes to the syntax.

ABL has almost come to a stand-still compared to other languages, it feels. Which i find sad, because it forces people to look for alternatives.

Posted by danielb on 06-Aug-2019 23:19

I would disagree with the comment of "more reliable or easier to maintain". These languages come with frameworks, frameworks that are supported, maintained and popular in the community.

With an "inferior" language like C#, I got 100% compile time checking (unless I did something like reflection). With the ABL, that only got added for class methods - no compile time checking of parameters for procedures or functions.

With an "inferior" language like C#, I can get frameworks that support package and dependency management (nuget). Progress? Nope, that's all up to the individual development house.

With an "inferior" language like C#, I can get supported frameworks to do dependency injection, mocking, and unit testing. Progress? ABL Unit, but no support for Dependency Injection or mocking of a database to run tests in memory.

With an "inferior" language like C#, I need a connection string only to create/update a database - the broker manages all that. With Progress, I more permissions to the server to create the database and database folders, generate the database, load the schema, etc.

Making claims like "inferior" is fine when talking internally, but when development houses have to look at real world problems like the cost of training, the cost of hiring specifically for the ABL, that argument tends to fail. When we can take any graduate from university and have them productive in C# or Java quicker than the ABL, that's a real business impact that needs to be addressed.

Posted by danielb on 06-Aug-2019 23:20

We can't get compile time checking of function and procedure arguments, so we're not going to get this.

Posted by marian.edu on 07-Aug-2019 06:06

Lieven, maybe something like Xtend (https://en.wikipedia.org/wiki/Xtend) could be an option to add some of that syntactic sugar and more. This could make the syntax less verbose, add some better defaults (no-undo) and type inference among other things but it will compile an extra pre-compile (code generation) step… this could work just fine in Eclipe (PSDOE) environment though. 

Marian Edu

Acorn IT 
www.acorn-it.com
www.akera.io
+40 740 036 212

Posted by agent_008_nl on 13-Aug-2019 09:14

Maybe the 4GL should resemble superior languages like haskell or erlang then? :-) But anyway, the business strategy of psc resembles placate and appease for many years already. I can understand that.

Posted by agent_008_nl on 13-Aug-2019 10:19

 Hahaha. More toys for boys!

Posted by agent_008_nl on 13-Aug-2019 15:33

Much agreed Gus.

> One might argue they have made things worse, but that is a topic for another day.

I would appreciate some argumentation here (links are perfect) as many members seem to love making everything more complex / less maintainable.

I love refactoring macho code (made with toys for boys) and half work, but would rather build some more new things. :-)

Posted by agent_008_nl on 13-Aug-2019 17:01

A mass of ideas www.youtube.com/watch

Domain driven design, FP vs  OO and typesystems. Use them to your benefit.

Posted by onnodehaan on 13-Aug-2019 19:07

[mention:5a647afc67ec4e118db4fd9337f8a264:e9ed411860ed4f2ba0265705b8793d05] : perhaps that’s making the discussion a bit to broad...

Posted by agent_008_nl on 14-Aug-2019 03:14

[mention:ce4312d1e00542be918fe616c695a5de:e9ed411860ed4f2ba0265705b8793d05]

 I would like to cut it down and reject monstertrucks. Also: a plaster upon a plaster does not help much in healing the wound - also read the famous paper "out of the tarpit" http://curtclifton.net/papers/MoseleyMarks06a.pdf for a "potential complexity-minimizing approach", the paper is a reaction on the book "Mythical man month" by turing award winner Fred Brooks who talks about "Software like a tar pit: The more you fight it, the deeper you sink!" (know your classics!) -.

  Psc could take the role of thoughtleader instead of follower of a couple of loud voices here. But it has chosen a third way, understandably.

Posted by Arno van der Ende on 19-Aug-2019 07:52

+1

Some OOABL ideas, (i.e. 'Generics') are requested in 2014 (or perhaps even earlier)

community.progress.com/.../openedge

Posted by agent_008_nl on 21-Aug-2019 08:02

naildrivin5.com/.../four-better-rules-for-software-design.html  :

"I’ve written before about conceptual overhead, and a nice side effect of reducing the number of concepts in a system is that you increase the number of people who can understand the system. This, then, increases the number of people who can make changes to the system. Certainly, a software design that can be safely modified by a large group of people is better than one that can only be modified by fewer. [..] Code isn’t art that you print out and put in a museum. Code is executed. It is observed and debugged. And, most importantly, it is changed. A lot. Any design that makes these things hard to do should be questioned and revised. Any design that reduces the number of people that can do these things should also be questioned."

Posted by dbeavon on 21-Aug-2019 13:29

As I was saying earlier, there may be a deliberate reason why ABL isn't evolving.  I see that the point is being made for me.  

It is fairly easy to come up with reasons why a language should be simple.  Nobody wants complexity for its own sake.  But neither do people want to tackle a huge project with the wrong programming tools.  For example, I wouldn't want to excavate a swimming pool with a tablespoon.  Sometimes that's what it feels like to be using ABL.  Ideally a programming language will meet the needs of both entry-level developers and more mature ones.  It should solve simple problems as well as very complex ones.

A good programming language will also create abstractions.  The abstractions allow the code to remain just as maintainable as ever, but with increasing power and functionality.  I think of C# with abstractions for OO, threading, ORM, lambda's, async/await,  etc.  All of these features of the language are very simple to use, since C# provides a language syntax that is very approachable.

One of the biggest failings of the ABL language might be its inability to use the available CPU resources.  As you may know, computers nowadays have many, many cores.  Modern languages have syntax and patterns that allow software to be executed on more than one core at a time, and then they allow subsequent synchronization after the CPU work is finished.  ABL is unwilling to acknowledge the existence of more than one core.  But then again, I suppose someone may give us a reason why 15 of my 16 cores should remain idle even though there is a lot of work that is waiting to execute (and there is tons of available capacity in terms of disk/network/whatever).

Posted by agent_008_nl on 21-Aug-2019 14:51

[mention:77d0f2ca82a041a08c26cc89b12b968e:e9ed411860ed4f2ba0265705b8793d05]  on multicore:

Have you seen how erlang (and elixir on top of it) handles multicore?

Here a presentation from Joe Armstrong: www.youtube.com/watch

And here the mindblowing movie Erlang The Movie II: The Sequel   www.youtube.com/watch

"Why programming languages ​​like Java, C, C++, C#, etc.., don’t fit well in these new computing architectures? Well this is due to several factors, but let’s start talking about two that might be the most relevant: mutable state and concurrency. [..]"

cabol.github.io/.../

"How can we write programs that run faster on a multicore CPU? It’s all about mutable state and concurrency.". (Programming Erlang, Software for a Concurrent World – 2007. Joe Armstrong)

C# has akka.net https://vimeo.com/189191045 en java akka  using the concurrencymodel (actor) from erlang btw. 

> A good programming language will also create abstractions.  The abstractions allow the code to remain just as maintainable as ever,

> but with increasing power and functionality.  I think of C# with abstractions for OO, threading, ORM, lambda's, async/await,  etc.

> All of these features of the language are very simple to use, since C# provides a language syntax that is very approachable.

In my view lots of programmers shoot themselves in the foot using f.e. OO. OO features are definetely not simple to use, and it is debatable if it is wise to use them at all. A debate: https://queue.acm.org/detail.cfm?id=2611829 , the writer is Erik Meijer who has been developing C# (he was the inventor of LINQ f.e.).

Posted by agent_008_nl on 21-Aug-2019 14:51

emptied (for some reason a copy of my prev message appeared here)

Posted by agent_008_nl on 24-Aug-2019 15:46

Yet another call to be carefull with (OO) additions to a language by Tony Hoare (from an interview 2002). "Sir Antony Hoare is Senior Researcher at Microsoft Research in Cambridge, England, and Research/Professor Emeritus at the University of Oxford. Hoare is the recipient of the A.M. Turing Award for fundamental contributions to the definition and design of programming languages.":

"Programming languages on the whole are very much more complicated than they used to be: object orientation, inheritance, and other features are still not really being thought through from the point of view of a coherent and scientifically well-based discipline or a theory of correctness. My original postulate, which I have been pursuing as a scientist all my life, is that one uses the criteria of correctness as a means of converging on a decent programming language design—one which doesn’t set traps for its users, and ones in which the different components of the program correspond clearly to different components of its specification, so you can reason compositionally about it."  See the complete text in the pdf here: conservancy.umn.edu/.../107362

  I would say you first at least make up your mind about inheritance before you ask for even more OO features.

Posted by JZimmermann on 26-Aug-2019 09:18

Coming a little bit late to this discussion :-)

In my opinion Gus is perfectly right - many of this extensions will make ABL more like Java or C#. While this is not necessarily a bad thing (we really want SOME of them, too) Gus already mentioned it - if I want to code in Java, I can do, because Java already exists.

In my opinion Progress should rethink the AB in ABL - as far as I know this means "Advanced Business" ... so it is worth thinking of what Business Software looks like and how you can help developers in writing this kind of software - and there are many concepts out there and there is a lot Progress could improve on the current language constructs.

What troubles me: while Gus is perfectly right I can't really see that Progress has a vision towards this. I am very fine with the statement, that Progress does not aim to mimic Java or C# - but then we need a vision from Progress! I am thankfull for language extensions like generics and annotations, but what I would like to see most is a broader vision about the "Advanced Business Language" and how to keep on top of languages like Java or C# in terms of Business Software.

Another Topic:

Sorry - I don't know how to cite here, now I am reffering to a post from danielb on 7th of August ...

Most of the points in there are about tools and the tool chain ...

Of course danielb is right, Progress is lacking many of those tools. And it would be great, if Progress would provide some of these.

And although I really think Progress should carefully check, what kind of tools are out there in other languages and should give us at least some of them, we should not be unfair ... if you look at languages like C# or Java, many, many of these tools are created and maintained by the community.

Progress Community will never get as big as the C# or Java community, but still - we could do better ... I had an interesting discussion last week about this topic.

I think, part of the problem is that most of the Progress Customers are coming from commercial companies. I am sure, there are many frameworks and little helpers out there, but as they are created from employes during their work time they are seldom published. That is a pity and it might be worth to discuss this topic somehow ... I have no idea how to even start a good discussion about that, because of the reason I gave above, but perhaps someone else has a good idea.

At least I will try to start a discussion in my company, as I really think we should do something about it, but this would also need some help from the community, some infrastructure like Repos, or a Package Manager or ... I don't know :-)

Posted by Mike Fechner on 26-Aug-2019 14:08

Hi Jochen,
 
I think a package manager for ABL components would be a very valuable tool to have. An ABL NuGet, npm, …
 
Challenge is not so much to implement the package manager. One challenge is to define which kind of artifacts to deliver and how to integrate that into existing projects. A PL is only able to contain (in a useful way) R-Code. But components might provide include file as source code etc and other files (config files, JSON, XML, XSD, Images, …).
 
IMHO it’s no option, that every imported component should add a large number of folders to the propath. One PL in the PROPATH per component would be desirable, more like an assembly in .NET which can contain various resources.
 
So once a PL is upgraded, a package manager would be much simpler to implement. Or maybe NuGet or npm might be used in their current form already.

Posted by egarcia on 26-Aug-2019 15:54

Hello Mike, Jochen,

Thank you for bringing up about package manager.

> I think a package manager for ABL components would be a very valuable tool to have. An ABL NuGet, npm, …

> Challenge is not so much to implement the package manager. One challenge is to define which kind of artifacts to deliver and how to

> integrate that into existing projects. A PL is only able to contain (in a useful way) R-Code. But components might provide include file as

> source code etc and other files (config files, JSON, XML, XSD, Images, …).

+1

Yes, I think that the key is the artifacts to deliver and how to integrate into existing projects.

I have worked with npm and RPM.

I think that ABL components can be managed with either of these package managers.

npm certainly being platform independent.

Thanks.

Posted by jankeir on 26-Aug-2019 16:04

Regarding package management, this is typically taken care of as part of a build pipeline. Almost all pipelines that are likely to adopt whatever package management any one offers at this point uses ant with PCT.

PCT has Apache Ivy to take care of this. We have implemented this locally and it works fine (we use Sonartype's nexus as repository which is basically a maven repo, but it contains zip files with abl r files in our case). The build pipeline pulls in a zip file for each dependency and flattens the various dependencies into a single tree for the actual run time.

Basically all that's needed is adding <target name="get-dependencies"><get-dependencies/></target> and xmlns:ivy="antlib:org.apache.ivy.ant" to build.xml and create an ivy.xml file that lists the dependencies:

<ivy-module version="2.0">

<info organisation="com.tvh" module="ms-whatever" revision="1.0"/>

  <publications>

  <artifact name="ms-whatever" type="zip" ext="zip"/>

  <artifact name="ms-whatever-full" type="zip" ext="zip"/>

</publications>

  <dependencies>  

    <dependency org="com.consultingwerk" name="scl" rev="1.0">  

      <artifact name="scl" type="zip" ext="zip"/>  

</dependency>  

  </dependencies>

</ivy-module>

No coding is needed for this, no changes to .pl files, no significant change in the way people work with building,...

If someone were to set up/host a public repo and write some tutorials it could be a problem from the past. I must admin though that it is not something I am volunteering to do.

Posted by jankeir on 26-Aug-2019 16:04

Regarding package management, this is typically taken care of as part of a build pipeline. Almost all pipelines that are likely to adopt whatever package management any one offers at this point uses ant with PCT.

PCT has Apache Ivy to take care of this. We have implemented this locally and it works fine (we use Sonartype's nexus as repository which is basically a maven repo, but it contains zip files with abl r files in our case). The build pipeline pulls in a zip file for each dependency and flattens the various dependencies into a single tree for the actual run time.

Basically all that's needed is adding <target name="get-dependencies"><get-dependencies/></target> and xmlns:ivy="antlib:org.apache.ivy.ant" to build.xml and create an ivy.xml file that lists the dependencies:

<ivy-module version="2.0">

<info organisation="com.tvh" module="ms-whatever" revision="1.0"/>

  <publications>

  <artifact name="ms-whatever" type="zip" ext="zip"/>

  <artifact name="ms-whatever-full" type="zip" ext="zip"/>

</publications>

  <dependencies>  

    <dependency org="com.consultingwerk" name="scl" rev="1.0">  

      <artifact name="scl" type="zip" ext="zip"/>  

</dependency>  

  </dependencies>

</ivy-module>

No coding is needed for this, no changes to .pl files, no significant change in the way people work with building,...

If someone were to set up/host a public repo and write some tutorials it could be a problem from the past. I must admin though that it is not something I am volunteering to do.

Posted by jankeir on 26-Aug-2019 16:08

hehe, get-dependencies is a macro, it takes slightly more but not that much:

           <ivy:settings file="ivysettings.xml" />

           <ivy:cleancache />

           <ivy:resolve/>

            <unzip-dependencies source-dir="@{target-dir}" target-dir="@{target-dir}"/>

where unzip-dependencies is a macro that does this:

            <unzip dest="@{target-dir}">

               <fileset dir="@{source-dir}">

                   <include name="**/*.zip"/>

               </fileset>

           </unzip>

Posted by OctavioOlguin on 26-Aug-2019 22:06

+100

Posted by Shao Chan on 13-Sep-2019 23:03

Personally, I've always liked pretty much everything about Progress and not really fussed about whether it has bolt-on's to be similar to modern languages - its about the speed and ease at which the application can be developed.

The biggest problem with Progress is purely to do with integration.  Whilst in the past Progress could live in its own world and companies only had one main application to support their business, its a whole inter-connected world out there.  When doing any integration, Progress has always been a sore point.  You can get all other database vendors into a room for applications to integrate with each other, but there will always be a separate 'How does Progress do it' meeting.

Whether its ODBC, SOAP, REST, SSL, whatever, Progress will not integrate reliably to the same level as other technologies such that you need to look for workarounds which then wipe out the advantages of using Progress to build the application at pace.  

bprowsdldoc hangs on many WSDLs and the -show10style option needs to be used to get a basic wsdl.  Code pages not supported.  Cipher suites not supported.  All these things make it so that even if you get code working in one instance, a change at the target end and you're looking for workaround solutions - often with other technologies.

For any kind of capability in the integration area, Progress needs a programme called 'Challenge Progress' or something where you send the endpoints you need to integrate with and either they get it working or they patch it so that it works in the next version.

Posted by onnodehaan on 13-Sep-2019 23:11

Hi Shao Can,

Agreed. For example: I've logged a request for a problem in the WRITE-JSON and am waiting for over a year now... such a long waiting time pretty much forces a person away from ABL and into other techniques. Which is a shame.

Another example is in calling out to a SOAP-service. It has client-side certificates; which is not supported properly in ABL. We have written our own in-between service in JavaScript for this.

Posted by onnodehaan on 13-Sep-2019 23:11

Hi Shao Can,

Agreed. For example: I've logged a request for a problem in the WRITE-JSON and am waiting for over a year now... such a long waiting time pretty much forces a person away from ABL and into other techniques. Which is a shame.

Another example is in calling out to a SOAP-service. It has client-side certificates; which is not supported properly in ABL. We have written our own in-between service in JavaScript for this.

Posted by Shao Chan on 13-Sep-2019 23:23

Hi onnodehaan.  Yes, that's exactly the kind of thing I'm talking about.  They need to get things like mutual authentication working, good integration with the leading JMS (RabbitMQ) and/or integration via AMQP to messaging brokers.  They need to analyse integration technology platforms in the cloud and ensure that if a Progress system is on one end of the integration, there are options open for integration without workarounds.  All this is the real important stuff.  Without it, there is simply no point unless you're creating isolated standalone applications.

Posted by onnodehaan on 14-Sep-2019 07:41

I recognize your point about "'How does Progress do it' meeting". That is in fact very true. We have a large customer (hundreds if not thousands of users, 300GB+ database) that uses 5 different ERP-systems within the conglomerate. Granted.. 1 of those systems is very old, but the other 3 are way ahead of Progress in connectivity. That sometimes forces them away from modules in our ERP into the hands of competing ERP-system. In the long run, that's not a sustainable situation. Currenlty its impossible to address those issues with ABL, and unfortunately PSC seems unaware of this problem.

Posted by Lieven De Foor on 10-Oct-2019 07:26

For those interested and attending the PUG Challenge in Barcelona at the end of the month, Mike Fechner and I will be hosting a session on Wednesday October 30th to discus this topic with people from the community and Progress. Hope to see you there!

Posted by Jean-Christophe Cardot on 10-Oct-2019 07:59

Good to hear! I will definitely attend!

This thread is closed