5 ms·

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

17 points by throwaway7645 9y ago

What do you imagine programming to be like in 25 years?

tabulatouch 9y ago
Mainly AI writing code under our guidance, detecting patterns, applying patterns, suggesting best practices, digesting decades of Stackoverflow to solve problems at higher level.
Bino 9y ago
I think we will come a far as we've done in memory safety with "logic safety", making programs that can't misbehave.
- throwaway7645 9y ago
  Interesting. I just hope we're not stuck in the same spot we're in now.
borplk 9y ago
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 9y ago
  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 9y ago
    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 9y ago
      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
MichaelBurge 9y ago
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.
- crispytx 9y ago
  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.
  - flukus 9y ago
    Those "higher level" tools are why you need a fancy IDE for android. Had they opted for simpler tools, more like swing then you could write an app with a couple of text editor files instead, just as you can do it for desktop apps today. Android is actually the perfect example of adding tools to simplify development that end up making development much harder than it needs to be.
- spcelzrd 9y ago
  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 9y ago
    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.
0xc000005 9y ago
less relevant
- crypticlizard 9y ago
  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)
bsvalley 9y ago
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.
untangle 9y ago
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 9y ago
  Like how the engineers, scientists, and techs code on the Enterprise. That would be nice!
tiredwired 9y ago
99% of code will be analytics tracking user actions, 1% actual useful functionality.
bbcbasic 9y ago
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.

17 points by throwaway7645 9y ago

What do you imagine programming to be like in 25 years?

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

Bino 9y ago

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

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

borplk 9y ago

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 9y ago
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 9y ago
  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 9y ago
    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

MichaelBurge 9y ago

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.

crispytx 9y ago
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.
- flukus 9y ago
  Those "higher level" tools are why you need a fancy IDE for android. Had they opted for simpler tools, more like swing then you could write an app with a couple of text editor files instead, just as you can do it for desktop apps today. Android is actually the perfect example of adding tools to simplify development that end up making development much harder than it needs to be.
spcelzrd 9y ago
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 9y ago
  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.

0xc000005 9y ago

less relevant

crypticlizard 9y ago
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)

bsvalley 9y ago

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.

untangle 9y ago

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 9y ago
Like how the engineers, scientists, and techs code on the Enterprise. That would be nice!

tiredwired 9y ago

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

bbcbasic 9y ago

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.