
Ask HN: What will coding be like in 25 years? - throwaway7645
What do you imagine programming to be like in 25 years?
======
MichaelBurge
It will probably be much the same as it is today. Styles will go in-and-out of
fashion(today: OOP is not cool; FP is hip), but in 25 years I for one will
probably be typing ASCII characters into a text editor, debugging with logs &
debuggers & print statements, and using a command line.

~~~
spcelzrd
25 years ago it was much the same as it is today. In 1992 people were typing
ASCII characters into a text editor and debugging with logs and print
statements.

You can do so much more with a line of code now and there are so many more
ways to make user interfaces, but the fundamental actions of the programmer
are the same.

~~~
flukus
Fundamentally it's just a good level abstraction. Much like we still use
writing for most communication even though we have audio and video options.

------
borplk
I hope that we stop sharing an ASCII language with the compilers.

It is the root of many of our difficulties in programming.

If we create very good "program editor" (not text editors) and store our
programs as a data object in a database a lot of our current "problems"
automatically vanish.

Every node of the program will have a unique identifier so the editor can keep
track of it across the lifetime of a project.

We will get automatic version control. Syntax war will end because you will be
able to customize the syntax exactly how you like.

The editor can track the association between tests and documentation with the
objects in the program.

And so much more. At the moment we share an ASCII language with the compiler.
This creates a fundamental tension between the human and the computer.

On one hand we want to specify lots of things about our programs to make it
more maintainable and reliable on the other hand we want to keep things easy
on the eyes and parseable.

So we create a strong dis-incentive to providing information about the code to
the compiler.

Because all we have is a single layer of text which will quickly become
polluted.

We need our programs to be able to have lots of meta-data but have an editor
that is capable enough to allow us to view what matters at a given time.

This can only be achieved if we stop thinking about programs as lines of text,
but rather as data objects.

This is known as "Intentional Programming" if you are interested search for it
on Youtube.

Also see Isomorf.io for a basic demo
([https://www.youtube.com/watch?v=awDVuZQQWqQ](https://www.youtube.com/watch?v=awDVuZQQWqQ))
(I'm not affiliated with them).

~~~
nilson
What would take to use for example image editor like mspaint to write programs
instead of text editor? We would still need to write text for interfaces with
users i guess

~~~
borplk
I'm not sure I fully understand your question.

Of course text would still be highly involved in the process. But the unit of
a program will not be lines in files stored on a file-system.

The program will be a data structure and what the editor presents to you is
just a editable projection of that structure.

And that doesn't mean some clunky tree editor GUI with drag and drop either. A
sufficiently capable editor could present itself to you almost like a text
editor but under the hood it would be operating on rich data objects that form
the program not on lines of text.

This opens up a lot of opportunities, for example in project navigation. You
could label an entire section of the program as something (example: "Create
user") then the editor could give you nice fold/unfold features you could
incrementally dig down and navigate the program that way.

You could tag objects in the program with stuff (example: tag a set of
functions with the business topic that they deal with).

Because the editor accurately tracks meta-data related to program objects, for
example it could be always aware of documentation related to a particular
section or function in the program.

So that editor could give you a shortcut to instantly switch to a
"documentation view" or "test case view".

I know some of this stuff is already sort-of possible with smart IDEs but they
are still quite fragile and inaccurate and easily tricked as they rely on
fragile tricks and heuristics to associate things with each other or they rely
on conventions that pile up on top of each other and conflict with each other
(file naming conventions to indicate something is a test case, etc...).

Treating programs as data objects gives us a strong foundation upon which we
can make these fancy features with ease and high accuracy so that you can let
your guards down and trust the editor to always be correct.

~~~
greenyouse
If you were going to take a new try at building a system like this, do you
think something like Datomic's codeq[1] would be useful? It allows for
navigating code semantics across multiple projects using a database query
language as the interface. I've never actually used it but maybe it could help
for data storage of an intentional programming system?

Thanks for the links, this was the first time I've heard of intentional
programming. Neat idea!

[1] [https://github.com/Datomic/codeq](https://github.com/Datomic/codeq)

~~~
borplk
Hmm I don't know enough about Datomic/codeq.

Data storage for a demo of something like that is not really hard. Something
as simple as a json object would work fine.

One hard part is to make it tolerant of incomplete/invalid objects.

If it's sufficiently tolerant you could make it look very similar to a normal
text editor but it would have magical powers under the hood.

You could do all sorts of cool text-editor-like features but because you have
a much richer object under the hood you could be much more magical.

The concept of "file" stops having any significance. You'd think in terms of
your domain logic and program objects.

So your sidebar project tree could be organised arbitrarily (not dictated by
the file system).

You could do fancy keyboard shortcuts. Imagine with key up/down you navigate
around a list of objects that are highlighted (like functions). While the
function is selected you'd press "d" and bam out pops the function
documentation (because documentation would be an attribute of that function
and tightly attached to it).

You'd type "h" and see the entire history of that function from day 1, who
created it who worked on it, etc...

"r" and it asks you for a new name (name could be a phrase like "login the
user into the system" because no text-parsing).

When you enter an entry is added to the history of that object (it has a
unique id) "[timestamp] greenyouse renamed this function to 'login the user
into the system'".

Then imagine the possibilities for CI/CD.

You could have constraint-based deployment and integration.

For example if any objects in the program tagged with 'security' have been
created/modified/deleted you could require stronger code review sign-off
etc...

You could "query" the diff of a software revision and do stuff based on that.
For example all your "SQL query" nodes would have a pre-determined type.

So when a new revision is pushed you could tell if new SQL queries have been
introduced in the system you could notify the database team "Revision #458 has
introduced the following 3 SQL queries (click to view)".

------
tabulatouch
Mainly AI writing code under our guidance, detecting patterns, applying
patterns, suggesting best practices, digesting decades of Stackoverflow to
solve problems at higher level.

------
bbcbasic
You'll explain what you want to the computer and it'll do it's best to
implement it. You'll definitely still need technical understanding but a lot
of the boring stuff like debugging and typing text will be like how we see
punch cards today.

------
bsvalley
It will probably be like electricity: Invisible, crucial, handled by a
gigantic infrastructure. Similar to the internet today, you subscribe to a
service then it's up to you to create products on top of that.

Depends how fast automation/AI will grow within the development field.

------
tiredwired
99% of code will be analytics tracking user actions, 1% actual useful
functionality.

------
Bino
I think we will come a far as we've done in memory safety with "logic safety",
making programs that can't misbehave.

~~~
throwaway7645
Interesting. I just hope we're not stuck in the same spot we're in now.

------
untangle
I think that the current responses aim too low.

Isomorph is really cool, but it's a "next 5 years" (or not) – not 25 years.

The future will be declarative. It'll allow voice input, possibly as the
primary modality. Objects and functions will be passe.

IOW, describe what you want the program to do, then we'll refine (i.e., sculpt
the details together).

~~~
throwaway7645
Like how the engineers, scientists, and techs code on the Enterprise. That
would be nice!

------
0xc000005
less relevant

~~~
crypticlizard
Yes and also totally hilarious as in like in my day we had to walk uphill both
ways. Jeez you guys had to actually program? That must've sucked, Grandpa. No
vr you can just point at and say/think what you want? (Like when Grandpa was a
kid and his dad didn't have a computer)

