Live data from Hacker News

Ask HN: What will coding be like in 25 years?

news.ycombinator.com

11–20 of 24 posts

Re: Ask HN: What will coding be like in 25 years?

#11

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.

There seems to be a trend: As software increases in complexity, programming languages and frameworks become higher and higher level to combat these increases in complexity.

For example, think about how much more complex it is to develop an Android app versus a web app. All you need to write a web app is a text editor to create three files: an html file, a css file, and a js file. Android development on the other hand is so complicated that you need a fancy IDE to organize everything for you. My prediction for the future is that Android development (and mobile development in general) will eventually become this simple.

Re: Ask HN: What will coding be like in 25 years?

#12

less relevant

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)

Re: Ask HN: What will coding be like in 25 years?

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

Re: Ask HN: What will coding be like in 25 years?

#14

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

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

Re: Ask HN: What will coding be like in 25 years?

#16
post #9
post #8

Earlier quoted context omitted.

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

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 coul…

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

Re: Ask HN: What will coding be like in 25 years?

#17
post #9

Earlier quoted context omitted.

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 coul…

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 intent…

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

Re: Ask HN: What will coding be like in 25 years?

#18

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.

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.

Re: Ask HN: What will coding be like in 25 years?

#19
post #5

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…

Are you interested in tackling this challenge? If so, let me know.

Re: Ask HN: What will coding be like in 25 years?

#20
post #5

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…

Are you interested in tackling this challenge? If so, let me know.

In principle absolutely, full disclosure realistically I honestly don't see myself being able to spend time on it between everything else. Love to chat further about it if you are interested or had something specific in mind that you would like to discuss. In that case let me know the best way to contact you.
Post reply on HN