To each their own. Yes, I'm sure one day more people will use software that allows them to put together amazing programs using complex GUIs that do wonderful magic. These may be business programs that do statistics, or games, and we've already seen both (hello Excel, hello game studios). The problem, as it always has been, is that point when you want to do more and suddenly find yourself in asm land or looking to talk to mysterious "drivers". After all, what's a port anyways? Does that mean my computer has Docker built-in? As I hint, people will hit that wall of mystery, and lower-level programming become inevitable. After that happens, they eventually become accustomed to this idea of telling a computer what to do by strict commands according to a specific protocol. For the average guy who never gets into it, you could tell him it's kind of like talking to a dog. "Sit." It sits. "Love." It wags its tail. "You're so smart, pooch." It gives you a blank stare... and keeps wagging it's tail.
These days, when I look for a programming language, it's not about the syntax sugar, it's more about the feature set that comes with the language: things like the module and build system (e.g. Java is pretty easy), the ease at which both complex and trivial tasks can be accomplished, and the availability of support community and libraries.
Agreed on the "let's make programming more accessible" point, but meh on the "good old days" view. I've been writing software since 1976 so I have some perspective on the good old days. Programming was always arcane, and it always required specialized knowledge and the patience to work at a level of detail few people find enjoyable. Yes, there were things like hypercard that opened up programming at a certain level to a certain semi-skilled person. Excel falls into the same category. But in the end it is not the symbology, or the tools, or the environment that makes programming difficult: it's the mental process of building up complex behavior from little pieces, analogous sometimes to being handed a bag of atoms and instructed to build a toaster. Some of us find building up these intricate abstract models fun and rewarding, but believe me we're a tiny masochistic fraction of humanity.
I think the idea that programming is a back-room industrial or maintenance operation performed by specialists misses the point that programming is also another way to use your computer. The most fluid and limitless way, in fact.
Programming is not just like being a car mechanic or factory floor engineer, its like being an expert driver at the same time.
When I use my desktop, it often occurs to me that I could write something to speed up a task, if only the application was accessible in a similar way to Emacs, or had Amiga-style ARexx ports that I could talk to in a script. From this perspective, programming is the most fine-grained GUI affordance within a computer system. By making it accessible along a continuum with simpler GUI tools, we greatly increase the ability of the user to do magic, or to learn to do it.
I would really like to see the development of an ergonomic expert-oriented desktop that lets me use my programming skills in a high-level and bureaucracy-free manner, to augment my use of an attractive and well-integrated GUI. There's no reason why such features should impinge on ordinary non-programmer use.
Sometimes I wonder if the current state of software/programming will, in the future, be seen similarly to cuneiform or hieroglyphics, in the sense of it being an archaic, overly complicated form of expression needlessly reserved to specialists. Coding might be something everybody is required to know in the future, like reading or writing are now. What I envision happening is that whatever become the popular languages will sacrifice similarity (in the sense that even across functional/imperative/OOP/etc families, languages are in general low-level/explicit enough that coding in them is similar) in favor of a highly opinionated programming style designed to make it easier to program in.
For example, imagine a language and IDE designed in tandem to compliment each other. You could incorporate all kinds of visual models into the design of the code, and actually make it easy/automatic to include things like the standard library, which you could make very large. The language could require such a high amount of structure that once you learned it to a reasonable extent, there would only rarely be a need to look up how to do something completely new. If kids learned how to use things analogous to e.g. python/matplotlib instead of excel, or jupyter notebooks for science reports / presentations, just imagine how much more productive we could be as a society.
I'm happy knowing that even if we suck now, we can perhaps live to see a future where we don't suck. I just hope it's soon
This scepticism shouldn't surprise you. Not being sceptical is just an indicator that you've not been in the field for long enough.
30 years ago, the end of programming was prophesised, because 5th generation languages (5GL) and visual programming would enable everybody to design and build software.
20 years ago, low-code and application builders were said to revolutionise the industry and allow people in business roles to build their applications using just a few clicks. End-to-end model-driven design and development (e.g. using Rational Rose and friends) were to put an end to bugs and maintenance problems.
10 years ago it was new programming languages (e.g. Rust, Go, Swift, ...) and a shift to functional programming that was advertised as being "the future".
Today it's back to "no code", e.g. tool-(AI-)driven development that's all the rage.
It's not so much being "uncomfortable" or clinging to the exceptionalism of the human mind. It's just experience. Every decade saw its great big hype and technological breakthrough, but the lofty promises didn't hold water.
Note that this doesn't mean nothing changed - model driven development still has its niche, visual programming is widely used in video production, rendering and game development. Features of functional programming have been added to many "legacy" languages and many of the newly introduced programming languages have become mainstream.
The same will happen with AI generated software. There a large portion of the "mechanical" process of programming will be done by AI. Large and complex software systems with changing requirements, however, will still be designed and implemented primarily by people.
Programming is a conversation between humans and machines. AI will in many cases shift the conversation closer to the human side, but fundamentally it'll still be the same thing.
I like to think of it as the difference between writing your program in assembly and writing it in Haskell; different approaches, same basic activity.
This article is very silly. Complaining that software has gotten easier to use but programming remains difficult is like complaining that cars have gotten easier to use but automotive engineering remains difficult. The design and construction of an end product is not the same as the end product itself. Product like cars and software can be made much easier to use over time with better design and technology. It's not obvious that the design and construction of these things itself can be.
Many people have tried to achieve this and will continue to try - look at light table and Apple's playgrounds for recent attempts. But these 'revolutionary' 'accessible' programming tools have never delivered on their promises. This is something Fred Brooks predicted in the 80s. Much of what makes programming hard is essential complexity inherent in the problem to be solved. Improving our tools and processes is a good thing, but there are no silver bullets when it comes to improving programming productivity.
"Do we continue to dumb down software to exclusive casual usage for house-moms or we try to move our society to be more techn savy as we are clearly moving to a more tech relying world. Why shouldn't everyone know how to code?"
To quote a commonly-used Web meme: "Why not both?"
In my opinion, why should a software tool only have one interface to it? What if there were many possible interfaces available, from very simple interfaces with reasonable defaults for casual users, to more option-rich interfaces for power users, to an API for programmers. What if we could take advantage of today's AI technology to automatically construct GUIs that are tailored to a user's experience level? What if users could customize the GUIs in order to make the GUI fit their needs better?
What if the system supported a variety of languages, not only common languages such as Python that many programmers are familiar with, but also beginner-friendly languages? Users are willing to program provided it's not too difficult: AppleScript from the 1990s was a step in the right direction, and Excel's macro language is probably the most widely-used programming language in the world. With today's AI/NLP technology, we could go further by developing ways for users to describe repetitive, routine tasks using natural language.
I think there's still a lot of room for innovation on the desktop. But you highlight a very big problem: where is the market? Who is going to pay for this innovation? Outside of open-source projects, the major commercial desktop environments are platforms controlled by multi-billion dollar corporations. Building a new desktop environment that is capable of competing against the commercial giants will take a lot of time and capital. The last company to give this a try was Be, Inc. in the mid-1990s, and they had a hard time competing against Microsoft's OEM strategy. I wrote more about this at http://mmcthrow-musings.blogspot.com/2020/10/where-did-perso....
I've been creating software professionally for over 20 years. The only tools from the start that are still in my toolbox are Unix (now Linux) and SQL. Java didn't even exist when I started, nor did Python or Ruby or JavaScript or even Apache. But my job feels basically the same. It always will, because the problems are always out there at the edge. They're incredibly specific, and often at the bleeding edge of what software can do.
Basically, software meets human needs. You need humans to come up with problems to solve, and describe them specifically enough that a computer can be programmed to repeat the solution. So those creative tasks, and the discipline of turning vague human ideas into strict logic, those aren't going anywhere, at least not with the tools we have today, or a reasonable extrapolation of those tools into the future. Programming languages may change, but the existence of programming languages does not. You still need humans to figure out how to say what they really mean.
On the other hand, I could spend days or weeks configuring a development server old-school, or I can run 'vagrant up' and have a perfect, repeatable development environment that works on any server. That's the robots. I love the robots.
The direction in which programming has developed over the past 70-some years is ever-increasing levels of abstraction.
40 years ago, good old C was considered a "high-level" programming language. Now it's about as "close to the metal" as 99% of software developers will ever have to get (outside of toy assemblers in school).
Now the highest levels of abstraction programmers work with on a daily basis are with scripting languages like Python that completely abstract away things like pointers and memory management, and that run on virtual machines and thus across completely unrelated operating systems or even CPU architectures. Many of these languages have rich ecosystems of packages that abstract away much of the tedious complexity of everything from making an HTTP request and parsing the response to reading and writing CSV files.
But even higher levels of abstraction are available to non-programmers - consider the marketing manager who strings together functionality from multiple richly functional SAAS programs to make a completely custom workflow in a point and click manner.
In another 100 years, the barrier to entry will be even lower; and more and more of the footguns will be hidden behind layers of abstraction; and complex functionality will be something that's pieced together from existing components.
There will of course still be room for defining custom logic. And someone will need to develop and maintain and update all those abstractions and the programming languages themselves.
But I imagine that to one of us, picking up the hot new programming language of 2118 would be a bit like how it would be for a 1965 Assembly programmer to pick up Python.
That assembly programmer would probably spend the first few days trying to figure out how to allocate memory or determine the contents of a register using Python and then realize how totally unnecessary that is and how much they can do in how little time if they stop worrying about being parsimonious with hardware resources.
We'd probably spend a few days wondering how to do something that seems unimaginable not to have to do - instantiate a class or catch exceptions or something. And then realize that those things are already taken care of and we can accomplish 100 times as much in a line of code as we used to be able to.
There's another point of view regarding this issue. Complex applications tend to evolve towards an 'inner platform'/'duck programming' state because serious power users want to avoid repetitive point/click operations. They demand a programmatic way to macro common tasks that they wish to apply to large amounts of data.
One might say at this point ok, the application should provide an API, and the power user should hire a part-time programmer to write a plugin. But that may not be feasible, and it misses the point that the user may not want to hire programmers and learn about API's.
The deeper question it seems to me is, is it always a sin to allow an end-user to have access to a Turing-complete, user-domain set of tools that are effectively a programming platform?
An answer of yes to this question smacks a bit of elitism: we are the priests of code; users must forever be relegated to pointy-clicky automatons.
The same tired argument has been made every decade since the 70s, with mostly the same cast of characters: artificial intelligence, English somehow being used to specify the behavior, stock libraries of code, etc. I think we're about as far from it today as we were when Prolog was a big deal.
The amount of incipient complexity in programming has been growing, not going down. What's more complex, "hello, world" to the console in Python, or "hello world" in a browser with the best and newest web stack? Mobility and microservices create lots of new edge cases and complexity—do non-programmers seem particularly well-equipped to handle edge cases to you?
The problem has never really been the syntax—if it were, non-programmers would have made great strides with Applescript and SQL, and we'd all be building PowerBuilder libraries for a living. The problem is that programming requires a mode of thinking which is difficult. Lots of people, even people who do it daily, who are trained to do it and exercise great care and use great tool tools, are not great at it. This is not a syntax problem or a lack of decent libraries problem. We have simple programming languages with huge bodies of libraries. What's hard is the actual programming.
I don't disagree with your arguments about how much more accessible programming is now. However I do disagree with your opening sentence:
> "Programming is so much more fun and awesome now."
Things are certainly easier, but a lot of the fun used to come from the reward of achieving something difficult. And the awesomeness would be discovering a new technique - or even simply a hack - that could optimise your routines in ways that you never previously thought possible.
That's not to say I don't still enjoy programming. But it's a very different experience: enjoyable and awesome in different ways. However on the whole, it now feels less like I'm performing magic and more like I'm building flat-pack furniture (or maybe a kit car if I'm building something a little more bare-metal and/or writing my own APIs).
I think you're spot on. Just as the personal computer and GUI brought "computing" to the masses for their use and massive scale return on investment, we need to see the equivalent innovation in programming components. In other words just as it's now easier than ever to edit movies, write a paper, polish a photo: we need to see this ease of interface brought to programming.
I know hard core CS types will say that making programming easy for the masses will mean it won't be fast, it won't allow for the optimal algorithms. However computing speed and bandwidth is rising exponentially and countless applications for software do not need to be as optimal as possible.
In the future people who are not programmers but who are one step removed (e.g. okay with spreadsheets, SQL, some basic scripting when needed, visual programming like Labview, and who understand software architecture) will need to be able to do more complex things with computers, things that today only programmers can do.
We need to see the separation between programmer and the technical creative masses disappear a bit. Or at least as tablatom says, there has to be room for two types: those who build the tools for easy programming and those who do easy programming.
I disagree. I'd say that attempts to let end users do their work without 'programming' have succeeded marvelously. We've handled the 50% case, and then the remaining 50%, and repeated this process several times.
When I was a kid, I had to type a valid line of source code to load and launch an application (often two separate lines). Today I can literally touch a picture of it with my finger to do the same thing.
There may always be tasks for which we need someone to write a process description in a Turing-complete language, but even as a programmer, almost all of the non-programming tasks I do today would have required programming 30 years ago.
Certainly there was some extrapolation on my part (though I do find it amusing that I got the two-fingered part right). I was using your posts mainly as a jumping off point for discussion seeing as they seemed to be in the spirit of the mentality I was referring to.
The fact is we are being constrained by the past. We still program in plain text files, using languages and environments that are as basic as possible presumably to maximize flexibility of development. I don't see the point. There are those that eschew the mouse, or GUIs because the terminal is cool (or something). The fact is that this field is moving towards more and more tooling, hopefully improved visualization, and soon to be automation (imagine APIs automatically wiring themselves up, or the gruntwork drudgery of programming happening automatically). This is the future we should all be looking forward to, not placing arbitrary constraints on the languages and environments we use for the purpose of compatibility with outdated tools. The more constraints we place on ourselves, the longer this future will take to become reality.
On the one hand, I agree with you. At some level the libraries and frameworks matter less and less. It becomes boring since you know what you want and the only question is to do it with the current tools.
In the other hand, I'm still fascinated by programming because it is the closest thing to magic we have: We utter some arcane phrases and a nearly unlimited set of things can happen. Most of Harry Potters magic is not impressive compared to our technology.
I have not found that in other activities yet.
It is still magic even if you know how it's done. -Terry Pratchett
My take on this is that programming may be niche now, but it shouldn't be. Simple scripting is useful and lets you easily perform tasks that would otherwise be repetitive.
I'm not saying everyone should be able to build a large application, but you shouldn't be stopped from building things on it, otherwise how will you even get started?
Computers that stop you from inspecting them and learning how they work build a moat between the users and developers of the system. That's the opposite of what I think we should be encouraging.
That would be interesting to discuss. As we can see we have many Programming Language now and more on the rise, all with a target of making scripting more human friendly and automating most of the functionalities to minimize dev time. I see more of this automation in the future where you can create complex application with just couple of clicks away (I believe we can see many of such now). What do you think?
Nah, these tools will empower programming. Almost no one writes assembly any more. We've got high-powered tools that already abstract away a ton of software engineering complexity so people can do what they want to do quickly and inexpensively. But I have a very hard time believing that "programming" — the act of writing out precise textual instructions in a file for a computer to read and execute — is going anywhere. It's a very elegant and powerful means of interacting with a machine. Similar to how the written word remains one of the most powerful mechanisms for interpersonal communication despite the massive and powerful media tools at our disposal.
Hey, some of us enjoy putting buttons on a page (UI/UX) ;).
However, I have to agree somewhat with the assertion that software is getting more specialized. When I started out, the advice I repeatedly got was not to worry about what programming language you knew, because every job you would work with would expect you to learn whatever their tech stack was.
These days, when I look for a programming language, it's not about the syntax sugar, it's more about the feature set that comes with the language: things like the module and build system (e.g. Java is pretty easy), the ease at which both complex and trivial tasks can be accomplished, and the availability of support community and libraries.
reply