14 ms·

“50 years from now, I can’t imagine people programming as we do today. It just can’t be." Dear writer, let me introduce you to FORTRAN, COBOL, LISP, or BASIC.

• xxs 10y ago
  you missed assembler; it's still a thing
  • deleted 10y ago
    [deleted]
  • pmlnr 10y ago
    I did miss that, true; however, Assembly is heavily architecture-tied. Therefore x86 Assembly significantly differs from, for example, ARM assembly, but nonetheless I should have mentioned it.
    • slededit 10y ago
      Its annoyingly incompatible and RISC is more verbose but really the concepts are pretty much the same. Load something to a register, do some very basic operations on said registers and save it out. An X86 programmer should be able to pick up other CPUs fairly easily. Although delay slots will probably piss them off every time.
• fossuser 10y ago
  I agree, though I think there are improvements that could make things better even for existing languages. It just doesn't seem to be a main focus of our industry. I found a lot of ideas in this article to be pretty interesting: http://worrydream.com/#!/LearnableProgramming http://worrydream.com/#!/LearnableProgramming
• greenimpala 10y ago
  Agree completely!
• GFK_of_xmaspast 10y ago
  The actual practice of writing programs is, a few outliers aside, incredibly different in 2016 as compared to 1966. (And even just looking at languages, Fortran 2008 is hardly recognizable as compared to FORTRAN IV)
• Iv 10y ago
  50 years from now, I can't imagine people driving cars as we do today. I do know that human-operated cars are old, but it does not mean that we can't do better nowadays.
  • cglee 10y ago
    drivers:users::mechanics:programmers
    • pessimizer 10y ago
      And designing cars hasn't become easier, it's become exponentially harder as we demand more from them.
• ksk 10y ago
  >Doing that with voice commands in my opinion is significantly harder compared to what we have now. 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.
• markbnj 10y ago
  >> 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. 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.
  • AnimalMuppet 10y ago
    Not all nuts are crackable. I agree, though, that people will continue to pound. Even if it doesn't crack, we may find a way for many people to get things done without learning to write "production" code.
  • marcosdumay 10y ago
    We will keep making developers more and more productive. And if there aren't enough of us to solve all the problems, well tough luck - let them unsolved, every profession is like that. 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.
• nickbauman 10y ago
  There's a serious gap in the writer's mind about computation and programming. It's like the author is suggesting that "eventually we won't need writing: it will be replace by writing-thinking or picture-writing". It's completely absurd. Specific, complex ideas can only be described and communicated in text. Not pictures. Blueprints, for example, have a pictorial element to them, but their fundamental value is our ability to use the formal language to analyze what's on the plan and whether it is correct or not. To the degree that a picture or a motion graphic can formally accomplish this is to the degree that it is supported by a specific language under the covers. Not the other way around.
  • imgabe 10y ago
    Blueprints/schematics are far, far superior at conveying the information they do compared to a written narrative. Given the ease of preparing written text compared to drawing schematics nobody would go to the trouble of doing so if that weren't the case.
    • d0mine 10y ago
      Graphics can be useful in some domains but nothing beats text in the general case.
    • pessimizer 10y ago
      Of course, all of the pieces of information that blueprints and schematics are conveying are 2D layouts. Once you're out of the realm of things whose forms can be reproduced at reduced scale, or simplified to functional equivalents that lie on a plane, the types of useful visual representations of things are sharply reduced; they become extremely stylized, and symbolic. At that point, you've basically arrived at language again.
    • humanrebar 10y ago
      > Blueprints/schematics are far, far superior at conveying the information they do compared to a written narrative. Blueprints don't change as much as software does. It's not generally interesting to diff, fork, reformat, or patch a blueprint.
• laumars 10y ago
  Aside specialty industries, the way the average programmer codes in a very different way to what it would have been like 50 years ago.
  • AnimalMuppet 10y ago
    Yes and no. 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.
    • laumars 10y ago
      That has changed significantly too though. Sorry about this being a long post, but having programmed through most of the last 50 years, I've seen a massive shift in the way people code even from a language perspective: 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
• ewzimm 10y ago
  You can't necessarily judge the future of of a technology by its past. Consider transportation. Imagine it's 1936, automobiles have been around for 50 years, but there are still plenty of people getting around by horse. Some people are claiming that in another 50 years, by 1986, horses will be hardly used for transportation compared to cars, other people say that horses have been used for thousands of years, there's no way they'll ever go out of style. 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.
  • nickbauman 10y ago
    There are currently no signs that what you think will happen will happen. Soft AI is the only place where anything is moving on that front and the movement is infinitesimally small. Here's an analogy for you: It took more than 1000 years (from Babylon to Archaic Greece) for us to go from writing with only consonants to using vowels for the first time.
    • ewzimm 10y ago
      Years don't make progress on their own, people working during those years push progress forward. The estimated population of ancient Babylon at its height was 200,000. Let's imagine that 1% of them were working on developing writing for at leat 2 hours every week and that those who came after them were able to maintain that level of work for 1000 years until ancient Greece, over 200 million hours of work. That's less time than the official Gangnam Style video has been watched on YouTube. In 50 years, 99%+ of all the work ever done by civilization will be done after 2016.
• beachstartup 10y ago
  for some perspective... 50 years is just twice the length of time since i've been coding (in some capacity)... and i'm only in my early 30's.
• noobermin 10y ago
  I've said this before, the reason code and CLI and texting and messaging all these text based modes of communicating and controlling computers are still popular is that they mirror one of the most intuitive and fundamental inventions humans have ever created: language, specifically, written language. Even speech doesn't rival written word in some contexts; for example, laws and organization rules, policies, are still written. 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.
  • laumars 10y ago
    I appreciate the context of your argument when you discuss the use of text in by-laws, but it's worth noting that there are lots of examples of by-laws being enforced via non-text mediums: 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).
    • noobermin 10y ago
      Right, note that in communication referring to written laws, people tend to use visual aids. This is also similar to how people try to visualize source code, like dependency graphs, inheritance graphs and such. In one case, we are reminding one about ideas using visuals and the other, we are helping comprehension of it. 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.
• Jtsummers 10y ago
  It should be noted that that quote is not from the author, but from someone that the author is quoting.
• autokad 10y ago
  I dont agree with that sentiment. 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
• bsder 10y ago
  > Coding didn't change much. 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."