When Will the Last Line of Code Be Written?

Thanks for this insight! I love this idea of code growing up to become data.

At 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.

> 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).

There's a cautionary aspect to this in that simply adding parameters and making configuration data(e.g. much of the Java XML ecosystem) is not enough to squash out "coding". It takes some carefully thought abstraction to make a difference. In some places we've made progress, in others we've churned through tech without going forward.

insightful. this question has been asked (at least) since i've been a professional programmer, which is 20+ years.

start of my career, >80% of my code was directed to memory management--allocating it, re-pointing it it, and de-referencing it under what seem now like impossibly tight optimization boundaries. I still work in compiled languages, but that fraction is now about 5%. Compiler & os optimization, hardware, etc. are the obvious reasons. Plenty of other challenges--some new some old, some completely contrived quickly occupied that attention vacuum.

>> What tasks that we accomplish with code today will be accomplished with data tomorrow?

Ahem. There is no separation between data and operation. It's what you learn if you play around with Lisp or Prolog, or any kind of language that doesn't start with "here's some variables, here's some functions that operate on them".

You should probably look up Adam DuVander. He's a well respected Developer Evangelist who helped Sendgrid grow their community.

Hey, author here. You're right, this post is about the big picture, the larger trend.

After 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.

This 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.

This. 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.

That kind of reminds me of the computer in The Moon is a Harsh Mistress

I 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.

Agreed! 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.

Your 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.

The 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...

This works for small projects that only you touch. However, if you are building a product for a company and plan on having teams make changes to the code base, frameworks are the way to go.

It's even easier when hiring because a big portion of your training is already done before the person is hired and they are knowledgeable in said framework.

Frameworks are anti-modular because they expect to be the world into which you plug your program. They’re prefab software architecture, which is great if it happens to be suited to your application, but painful if you later discover you have different needs.

To me, the defining feature of a framework (as opposed to an ordinary library) is that it’s explicitly not compositional, not replaceable, and not a “good citizen” for interoperation. Doesn’t sound great.

But there is a valid reason to incur these costs: prefab solutions let you ship something basically good now. The same thing happens in game development: do you just write a game, reinventing a lot of architecture now, or do you choose an engine, working around its limitations later? It’s more of a business decision than a technical one.

> 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?

If 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).

> 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.

Did the article rule out a "doomsday line"?