But the drawing wasn't the source of stress, rather it was the project "specification" that he sweated. The issue was the spec was a legal, text-format document detailing the size of beams, type of wire, plumbing, fixtures, etc. He had to assure that beams were sufficient to support structure, electrical wiring was safe and up to code, etc. A mistake could expose the contractor and himself to legal liability if a component failed, so an accurate spec was a task he took seriously.
Of course the subject of program specifications is commonly discussed, though often doesn't have the same significance that my father experienced. I guess in most cases program crashes don't have the same impact that a roof caving in would entail. In situations where crashing can't be tolerated, the spec will mean a whole lot more.
Your info was relevant to the idea of that at some level of complexity it becomes necessary to use text vs. only graphic presentation. Maybe in construction that occurs when there are more than a few elevations to juggle, but you probably know much more about it than me.
It is not about how much more information can we convey, but how much less data must be expended to present a tractable model of reality to the human operator. Conveying more details is worse than useless, it results in informationi overload and cognitive stagnation.
Historically, the way it happened in computer programming is those tools are text based. This is as much about the early use of computers as clerical aids to process business data, and the early synergies between computation and linguistics. Maybe it can be done, but it will require millions of man hours to accomplish. And almost nobody wants to invest in doing so because of the cost of opportunity.
If, on the other hand, you cannot ever be 100% sure that fixing one stop light in Brooklyn will cause a bunch sewage lines to flush out to the street in Long Island, then zooming does more harm than good. At the end of day, you need the map to conform to the realities of the territory. If that gets in the way of that pretty abstraction of yours, then the abstraction - not reality - is wrong. And when that is the case, you need to start over and make a better map.
Text based toolchains are, for all their limitations, a (sufficiently) reality conformant map. It does not mean there cannot be others; but as of today I do not know about any suitable candidate.
Blueprints don't change as much as software does. It's not generally interesting to diff, fork, reformat, or patch a blueprint.
I thoroughly hated LabView when I had to program in it, but it did convince me that a graphical programming language could work -- if only it refrained from doing the cking stupid things that LabView did (such as the strongly typed editor* that would automatically progate the any type error it found, but not your fixes).
In my current C++ work, I would dealy love a graphical tool that showed me where any given value came from, much like LabView does by its very nature.
My understanding is linguistics research has pretty thoroughly debunked this idea.
Don't remember the experimental design (was a long time ago, sorry), but I believe a study showed Chinese readers basically translate the characters back into the sounds of spoken language in their heads, before any processing of meaning takes place. In other words, pictographic mnemonics may be helpful when first learning the characters, but play no role for a fluent reader.
I suspect a similar thing will be true with programming for a long time to come. Even if you try to replace keyboard characters with other icons, it will be just substituting one arbitrary association between symbols and meaning with another. (Which is basically what language boils down to, anyway.)
That's funny. I came away with the opposite opinion. Text is much better at describing details and it's much easier to be consumed by various things: people, editors, analysis tools, web apps, test engines, code generators, code transformation tools, ... I could go on.
Languages like LabView never have a complete toolchain (Prove me wrong by posting a small piece of editable LabView in a reply to this HN comment). They work well as domain specific languages, but that's about it.
Based on these two sentences, I'm confident that you don't know the first thing about Chinese characters or Egyptian hieroglyphics.
Programming languages exist today because computers can't handle ambiguity and don't understand software design. In another 50 years, machines will be a lot smarter, more able to handle ambiguity, and better than people at designing workflows and catching potential errors. Like the horse, no doubt some people will still prefer to do things the old way, but there's a good chance this will be limited mostly to academic exercises.
All they're saying here is that the tools we have will progress a lot in the next 50 years. There are some obvious problems with the way we design software right now which are due to human limitations. The only way to fix those is to remove a lot of direct control from humans and give it to AI programmers. Manually writing JavaScript in 2066 will be like manually carving arrowheads today: still effective but not something you would do for a serious purpose.
And that computing horsepower mostly goes towards fuel efficiency and safety. Which is nice, but almost certainly not the kind of progress people in the 1960's thought we'd make in automobiles over 50+ years.
> traditional pilots being essentially babysitters for autopilot systems
The first autopilot takeoff/cruise/landing happened in 1947.
> hyperloop designs
But we don't have hyperloops.
> I'd say those are much bigger changes than 1936-1986.
By 1986 we had fully-digital fly-by-wire aircraft. Our big achievement since then has been about a 20% improvement in fuel efficiency.
To bring your comparison closer to the subject at hand, this article has nothing to do with the design of computers themselves. We could use the same basic Von Neumann architecture in 50 years and still get rid of traditional programming languages as a primary method of designing software, just like we use the same basic engine designs from 50 years ago but use entirely different methods of designing and controlling them now.
Take an engineer designing a jet in 1966 and put them with a 2016 team. They will have to learn an entirely different workflow. Now computers are heavily involved in the design process and most of what was done manually by engineers is now written into software. The same situation will happen 50 years from now for people who design software.
Take an extreme example like game creation. In 1966, you could make a computer game, but you were doing manual calculations and using punch cards. Now you download Unity and almost everything but the art design and game logic is done for you. Game design moved quickly toward these kinds of automated systems because they tend to have highly reusable parts and rely mostly on art and story for what separates them from the competition. But there's no reason why this same concept wouldn't apply to tools used for any kind of program.
The horse to car comparison was only meant to show that the development of a technology in the first 50 years (or any arbitrary number) will not necessarily look like the next 50 years. Well-established tools quickly fall out of use when a disruptive technology has reached maturity, even if that tool has been used for thousands of years. Right now, software design is difficult, buggy, and causes constant failures and frustrations. Once we have established and recorded best practices that can be automated instead of manually remaking them every time, there will be no need for manual coding in traditional programming languages. Machines are getting much better at understanding intent, and this will be built into all software design.
Send them to the "PCs for seniors" course at the local library to learn the basics of clicking around on a computer. Then a one or two week training course on whatever software is used to design planes these days.
Getting up to date on modern "workflow" is not going to be a major hurdle for someone smart enough to design a jet. Heck, it's very likely there could be someone who started designed jets in 1966 and still designs them today. (Post retirement consultancy.)
Yes, Unity helps to visually organize your game's data, and there are built in and downloadable components (which are all created by coders) that can be used to plug into your game, but it's just another set of abstractions. Most of the time you will be writing your own components in a traditional coding language or delving into other's component code to adapt it to actually make your game function. There ARE game creation systems intended for no coding required, but they come with the expected limitations of visual coding that people are bringing up in this thread. No, Unity doesn't really fall into this category, barring a few limited game domains.
Perhaps in 50 years every domain will be "mapped" in this way, with predefined components that work with each other and can be tweaked as needed, but I don't see how that could eliminate coding, or even displace it that much. Two reasons I think coding is here to stay:
1) Any sufficiently complex system needs it's organization to be managed. At a certain complexity, whatever system is replacing coding will become something that looks a lot like coding. At that level of complexity, text is easier to manage than a visual metaphor. 2) Most pieces of software need custom components, even if only to stand out. Those game creation systems with no coding? No one is impressed by the games that are created in those systems. Not because the system cannot produce something worthwhile - but because with everything looking the same, the value of that output drops substantially.
I think coding will only go away when programming does. When the computer is as intelligent and creative as we are. And that's a point which I do not want think about too much.
This like the shift in transportation. A lot of people love driving and mistrust autonomous vehicles. But the tech is almost to the point where it's safer than human drivers. In most situations, it already is.
Another comparison would be SaaS. For a lot of companies, it's about risk mitigation. Moving responsibilities away from internal staff makes business sense in many cases.
This is a criticism of the idea that we need to make coding a basic life skill that everyone should focus on. It looks a lot like denial to some people.
Let's go back to transportation. Imagine if people were pushing the idea that commercial driving needs to be in every high school because driving was such a big employment area. Some people might say that the autonomous vehicles look like a big threat to job prospects, so maybe it's not such a good idea to focus on those particular skills.
Coding is great, provides a lot of opportunities to the people that it attracts, but it's a pretty specialized skill that's going to be increasingly displaced by more natural and automatic interfaces this century in all likelihood.
Cars now go 100,000 miles between tune-ups. They used to go, what? 10,000 miles?
Cars are much safer in collisions than they used to be.
Most cars now have air conditioners. I've driven in a car without AC in Arizona in July; believe me, AC can be a really big deal.
Most cars now have automatic transmissions, power steering, and power brakes.
And cars get much better fuel economy.
Driving from NYC to LA takes less time due to interstates and higher road speeds (and cars that can comfortably handle those speeds). Not half the time, but still a significant improvement.
And yet, most cars are not dramatically different as far as the experience of driving them is concerned. Nothing in the last 50 years looks revolutionary. It's been an accumulation of improvements, but there has been no game changer.
I suspect that the next 50 years in computing will be similar.
I'm curious what your definition of tune-up is, because I don't believe there exists a car that can go that far unmaintained without doing lasting damage to various systems.
After a quick Google, my impression is that most 2016 cars have a first maintenance schedule around 5k-6k miles. Some as low as 3,750.
For even lower maintenance look at electric cars. I think Tesla has very very low maintenance requirements for the first years.
It's not.
I have a couple of 60s Mustangs and several newer cars. My original '65 needs ignition service (what most people call a "tune up") every couple of years (of very modest usage). My '66, converted to electronic ignition, gets about twice as long (and 10x as many miles) before needing ignition service. They both end up fouling plugs because of the terrible mixture control and distribution inherent in their carbureted designs.
My wife's 2005 Honda CR-V gets about 100K to a set of plugs. (Fuel injection, closed loop mixture control, and electronic ignition are the key enhancements that enable this long a time between tune-ups.)
My diesel Mercedes and Nissan LEAF obviously never get tune ups.
You don't do valve adjustments on the Mercedes?
About the only thing I've done abnormal on the car in 7 years is replace two glow plugs. (And when the second one went, I actually replaced the 5 that hadn't been changed yet, since they are cheap and I didn't want to take the manifold off again to change #3...)
In 50 years, 99%+ of all the work ever done by civilization will be done after 2016.
Creating clear and accurate design documents is so much harder and more specialized a skill than programming that many places that do programming either avoid it entirely or make a pro-forma gesture (often after-the-fact) in its direction.
(I am only about half-kidding on the reasoning, and not at all about the effect.)
This is exactly what programmers do today. We just call the "design document" a "program".
Over time, our design documents become higher and higher level, with the programmer having to specify fewer details and leaving more of the work of sorting out the actual details to the computer.
http://shaffner.us/cs/papers/tarpit.pdf
There has already been some significant progress on this front. E.g., SQL and logic programming let you describe what you want to happen, and let the computer figure out some of the details. Any compiler worth using does this, too. Smarter machines and smarter programs will mean smarter programming languages.
> we know that we can create tools that translate designs into executable code that can be less error-prone and more reliable than people typing letters into a text editor.
I disagree. Maybe you know, but I haven't seen any indication of the sort.
Speaking as someone who has studied cuneiform and Akkadian, I would say that this claim isn't true. Here's a vowel that predates the period that you mentioned[0].
Where did you get this idea? Babylonian writing fully indicated the vowels. It always has. You're thinking of Egyptian / Hebrew / Arabic writing.
Even where a semitic language was written in cuneiform, vowels were always indicated, because the cuneiform system didn't offer you the option to leave them out. https://en.wikipedia.org/wiki/Akkadian_language#Vowels
(Old Persian was written in repurposed cuneiform, and therefore could have omitted the vowels, but didn't.)
Yeah and it took "us" 60 years from discovering flight to landing a rocket on the moon. Took "us" 60 years from the first computer to globally-live video streaming in your pocket. Time is a pointless metric when it comes to technology. You don't know what someone is cooking up down in some basement somewhere that will be released tomorrow and shatter your concept of reality.
Be really hard to identify, though.
This is particularly true, e.g., of How to Design Programs [0].
You can't beat written word. Corps are not lining up to rewrite their bylaws in a bunch of connected drag-and-droppable blocks. I really don't think it's just inertia, the preciseness, versatility,and ease of examination and editing, and permanence of written language is hard to beat. Same with source code.
1) road signs, which are predominantly graphic based
2) public information signs. Eg no smoking. Also usually picture based albeit does often contain text instruction as well
3) beach flags indicating where to swim etc.
All of these are enforcing by-laws yet none specifically text driven. In fact when conveying simple rules to people, it often makes more sense to explain that in meaningful images as that enables anyone to understand the message, even if one doesn't understand the written language (eg tourists).
However, the original specification, which in the case of the signs are laws and for software is code, is text, not in visuals. There in lies the difference. I think visual aids like dependency graphs will help us visualize code and communicate ideas like in the signs you mention, but due to the reasons I mentioned previously text will still be the preferred method for specification, or in software engineering, programming. For example, visuals only go so far. The best visual specifications I can think of are blueprints, which I'd argue still require a little of reading to understand. But in certain domains, as I said, text is a better medium.
I found a lot of ideas in this article to be pretty interesting: http://worrydream.com/#!/LearnableProgramming
I think something eventually will, though. My reasoning for this conclusion is simply that I don't believe a significantly larger percentage of people will learn to write production software than are able to do so now. At the same time the need for software in every sector continues to grow, leading to some varying levels of scarcity in programmers. That's a massive economic opportunity, and so people will continue to pound at that nut until it cracks.
But if we create an AI that can understand people well enough to know what those people want without clear instructions, yes, we will have placed us out of the job market, together with everybody else.
That's not true and even Sussman acknowledges this:
"The fundamental difference is that programming today is all about doing science on the parts you have to work with. That means looking at reams and reams of man pages and determining that POSIX does this thing, but Windows does this other thing, and patching together the disparate parts to make a usable whole.
Beyond that, the world is messier in general. There’s massive amounts of data floating around, and the kinds of problems that we’re trying to solve are much sloppier, and the solutions a lot less discrete than they used to be."
50 years ago, it might be conceivable to build auto scaling website that does something like pinterest within a decade, which now can be built in hours.
I'm not just talking about scaffolding and api usage either, so much has changed in coding in the last 15 or so years as well. think object oriented programming, interfaces, and GIT, and other new / useful practices.
the way we store our data is different as well. I believe it was the 70s, but during that time people needed convincing storing data in relational databases was a good thing.
today even that is changing
(And even just looking at languages, Fortran 2008 is hardly recognizable as compared to FORTRAN IV)
You could have automations around that though. A lot of manual work could be replaced with little AI bots that do the work. And since this work is not really "creative", it could be done through AI.
Yes, in that the tools are massively better. So is the hardware that it all runs on.
No, in that you still have to tell the computer precisely and unambiguously exactly what you want it to do, and how, mostly in text. The level of detail required today is somewhat less, due to better tools, but at a high level the work hasn't changed.
1) There's a massive reliance on reusable libraries these days. Don't get me wrong, this is a good thing, but it means people spend less time rewriting the "boring" stuff (for want a lazy description) and more time wring their program logic.
2) Most people are coding in languages and/or language features that are several abstractions higher than they were 50 years ago. Even putting aside web development - which is probably one of the widest used frameworks these days - modern languages and even modern standards of old languages have templates, complex object systems, and all sorts of other advanced features that a compiler needs to convert into a runtime stack. Comparatively very few people write code that directly maps as closely to hardware as they did 50 years ago.
3) And expanding on my former point, a great many languages these days compile to their own runtime environment (as per the de facto standard language compiler): Java, Javascript, Python, Scala, Perl, PHP, Ruby, etc. You just couldn't do that on old hardware.
4) Multi-threaded / concurrency programming is also a big area people write code in that didn't exist 50 years ago. Whether that's writing POSIX threads in C, using runtime concurrency in languages like Go (goprocesses) which don't map directly to OS threads, or even clustering across multiple servers using whatever libraries you prefer for distributed processing, none of this was available in the 60s when servers were a monolithic commodity and CPUs were single core. Hence why time sharing on servers was expensive and why many programmers used write their code out by hand before giving it to operators to punch once computing times was allocated.
So while you're right that we still write statements instructing the computer, that's essentially the minimum you'd expect to do. Even in Star Trek with the voice operated computers, it's users are commanding the computer with a series of statements. One could argue that is a highly intuitive REPL environment which mostly fits your "you still have to tell the computer precisely and unambiguously exactly what you want it to do..." statement yet is worlds apart from the they we program today.
Expanding on your above quote, "mostly in text": even that is such a broad generalisation that it overlooks quite a few interesting edge cases that didn't exist 50 years ago:
1) web development with GUI based tools (I some people will argue that web development isn't "proper" programming, but it is one of the biggest areas in which people write computer code these days. So it can't really be ignored. And there are a lot of GUI tools that write a lot of that code for the developer / designer. Granted hand crafted code is almost always better, but fact remains they still exist.
2) GUI mock ups with application-orientated IDEs. I'm talking about Visual Basic, QtCreator, Android Studio, etc where you can mock up the design of the UI in the IDE using drawing tools rather than writing creating the UI objects manually in code.
3) GUI based programming languages (eg Scratch). Granted these are usually aimed as teaching languages, but they're still an interesting alternative to the "in text" style programming languages. There's also an esoteric language which you program with coloured pixels.
So your generalisation is accurate, but perhaps not fair given the number of exceptions
Lastly: "The level of detail required today is somewhat less, due to better tools, but at a high level the work hasn't changed.":
The problem with taking things to that high level is it then becomes comparable with any instruction-based field. For example, cook books have a list of required includes at the start of the "program", and then a procedural stack of instructions afterwards. Putting aside joke esoteric languages like "Chef", you wouldn't class cooking instructions as a programming language yet it precisely fits the high level description you gave.
I think as programming is a science, it pays to look at things a little more in-depth when comparing how things have changed rather than saying "to a lay-person the raw text dump of an non-compiled program looks broadly the same as it did 50 years ago". While it's true that things haven't changed significantly from a high level overview, things have moved on massively in every specific way.
Lastly, many will point out that languages like C and even Assembly (if you excuse the looser definition) are still used today, which is true. But equally punch cards et al was still in widespread use 50 years ago. So if we're going to compare the most "traditional" edge case of modern development now, then at least compare it to the oldest traditional edge case of development 50 years ago to keep the comparison far rather than comparing the newest of the old with the oldest of the new. And once you start comparing ANSI C to punch-inputted machine code, the differences between then and now become even more pronounced :P
Dear writer, let me introduce you to FORTRAN, COBOL, LISP, or BASIC. These are alive languages, all 50+ years old.
Coding didn't change much. The languages, the methodologies, the ideas change, but the approach is the same, and whoever thinks this will soon (50 years is not _that_ far) changes, have never had to debug something nasty. Doing that with voice commands in my opinion is significantly harder compared to what we have now.
We will have tools, accessible, easy tools; Arduinos and Pis of the future; sure. But it will not replace, nor eliminate or reduce the amount of code written.