I think the problem with this article and their approach will be more visible when super star developers start to leave the company. If they are all the same people from the very beginning, yes, throw lots of practices out of the window because people know the codebase very well. But once they are out, there will be a mountain of tech-debt. They even try to make it testable.
As far as I understand, this is for developers to develop algorithms, right? If that is the case, aren't the algorithms mature already? Or are we as developers just passing the data to existing algorithms and problem types of your system?
In sound-byte form, this is for developers to develop algorithms.
What we really mean by that is for developers to easily automate decision making at any scale. Those can be simple rules-based decisions, or complex decisions requiring sophisticated approaches. We believe that the practice and methodology behind the automation are as important as the algorithms themselves.
Regarding your questions of maturity, it depends :). Some algorithms commonly used in decision making, such as linear sum assignment or shortest path algorithms are quite mature and (generally speaking) fast. Others are mature and often fast enough, but sometimes not. Plenty of important problems are more or less unsolvable right now.
Mixed integer programming solvers, for instance, are extremely powerful and handle large general classes of problems. They also require translation of business rules into specialized form by domain experts, and can blow up in terms of optimization time or even time to find a feasible solution.
Complicating this is the fact that most real-world problems have side constraints which may render well-studied algorithms or models useless. We are eternally searching for more flexible, more advanced techniques, and maturity depends a great deal on what you need to accomplish.
So the assumption is that the targeted developers work in an environment where business rules are translated into code and they have access to domain experts? They will use your system to develop easier.
By the way, I signed up for beta to try the system.
It is a neat idea to separate the semantics and the syntax. However, for some reason, it didn't get enough popularity.
Apache Commons has an SCXML package which parses scxml statechart format (standard) and produces dynamic java objects but this couldn't see the daylight and suspended at version 0.9 in 2015.
I had nice experiences with this separation logic though. It is more flexible and extendable than regular finite state machines. There is parallelism and timeouts built-in the standard and as mentioned in the presentation, it solves a lot of if-else kinda structure without a hassle.
The article just focused on Uncle Bob's asking for "unit tests" in "Tools are not the answer". But I believe Bob just asked a rhetorical question over there. If someone is not writing unit tests at the very first place, he doesn't need to ask any other kind of tests furthermore, which are likely be less and less people raising hands.
It would be more interesting for GUI based projects. For example a WPF or html/css application. Seeing how it evolves step by step would be nice. Of course I am assuming the repository has logical commits.
My main perspective on the issue: If I want to learn a completely new topic, I like it to with a teacher standing in front of me. Otherwise, I can take an online course just to recall some topics and update my outdated information.
I forgot why. Because I like to interact and get answers for my unique questions from the teacher. Not a lot of online classes provide this interaction. Actually most of them are prerecorded videos and stuff.
I believe much of the problem mentioned in the article is about us not being software engineers but only programmers/coders. If we, as an industry, would have adopted engineering discipline instead of producing systems in light speed by just coding, what we are talking now would be different things.
This is my view as well. But I'll go further: I believe there is an almost active hostility toward engineering, as if it's viewed simply as something anyone can pick up, like the much derided "liberal arts."
