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.
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.
... 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!
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.
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.
Like I said - god complex.
You are not a surgeon. Also, we need waaaaaay more programmers than surgeons.
> 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.
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
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.
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.
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
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."
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.