Slashdot Mirror
'The Problem With Programming and How To Fix It' (alarmingdevelopment.org)
Jonathan Edwards has been programming since 1969 (starting on a PDP-11/20). "Programming today," he writes, "is exactly what you'd expect to get by paying an isolated subculture of nerdy young men to entertain themselves for fifty years. You get a cross between Dungeons & Dragons and Rubik's Cube, elaborated a thousand-fold."
theodp summarizes the rest: To be a 'full stack' developer, Edwards laments, one must master the content of something like a hundred thousand pages of documentation. "Isn't the solution to design technology that doesn't require a PhD...?" he asks. "What of the #CSForAll movement? I have mixed feelings. The name itself betrays confusion -- what we really want is #ProgrammingForAll. Computer science is not a prerequisite for most programming, and may in fact be more of a barrier to many. The confusion of computer science with programming is actually part of the problem, which seems invisible to this movement."
It wasn't always this way, Edwards notes, citing spreadsheets, HyperCard, and the many incarnations of Basic as examples of how programming technology can be vastly easier and more accessible. "Unfortunately application programming got trampled in the internet gold rush," Edwards explains. "Suddenly all that mattered was building large-scale systems as fast as possible, and money was no object, so the focus shifted to 'rock star' programmers and the sophisticated high-powered tools they preferred. As a result the internet age has seen an exponential increase in the complexity of programming, as well as its exclusivity."
"It is long past time to return to designing tools not just for rock stars at Google but the vast majority of programmers and laypeople with simple small-scale problems," the essay concludes, arguing we need new institutions to fund changes in both the technology and culture of programming.
"We've done it before so we can do it again, even better this time."
theodp summarizes the rest: To be a 'full stack' developer, Edwards laments, one must master the content of something like a hundred thousand pages of documentation. "Isn't the solution to design technology that doesn't require a PhD...?" he asks. "What of the #CSForAll movement? I have mixed feelings. The name itself betrays confusion -- what we really want is #ProgrammingForAll. Computer science is not a prerequisite for most programming, and may in fact be more of a barrier to many. The confusion of computer science with programming is actually part of the problem, which seems invisible to this movement."
It wasn't always this way, Edwards notes, citing spreadsheets, HyperCard, and the many incarnations of Basic as examples of how programming technology can be vastly easier and more accessible. "Unfortunately application programming got trampled in the internet gold rush," Edwards explains. "Suddenly all that mattered was building large-scale systems as fast as possible, and money was no object, so the focus shifted to 'rock star' programmers and the sophisticated high-powered tools they preferred. As a result the internet age has seen an exponential increase in the complexity of programming, as well as its exclusivity."
"It is long past time to return to designing tools not just for rock stars at Google but the vast majority of programmers and laypeople with simple small-scale problems," the essay concludes, arguing we need new institutions to fund changes in both the technology and culture of programming.
"We've done it before so we can do it again, even better this time."
What you get when you let coders decide where to go is nothing. Ever. At least nothing that's ever done. Mostly because you get this and that and something else because all of those things are absolutely necessary, and then eternity to accomplish it all. If programmers were to make a toaster, it could toast anything from bread to waffles to muffins and even your sweater, because someone sometimes thought it might be helpful (but we don't remember who said that, but we also can't remove that sweater-module anymore without breaking the rest), it would measure its own temperature based on all the toasting done before to determine the perfect toasting temperature and time (both would be measured by three different sensors and devices), you'd have to give detailed feedback on your toasting and eating experience that would then be used to create a heuristic based on world wide averages... Well, that's the theory. Right now it's basically a stove top with a pan attached.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
Not at all. You can pretty much use any modern language for any problem, but some are better at some tasks than others. Some are also more intuitive, easier to read and elegant, and often those things are sacrificed for the sake of flexibility. I think the person is trying to say that we can have both. For example (from the article) spreadsheets written in BASIC that were both easy to program with low barriers to entry, and powerful as well.
I see that many professionals might be able to use basic programming skills to be more efficient and productive. But most programming tasks require basic logic, math, reading comprehension and critical thinking skills. The very skills many entities in our education system are failing in their attempts to teach. Not to mention the drift away from the 3 R's and the moves to gender and social focus points of our educational curriculum
;)
I wonder what percentage of individuals have the core foundation to even absorb how to write code.
Just my 2 cents
I don't get why the notion of "full stack developer" is such a big deal. I mean, do people go to build a home and say, "I want an 'all trades craftsman'."? Or do people go looking for a doctor and say, "I want an 'all specialties surgeon'."?
Of course not. Certainly there are people in every skilled profession who could be classified as generalists. They can probably handle most small things that are not very highly specialized and, if they are good at their profession, they know when something is outside of their skillset and can provide a link to a specialist that can handle it.
I am not saying that we should make technology and programming more difficult than they need to be. But, let's face it, there is a tremendous amount of knowledge, skill, and experience one must acquire in order to be a good programmer. It is very difficult to acquire all of that for what would qualify as "full stack."
I think it was Stroustrup (or maybe Dijkstra), speaking on the idea of making programming "easier" so more people could be programmers with far less training and education, who said something to the effect of "I wouldn't want a surgeon operating on me who only had 6 weeks of training."
Maybe I misread/misunderstood this article but I read this as, 'let's dumb down computer programming".
Yes! Good! We need to get over this god-complex if we're ever going to sort out our profession. Programming *needs* to be easier, you can't just continually hire super-intelligent people because there just aren't enough of them. And even when you do, they still produce poor bug-ridden code, because the task is just too hard.
The level of complexity in computing is all but impossible for any reasonable human to handle. A really big portion of my days is spent finding things in other people's code (ie mainstream libraries) that don't work as they should, and god knows what mistakes I am personally putting out into the world. If big players (eg this week I found horrible problems with Google & Dropbox code) can't provide consistently working libraries what hope do the rest of us have, with tight deadlines and limited intelligence.
Every other profession, medicine, law, accountancy, engineering, have to deal with the fact that not everyone is a genius, and have systems and checks in-place that means people don't have to be flawless to work in them. Until computing is the same, it will remain a wild-west hobby. Programmers need to get over their pride.
He states the problem. He says it should be better. He doesn't go into "how".
The fix should be to have software write the code. Input the behavior you want in any programming language — maybe a new one, but old ones to start with.
Then the software translates it into whatever other language, replaces the easy to understand loops and such with efficient implementations that provide the same result and are provably secure, identifies sequence points, breaks it all up into parrallelizable nuggets, and sends the whole thing to a scheduler that runs it on a set of CPUs.
... people don't want to learn. No doubt tools can always be better but knowing how to improve them is a non trivial undertaking. They want easier to use tools but those "easy to use tools" take decades of research and development to make. If good tools were so easy to make they would already exist.
Computers programs are only as good as the coneptual and modelling approach you use. Consider many 2D videogames who render spries as largely square/rectangle block, if you want two sprites to do something complex like melt into one another, that would require 1) faking it or 2) coming up with an entirely new way to model and animate sprites that broke them down into individual pixels/atomic components.
The problem with computers for normal people, is that computers force you to specify and make clear your thoughts and most peoples thoughts are hopelessly vague. That's why people are frustrated they simply do not know nor understand the complexity of the work they are asking when the want some problem "they think is easy" to be be rigorously quantified before you can code up a solution in a program.
He seems a lot smarter than I am and so I do not want to dismiss what he is saying... but I cannot possibly see how programming is harder than it used to be.
It seems like he is looking at the languages and tool chains used in the enterprise, and complaining that they are not suitable to get Joe Sixpack programming, while ignoring all the incredibly easy ways for somebody to make something useful at home. And, I'm sorry to say it, but the most obvious counter-example to what he is saying is... Python.
The Daddy casts sleep on the Baby. The Baby resists!
It's not the 80s anymore. Useful systems are complex, have many layers, and tend to grow new layers over time.
In the 90s, a web page was a static .html file. Some minimum understanding was enough to make one.
Later, CGIs were added. Now you need some understanding of HTTP.
Add a database. Now you need to understand SQL, and related matters, like SQL injection.
Add JavaScript. A whole new language to deal with.
Add dynamic content. Suddenly, the page isn't a static thing, there's a DOM that's being modified in real time.
Add a growing internet, with many users of your page. Now you need to know how to make a scalable system, and how to design a proper database.
Add cloud computing, where the underlying infrastructure itself can be scaled in real time, and where you can get extra database servers if you need them for a couple hours.
Add internationalization, and now the programmer has to be aware of Unicode, different date formats and so on.
With each added feature and with each added layer the complexity grows. And you can't just throw your hands up and say "fuck this, let's do it like we did in the 90s", because all those things were added for a reason. Without Unicode, you have problems with your international clients. Without dynamic content your page is clunky and slow compared to the competition. Without planning for scalability, your infrastructure falls down right when your business is on the front page of Reddit.
I get the nostalgia for the good old and simple times, but that never lasts. As soon as a new tech emerges, people build on top of it, and then on top of that, and so on, and things escalate until it's hard for a single person to deal with all of it anymore.
Sounds like a middle manager who doesn't really understand anything but wants it to be cheaper/easier so he doesn't have to pay PhD wages
Anyone can program.
Hell when I started I could crank code like it was nothing. But guess what. That code was total crap. I mean it was *very* *very* *very* badly written.
Once I learned a good amount of CS I became much better. I did not make terrible memory mistakes. Big 'oh' is a thing and it matters at all levels memory, cycles, instructions, time, etc. It maters it takes a decent math foundation to understand it.
Once I got the CS degree I still was fairly 'mediocre' at it. At least my code was not terrible. It was not exactly great either. That has take years of practice and time. Tooling around it has helped pick off the silly 'typo' mistakes. But not all. Also more practice. This is an art. We are craftsman. We can use science and math to build our art. But art it is. Once you realize that you can figure out how to make CS great again.
One of the biggest lessons is. Do not worry about 'stacks'. HR worries about them because the managers think they need to worry about them. What you want is well rounded individuals who can grok the idea of how the stack you are using works and is not an ass to work with.
We have ended up with giant sweeping stacks that no one person can understand because of 'crunch'. Everyone in the industry wears it like a badge 'I work X hours per week'. That sort of work ethic create crap. You are not stopping and using the the thing holding your ears apart on how people will use your 'latest greatest API which is trending #1 on stackoverflow'.
Leaky abstractions are dead easy to make. Ones that 'just work'. Those are hard to make. I am currently in the process of picking up spring. What an un-holy mess of a stack. Oh you can do great things fairly quickly. But the one thing everyone bitches about is 'how do I debug this bitch with its 200 line stack traces'. That is one of the 'popular' ones! So everyone is floundering around trying different stacks and transpilers to spackle over the defects of a poor language choice in our browsers. We are also winding up to create the worlds largest lockin of code ever with webassembly. Then deriding our languages for the 'bad' things that are going on (hell I just did it). So we invent 3 more that do pretty much the same mistakes eventually.
So yeah CS/Programming is hard. Because we are too busy trying to be the next vendor lockin and putting in way too many hours on stacks that just do not help get shit done. But hey at least I am trending and have a banging blog and youtube video series that no one gives a crap about!
Just another guy who wants to make another programming language environment. Visual programming has always failed. But it doesn't stop the next idiot from suggesting it again.
Everyone must be a surgeon.
Not those rare few uppity elites who can afford the education.
It's discrimination I say!
We need to change how the human body operates to make it easier for more people to work on.
You might as well suggest that people could master painting or mechanical engineering or something without putting in a time investment.
I'm all for getting more people to code. I'm all for an introductory language for new coders.
But when it comes to the big league heavy lifting coding, it is going to be complicated because it is complicated.
It isn't complicated because some "nerds" made it complicated. It was complicated before anyone coded at all. It is inherently complicated.
I've decided to stop wasting my time responding to AC trolls/sockpuppets... so if you want a response from me... login.
> There are so many javascript web frameworks that let incredibly poor programmers produce useful tools. They may be horridly inefficient and buggy but they work.
Yes, they seem to pretty much work, when they receive the expected inputs. Since the person who wrote it doesn't know what they're doing, inputs they didn't anticipate result in yet another $20 million breach.
There is a place for something like Hypercard, macros, etc - on your own desktop, to make your job easier. Programming that's going to be exposed to hundreds or thousands of attacks per day, programming on the web, needs to be done right.
"Done right" doesn't just mean "a professional", an English major given the title "Programmer". It means someone who actually knows what they are doing.
I feel as though I am missing part of his argument as well. Python is perfectly good for banging out small programs and frameworks like Django make it much easier to build a functional website once you bother to learn how it works. Contrast this with cobbling something together in PHP as often was the case a decade or so ago and I fail to see what the problem is.
This can all be done without tools as nothing stops a person from writing their code in a simple text editor and testing it by running the program live and troubleshooting and bug fixing as they go along. However, this is not efficient and in the long run it pays to learn to use an IDE, debugger, SCM system, persistence framework, automated build and regression test setup, and all the other tools that make developers much more efficient in the long run.
If a person just needs small programs on an infrequent basis, they probably would not take the time to learn a programming language to start with. Instead they can probably use something like Excel to solve their problem. Hell, there are plenty of things I use spreadsheets for as they are a perfectly good solution and if I need interoperability it is easy to have most programs read or spit out CSV. It seems as though the author thinks that everyone should learn to write their own programs to solve problems that are better solved with existing tools in which they may be more competent. Then he laments that programming is too complicated to use when he has already made things over-complicated by suggesting that programming be used at all.
You don't need to be super-intelligent to program effectively. You just need to be able to think logically and break down tasks. It doesn't need to be made easier, because if you can't do those two things you shouldn't be programming.
Reading the article, I feel like the solution is adding meaningful instruction in programming at grade school and continuing it through a person's education. From here, programming platforms for the masses will become obvious and well supported.
Sometimes when the common denominator is too low, you have to change it rather than cater to it.
Mimetics Inc. Twitter
"'let's dumb down computer programming".
What's wrong with that? The trick would be HOW to dumb down computer programming without ending up with an intractable shambles like the last 50000 attempts to do so.
You can't see ANYTHING from a car, You've got to get out of the goddamned contraption and walk...Edward Abbey
Actually, there's some bits that require dumbing down.
QBasic was as simple as "Screen 13", followed by "Pset (1,1),43", plus there's other quick graphics functions available. This is as simple as it gets.
In C for MS-DOS, you could do simple graphics rather quickly. Maybe you needed a library for C in order to quickly produce graphics, but you're still only one step away from drawing whatever picture is desired. You may need a library, but any proper compiler would have allowed directly calling the appropriate BIOS procedure. Still on the simple side.
In C/C++ for Windows, creating a drawing space is much more complex, requiring a few screens of code just to setup the drawing region, Read here to see how it's bulky. Similar reasoning applies to XWindows.
Most of this bulk is expected, since one has to create a window and make sure it doesn't interfere with others. However, it's still something that could take a lot of simplification in the future.
Something in the style Hypercard or OS macfos, or Excel macros can be very helpful to partially automate your job. Rather than clicking the same thing over and over, you can script your task. That doesn't always require a lot of expertise.
Contrast that with code exposed on the internet, which potentially connects to your company's critical databases. Being on the web, that code will be attacked hundreds or thousands of times per day. Sometimes, attacked by very skilled attackers. These are two VERY different situations.
On your desktop, sure go ahead and script autoreplies to common emails. For code on web, being attacked thousands and thousands of times, which can result in multi-million dollar losses, that's best done by someone who really knows what they are doing.
That does NOT mean a "professional programmer" who was hired as a programmer because he "knows a lot about computers". That means someone who has actually studied how to architect and author secure systems to be robust while under attack, and continues to study. Twenty years into my career, I still study several hours per week, because the black hat hackers keep learning new ways to attack us.
You don't need to be super-intelligent to program effectively. You just need to be able to think logically and break down tasks. It doesn't need to be made easier, because if you can't do those two things you shouldn't be programming.
If it were that easy then we wouldn't be in the horrendous situation we are in now. Just go read the issues lists of major software - you don't have to believe me, the state of the profession is plain to see.
Well, I like that it's wild west because, at the end of the day, merit still counts. You sound like some phb who thinks engineering is factory work. It's not.
I mean - I enjoy the wild-west nature. I just know it can't continue.
Until we have worked out how to build software in the same way an architect designs a building, where it can be proven to be strong enough to withstand the forces against it, we'll be in trouble.
Borland Delphi (and later, C++ Builder, maybe) were great examples of how components could be visualized, packaged, and used for development.
It's really a shame nobody has pushed this direction. It worked really, really well.
..don't panic
It is that easy. The problem is that many people can't think logically or break down problems into manageable parts. By the way, I can show you "issues lists" of automobiles, or buildings, or airplanes, anything moderately complex. Every system that has complexity has issues. You software guys think that software is the only thing that have bugs.
I think what you're talking about has already happened. The best example would likely be Ada SPARK, but that's in the very opposite direction of the "Java is too hard" mindset that TFA advocates.
This is my signature. There are many like it, but this one is mine.
Architecture is an excellent example. You probably think an architect designs a building and it just happens and there are no issues. The reality is that building have TONS of issues. Some of the "greatest" architects have produced buildings that have leaky roofs and cost millions just to maintain. And we have been making buildings a lot longer than we have been building software.
Arduino is C++. A lot of the documentation basically says "refer to the samples" and the samples themselves are poorly commented. Arduino is awesome, but it's not easy. It's just easier than MCU programming has been in the past.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
I have to disagree. The necessary CRUD, GUI, and relational idioms to do the job of typical business applications are mostly the same as the 80's. The web and silly fads came in and mucked it up, turning bicycle science into rocket science by pounding a square peg into a round hole.
Nobody seems interested in exploring and developing new standards to make CRUD and productivity applications easier again. The arcane fidgety nature of the state of the art is too much job security: simplification may trigger an IT bust.
For example, the Oracle Forms developers at our shop can crank out applications at about 1/7 the pace of the "web" oriented developers. The result is not aesthetic, but they work and get the job done. (Oracle is a jerk in other ways, but Forms just works.)
But our shop has to migrate away from Oracle Forms because Oracle stopped making a Forms client and converted it to Java. Java doesn't get along with our security infrastructure. Flash and Java made the same mistake of making their client into do-all behemoth, which resulted in security holes. If they or the industry had focused on making just a "GUI browser" (hopefully with an open standard), we could toss HTML browsers for productivity applications. HTML browsers are better for e-brochures, and not eCRUD.
So, if you want to fix it, learn from past products that work, and produce a stateful "GUI Browser" standard. Let's go back to coordinate based clients instead of client-size auto-flow placement. The server side can resize for the client size as needed. That way we have one placement engine instead of the 50+ placement engines we have now (browser brands & versions). Client-side layout sucks big productivity donkey dicks. (This is not the same as proposing only WYSIWYG as some critics have claimed, because the server can still do auto-flow if desired.)
Put on the client just enough to get the client job done, shifting the rest to the server, but otherwise learn from the failure Java applets and Flash and don't make the client into a do-everything monstrosity. (Resisting Emacs jokes.)
Table-ized A.I.
It's everyone's fault really.
I've dealt with programmers who never have and never want to talk to the users of the software they produce. It's just too scary, that's what the support, sales, and marketing people do. If they are needed, then those folks will make bullet points and disseminate to the 'architects' who will task the 'leads' to direct the 'programmers'. There is no way this can lead to good result. Yet this is a common perception of how to manage commercial software development.
XML is like violence. If it doesn't solve the problem, use more.
"To wit, they will not use pre-existing code, because it couldn't POSSIBLY compare with their own brilliant code."
Right road, but wrong driveway I think. It's often easier to solve a complex problem yourself than to understand how to use someone else's solution even when their solution is perfectly valid. Throw in the number of times when their solution is flawed or is the solution to some other similar, but not identical problem (now you have two problems) and there is often some justification for being leary of at least some pre-existing code.
You can't see ANYTHING from a car, You've got to get out of the goddamned contraption and walk...Edward Abbey
There is SERIOUS money behind "making programming easier." The economic incentives to do this are overwhelming, and all of the tech giants have been trying to do precisely this since before they were tech giants.
The article makes it sound like the current state is a cultural problem. As if the only reason programming is hard is because a bunch of geeks like it that way. Absolutely ridiculous! Programming is hard because the best minds in the world still haven't figured out how to make it easy.
Remember Cobol? Remember what it's goal was? It was the language that was going to eliminate the programmer. It was designed to be so simple that someone didn't need any computer science background nor any technical knowledge at all to implement code. A fortune in research and development was spent to make cobol into that holy grail of software development that would mean no business would ever have to pay a programmer's salary again.
It failed, miserably, and today Cobol programmers rake it in. Have we learned from our history?
Sheesh, if BASIC was the answer, then the industry would be using it already. Why hasn't BASIC already revolutionized the software development world, making it easier for everyone? Because BASIC is not powerful enough to solve the real-world problems that people are willing to pay to be solved.
And yes, Visual Basic .net might be powerful enough to shoulder that load, and guess what? You have to be a smart geek in order to actually use it to solve real world problems.
The problem here is not that people have just not bothered trying to make programming easier. The problem is that the problems that need solving are HARD.
And that's why software developers need to be of above-average intelligence to succeed. Which, in turn, is why there aren't enough of them on the market to meet the demand.
That is how it is. All else is bullshit.
Freebasic is quite darn quick, sometimes even beating stuff like java, but mostly because it is a C compiler in disguise.
Say you have a BASIC compiler that uses the same back end as a C# compiler. What would make BASIC code any slower than C# code?
(In fact, we do. It's called VB.NET.)
Medics have it easy. Sure, the human body is a complex system, but
- it's A complex system, not many
- outcomes are pretty straightforward : Alive, healed
- no innovation required (if illness A, issue medication B)
- limited scope
That last one is massive. Lets take security. Medics don't have to protect their systems against intrusion attempts, malicious attacks, user ignorance, data loss or unsafe use.
A full stack engineer is like a medic that has to diagnose, dispense the right medicines, assure they're taken correctly, hire bodyguards for the patient, wrap them in cotton wool, prevent them from burning themselves while cooking and actively preventing them from climbing up steep mountains. They also have to do all their cooking, change their nappies, take the blame if they get pregnant, raise the child, and issue comprehensive documentation on how to dress each day.
You're absolutely right, other professions get by with a good memory. Lucky sods.
The problem is that it's impossible. The complexity of software comes from the complexity of the underlying problem. No matter where you move the complexity, whether it's from the frontend to the backend, or from an application to a library or to the OS, it still exists. Someone needs to understand that complexity to create working software for it.
Lay people, especially managers, like to think "if we just used library X" that could take care of all the hard stuff. The reality is, using library X now becomes the hard part. It could be bugs, performance problems, bad behavior for certain edge cases, incompatible API changes or security problems. In many cases it could be worse to work across an abstraction layer like that, since the business-destroying bug you're running into is just one of thousands that the upstream developer has to deal with.
You missed the most important difference - they don't bring out a new version every five months.
Doc: Shit, he's got a 3.1.05 heart!
Paramedic: Don't you know it?
Doc: No, we only covered the 1 series at med school. I did a refresher a while back, but that was only up to 2.6.
Nurse: [handing him a laptop] I already opened Google for you.
(Under her breath) I hope your typing's better than your handwriting.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
After the "intractable shambles" the last 50000 attempts have produced it should be more than clear enough that dumbing down programming just doesn't work and the solution really does need to be making those with the knack for the job more productive rather than just maximising the number of bodies.
Not everyone is suited for every job out there and there's genuinely no shame in admitting a particular job just isn't for you.
"Why should I want to make anything up? Life's bad enough as it is without wanting to invent any more of it."
I'll stick to C++ on Ardunio myself but programming Arduinos with Python, toolchain-free, is now a thing thanks to small onboard flash storage, complex but hidden bootloaders, and more powerful microcontroller chips such as the Cortex M4.
https://learn.adafruit.com/welcome-to-circuitpython/what-is-circuitpython
~.~
I'm a peripheral visionary.
He mentioned Hypercard. I'd say, bring back something like the CanDo programming environment that we used to have on Amiga.
Re: https://randocity.com/2018/03/...
This was amazingly accessible, like BASIC if you had a BASIC where everything was created visually with a GUI—which is very different from having a visual GUI editor as some kind of mere accessory sidecar. Rather than create your code in one IDE, and a GUI in another, and then try to graft them together (like IB on the Mac), CanDo had you create your GUI which you could then embed code objects into. Your bits of code were simply properties of GUI objects, although it was also possible to have dedicated code-holding objects with no visual presence. It wasn't perfect, because large projects could become disorganized, but for relatively smaller stuff it was brilliant.
So why didn't it get traction; why didn't it take over the world? For one, CanDo was an Amiga thing, and therefore unknown to most of the world. For another, it came out exactly at the time when the internet was taking off, and the rest of the world was going gaga over HTML and Java, while CanDo had no concept of network connectivity.
I am *amazed* at how many words you used to say basically nothing.
One thing you certainly didn't accomplish in your post was the formulation of a cogent counter-argument to the statement "The problem is that the problems that need solving are HARD." You opened by stating you disagreed, which suggests that you were going to demonstrate how the statement was wrong. But instead you just rambled aimlessly, making a heaping mass of independent statements that did not connect to one another in any meaningful way.
Consider:
Many businesses spend a lot of money on programmer salaries.
These businesses would do better if they did not have programmer salaries as a cost center.
These businesses would, therefore, happily buy tools that enable non-programmers, or significantly fewer programmers, to get the job done.
Therefore, there is a HUGE market for such tools, and any business that can provide them will make empire-level profits from them.
Therefore, every tech giant is doing everything it can to produce such tools already, because they all want that money.
And yet, the industry still needs programmers to use the best and easiest tools that are available today.
Therefore: the problem can't be that the industry just hasn't tried. The problem must be that the problems being solved are hard.
There, a cogent and succinct argument that demonstrates the original point.