“There ain’t no such thing as a free lunch.” - Moore’s Law

Given 2004 is already passed for quite some time now, what do you think a ‘business logic’ language should do about concurrency? Apart for a parallel execution that could be implemented in database/application server I don’t see anyone needing complex algorithms processing in a regular business application and doubt anyone would consider using the 4gl for building games, graphical processing, AI, or anything else that require much CPU attention. 

Not to mention that the architectures we are using these days has the client spread across a large number of machines with very lightweight front ends and the database code is not ABL, so the only possible impact is in AppServer code which is inherently a large number of separate processes with their own context.

> Given 2004 is already passed for quite some time now, what do you think a ‘business logic’ language should do about concurrency?

I think it cannot do much. No ROI to be expected. At least developers of new languages take the hardware trend into account, they are not chained to that leaden ball of the past.

> I don’t see anyone needing complex algorithms processing in a regular business application and doubt anyone would consider using the 4gl for building games, graphical processing, AI, or anything else that require much CPU attention.

For simple applications and maybe conservative vendors with not too much ambition and imagination (sorry) oe will be ok. Softwarehouses with ambition will find out how to get profit from the hardware improvements. It's at least interesting to imagine what would be possible outside the bounds you are used to. And who will buy into oe nowadays, knowing what else is available.

Concerning the complex algoritms processing you name: the article does not name much more concurrency techniques than traditional multi-threading. That is complex to do right. But there are other concurrency models, like the actor model, used in akka programmers.stackexchange.com/.../why-is-akka-good-for-concurrency and erlang / elixir f.e. (much more and deeper  explanations to be found with google). Since you're besides oe a node lover (and node seems to be rather 'in' in the community) I'll add another article joearms.github.io/.../Red-and-Green-Callbacks.html. Now isn't Joe explaining this clear and simple? :-)

  Edit: deeper explanation concerning the problems of tradional mt & actor model:

http://www.coastrd.com/multithreading-with-the-actor-model

Having worked on some very large systems on a variety of different languages and databases... Multi-threading inside of a programming language is highly overrated. There are much better ways to solve performance and scaling issues than making any given client do more work.

When a developer decided that MT was needed there was almost always a design issue or a programming issue that needed to be resolved instead of just using brute force to try and finish the task faster. Throwing more horsepower at application problems can quickly lead to needing more horsepower for the database tier.

Even parallel queries in the database are often abused as a "fix" instead of correcting the query or index/tables.

Of all of the things that could hurt the future of OE and/or make comparisons with other languages/databases unpleasant.. MT in the ABL is probably not even in the top 100.

I was not talking about multi-threading but about concurrency techniques. On performance and scaling read about erlang and how they perform, scale and realise fault-tolerance. In short  http://joearms.github.io/2016/03/13/Managing-two-million-webservers.html 

Read about a move at pinterest engineering.pinterest.com/.../introducing-new-open-source-tools-elixir-community Read about whatsapp www.fastcompany.com/.../inside-erlang-the-rare-programming-language-behind-whatsapps-success (maybe there are morte informative links).

 At least Holland oe is already disappearing for many years. I've worked almost 20 years with it as a consultant, I know what I'm talking about. I'm of course not saying the applications were replaced with erlang. ;-)

I am not saying that OE doesn't have issues... or disputing your personal experience in Holland. I am saying that the bright and shiny 0.1% use cases aren't the problem.

OE isn't losing out on those types of sales... they are losing to Oracle and SQL Server with Java, Web, .Net, etc. front ends. With the occasional open source DB/UI thrown in. The bread and butter apps are core business applications like ERP, MRP and not the Facebook/Pintrest model.

I am saying the real issues are:

0) Lack of exposure (OpenEdge who? instead the old Progress who?)

1) The database (compared to other modern databases)

3) Lack of skilled people compared to other solutions

4) Pricing

I am far from a cheerleader for OE (ask the DB development team lol).. but if you want to leave then leave. If you want to try and promote changes to make OE more competitive I would suggest focusing on the real world issues of why people are choosing other technologies instead of OE.

Fixing the above list would go a long way for sales and the future. Adding esoteric features that only a tiny percentage of developers use will not help.

> OE isn't losing out on those types of sales... they are losing to Oracle and SQL Server with Java, Web, .Net, etc. front ends. With the occasional open source DB/UI thrown in.

Agreed, but I mentioned pinterest, whatsapp etc. for other reasons (performance, scaling, fault-tolerance).

> but if you want to leave then leave.

What is this remark good for.

About the real issues you name: Current pricing makes more exposure almost useless I think. Even when oe was made open-source. I don't want to propose changes to oe (already mentioned that roi seems not to be expected from retrofitting concurrency etc.), I only question what it's future will be.

> f you want to try and promote changes to make OE more competitive I would suggest focusing on the real world issues of why people are choosing other technologies instead of OE. Fixing the above list would go a long way for sales and the future.

I think it cannot be saved and will slowly die.  

> Adding esoteric features that only a tiny percentage of developers use will not help.

I do not see features like actors as esoteric.  They are very usable, in the context of functional programming also. Which I find a far superior model compared to oo. You can perfectly create normal business apps with a language like elixir. And you can extend such an application... Far beyond what is possible with oe I think.

Performance, scaling and fault tolerance are really database related issues for OE applications. For all applications really. Code can be spread around and easily scaled out... the issue is always with the database. The databases are the center of the universe and everything is limited by how fast data moves in and out. If not... you have some coding/design issues to deal with.

With the current OE app I am supporting we can spin up appserver and UI hosts on demand. Everything is load balanced and spread across multiple datacenters. No real scaling, performance or fault tolerance issues there.

Scaling up/out a DB server is obviously much more complicated as is the current failover process. Especially when compared to Oracle or SQL Server. I have faith that PSC will solve some of these issues in the near term and more as time goes on. Right now we aren't near the current hardware limits and newer/faster servers always show up every year.

I made the remark about leaving to suggest that you have productive choices to make... give up on OE and move on, continue to use what you think is a dying platform or focus on the real issues that OE faces. Wishing for fringe improvements that have little real world business value is just going to frustrate you.

There is nothing inherit in functional languages that make them better than ABL (or T-SQL, PL-SQL, Python, C#, etc.) for real wold applications. Bad design is bad design. I have seen plenty of examples of good and horrible applications written in all of those languages against various databases.

I can't think of a single example where the root cause of any performance problem was related to the ability of the programming language to scale/perform. Everything has been design related, poor queries/indexes, hardware/network related or database tuning related. Many of us support/have supported OE based systems with terabytes of data and thousands of concurrent users. OE indeed has issues but lets not pretend that it isn't suitable for a large percentage of business applications.

You also have to understand that PSC is going to implement new features based on customer demand and their perceptions of the value of those features. Whether you see actors as esoteric or not.. the business world in general does.

> Performance, scaling and fault tolerance are really database related issues for OE applications. For all applications really.

That is a very very black and white statement. There are more types of performance-bottlenecks, scaling and fault tolerance ditto. I'm not going into details, I don't have time for that. It's a big / complex subject.

> There is nothing inherit in functional languages that make them better than ABL (or T-SQL, PL-SQL, Python, C#, etc.) for real wold applications. Bad design is bad design.

Languages themselves are designed better or worse, not only the quality of the code written in those languages matters. Of course languages have been designed with different goals. You will not want to use erlang or oe for number cruching (so it's easy to find the single example you could not), you call a module in f.e. C, C++ or R for that. For discussions on the quality of oo compared to functional languages I like to point at the writings of specialists like Edsger Dijkstra. Or f.e. http://shaffner.us/cs/papers/tarpit.pdf. It further is significant that languages like java and C# are incorporating functional aspects. And that oe is not, hahaha (xcuse me).

> I made the remark about leaving to suggest that you have productive choices to make [..]

My personal choices do not matter in this discussion. But let me tell you then that I am learning elixir. The use of it in Holland is increasing, mainly ruby on rails software houses see the benefits of elixir / phoenix compared to RoR. Yes yes, for exactly these reasons: performance, scalabilty, fault tolerance. Not related to the db. The language does matter for them, for very practical and not-esoteric reasons. It has become more and more difficult to find contractor jobs for a oe specialist like me. I am not planning to make a real choice, I will do oe projects when needed, but my preference will be clear.

> You also have to understand that [..]

I don't have to at all.

> Whether you see actors as esoteric or not.. the business world in general does.

As easy you can say that the business world in general sees oe as a not sexy + some more negative predicates. Moreover it is starving in Holland and f.e. elixir is growing in popularity (sexy as it is ;-).

Ah! Fresh air please, open the windows! ;-)

I guess we will agree to disagree (or at least I will).

Enjoy

Let's say that developer communitiies can look like a church. It can be cozy to sit with fellow believers.  

Enjoy. ;-)

Congratulations... you just made half of the OE development, support and management teams laugh uncontrollably :-)

I assure you they don't consider me a blind believer in the OE faith. But hopefully one that makes productive suggestions.

Ah did not hear them. You must be psc's bully, I did not realize that. :-)

"I have read a bit about the actor model, but don't really understand how to use actors in a real world situation – how to model a problem with them. Can someone please explain?"

programmers.stackexchange.com/.../how-is-the-actor-model-used (read the first answer to the question: "Actors, in the sense of modeling actions, with messages [..]").

  Another answer to your question Marian (if you were really interested you could have found them yourself - but no: you are mainly interested in being hired as progress programmer so why bother :-(  )  can be found f.e. here.

  Even in .net the actor model is implemented I see btw. Exotic Keith? Grr... For those with blinkers, yes. 

Especially this part of that answer (programmers.stackexchange.com/.../how-is-the-actor-model-used) I found interesting:

 "Helps focus on Task Based events rather than CRUD events. CRUD is simple but it's just like interacting with a filing cabinet. If we can provide more value than in the software we produce, why are we doing it? Tying multiple actions to a single "Update" command in a task based system is more useful than just saving to the DB. This also gets into stuff like CQRS." with this link about Task based UI: web.archive.org/.../

"One of the largest problems seen in “A Stereotypical Architecture” was that the intent of the user was lost. Because the client interacted by posting data-centric DTOs back and forth with the Application Server, the domain was unable to have any verbs in it. The domain had become a glorified abstraction of the data model. There were no behaviors, the behaviors that existed, existed in the client, on pieces of paper, or in the heads of the users of the software. [..]" 

I am writing a small bpms in elixir at the moment.  It works with websockets (a persistent connection via the web of a client and a backend). Many of them (in principle millions within elixir) can exist simultaneously for different users / tasks. That means many *statefull* connections, per connection I will use more than one actor. All these actors can communicate with other.

Speech is silver, silence is golden, eh? :-)

0) This is getting old and very unproductive imo.

1) This was a holiday weekend in the US. Declaring a lack of responses as victory doesn't make it true.

2) You don't really seem to be interested in having a realistic conversation about what can and cannot be done with OE, Oracle or MS-SQL (without the latest shiny tool/language). Comparing an application written the way it should have been from the start (service/action modeled, business logic driven, etc.) to a legacy application written poorly doesn't make the case for new language as much as it does for proper application design.

3) Just because .NET added a feature doesn't make it main stream or important enough for OE to implement before other features. .NET, Oracle, SQL Server, etc. all have a large feature set... but most only use the common core features.

4) You seem to think that everybody here only uses OE and has blinders on to everything else. I promise you there are those of us who have done large applications (thousands of concurrent users) in non OE languages and databases. I will put more faith in my real world experience with large applications than with your internet searches and playing around with Elixir. Sorry :-)

Convincing enough for the likers, not very impressing.  It's your work, good luck in your antique shop. :-)  I know some others that of course do not react that are interested.

Okay.. no more interactions with you because you obviously cannot be bothered to actually read what I post instead of just skimming and jumping to your own conclusions.  I have said numerous times that OE has issues but we obviously disagree on what those issues are.

By the way... my "antique shop" is running Oracle, SQL Server, OE, PostgreSQL, Cassandra and a host of other technologies all running in a cloud environment.

Best of luck in your future Elixir endeavors.

4) You seem to think that everybody here only uses OE and has blinders on to everything else. I promise you there are those of us who have done large applications (thousands of concurrent users) in non OE languages and databases. I will put more faith in my real world experience with large applications than with your internet searches and playing around with Elixir. Sorry

Convincing enough for the likers, not very impressing.  It's your work, good luck in your antique shop. :-)  I know some others that of course do not react that are interested.

---

Someone wants to talk about something else other than OpenEdge in this forum and then bad mouth the technology.  That is bad form in this forum, which is dedicated to OE tech.

What you should be bad mouthing are corporations that use the tech and insist on using character interfaces and years old techniques.  But hey, it makes money as is for them, it makes money for the developers who have to live with such things.  I'm sure Progress wants to get them off the old tech too!

IOW, no amount of bad mouthing the technology is going to get the user base (ie, corps)  off old sh!t.  The user base is what pays the bills for nearly everyone on this site.  You can talk sh!t while the rest of us get the bills paid.

All your doing, agent, is making yourself look bad for OE projects (and many others too.)  Be careful, Europe has more Progress work than the states and I am sure the bad mouthing isn't having anyone stand up and say "Hey, come work here!"

Like you both say, I am a DB2, Oracle, MySQL, PostgreSQL, and Progress DB programmer with the ABL, HTML/Javascript, C, PHP, C++ and a bunch of languages you never heard of (net.data anyone?)  Progress it's self is pretty much a C shop from what I remember when I contracted here.  After all, the ABL is made with something.

I am open to hearing about other tech, even though it might not be welcome by the admin of this site.

But telling people they are welcome to work in their antique shop does not a good reputation make for getting paying work in OE.

I'm not afraid of my reputation. Not good to promote an angst culture. If someone thinks I cannot deliver good work because of my opinions that's not really a problem for me. I like freedom, honesty, open culture. On work in the Netherlands with oe: I already mentioned it 100 X: disappearing. Work in languages like elixir: appearing. Maybe it would be "smarter" to learn the most used, fe javascript / angular, but I like my job and programming in a really advanced language that makes it in the commercial world. It's not only going from chui to gui that makes up modernization, there is so much more to think about. Oe is mainly focussed on crud. But there is the task based ui, bpm, CQRS, DDD, the jsonb field/noSQL etc etc. And the free lunch is over, which can have consequences or your business in the long term.

  You can neglect the benchmarks you can find comparing phoenix / elixir with others of course. But it is already used in production for some time, and innovative companies in Holland use it. I have seen very advanced workflow solutions with web-based modelers (canvas elements and so). Not using some expensive bpm solution (not webbased, no seamless fit with the used development language and not built to meet the needs of a specific client or a specific group of clients) out of the box, but the opposite. Built with elixir / phoenix; most developers are full stack so they can create a canvas.

Well, my hiring wouldn't be for people shooting down other people as "antique" for having knowledge of a database system.  One more tool in the tool box.

I still hold to the belief of the proper language for the proper job and resources.  Would I use R to write a database application - of course not.

IOW, if one focuses only on Progress, then yes, one's options are limited.  But Progress is one tool of many out there that should be in a programmers tool box.

> Well, my hiring wouldn't be for people shooting down other people as "antique" for having knowledge of a database system. 

I did not shoot with that reason. Should be clear already.

> But Progress is one tool of many out there that should be in a programmers tool box.

OE + db can be missed. There are other products. R I mentioned only for use as number-cruncher. But you understood that I think.

Ah, look at this Scotty! They realized advanced OO in elixir! Wow!

www.youtube.com/watch