5 ms·

I've been trying to imagine what programming will look like in the far future, and I just can't believe that it will be fundamentally structured around typing E

I've been trying to imagine what programming will look like in the far future, and I just can't believe that it will be fundamentally structured around typing English-like text into a text editor, with a smattering of tools to help manipulate the text and debug the resulting binary, like it is now. There has to be more that computers can do to augment our brains and help us become more efficient at writing code. Gary Bernhardt's "Whole New World" talk (https://www.destroyallsoftware.com/talks/a-whole-new-world https://www.destroyallsoftware.com/talks/a-whole-new-world) is a good start, but it could go so much further. Unfortunately it seems like most working programmers are deeply suspicious of new paradigms for producing programs. Understandably so, since all the "visual programming" tools up until now have been either teaching toys or unusable disasters, but I think we're limiting ourselves tremendously. But it may not be possible to arrive at my glorious imagined future incrementally. It may take some genius just sitting down and working on this for years and producing a completely finished system to convince people of its capability. Sorry this is a bit lofty and light on specifics. It's more a feeling that I have that it would be ridiculous if programming in 2100 looked the same as it does now, and not something I've thought about deeply.

keyle 8y ago
FYI Unreal Engine's "blueprint" is a visual programming language that is neither a teaching toy nor an unusable disaster.
- Too 8y ago
  https://blueprintsfromhell.tumblr.com/ https://blueprintsfromhell.tumblr.com/
  - keyle 8y ago
    Numerous website highlights similar things in text :) And considering blueprints spit out C++ once compiled, I'd take my chance with BP!
- sriku 8y ago
  So is Max/MSP/Jitter.
wtetzner 8y ago
I hope programming advances a lot, but I'm not convinced that the medium is the interesting part. It's the semantic model that matters, and I think text has won so far because it's the best way we've come up with to express the models we have. So maybe we'll be programming in a medium other than text, but I sure hope that's not the main advance that's made.
Vivtek 8y ago
Ostensibly, it won't look the same as it does now, but in reality it will still be hacked together with Perl.
WilliamEdward 8y ago
You give people a language with a lot of influence from mathematics like Haskell, which should be easy to write because we familiarise ourselves with mathematics from a very young age. You give people a language which is very close to english, like Python, which is accessible to an even larger audience. Thousands of packages get written just to make it even closer to english, even more plug-and-play. At the level of Haskell, their comfy syntax means you need to understand the logical implications of literally everything you write. At the level of Python, their comfy syntax sacrifices control over performance. Both good syntax, both problematic. I'm beginning to think you can't have your cake and eat it too when it comes to languages. Maybe you'd even want to make the argument that it's a good thing that languages are inaccessible to most people.
nradov 8y ago
Check out the work done by Viewpoints Research Institute. http://www.vpri.org/writings.php http://www.vpri.org/writings.php APL did away with English-like text and was moderately successful, but the high learning curve inhibited popularity.
reificator 8y ago
The reason the visual languages even come up so often is because people outside of programming believe that code is the hard part. It looks scary, so if we just took that part out everyone could be a programmer. Which makes you wonder why every single attempt to do this makes easy things trivial and everything else difficult to impossible. Programming languages are (usually) tools created to help get things done. They're not (usually) there to make your life harder, or to force you to learn something. So why does it seem like that's the starting assumption to every alternative proposed? (NOTE: If your scope is limited, it makes sense. Unreal Engine 4's Shader Blueprints are great, not only is the scope limited but the visual approach allows you to preview each step at a glance.)
- arvinsim 8y ago
  I guess it's somewhat the same complaint with math and musical notation. Some mathematical expressions are very complex and compact but people use it since it is the best we got.
  - reificator 8y ago
    Yeah exactly. It's not that there's no improvement to be had, it's that you're not going to get far if you assume the current system is there to make things harder. I think part of it is, despite widespread acceptance of puns, most people seem to think English (or any other widely spoken language) is a lot less ambiguous than it really is. There's a reason legal documents are the way they are as well. Granted in that field there is sometimes incentive to obfuscate your meaning, but I still don't think that's the reason for most of the difficulty in outsiders easily reading and writing legalese. The fact of the matter is, expressing logic (or music) in words is hard. The more detailed you need to be, the harder it gets. That's why the example of making a sandwich comes up so often in introductions to programming[0]. If people can't express in their native language how to do something they do every day, in an unambiguous enough manner for a "computer" to perform the action, that speaks to a deeper problem than the representation being too hard. [0]: It's not a great example, because the instructor usually is going to maliciously try to find any logic hole they can, making it feel more like a hazing ritual than a lesson to be learned. But it does come up a lot for a reason.
tuesdayrain 8y ago
I expect programming to trend towards being more declarative. Developers will state what they want and it will be up to the interpreter/compiler to come up with the most efficient solution.
spiralganglion 8y ago
I consider myself a serious programmer (fond of Clojure, Haskell, writing hyper-performant graphics code, etc). I'm also very fond of visual languages, so much so that I started collecting and cataloging all the noteworthy examples of them I came across in my research travels: https://github.com/ivanreese/visual-programming-codex https://github.com/ivanreese/visual-programming-codex Yes, the vast majority of visual languages are uninspired and underdeveloped. But the same is true of text languages — look at Pascal or xBase or C++ templates. Yes, it's possible to make a terrible mess in a visual language. But the same is true of text languages — we had to learn the hard way not to goto, not to do TCL style string-based metaprogramming. When we think of the greatness of text languages, we're thinking of Idris and APL and Racket, not the Java you see on The Daily WTF. When we think of visual languages, we should look for similar examples of greatness (modern Max/MSP is not a bad place to start), and not indulge in Blueprints From Hell schadenfreude.
- arvinsim 8y ago
  There needs to be an "Assembly" of visual languages. Otherwise, we will still be limited if we code them in text languages.
  - uryga 8y ago
    could you explain this idea a bit more? it sounds interesting, but i don't quite see why "visual assembly" would be necessary. most "high level" languages are written in something lower level like C (possibly with Assembly bits), but that's an implementation detail – the semantics of C have little bearing on the semantics of the implemented language. why would it matter what makes a visual language tick under the hood?
_bxg1 8y ago
Reasons we use text: - It's very close to the computer's "native language"; a raw series of bytes on disk can be stored and processed efficiently, and are analogous to the binary form, which has to be a series of bytes - It's visually compact, so you can view a large amount of complexity per screen space - It can be created and edited purely by keyboard. I'm not an anti-mouse zealot - I often use it when I'm going back and tweaking code - but nobody can deny that the keyboard is a faster and more direct way of getting new ideas out of your head and into the computer I also think there's value in being able to get down to the baseline and see the "raw stuff" that makes up a program. Being able to see that full definition with no layers of indirection, even if you always use layers of indirection when actually working on it. None of these are insurmountable, but I think they'd have to all be addressed by any true graphical replacement for textual code. Personally my vote is for a more fully graphical editor that still operates on textual code underneath, which can still be read by humans on its own.
- Nasrudith 8y ago
  There is another factor in favor for text - it is precise in meaning and easy to output as opposed to even "memorize an 8 bit Mario sprite and get all colors right without a single pixel out of place".
6keZbCECT2uB 8y ago
I find that giving names to things is a way to manage complexity and relationships which scales to far more complicated systems than visual representations that I'm familiar with. Maybe the inability of a visual representation to cope with complexity is an advantage in promoting less complex systems, but making systems which handle our world that are that simple seems expensive. I started introductory work in circuit design via a visual interface. You could drag and drop components, size them, connect them, and so on. I had to do quite a lot of work on the layout for even simple designs to appear comprehensible. There were just so many relationships, and crossing wires is so problematic that it's hard to provide high level detail or low level detail. You graduate to connecting things by names, then to a description language which is purely in terms of names. Programming visualization struggles to remain comprehensible in view of the full complexity of the underlying system. I took a single variable, and tracked every function which interacted with this variable based on read or write relationships across a single (fairly top level) function call. The graph that I generated from this fundamental tree-like structure was unusably complex. After collapsing nodes appropriately, I could explore the graph to get some understanding, but no one that I shared this with understood how to use it. I don't know if this is argument for visual representations (since I used it to explore these relationships) or against. Nevertheless, I see no reason why we need to draw such a distinction between a text-based specification and a visual one. We certainly can design a language-visual dual which is trivially isomorphic, so getting that system hardly requires a paradigm shift.

keyle 8y ago

FYI Unreal Engine's "blueprint" is a visual programming language that is neither a teaching toy nor an unusable disaster.

Too 8y ago
https://blueprintsfromhell.tumblr.com/ https://blueprintsfromhell.tumblr.com/
- keyle 8y ago
  Numerous website highlights similar things in text :) And considering blueprints spit out C++ once compiled, I'd take my chance with BP!
sriku 8y ago
So is Max/MSP/Jitter.

wtetzner 8y ago

I hope programming advances a lot, but I'm not convinced that the medium is the interesting part. It's the semantic model that matters, and I think text has won so far because it's the best way we've come up with to express the models we have. So maybe we'll be programming in a medium other than text, but I sure hope that's not the main advance that's made.

Vivtek 8y ago

Ostensibly, it won't look the same as it does now, but in reality it will still be hacked together with Perl.

WilliamEdward 8y ago

You give people a language with a lot of influence from mathematics like Haskell, which should be easy to write because we familiarise ourselves with mathematics from a very young age. You give people a language which is very close to english, like Python, which is accessible to an even larger audience. Thousands of packages get written just to make it even closer to english, even more plug-and-play. At the level of Haskell, their comfy syntax means you need to understand the logical implications of literally everything you write. At the level of Python, their comfy syntax sacrifices control over performance. Both good syntax, both problematic. I'm beginning to think you can't have your cake and eat it too when it comes to languages. Maybe you'd even want to make the argument that it's a good thing that languages are inaccessible to most people.

nradov 8y ago

Check out the work done by Viewpoints Research Institute. http://www.vpri.org/writings.php http://www.vpri.org/writings.php APL did away with English-like text and was moderately successful, but the high learning curve inhibited popularity.

reificator 8y ago

The reason the visual languages even come up so often is because people outside of programming believe that code is the hard part. It looks scary, so if we just took that part out everyone could be a programmer. Which makes you wonder why every single attempt to do this makes easy things trivial and everything else difficult to impossible. Programming languages are (usually) tools created to help get things done. They're not (usually) there to make your life harder, or to force you to learn something. So why does it seem like that's the starting assumption to every alternative proposed? (NOTE: If your scope is limited, it makes sense. Unreal Engine 4's Shader Blueprints are great, not only is the scope limited but the visual approach allows you to preview each step at a glance.)

arvinsim 8y ago
I guess it's somewhat the same complaint with math and musical notation. Some mathematical expressions are very complex and compact but people use it since it is the best we got.
- reificator 8y ago
  Yeah exactly. It's not that there's no improvement to be had, it's that you're not going to get far if you assume the current system is there to make things harder. I think part of it is, despite widespread acceptance of puns, most people seem to think English (or any other widely spoken language) is a lot less ambiguous than it really is. There's a reason legal documents are the way they are as well. Granted in that field there is sometimes incentive to obfuscate your meaning, but I still don't think that's the reason for most of the difficulty in outsiders easily reading and writing legalese. The fact of the matter is, expressing logic (or music) in words is hard. The more detailed you need to be, the harder it gets. That's why the example of making a sandwich comes up so often in introductions to programming[0]. If people can't express in their native language how to do something they do every day, in an unambiguous enough manner for a "computer" to perform the action, that speaks to a deeper problem than the representation being too hard. [0]: It's not a great example, because the instructor usually is going to maliciously try to find any logic hole they can, making it feel more like a hazing ritual than a lesson to be learned. But it does come up a lot for a reason.

tuesdayrain 8y ago

I expect programming to trend towards being more declarative. Developers will state what they want and it will be up to the interpreter/compiler to come up with the most efficient solution.

spiralganglion 8y ago

I consider myself a serious programmer (fond of Clojure, Haskell, writing hyper-performant graphics code, etc). I'm also very fond of visual languages, so much so that I started collecting and cataloging all the noteworthy examples of them I came across in my research travels: https://github.com/ivanreese/visual-programming-codex https://github.com/ivanreese/visual-programming-codex Yes, the vast majority of visual languages are uninspired and underdeveloped. But the same is true of text languages — look at Pascal or xBase or C++ templates. Yes, it's possible to make a terrible mess in a visual language. But the same is true of text languages — we had to learn the hard way not to goto, not to do TCL style string-based metaprogramming. When we think of the greatness of text languages, we're thinking of Idris and APL and Racket, not the Java you see on The Daily WTF. When we think of visual languages, we should look for similar examples of greatness (modern Max/MSP is not a bad place to start), and not indulge in Blueprints From Hell schadenfreude.

arvinsim 8y ago
There needs to be an "Assembly" of visual languages. Otherwise, we will still be limited if we code them in text languages.
- uryga 8y ago
  could you explain this idea a bit more? it sounds interesting, but i don't quite see why "visual assembly" would be necessary. most "high level" languages are written in something lower level like C (possibly with Assembly bits), but that's an implementation detail – the semantics of C have little bearing on the semantics of the implemented language. why would it matter what makes a visual language tick under the hood?

_bxg1 8y ago

Reasons we use text: - It's very close to the computer's "native language"; a raw series of bytes on disk can be stored and processed efficiently, and are analogous to the binary form, which has to be a series of bytes - It's visually compact, so you can view a large amount of complexity per screen space - It can be created and edited purely by keyboard. I'm not an anti-mouse zealot - I often use it when I'm going back and tweaking code - but nobody can deny that the keyboard is a faster and more direct way of getting new ideas out of your head and into the computer I also think there's value in being able to get down to the baseline and see the "raw stuff" that makes up a program. Being able to see that full definition with no layers of indirection, even if you always use layers of indirection when actually working on it. None of these are insurmountable, but I think they'd have to all be addressed by any true graphical replacement for textual code. Personally my vote is for a more fully graphical editor that still operates on textual code underneath, which can still be read by humans on its own.

Nasrudith 8y ago
There is another factor in favor for text - it is precise in meaning and easy to output as opposed to even "memorize an 8 bit Mario sprite and get all colors right without a single pixel out of place".

6keZbCECT2uB 8y ago

I find that giving names to things is a way to manage complexity and relationships which scales to far more complicated systems than visual representations that I'm familiar with. Maybe the inability of a visual representation to cope with complexity is an advantage in promoting less complex systems, but making systems which handle our world that are that simple seems expensive. I started introductory work in circuit design via a visual interface. You could drag and drop components, size them, connect them, and so on. I had to do quite a lot of work on the layout for even simple designs to appear comprehensible. There were just so many relationships, and crossing wires is so problematic that it's hard to provide high level detail or low level detail. You graduate to connecting things by names, then to a description language which is purely in terms of names. Programming visualization struggles to remain comprehensible in view of the full complexity of the underlying system. I took a single variable, and tracked every function which interacted with this variable based on read or write relationships across a single (fairly top level) function call. The graph that I generated from this fundamental tree-like structure was unusably complex. After collapsing nodes appropriately, I could explore the graph to get some understanding, but no one that I shared this with understood how to use it. I don't know if this is argument for visual representations (since I used it to explore these relationships) or against. Nevertheless, I see no reason why we need to draw such a distinction between a text-based specification and a visual one. We certainly can design a language-visual dual which is trivially isomorphic, so getting that system hardly requires a paradigm shift.