I think it comes down to a question of measurement. Now, of course you're going to find a lot more programmers now because computers are ubiquitous and CS is a hot major. But one way to think about it is what is the ratio of users that can program their computers to the ratio of pure end-users. I think its orders of magnitude lower now. You could argue that because we have all these fancy apps now and we don't need to program our computers but I believe people don't get a fraction of the computing power they can or need from their devices. This is evident by the recent trend in bots and "workflow" applications (e.g. Microsoft Flow, IFTT, etc). People want a lot more from their machines. And apps are a single-purpose, crude way of doing computing. The way you get the most out of your computer is that you program it.

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.

When thinking about if we've improved or not, I like to point out stuff like this, from 1976:

"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...

[a] http://www.atarimagazines.com/

> ... but whenever I read the VPRI articles, I always feel there's too little code to play with.

That's the whole point of the STEPS project: Less code to play with ;)

Your last point, that kids are being introduced to apps through devices that don't have easily accessible dev tools, is something I hadn't considered. That could certainly push the bar back up, especially if they don't have a PC at home or at school as well. That's something to think about.

I agree that the tooling is better. But if I compare the mid to late 90s to now, it feels like we haven't moved very far. Sure, computers are faster, compilers are a bit more polished, we have access to a CodeView-style debugger more often than not, code completion is a bit more reliable, we can test more easily and use stackoverflow to provide context for new problems.

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.

I think I pretty much agree about all of those changes except for "the work necessary to get something to display on a screen". This was much less in BASIC on machines like the Atari 400/800, Commodore 64, Apple ][, and IBM PC that could boot into a BASIC interpreter. Then you could turn on the machine, type

  10 PRINT "HELLO, WORLD"
  RUN

and see something on the screen.

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).

Of course the coverage by libraries, accessibility of varied example code have improved tremendously, as have version control (es. distributed).

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.