I'd like us to create something like a taxonomy of our different approaches here and elsewhere. For example: • Scratch-like • FRP-based • Dataflow, boxes and arrows • if this then that • spreadsheet-like • ... This should inspire discussion of their merits and costs, which doesn't seem to happen much here. And also we could do the same for our common goals with our projects: • end user liberation, empowerment • better IDE UX • discover the pure essence of what programming is • ...

Creating metrics is incredible important. I would like to see that happen for a variety of complexities

I started categorizing some projects @Duncan Cragg in https://github.com/pel-daniel/mind-bicycles. It’s just a start I’m sure I’m missing many more

Looks good. I'll dig into that later today 👍

The most useful categorization is in terms of target: what kind of programming, and what kind of programmers?

Probably most significant sections: • https://github.com/pel-daniel/mind-bicycles#datalog-inspired-environments • https://github.com/pel-daniel/mind-bicycles#other • https://github.com/pel-daniel/mind-bicycles#spreadsheets • https://github.com/pel-daniel/mind-bicycles#visual-programming-with-nodes .. "Other"? Wondering if that's the sweet spot! 😄

I believe Jonathan means systems programming vs application programming, and career programmers vs end users (scientists, moms and dads...)

I’ve only read a very little of @jonathoda’s blog, but it seems like he’s looking to end career programming as phenomenon. While there will always be specialists for special areas, in his vision there won’t be “programming generalists”, and certainly nothing like a “full stack developer”. (Am I reading that right, Jonathan?). I think, in this future world, the kind of person who makes a good programmer today would be something more like mathematician then, and most of the lousy programmers would find some other work, as the people who actually know the specialize in the domain could get on without them.

@duncan @Nick Smith Yes System vs application and professional vs amateur is a rough distinction. I think we could get a little more granular than that: big diff between OS and ML, and between artists and businessmen. The point is that you have to identify the target to hit it.

Yeah, that makes sense.

Counterpoint: the actual programming is the easiest part and the hard part is figuring out details in business process and how those details form the mesh of a larger system. In my experience working with the non-technical people adjacent to programming this skill will always be in broad demand and "normal people" just won't do it. Remember: we think CRUD apps are stupid and simple, but how many people, even bright and talented business people today could translate their human-level desires into software-level details even if the implementation is something as simple as a CRUD app?

The argument is that most of the toil and expertise required is for solving the purely incidental problems of software - the ones that have no bearing at all on the business, but are merely implementation details.

I agree the incidental implementation details can be reduced, but you can never reduce-to-zero the act of translating human problems into technical details. And many of these implementation details are actually important and well beyond the "I care about this" level of normal people. For instance, how does localization work when a normal business person is doing the development? Do they know or care about how their site renders in Arabic? Do they know or care about the translation or do we accept Google Translate's output? How do they fine-tune things when their page looks goofy in German? These are edge case details that require real expertise only a profession can provide.

… For now. At my last job, a savvy group of young, non-technical, fresh-out-of-college folks googled their way through administrating a Dynamics CRM deployment, and were able to create quite an amazing, custom-fit system, with no previous IT experience and very little help from the IT department. That wouldn’t have been possible 15 years ago, and I imagine even more will be possible in the future.