As 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?
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.
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.
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?
"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).
How 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.
I think it's definitely "programming", though I'm willing to agree that "coding" seems to imply more typing text in some 80-column format and less clicking. People certainly call doing-stuff-with-LabView "LabView Programming" and it involves a similar interface.
Two other thoughts
a) Do you think tools like this will ever actually replace all coding? My experience with graphical programming has been that it's great for simple things, but you often reach a point where it'd be way easier to write it as code, particularly if you're doing something the designers haven't anticipated.
b) I was actually interested in the contrast between ANNs, where the functional part is learnt from data--in part because we have no idea how to actually write a decent object recognizer from scratch--and something like a video game where you're necessarily designing/programming/coding up a creative idea that you have.
>> 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".
I 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.
> "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)."
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.
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.
But 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. :)
I'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. :)
As 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.
You are disregarding the moral problem of the needs of many outweighing the few. Given two options, kill 1 a child or kill 2 adults which do you choose? Either way, someone dies. Who is responsible for the potential man slaughter?
In a short phrase, someone has to go to jail / get in to trouble.
The 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.
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.
Unless 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.
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...
I think the crux of the original point is: Don't use a framework when you need a library.
For example, I ripped NHibernate out of a project because the SQLite database only had 6 tables. (Later reduced to 3 tables.) In this case:
- The original author used NHibernate incorrectly, making the product 10,000x slower then it should be
- There's a high learning curve to NHibernate that all newcomers to the project must go through
- There's a risk of having to work around an NHibernate bug
- We have to ship NHibernate and adapt to new versions or potential security holes
- The lawyers have to approve of the NHibernate license
- A small, infrequently updated xml file using built-in serializers is much easier to work with then SQLite + NHibernate.
Sure, we probably have about 1000 lines of DAL code instead of 200 lines of hbm files; but it's DAL code that's bug-free and has no external dependency risk.
Would I use NHibernate, or a different DAL framework, in a different context? Sure! If we had many more tables, and changed our schema frequently, it would be the correct thing to use. It's all about understanding when to use a framework versus a library.
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.
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.
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.
- Using a framework when a library is more appropriate
For example, Dependency Injection should start as a design pattern, and then a framework brought in based on the project's requirements. A couple of screens of "new" statements have very little learning overhead. No framework can define the way an application's modules relate with each other.
That a person is familiar with a framework doesn't guarantee they'll require significantly less learning for a company's particular project. In fact I'd argue that if one's use of a framework makes the learning curve so small, the project is probably not that complicated in the first place.
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.
Maybe 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.
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).
> all the computer code will become encoded in lambda calculus, and immediately matched and refactored against huge database of existing lambda abstractions
It'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.
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?