7 ms·
When Will the Last Line of Code Be Written?
- warmwaffles 10y agoNever. People like to build things. Just like asking, when will the last muzzle loader be made? Simple answer, never. People love hobbies.
- yetihehe 10y agoAfter your "never" I wanted to write "When we don't code in lines anymore", but yeah, "last line of code" is a strange thing to achieve. Even now some people make flint tools and it's a growing hobby.
- zdw 10y agoThis is exactly right - between "Not Invented Here" and the pride of making something work in a new and custom way, there's always going to be people writing code. Ikea's existence didn't wipe out woodworking.
- stevenwiles 10y agoThis. It's exactly like self-driving cars. I hope it NEVER becomes illegal to drive on public roads, even when there are self-driving cars. No one can ever take the freedom of driving away from me. I love driving and I will never stop doing it. Just like coding.
- dota_fanatic 10y agoBut you're not free to code on publicly available software (the production instance) just because you want to. I'm guessing driving on public roads will become illegal for safety and efficiency reasons once automated driving takes over. I bet you'll be able to go to a closed course and drive there though, for a cost. :)
- stevenwiles 10y agoI'm not sure why you are in favor of the government taking away our basic freedoms, but I do not agree with you, sir. If you want to live in a fascist country, you are more than welcome to move to one. :)
- lfowles 10y agoWell, you can't trot your horse down the highway. Not a far stretch to say "manual operation" cars are restricted to a subset of roads.
- Thimothy 10y agoAs self-driving highways, with cars that move at 250 km/h (155 mph), become common, regular driving will probably be restricted to secondary roads first, tertiary later. As time goes by, you will be seen as a nuisance from most of the drivers, as your car will be restricted to driving 60 km/h (37 mph) less than the rest in the same kind of road. So by the time a law passes that forbids non-autonomous driving, it won't be a "fascist government" but your own countrymen who will take your "basic freedom" away. But don't worry, I was using the "you" figuratively, by the time this happens, I don't think any of us will be alive. And, of course, there is always the off-chance that someone codifies in the constitution the right to drive a car, assuring that future generations have the freedom to kill themselves in the roads as we proudly do today.
- gwbas1c 10y agoI don't think that will ever happen. We'll all be traveling via self-driving drones instead! The roads will just be for hobbyists who like to drive their own cars (and write their own code,) and probably transportation of heavy materials.
- paulddraper 10y agoThe Autobahn does fine with very varied speeds.
- warmwaffles 10y ago
- thallukrish 10y agoUnless there is a compelling reason I never felt comfortable using frameworks. They tend to make a small problem much bigger. You end up spending time understanding, fixing and adjusting to the framework than making that little adjustment to your code to extend the functionality or relook at your needs.
- duvander 10y agoAgreed! Frameworks, libraries, and APIs are all about tradeoffs. Because they will never make sense for some programmers and use cases, the last line of code will probably never be written... but there's an undeniable trend heading that direction for so many. Thanks for reading.
- pascalxus 10y agoYour totally right about this, in most occasions. People look for short-cuts and fall in love with novelty shiny magic that appears nice on the surface. but, they don't evaluate the long term costs - that's what kills productivity in the long term: the cost of not understanding what a framework does in certain situations, or how to debug it when it's not working right. with code, you can always step into it and figure out what's going on, not necessarily the case with frameworks.
- macNchz 10y agoThe counterexample to the this line of reasoning comes in the form of nightmarish home-grown frameworks that have emerged slowly from years of piecemeal additions to that original small problem. These accidental frameworks often wind up replicating many features of prefab frameworks, without any of the tests, documentation or architectural forethought that would have come with a pre built one. I don't always see the need for a framework, but once you've gone through the process of learning the ins and outs of one, which does indeed take extra time the first time around, it's a familiar tool and can really speed things up when you re-use it in the future. Now if you try out a new framework on every new project, that's a different story...
- gwbas1c 10y ago
- tlextrait 10y agoIt's not because we achieve more with less code that we write less code. Instead we want more. Doing speech recognition would have been unthinkable with punch cards... plenty of things are still unthinkable today, but maybe not tomorrow.
- marcosdumay 10y ago> It's not because we achieve more with less code that we write less code. Instead we want more. It's inevitable that this changes some day. Probably a very distant day, but we must get to the point when we solved nearly half of all the problems that we can solve with software.
- gliderShip 10y agoReminds me of [Why I Hate Frameworks] http://discuss.joelonsoftware.com/?joel.3.219431.12 http://discuss.joelonsoftware.com/?joel.3.219431.12
- simbalion 10y agoprobably around the same time as the last stupid blog post. maybe shortly after.. :)
- deleted 10y ago[deleted]
- heurist 10y agoWhen will the last painting be painted?
- rajington 10y agoFizzBuzz on a whiteboard for an interview at the top AI firm: Gopplezonsoft in 2048
- peter-m80 10y agotl;dr "Will the last line of code ever be written? Probably not"
- jsprogrammer 10y agoDid the article rule out a "doomsday line"?
- moftz 10y agoI don't believe the author even writes code, he is just a liaison between the developers and management. He's only seeing the big picture, none of the actual work involved with creating low level libraries, drivers, etc. You can't really just point and click something like snapchat or facebook into existence.
- josh_carterPDX 10y agoYou should probably look up Adam DuVander. He's a well respected Developer Evangelist who helped Sendgrid grow their community.
- duvander 10y agoHey, author here. You're right, this post is about the big picture, the larger trend.
- jcadam 10y agoThe topic of this post reminds me of the state of 'programming' in the distant future described in the novel "A Deepness in the Sky" (https://en.wikipedia.org/wiki/A_Deepness_in_the_Sky https://en.wikipedia.org/wiki/A_Deepness_in_the_Sky): From the article: > "The Qeng Ho's computer and timekeeping systems feature the advent of "programmer archaeologists": the Qeng Ho are packrats of computer programs and systems, retaining them over millennia, even as far back to the era of Unix programs (as implied by one passage mentioning that the fundamental time-keeping system is the Unix epoch)."
- RyanCavanaugh 10y agoAs systems evolve into higher levels of abstraction, things that we used to consider to be "code" become "data" instead. For example, in 1950, you would write a lot of code to accomplish what you can do today with a pivot table in Excel (which we don't consider to be "coding"). Page layout you'd write as code in 1996 is now "data" encoded in CSS. At the same time, things that used to be major code concerns have been abstracted into the underlying systems. Garbage collection, privilege separation, caching, and so on continue to move lower in the stack. The trend toward programming languages that more natively support asynchronicity is another great example. The better question to ask is: What tasks that we accomplish with code today will be accomplished with data tomorrow?
- duvander 10y agoThanks for this insight! I love this idea of code growing up to become data.
- bbctol 10y agoAt the same time, we'll (hopefully) keep pushing the boundaries of code further. Developing CSS and spreadsheet tools just made the code that we do have to write line-by-line more interesting and powerful. We'll never stop writing code, because there will always be people pushing the boundaries of abstraction, but one day, we might look back on today's programs as a mere step above machine code.
- Florin_Andrei 10y ago> What tasks that we accomplish with code today will be accomplished with data tomorrow? "Eventually" all of it? (mind the quotes) If you save the config of a neural network, the "meat" of the NN so to speak, it's all "data" (matrices), but OTOH it's "code" (it tells the NN what to do).
- mattkrause 10y agoHow about things like video games? Frameworks/libraries/engines will certainly abstract away more and more of the nitty-gritty details, but the framework can't write the gameplay parts for you: those are essentially creative decisions. I'd argue that writing anything like (State, Action) -> NewState transitions is, in fact, coding, even if it's done in a way that's much more declarative than we're used to.
- pg_is_a_butt 10y agowhen a self fuzzing worm locates an injection vulnerability into the nuclear launch execution systems
- forty 10y agoI have not read the article yet but the title reminds me of this http://www.commitstrip.com/en/2015/11/13/the-last-ever-line-of-code/ http://www.commitstrip.com/en/2015/11/13/the-last-ever-line-...
- jcwayne 10y agoAbout 5 minutes before attempting to open the first trans-multiverse wormhole.
- js8 10y agoMaybe in the far future, all the computer code will become encoded in lambda calculus, and immediately matched and refactored against huge database of existing lambda abstractions. So the code will not be written anymore, it will only be rediscovered as a combination of already existing abstractions.
- marcosdumay 10y ago> all the computer code will become encoded in lambda calculus, and immediately matched and refactored against huge database of existing lambda abstractions You mean a Lisp optimizing compiler?
- smaddox 10y agoIf you posit the conceptual existence of such a database, then all we really do when we code, even today, is choose a particular set of abstractions to implement a specification. It would be certainly be nice if existing languages/analyzers were capable of suggesting "better" abstractions, though, for whatever operational definition of "better" applies at the time (e.g. more compact or common or efficient).
- westoncb 10y agoThe fundamental thing we're doing when writing code is specifying computations. The difficulty of it comes from the fact that when we conceive of some computation we'd like executed, we do so with human brains, whereas the thing that's going to execute the computation is a totally different kind of thing: they each have something like their own 'internal format' for representing program concepts. Our strategy has been to write stacks of translators to bring the machine's internal format nearer to our own. The last line of code will be written when we develop translators for languages near enough to our own internal representations that we no longer require special training to learn the machine's representation. It won't make sense to call it 'code' anymore. This kindred language/representation may be natural language (and maybe not), but if it were I'd imagine there'd have to be a tight feedback loop in the machine's attempts to sort out ambiguities in a developer's specification. So, programming would turn into a conversation with a computer: you ask for something, it proposes a solution ("Thanks John! How's this?"—it'll probably be like that. Ugh.), you express your modifications, it proposes another solution etc. That's my guess anyway.
- foota 10y agoThat kind of reminds me of the computer in The Moon is a Harsh Mistress
- Jtsummers 10y agoUsing loglan[0] as the primary language of interaction. Addressing the issue (in theory) of ambiguity in other human-oriented languages. [0] https://en.wikipedia.org/wiki/Loglan https://en.wikipedia.org/wiki/Loglan
- emilecantin 10y agoI think of it at a higher level: My job is not writing code, it's clarifying ideas. Even though my boss / client talks to me in their natural language, I still need to have a conversation with them to clarify what they mean, what do we do in such and such corner case, etc. Also, people usually don't know what they want until they see it, which gave rise to the whole field of Agile development. I don't think that higher and higher levels of translations between human language and machine language will free us from clarifying our ideas.
- stevofolife 10y agoWho cares... Not trying to be harsh here but seriously why is this on HN? Moreover the article is too brief to discuss meaningfully a nodus like this.
- kapv89 10y agoI'd like to share something I wrote in response of seeing too many posts like this: https://medium.com/@kapv89/code-will-always-be-written-207d3cdfe145#.6snta46s8 https://medium.com/@kapv89/code-will-always-be-written-207d3... - Code will always be Written