They released a video last year that showcased some iterations of their prototypes and I found them to be very innovative and promising: https://www.youtube.com/watch?v=VZQoAKJPbh8
This industry has become a branch of the finance industry. So instead of programming being driven by math (e.g. category theory, abelian groups), it's driven by the market (e.g. time-to-market, what works now).
HARC is a push back the other way, giving space to people who are thinking about it in the right way, and I applaud that. But we're still missing the 'inclusive' piece of it; until we can talk to each other and listen to each other, we'll remain frustrated.
Yet at the same time there hasn't ever been so much working software produced, or so many working programmers, so something is working. The barrier to entry to writing code has been lowered. That's a good thing. We have more people trying out their ideas now because it's easy to get something working. You can't reasonably ignore that with a hand-wavy "it could be so much better" lament.
That isn't to suggest for a second that things couldn't be even better. I just think it's important to understand that getting lots of people involved in development, even if what they produce is awful, has benefits for society. That might be more important than good code.
One wonders what could be if programming was easier, being considered as such a basic skill as writing an essay.
They really are. I've been writing code for 30 years (professionally for 20) and while the logic hasn't really changed a great deal, all of the things around coding absolutely have. The work necessary to get something to display on a screen, the speed of both compiling code and running an application, the sheer quantity and quality of example code to learn from, the tools available to do things like source control and testing, the libraries that do most of the work so you can concentrate on the bit you're actually interested in, the quality of debugging tools and error messages that a language will give you ... all of these things add up to an environment where writing code is just so much simpler than it ever has been before. All that means that beginners can concentrate on learning rather than getting frustrated by incomprehensible messages that they need to look up in a manual and decipher because a lot of technical writing was pretty awful back then.
It's impossible to overemphasise how important it is when you're learning to be able to concentrate on what you're trying to figure out without needing to worry about other stuff that might distract you. That is what's made it easier to get in to development.
Looking at it from this lens -- I don't the barriers are lower. Most kids' first interaction with computers now are through smartphones and tablets. And the separation between using these things and actually programming them can't be further away.
"My name is Marian Goldeen. I'm an eight grade student at Jordan Junior High School in Palo Alto, California, and I would like to tell you about how I got started working with computers at Xerox, and the class I taught.
It all started in Dcember, 1973, when I was in the seventh grade. (...)"
(My emphasis) http://www.atariarchives.org/bcc1/showpage.php?page=61
Now, after reading that, are you proud at how far we've come in 40 years? I think we're doing rather poorly, and I believe the VPRI folks (and now this new project) is part of how we might do better.
I just wish these people would/could be more generous with throwing code out there for people to run and play with. I'm not sure if it's a culture thing, a funding thing, or a bit of both -- I understand that a presenting a coherent whole can be more powerful than small ideas, but whenever I read the VPRI articles, I always feel there's too little code to play with. I want more! :-)
By the way, there's lots of interesting stuff in that archive[a], like:
"Is Breaking Into A Timesharing System A Crime?" http://www.atariarchives.org/bcc1/showpage.php?page=4
And in fairness, we have seen some improvements:
http://www.atarimagazines.com/compute/issue1/3159_1_THREE_WO...
That's the whole point of the STEPS project: Less code to play with ;)
But that maybe makes me only about 10% faster. As for learners, I'm sure it is useful, but they aren't that far off from when I started (when docs were mostly first-party vs. crowd sourced), and that is depressing to me. Every new step we take is very incremental.
10 PRINT "HELLO, WORLD"
RUN
In more recent environments you have a text editor and IDE or shell, which likely introduce more steps (even the concept of saving your code in a file!). I've also seen people worry about how much harder it can be to make a program display graphics compared to the BASIC era (which generally had built-in language primitives to go to graphics mode and start drawing stuff, which may at least require importing a library in contemporary languages and maybe installing a library).
But I would say that the amount of code to put something on the screen, speed of compilation and running (non-cpu bounded) code, quality of debugging tools are all approximately catching up now to the state of the art of 1980: a Smalltalk environment created by Alan Kay, Dan Ingalls and friends at Xerox PARC (I've heard LISP workstations were similarly advanced). By their work at VPRI, they still have a few things to invent and for industry to learn.
So while I agree barriers have decreased a lot, it is important to remember that the gap between state of the art what is common is also commonly huge in this area.
Arguably, _introducing_ people to programming through C++ and R (complex languages with difficult tooling) adds about 30 years worth of barriers right back, and is still common practice in some places.
The core problem there is two-fold. One, humans are bad at breaking things down explicitly into steps, and we make errors of description and errors of omission, which we call bugs. The program arrives at a goal, it is just the wrong one. Second, that goals grow more ambitious with time. At one point making a basic spreadsheet was a major endeavour, now it is a practical exercise as part of a programming course. Because the goal is more complex / further away, the number of steps required grows bigger. The current focus of tooling is in ways to make it easier to describe the steps, by giving you starting points closer to the goal (frameworks and blueprints) or by making the steps bigger (languages, libraries and abstractions) or by agreeing on patterns of steps, etc... I think this line of thinking, while important, is inherently limited in its ability to solve the problem.
Fundamentally, the trick to making programming easy is to turn it into something goal-oriented instead of step-oriented. You describe the desired results and the computer works out all steps regardless of the state space, and adapts as the state space changes (new data, changing circumstances).
Basically this is what unit tests do, minus the part of programming the code behind the test. But imagine one person writes only tests, and one writes only code. Replace the second person by an algorithm, and tada, goal-oriented programming. That part looks solvable to me. But ... now the problem becomes one of describing the goal, and we're merely shifting piles around in the problem space. Someone who cracks the problem of easily and accurately describing a goal would solve the harder half of the problem.
Anyway, just my two cents.
https://en.wikipedia.org/wiki/Logic_programming
https://en.wikipedia.org/wiki/Declarative_programming
It's clear that these paradigms can be easier for solving certain kinds of problems. For example, they're very good for solving puzzles like Sudoku; instead of writing a full-fledged Sudoku solver, you can, in some of these environments, basically just describe what would constitute a solution to your problem, and then the programming environment can find one for you.
But you're right; for my project we scrapped it all. What's left is essentially a thin VM layer over hardware. It was the only way.
The next step is writing software that can write software. Maybe automated automation can't write a self-driving algorithm, but automation should be able to write the code to send email to a list of addresses.
We shouldn't automate dumb things. We should automate the automation of dumb things.
The programmer and the program have never been further away from each other as it is today. The development environment have never been further away from the production environment as it is today. And end-user interfaces have never been as abstracted away from computing as it is today.
If any group can breathe some life into this stagnant area then my bet would be on this group.