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().
I would expect these to be reasonably easy to implement (but please correct me if I'm wrong)
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.
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.
This one I really do not agree. I like to differ between define and use, clean code.
@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.
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..
To make a little more 4GL maybe
VARIABLE SomeClass AS SomeClass = NEW SomeClass().
Block scoping is something I've wanted once in while too!
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.
Yes, type inference (not to be mistaken with dynamic typing, let's not go there...) would be nice indeed.
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.
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.
We can't get compile time checking of function and procedure arguments, so we're not going to get this.
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.