Hahaha. More toys for boys!
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. :-)
A mass of ideas www.youtube.com/watch
Domain driven design, FP vs OO and typesystems. Use them to your benefit.
agent_008_nl : perhaps that’s making the discussion a bit to broad...
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.
Some OOABL ideas, (i.e. 'Generics') are requested in 2014 (or perhaps even earlier)
"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."
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).
dbeavon 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. [..]"
"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.).
emptied (for some reason a copy of my prev message appeared here)
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.
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.
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 :-)
Architect of the SmartComponent Library and WinKit
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, …).
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.
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:
<info organisation="com.tvh" module="ms-whatever" revision="1.0"/>
<artifact name="ms-whatever" type="zip" ext="zip"/>
<artifact name="ms-whatever-full" type="zip" ext="zip"/>
<dependency org="com.consultingwerk" name="scl" rev="1.0">
<artifact name="scl" type="zip" ext="zip"/>
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.