
When Will the Last Line of Code Be Written? - josh_carterPDX
http://blog.brightwork.io/when-will-the-last-ever-line-of-code-be-written/
======
RyanCavanaugh
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?

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

~~~
collyw
It moving from imperative to declarative programming essentially.

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

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

~~~
gaius
But not an engineer?

~~~
duvander
I have a computer science degree and I love to write code. My title does not
have "engineer" in it. Feel free to hold that against me :)

------
jcadam
The 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)."

------
warmwaffles
Never. People like to build things. Just like asking, when will the last
muzzle loader be made? Simple answer, never. People love hobbies.

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

~~~
dota_fanatic
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. :)

~~~
stevenwiles
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. :)

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

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

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

That's my guess anyway.

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

~~~
Jtsummers
Using 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)

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

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

~~~
gwbas1c
I've found that the bigger problems are:

\- Confusing design patterns with frameworks

\- Using frameworks incorrectly

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

------
rajington
FizzBuzz on a whiteboard for an interview at the top AI firm: Gopplezonsoft in
2048

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

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

------
heurist
When will the last painting be painted?

------
gliderShip
Reminds me of [Why I Hate Frameworks]
[http://discuss.joelonsoftware.com/?joel.3.219431.12](http://discuss.joelonsoftware.com/?joel.3.219431.12)

------
forty
I 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-...](http://www.commitstrip.com/en/2015/11/13/the-last-ever-line-of-
code/)

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

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

------
kapv89
I'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-207d3...](https://medium.com/@kapv89/code-will-always-be-
written-207d3cdfe145#.6snta46s8) \- Code will always be Written

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

------
peter-m80
tl;dr "Will the last line of code ever be written? Probably not"

~~~
jsprogrammer
Did the article rule out a "doomsday line"?

------
jcwayne
About 5 minutes before attempting to open the first trans-multiverse wormhole.

------
simbalion
probably around the same time as the last stupid blog post.

maybe shortly after.. :)

