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."
Maybe I misread/misunderstood this article but I read this as, 'let's dumb down computer programming".
Please. Google's talent is waaaayyyy over-hyped. And some of the shit I've seen them do is cringe worthy.
Arduino?
relative to many other tech things.
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.
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."
Programmers and Program Designers still do not understand the objectives or how the âoereal worldâ works. Meaning that they donâ(TM)t get the problem and donâ(TM)t have any idea what a proper solution might look like. Which explains handily the opening assertion.
There is only one direction in complexity and that is toward more complexity. There is an arrow and it only points in one direction. Eventually there will be a complexity collapse and things will start over.
E Proelio Veritas.
This is because we (or weak technical managers) let programmers change their language/framework/paradigm based on boredom. Bored with PHP/Python? Use NodeJS! Bored with your site being complete and only needing minor fixes? Make it a Single Page App and now you have to struggle with webpack and babel and angular/react. “Sorry boss, I gotta rewrite the app to use typescript, trust me it needs to be done, it’s the way the industry is going!
I say this as someone who got stuck in web dev and has to go along with my coworkers as they chase te latest trend.
If I were more cynical I’d have said “job security” instead of “boredom”.
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!
The problem is that computers are still not idealized Turing machines. Execution times are not zero and memory is not infinite. Knowing how to break a problem in proper structure is what requires years of knowledge, not large manuals of libraries, but rather the knowledge of how to map the problem to the available libraries or do you need to create something new. To manage queries on the US population do you need a list, an ordered list, a tree, a hash table, a distributed hash table or something else? Which of those is going to able to sustain 1000's of queries a second?
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.
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!
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.
The problem with saying "we need to make ???? easier so that everybody can use it" is that you need highly technical people to make ???? easier for everybody else. I see Javascript as being an example of this mindset. It was created to make it possible for basic programmers to create intelligent web pages - for teaching basic programming and implementing simple functions (like convert inches to centimetres) it's pretty good. But, choices made to keep things simple resulted in the language becoming incredibly complex to implement more than simple functions.
Mimetics Inc. Twitter
> 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.
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
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.
Users demand more sophistication than the 80x40 character-based applications I first wrote starting out. Back then, I could churn out a working departmental application inside of a week, including data tables, using a 4GL.
Who wants to go back to those days? Now we have internet instead of LANs, GUI, events, threads, all sorts of data stores, and layers of abstraction to manage it all. I don't see it getting any simpler.
If you post it, they will read.
They=> The
ugh. can't edit in /.
If you post it, they will read.
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
and, oddly, it's the capitalists who are always trying to answer this admittedly stupid question with equally stupid (but profitable) solutions.
just a ghost in the machine.
I created a Forth-derived language, embedded in C (link below) to tap into some of that old school simplicity without loosing contact with the bigger picture. Even Python is too complicated for my taste when it comes to whipping out simple tools, and not integrated deep enough with C to use as an embedded scripting language. Suggest JS at your own peril. https://github.com/basic-gongf... https://github.com/basic-gongf...
Yes, sure. The whole thing where a guy thinks you can simplify complicated things by using what you think is a "simple" tool. Because the task all of a sudden will become simple as well, right? I guess we should all start learning Scratch.
There, fixed that for you.
Bingo!
And that complexity makes it nigh upon impossible for any one person to understand everything about how their site works. (Well, I guess, unless you're a rock star.) Even then, though, you see job ads with a laundry list of "must haves", "should haves", etc. as though any one person could have an in-depth understanding of how all those technologies work---and their potential security problems if used improperly. I am still seeing emails from recruiters for what's described as an "entry-level" position that lists more requirements than I can view on my big monitor without scrolling with many of the requirements also wanting several year's worth of experience. (I can only assume that the reason these are still being sent out by recruiters is that a hiring manager hasn't quite figured out the oxymoron that is "entry-level software engineer with years of experience".) And don't think that concentrating on a major vendor's web application environment will make fully understanding how it all works together not a daunting task when the environment is made up of software tools developed by small vendors that the company bought up and cobbled together with little-to-no effort made to have them conform to a consistent look-n-feel. And that's just the crazy quilt knowledge base you need to absorb just to support the resulting web site(s). I can't imagine having to develop in such an environment without wanting to run screaming for the door.
CUR ALLOC 20195.....5804M
The line between using a computer and programming one used to be thinner. HyperCard and spreadsheets are great examples of how people brought programming to the masses. (Visual Basic, I'm not so sure of.) Shells of all kinds and other environments like MATLAB did some of the same things. Macro languages in programs like WordPerfect likewise empowered the user and lowered the barrier to entry.
My favorite example is RPL on HP 28/48 calculators. It took a little doing to learn how to use a postfix calculator, but once you did, all you had to do was enclose the keystrokes you'd normally use inside a <<>> and BOOM, you're programming. Then users, having already stepped over the low barrier to entry, could gradually learn additional constructs as needed instead of needing a full 'intro to programming' class before they could do anything useful.
Thing is, none of the good examples that come to mind date from 1990 or later. Our ideas about how users interact with computers have for roughly thirty years been too stagnant or too simplifying and un-empowering.
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.
Every time someone does that, their "simple" tools end up being used for problems far more large and complex than they were designed for, and we get a godawful mess. Think shell programming, Perl, PHP, Excel, etc. (Spreasheets have been used to produce the most opaque, incomprehensible modeling code I've ever encountered.) It's the Peter Principle for programming languages and tools.
I'd say it depends on what you are trying to do. As a general purpose programming language, VB indeed did suck. But as a platform for internal CRUD applications (data entry and search forms), it simplified a lot of common tasks. Users loved tabbed forms.
Delphi was more flexible in terms of customizing the architecture and distribution. For data-centric applications with a similar drag-and-drop programming feel, there was also PowerBuilder.
A language or tool probably cannot be optimized for all usages. Same with the web browser: it's pretty good for e-brochures, but weak at productivity and data-centric applications.
Table-ized A.I.
> 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,"
FoxPro on DOS fits that.
Did you actually read the article? He proposes the programming equivalent of "trade school" education - which was pretty common 30-40 years ago.
On the other hand, he complained that nobody is going back and rewriting legacy code, just layering on top of it (that's the context for the "100k lines of documentation" comment). I understand his concerns, but this is as unattainable as expecting politicians to review and rewrite all the old laws. The vast majority of organizations can't afford the resources necessary to re-engineer, rewrite and re-validate ancient code.
People have been saying "programming should be easier" forever.
Many have tried, all have failed.
And the task keeps getting bigger because the uses and requirements keep expanding. From one simple input (keyboard) from one source (user) to a variable domain of many complex inputs from many sources. From one simple output (answer) to a variable domain of many complex outputs to many destinations. And the core tasks, too, aside from input and output, are far more complex than they were.
If you have one hex nut to loosen and tighten, you can make a simple wrench to do it. If you have to be able to work on an infinite number fasteners—hex nuts, machine screws, torx screws, allen bolts, grommets, flip latches, tumbler locks, screw-down locks, snap fittings, adhesive strips, magnetic plates, snap rings, cotter pins, etc. and the domain of tasks goes from loosen and tighten to loosen, tighten, open, close, diverge, converge, adjust left, adjust right, increase weight, decrease weight, etc. and the number of possible surfaces increases from two adjoined flat surfaces to be bolted together to N surfaces of M possible shapes... Well, you're going to end up with a shed full of tools, each one of them reliant on a different kind of knowledge and experience.
Life is complicated. Programming is approaching use in virtually every domain of life. Ergo, programming will be complicated.
You want programming to be simple, you may as well start off by trying to make life simple—that's the root of the problem.
STOP . AMERICA . NOW
That's what all plattforms are.
To emphasise: Today we do applications in a webbrowser and the avantgarde is done in a scripting language of which - if you had said it would rule the world 20 years ago - people would've stuck you in the l00ny-bin.
The biggest remaining problem today is that visual stuff (builders, modellers, DMIs etc.) is still 10 years behind what used to be the epitome of DMIs (direct manipulation interface ... look it up) called Flash. That was a prorpietary technology and had a shitty herald (Adobe) but it was cross-plattform and any idiot could wip up a feasible piece of software that was good looking and ran everywhere within a few hours.
Full-stack - and I presume we're talking about the web because, ... what else is "full-stack"? - looks the way it does because it's FOSS tech bolted on to FOSS tech each of which became popular for totally different reasons. I expect us to weed the problems out within the next decade or so and then programming will have universally become some neat DMI / BPM / Modelling thingie with code attached whenever needed and whenever an expert is needed. Today, we pay little more than a maintenance allowance for tools that used to cost as much as a luxury car (or an entire luxury carpark), if we pay at all.
Plattforms will become a fashion choice, nothing more. See Apple for how this is done well. And programming will be easyer than ever with most work done by bots anyway. Just look and see what is happening in the middleware and ERP space right now - high profile toolkits and the high-profile specialised jobs that come with it are dropping left, right and center and we flexible FOSS tookit and web proggers are going to have the bots on our heels aswell. Sooner than most would like to believe.
My 2 Eurocents.
We suffer more in our imagination than in reality. - Seneca
Tons of programming languages, libraries, tools, etc, etc. Some are easier than others save when you have a problem they aren't suited for. There is no such thing as one size fits all programming, and I'm pretty sure never will be.
many of those libraries are driven by ego. others are driven by unintelligible code bases that make it easier to create another unintelligible code base than modify the existing unintelligible code base.
I think the thing that this person may be missing about the 'internet age' is that people don't read all the documentation and understand every aspect before sitting down and starting a project. I think people are generally going to do a quick start or some tutorials and Google on anything else they need, or reference it then.
Laws are rules for the court, but merely a bottom bar to hit for life. Think beyond laws in your actions always.
Cultural references don't work any more. A tiny, tiny, tiny fraction of readers watch NCIS. Most people probably don't even know it's a TV show.
Also, what's wrong with advocating for better tools? Please post your better ideas if you have them. Then it would be an interesting discussion.
If a solution takes a Business Analyst, an Architect, Security Expert, DBAs and Testers to deliver, why would you expect the actual coding to be simple?
> don't think your solution of hiring just "a professional" works.
I specifically said hiring just a "professional", someone hired as a programmer, is not sufficient. In my other post I mentioned that I still study several hours per week, because new vulnerabilities and attacks arise every week.
I also insisted on establishing code review / peer review at my job, where other people trained in security review all of my code before it's deployed. We have weekly sessions where someone on the team presents something related to security for the all of us to learn - continuing education every week. Those things are part of actual professionalism. Now, I'm learning more about how one of the best companies does security with software designed for top secret software. I'll apply what I learn, where appropriate. Lockheed Martin seems to take security very seriously, and do a pretty good job. If anyone reading this has worked for Lockheed, I'd enjoy talking to you.
They do: VB, Delphi/Lazarus, PowerBuilder, Oracle Forms, Paradox, Clarion, and a few others.
The problem was deployment, and NOT programming productivity. Nobody ever said, "Our GUI/CRUD tools make programming too tedious, let's go Web!" Deployment issues are what "sold" the web: reduction of client-side installs and updates. But, we should revisit the assumptions behind all this.
As I mentioned elsewhere, Oracle Forms used to have a thin client that was relatively easy to install and distribute, but they mucked that up when they converted it to Java: a really fat client.
The mantra of the Web was that in order to get easy or no deployment you had to live with a more complicated and layered development environment. You either hired 25 more deployment specialists (desktop support) or 10 more programmers, and the second looked cheaper to most bosses and owners. (It's why we've had a dev boom/bubble.)
Implied is a fundamental trade-off between simple development and simple deployment. The theory is that one MUST make this trade-off; that it's hard-wired into the Universe.
But I'm not convinced it's a Law of Nature. Nobody's produced something akin to Amdahl's Law for an inherent dev-vs-deployment tradeoff.
Pre-Java Oracle Forms seemed to just about get it right (with some fixable qualms). I believe if the client's and server's responsibilities are partitioned well to avoid a bloated client standard, we can have the best of both, or at least a better mix than the current web mess. A work-world-oriented "GUI browser" standard.
Table-ized A.I.
I was part of the generation of kids who latched on to the early 8 bit personal computers and learned to program in BASIC because, well ... that's what the manuals told you how to use them. As things got more advanced, I started a hobby of running my own computer BBS, and initially used software I wrote myself in BASIC. (By then, I was already hitting limitations of what the language would let me do, because BASIC had no way to collect input or produce output to and from my modem. I had to use a lower level assembly code driver program to handle the I/O. A friend of mine, who knew some assembly programming, helped code that and maintain it for me with updates for a while.)
By the time I'd done that for a few years, the Borland "Turbo" products for coding in PASCAL or C were becoming really popular, and friends of mine were modifying existing code-bases for PC compatible BBS packages using those languages. I was too invested in what I'd put together in BASIC to care about that, at the time.
When I finally went all-in on a PC clone (vs. my Tandy Color Computer 3) - I was sidetracked by other things in life, including learning to play guitar and playing for a while in a small, local band that some friends had put together, and taking college classes. When I re-visited software development for Windows, people were WAY ahead of me, using the visual development languages and object-oriented programming, which was a foreign thing to me.
I went on to a career in I.T., which I do to this day, but beyond your basic batch scripting, I really don't ever attempt to code anything. Truth is? There's SO much out there already, I struggle to imagine scenarios where I'd ever want to write something that hasn't already been done! It's a full-time job mastering several of the existing Enterprise-class products on the market that a given employer might expect me to be proficient in.
I think I understand what Jonathan Edwards is saying, because it's exactly what I experienced that drove me away from programming. But I'm not sure it's a "problem" anymore? The days of things like HyperCard are past us because the types of applications one would typically create with them are already readily available, and in the form of code that runs natively on the system without "helper" software interpreting it first. Even in my early days of using BASIC, I hit hard limitations on what it could do that forced me to use outside assistance (that assembly code device driver for modem I/O).
The expectations for the level of what applications, games or utilities do is high enough, today, that I think you need specialists, well versed in complex programming languages, to pull them off. There are times I really do missing coding in BASIC. To this day, I remember the commands and most of the syntax. But even with the "last gasp" of attempts to modernize traditional BASIC with those BASIC compilers they had for MS-DOS for a while? The language just couldn't DO enough to keep up with people's expectations.
This argument works just as well for other professions; allow me to demonstrate.
People have been building airplanes for roughly twice as long as their have been computers, but yet we are still paying hundreds of millions of dollars for top-end fighter jets. Why is that? Why have we not yet advanced to the point where building fighter jets is commoditized, and can be done with minimum wage workers with high school educations? Why do we still have to pay exorbitant salaries for so-called "experts", in this nerd-driven culture of exclusivity? #RocketScienceForAll
See, the answer is pretty simple, when you are enough of a "rock star nerd" to apply some simple logic. Making complex computer programs is "hard", and thus requires people with "intelligence" and "experience". It's the same in pretty much every specialized profession; programming is sorta the outlier because for some reason (media, outreach, or otherwise), people seem to have the misguided notion that if we were better at dumbing it down, we could make it accessible to everyone. The reality, though, is that for the same reasons that we don't have many high school only educated doctors, or lawyers, or physicists, or rocket scientists, etc., we also don't have (and it's not really possible to have) a plethora of minimally educated/experienced good software developers.
TL;DR: Don't be an idiot, good science/engineering is hard, and that's why "normal" people cannot magically be good engineers. Try to remember that good engineering is hard, even if ignorant people say programming should be easy.
It's why JavaScript, PHP, VB.NET, etc exist and are popular. The learning curve isn't so too steep and just about anyone can write small programs in them. If you want to make a large and complex program, well that's a tough job. I guess we should be sorry that we haven't made it easy to do hard things?
Car analogy: It's not too hard for an amateur to make a small steam engine or small electric motor. It's significantly more complex to make a fully working and safe car, that includes engine, brakes, rolling chassis, etc.
“Common sense is not so common.” — Voltaire
Yes, some tasks only require a quick solution without a lot of engineering; but complex systems that run frequently need skilled programmers to design and build them.
Back in the day, software had to be as small and efficient as possible because CPUs were slow, memory was limited, and storage took forever. Programmers would sometimes take days to squeeze out a few percentage points of efficiency in a single function. Today, all kinds of horrendous software can run fairly quickly if you put it on a fast enough machine. The cloud can make things even worse. An atrocious algorithm against a large data set can still get done in a less than a minute when it runs on a 1000 server cluster. The fact that it could have run even quicker on a 10 server cluster if the algorithms were changed, is rarely explored...after all it works, right?
I am building a new, general-purpose data management system. One of the best things for its development, was my insistence on testing it on a 10 year old Core 2 duo processor (Q8300) with only 4 GB of RAM and no SSD. It forced me to really optimize a bunch of things so that it was running fast on the old box and is thus lightning fast on the latest hardware. It is an object store that can do file system, database, and NoSQL operations within a single system. The database queries it runs have so far been about twice as fast as PostgreSQL in my benchmarks. It can store 100 million files and find them thousands of times faster than file systems like NTFS or Ext3. I am currently working on ingesting data exported from MongoDB (Json) to see how much faster I can make that run too.
Put numbers on each face of the cube. You can quickly manipulate the cube on your turn, then roll it like a die. add up all the numbers on a face and that is your result.
“Common sense is not so common.” — Voltaire
Look at the use cases for computers in the 60s. 90% of that can be done by installing a package.
Or the 70s, or the 80s, or the 90s.
A million accountants worldwide program: They program a computer to read in data, manipulate it, transform it and output it again. They happen to use Excel to do this.
A million Android users automate their daily schedule. They use ITTT, or the new Samsung thing that got installed on my phone yesterday, or some other programmable automation tool.
Thousands of call centres are automated by people that barely know how to use a computer. They use Blue Prism or Automation Anywhere or an equivalent.
Full stack developers don't do this shit. They don't need to. They deal with more complex systems, that do more complex things, and write the tools that others use to do the easy shit.
Oddly enough it's hard. Robust, secure, scalable, performant code is easy, if you don't need it to do anything. When you're asked to make it do everything, and what 'everything' encompasses changes on a daily basis, and you're given a deadline that's too soon.. yeah, it's hard. So be professional, learn how to do it (including managing the requirements, the deadlines, the budgets and the ways to optimise the fuck out of the lot of them) and stop bitching.
But what the business needs hasn't really changed much for those types of apps. It's still a matter of maintaining master data and entering transaction data. Today's ERP apps generally look the same as 80x40 but inside a GUI window instead, and the reason is because the actual app requirements are the same: enter character based master and transactional data. There are some examples where graphics adds real value, like displaying images of items, or grids of detail with cut and paste, but most of the apps haven't changed much.
....and this is how it should be until the business requires an intelligible code base.
I object to power without constructive purpose. --Spock
Web apps will die as mobile cross platform matures.
I object to power without constructive purpose. --Spock
Anytime I want to write a quick program for my linux system, I have to decide on which gui framework to use. And they all have big issues. 95% of my time is dealing with the issues - which change with each update and 5% is actually writing code to solve my problem du jour. I've resolved to writing things in the terminal with ncurses now (least common denominator. Screw all the gui idiosyncrasies and especially bugs.
Hypercard was THE answer. We could do something quick and dirty working just with graphic interface, or use Hypertalk if we needed something more sophisticated, or write an XCMD or XFNC in C or assem. if we needed more in capability or speed. Never having to deal with the Mac's graphic subsytem. It could have morphed into being the finder and the core interface for the Mac ala smalltalk. But Jobs was never a programmer's visionary. I would buy a Mac today, IF it came with a modern Hypercard. But it would probably be bogged down with so much baggage that it would be unrecognizable.
Software is a force multiplier - it doesn't inherently do anything, it allows people to multiply whatever they do.
It's good that software isn't a super-simple thing to do, because we don't need to multiply the level of retardation in the world.
If software becomes easy enough for everyone to write then everyone will write software, meaning every fucktard on the planet has equal influence over the world to the non-fucktards
The fucktards are more numerous so this would basically be an extinction level event.
They should make the tools simpler so everyone can participate.
They have. It's called an "Arduino".
You know, have like blocks that fit together so you can build a robot
They're called "Arduino Shields".
Or if you prefer, it's called I2C or SPI. But really, you can build a robot by taking an arduino, attaching a stepper shield and plugging in a beefier PSU and some steppers. Adding even pretty advanced sensors is a question of shoving another shield on.
But if you think a lot of EE hasn't got easier recently, the you really really haven't been paying attention to the field.
SJW n. One who posts facts.
Programming is easy. Many people can pick up programming, put them on a computer with logo and have them move the turtle. Et voila many people will pick up quickly how to move the turtle. And bam you are a programmer. But see the difference between a programmer and a developper is that there are certain more complex you have to understand to make something, e.g. security, how memory function for your framework, GUI concept, HMI concept, what is the difference beetween n.log n and n^2 , and is it relevant to your application, scalling, maintainability, normalisation and when to use it and so forth. The difference between programmer is the same as knowing how to apply cpr , and how to be a heart surgeon. Everybody can do the one, but it need training and understanding to do the second. I have 30 years of developpment training and often i think I feel I am still at the programmer level, butchering stuff rather than do good development. But at least those 30 years gave me to see that not everybody can do development and a lot of folk don't understand those important concept. I have had many *programmer* not understand the concept of maintainability and shit code which long run make us lose hard cash. Or use normalization haphazardly.
Making programming easier does not help one understand the more complicated concept, and thus it will not enhance the quality of our software. Just like not everybody has it to be pilot or heart surgeon, sorry, but many of us are not really developper, we are code butcher.
C. Sagan : A demon haunted world:
http://www.amazon.com/gp/product/0345409469/
visit randi.org
you want a fail safe and simple solution that solves complex problems. I wish I thought of that, I'd make billions I tell you.
While the article proposes 'trade schools', I think similar results can be accomplished though further visual abstraction which will benefit everyone: just like 'real programmers' and regular people use a desktop GUI to visually organize and minimized the lists of commands they need to know, the same can be done with programming. Indeed, one can already see impmentations of this with things like:
IFTTT
Stringify
Pipeline Pilot
Orange
Scratch
mBlock
Bubble.is
etc.
Funny you mention WordPress. Scheduled for the next sprint, we'll be programming detection for over 800 known vulnerabilities in WordPress plugins, and 300-400 in WordPress itself. If WordPress plugins are your example of programming by non-experts ...
I was involved with a pie in the sky project where the developers were given a chance to rewrite and entire legacy application suite. We ended up with a new legacy code base consisting of all the latest fads and trends which were misused and abused. It is worse than the old legacy...literally.
I object to power without constructive purpose. --Spock
Unless you can teach the average schmoe the difference between O(n^2) and O(nlogn), you've got no hope of bringing "programming" to the masses. I sped up a visualbasic "program" written by a "normal", by fixing their check for duplicate records by sorting *first*, then looking for dups, instead of going to each row, and checking every other row in the database for dups. Went from running 48 hours to less than 2.
Put another way, there are *lots* of ways to program poorly. Democratizing even the most basic tools won't prevent that.
IBM still makes a good deal of its money building hardware and operating systems that support 40+ year old software. Some of this software has cost hundreds of millions of dollars to develop over decades, and replacing it would be obscenely expensive, not to mention disruptive. And really if it still works and is still maintainable, then what's the problem? When you stop finding programmers who can work on the system, then you've got a problem, but until then if you have a vast sunk cost
The world's burning. Moped Jesus spotted on I50. Details at 11.
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.
What you are saying is that you want to be a code monkey because you are too lazy to properly learn most of what is needed to do things properly and clean without taking short-cuts. You must be a millennial!
Tired of my customary (Score:1)
We used to be able to build GUIs with a few thousand lines of code, now you need hundreds of megabytes of js, css, html and whatever else, and everything interacts in strange ways and weeks breaking and getting broken in to. Its a clusterfuck of terrible design.
http://michaelsmith.id.au
Rewriting ancient legacy systems is trivially easy. You just have to leave out all the accumulated business rules.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
Well boohoo. I like our nerdy culture. If you wanna be a sanctimonious white knight, there's always the Rust community.
He proposes the programming equivalent of "trade school" education - which was pretty common 30-40 years ago.
Trade school education might be fine for trade school problems, but which master practitionser is going to decide whether a problem is a trade school problem or not?
When all you have is a hammer, every problem starts to look like a thumb.
Christopher Hitchens:
With writing, the bar is to be more interesting than silence.
With coding, the bar is to achieve a tiny modicum of formal consistency.
Most people suck at both.
And this is before you describe the operating environment, which 90% of those 100,000 pages of documentation are actually addressing.
The average internet user has trouble expressing his ideas, even after years of schooling. Considering they can't master the English language, I'd be surprised if they get any result out of the more formal computer languages.
ID: the nose did not occur naturally, how would we wear glasses otherwise? (apologies to Voltaire)
Programming today reminds me of the clutter pervading so many homes in the 70s, 80s and early 90s. No surface free from some sort of curio, knick-knack or souvenir. Some useful, some to document an important precept, or capture a moment, some just for entertainment.
Programming needs its own minimalism movement. Mental work surfaces free of clutter, with the sophistication baked into tools that are visible.
For instance, webMethods, a Java-based programming IDE from the 90s, had the right idea back then. A program statement in their native 'Flow' language was no longer a linear line of text. Instead, a line became a 2-D canvas, graphically showing all the in-scope stack variables (so you were reminded of what was in-scope). The variable types (Java objects, strings, arrays, etc) looked different and could be manipulated in the canvas -- so a single 'step' could do multiple assignments, math operations, etc. It also had nifty builtin operations to snapshot and restore the stack-frame (handy for debugging).
Unfortunately, the core webMethods language hasn't progressed much in the two decades it's been around. Neither is it open-source.
I agree with everything you said except one nitpik: web browsers are only marginally tolerable for graphics design and brochures. Many of the designers of CSS and HTML didn't want it to be good for that, they wanted it to present information and thay was it. Other people wanted that, of course, but the result of these conflicting goals is one that does page layout, poorly. This is all my opinion, of course.
"First they came for the slanderers and i said nothing."
The problem, I think, is that the overall model is lost. That programing has become something different to doing things on the computer.
In younger days, I could program Lotus for DOS, even doing clever things like programmically hiding lines in print, or adding one's own menu to a spreadsheet. Then Windows came along, and it was all hidden in things like VBA. It no longer was a copy of the commands with logic.
When you could get into files, and see what was needed, you could program for it. I used an RTF file as a batch for a rexx processor, that created documents based on the user input file, and checking the file you could produce good copies of letters. It's a lot harder to do this with a binary file.
I still use REXX. It's a simple language, and IBM envisaged it as the glue of the OS. But they did not lock it up like visual basic. The thing is an extension of the command prompt, and you can write neat filters for things, or fiddle with INI and registry, and create desktop icons from a batch. The current install on my computer is to copy a directory structure, and run the batch file to create links to lots of programs.
OS/2 - because choice is a terrible thing to waste.
The comments here are mostly in two groups: (1) those who feel that programming is fundamentally simple and anyone should be able to do it, given simpler tools, and (2) those who feel it is fundamentally difficult and not everyone can do it.
Those in group (1) point to languages like Python and Basic as proof that anyone can program. However, there is an important issue that is missed in most of the comments: How productive a language is for the original programmer, versus how easy it is for someone else (on your team, or another team months later) to figure out your code and be able to modify it safely. These are very different things.
For an organization with lots of teams, it is very difficult to create maintainable, shareable code. It really takes a professional. I have been in many organizations that had to deal with "the end user computing problem". These organizations undertook large efforts to get code out of the hands of users and into the hands of professionals where it could be maintained properly.
Should it be so hard to code? No, but we are kind of stuck. The OSes and frameworks keep getting more complicated; and worse, the fundamental technology choices that underpin most things were deeply flawed choices - we are stuck with approaches that make things brittle and unnecessarily complicated. Thus, I see little hope of non-professionals being able to write code in the context of those flawed frameworks and technologies.
One of the biggest problems anyone sees if they look at the code being put into production is that whoever wrote the code never gave any thought to its being maintained later, after he/she departs the project. The coolest, froodiest, whiz-bang collection of libraries in use today may have been completely discarded when the next programmer comes along to fix the security hole written into the website/application/whatever, and perforce the new programmer MUST reinvent the wheel in order to repair what the first programmer never saw as a fault.
Languages such as COBOL survive because they are, in large part, self-documenting. (They also survive because no newer language is capable of accomplishing the job the original language did...but that's a separate argument.) While we slog our way through our next entry in the "Obfuscated C contest", similar code gets put into production as back-end processes for data mines, with predictably poor or unusable results, and after the programmer gets fired for not accomplishing the design goal in the PHB's time frame, the next poor sap dropped into the chair is left with trying to puzzle out what the first one was trying to do, and matching that up with whatever design specs the PHB expects to be met, and doing both in the same or shorter time frame as the first poor sap was given. Meanwhile, COBOL applications written 40 or more years ago continue to do the job they were designed to do, and do that job very well, and (provided one can still find a COBOL programmer) are maintained at comparatively low cost.
To avoid being accused of crossing Teddy Roosevelt's line (paraphrased as "Pointing out a problem without proposing a solution is called whining"), here's part of the answer: start programmers out on the KISS formula, and keep them writing code to that formula.
That's as far as I go.
All the world's an analog stage, and digital circuits play only bit parts.
How can you make things easy when what you're trying to achieve changes all the time? Sure, if you want static pages that work at desktop resolutions of 10 years ago, I think you've got the problem licked. Want something dynamic that changes style between desktop and mobile? Sure, you could design it now. By the time it's done and bug free, things would likely have moved enough that it won't fit the bill.
It's easy to make something that would be easy to use -- just limit its scope severely. There's pretty much no other way to do it (although AI might get to that some day, and you'll be looking for a new job). You already have a multitude of solutions of this sort. I can create a nifty site quite easily at Wix or a nice blog at WordPress.com. The only problem is, they're not what your client or your boss wants, and they will never be.
https://xkcd.com/927/
The problem here is not to make programming easier but to classify the type of tasks you are trying to accomplish.
Some tasks are easy and can be accomplished by anybody without training, so the people without knowledge or sophisticated skills can work them easily. But other tasks are very critical and complex and well trained specialists need to work on them.
Don't try to put everyone in the same basket because you will obtain super complex and heavy things (when you need to do special programs with very easy and powerless tools), or super dangerous solutions (when you are trying to use those easy to use tools in critical environments).
Another issue is about the computers. Before everything was "Basic" because the machines were very simple, slow, with less resources, so only Basic or machine language was possible. But today the user machines are ultra powerful computing devices with many layers or complexity to deal with. An option is to go the Raspberry Pi path and to define small simple things on machines that only do one thing and can do it without a lot of complexity, and not to try to resolve all humanity problems with the current bloated operating environments that are excessive in everything they "try" to do. This is not a programming problem, this is a conceptualization one.
Okay, I'll share a peak into my history when it comes to programming. Started out with raw assembler on 68xx and 8051 8 bitters. Complex and frustrating for the first six months but then it was easy. Then came the RISC parts in assembler not too bad to adjust to. Then I changed jobs and created programs to run on DOS for production end of line testing using QuickBasic. I literally said to myself this is for kids given it's absolute simplicity. Then I shifted to C on embedded micros, very nice as it gave you almost as much flexibility as assembly did, but in a far more human like language, so I found it to be perfectly in the middle of assembler and basic. As the embedded processors got bigger and faster I stayed with C and let all the young whipper snappers go down the path of C++/prime/sharp and so on. For me those spin-offs just added complexity that to this day I still say is overly complicated even when running on Cortex M4s. Of course somebody came out with a zillion RTOS's to make life easier. I never went the way of RTOS, but my co workers did and seem to like it. But over the years I've shifted from software/firmware to hardware. I write enough code now to validate the functionality of the hardware, and C works very well in that environment. In short, I stuck with C and didn't bother with the babble and its complexities today. So, for embedded, I say C is the Language, it goes great with a bottle of Vodka too! But then of course there was a fellow I worked with 20 years ago that was stuck on embedded Fortran, he loved it!
Life is in a state of dynamic equilibrium, it both blows and sucks
Delphi is still in use. It's used for major application in the industrial and transportation sector. I work with it to create industrial GUI's and communication software.
It is better than ever, and is gaining very good cross platform capability.
In the bad old days of Basic, software structure and layers were non-existent. Good luck trying to reverse-engineer somebody else's old code! Today, programming has become much better structured, making it far easier to maintain and extend. There's no way I want to go back!
The hardest part of programming is not the coding. It's deciding exactly what you want the software to do! This is called engineering.
In a way, it's like road building. The hard part is not moving the dirt around and pouring concrete. The hard part is deciding where you want the road to go, buying the land where it will go, putting up with people who don't want the road nearby.
Well maybe, but they are usually less critical. If your ad doesn't display right on 2% of browsers, that's not a big loss. If your app doesn't work on 2% of browsers, then you flood your help desk.
Table-ized A.I.
If someone just finds a way to make Delphi/Lazarus easy to deploy (install & upgrade) on desktops, it might catch on in corporations. Desktop deployment headaches are mainly what made Web-based applications catch on. Solve the deployment problem and we can get away from the spaghetti web stacks, and UI's become simpler to make again. MUISA!
Some say Microsoft has greatly improved Windows WPF application deployment, making it automatically detect upgrades, prompting users; and optionally automatically upgrading without a prompt if the developers choose. The pendulum often swings, so maybe desktop apps are back.
Table-ized A.I.
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 women to entertain themselves for fifty years.
Johnathan Edwards, yuou have outed yourself as a sexist bigot. Gotta remember my good sexist, if you Exchange "women" for "men", and it is considered sexist, the original statement was as well. I mean, it is politically accptable to blame matters on people by the basis of them having a penis, but that's their sex.
The shepherds did so well protecting the flock that the sheep no longer believed that wolves existed.
I agree with the general sentiment. My own answer to this was something called "concept programming", which focuses on the translation of ideas into code. The following presentation gives an outline of what this means and a few early results: http://xlr.sourceforge.net/Con....
From that I derived a concept programming language called XL, https://github.com/c3d/XL. Which keeps evolving too fast to ever stabilize. Two semi-stable variants emerged, however, one called Tao3D for interactive real-time animations (http://tao3d.sourceforge.net), one for distributed programming and the Internet of Things (https://github.com/c3d/elfe).
Both variants demonstrate, technically, how well the concept programming approach works, and how well it answers the original posters questions. However, nobody cares. None of these languages ever reached a "good enough" status, i.e. a status where you can really make a living out of programming them.
I'm still working on this, though, and I still believe that the original idea is sound. It just needs more focus on execution, ironing out all the details (e.g. having a complete runtime support library), building a community, etc, things I never really had enough resources to do well enough.
-- Did you try Tao3D? http://tao3d.sourceforge.net
Which is why there is still so much COBOL code still in use. People who hate COBOL and want to replace it with a Java, C# etc. application instead are not aware of how complicated and involved the COBOL code is, also how much money it cost to write and get rid of all the bugs. Writing software is a time consuming thing, and since time = money writing software starts to get VERY expensive.
There are three kinds of falsehood: the first is a 'fib,' the second is a downright lie, and the third is statistics.
It's been tried - and rejected by the folks that pay salaries.
There was a programming language way back that utilized a flow chart type language with visual blocks that you simply filled in the logic parameters.
Arguably Visual Basic was accessible to non-compsci folks. Nope - they hired people to code still.
Hypercards died from lack of interest.
IBM had a database product with flexible field definitions assigned as a form.
Basically you picked a field type, gave it a name and label, slapped it on a form and the thing would create a database.
Filemaker used to be approachable in a simplistic manner.
Nope, truth of the matter is that business people simply want to offload responsibility for doing to doers and stick to managerial tasks.
Corrections:
Re: "can crank out applications at about 1/7 the pace"
It should be "at 7 times the pace": 7 applications per 1 application from the web stacks. I should also clarify it doesn't really speed up the analysis side of things by 7 times, but because they can make an actual product faster than others make examples and prototypes, it does speed up the feedback cycle with customers to a degree. (Our web stacks could probably be simplified to some degree also, but our shop is stuck in habits. With a well-tuned web-stack, per fitting our org, the ratio would probably be 3-to-1.)
Re: "learn from the failure Java applets and Flash"
Should be: "learn from the failure of Java applets and Flash"
Table-ized A.I.
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.
I've seen many of these "technologies" which are supposed to make programming easier and more accessible, from the ones cited to things like true visual programming (e.g. LabView...) and the by far the biggest problem these "solutions" have is that they are only really applicable to trivial problems, and when you try to apply them to large real-life problems, they quickly become unusable and WAY more complicated than traditional approaches.
Sure, it might be easier to write "Hello World" with some of these, but try writing an enterprise app that has to handle hundreds of thousands of users with them: you're either not going to be able to or it's going to be a LOT more complicated than doing it the normal way.
TL;DR
Trivial solutions only work for trivial problems, and most real life problems are NOT trivial.
Two seconds into a discussion about how programming computers should be simple and easy to do without a CS degree and all our multiple coding/design/development designations - we get into wanking about Arduino or C++, frameworks, Java . . . You just don't get it do you (mostly) guys? It isn't about the tools you love to handle and the joy you get from them yourselves, it's about the ease and speed with which you develop a working, bug-free system for your client.
I opened Visual Studio 6.0, had no idea what to do in the IDE. So I opened the help, clicked on Getting Started. I got to a page that told me how great Visual Studio is. I clicked links to other pages, and other links there. And I just came to pages that told me how great it all is, and I did not get started at all. It was just a large loop between such pages.
And I already knew how to program, in Delphi, Pascal and Basic. I got along with Delphi without any outside help. But this Visual Studio was just impossible to get along with if on your own, without literature.
Web Code is a solved Problem: How about fixing Web UI next?
Table-ized A.I.