5 ms·

> Visual content creation tools such as Scratch, DWNLD and Telerik will continue to improve until all functionality required to build apps is available to consu

> Visual content creation tools such as Scratch, DWNLD and Telerik will continue to improve until all functionality required to build apps is available to consumers — without having to write a line of code. > Who needs to code when you can use visual building blocks or even plain English to describe intent? Advances in natural-language processing and conceptual modeling will remove the need for traditional coding from app development. Seriously? This dream died long, long ago. The hard part of software development is not the syntax; it's deciding exactly what you want to happen for every possible input or event.

_fizz_buzz_ 11y ago
This is very true. The idea of visual programming has been around forever and there is nothing wrong with it inherently. It certainly hasn't quite delivered as expected. But even established visual programming environments (e.g. LabView) are a skill itself now.
- vegabook 11y ago
  While I agree with you on visual programming, I think another issue raises itself: we are used to linear text editors - write one line after another - because they fit the way the computer works. Even breaking code down hierarchically as we do (functions, modules) still breaks a linear process into many linear processes. Yet increasingly as problems become more asynchronous / parallel, I sometimes wish for a more sophisticated code-creation paradigm, one where, for example, there would be some kind of two dimensional or even multidimensional visual representation of the logic of the program (even if those were each composed of linear text blocks). It's always possible to represent multiple dimensions in a lower-dimensional medium, but it becomes harder to conceptualize. So we have code folding tools, we have NERDTree etc to help us manage all the blocks, but sometimes I wonder if I could have some kind of multidimensional VIM that would allow the visual structure of my code more directly to map to the logic flow. I have taken to coding on a 4k 40 inch monitor (highly recommended - the BDM4065UC from Philips is so good I bought two) because it allows to me see so much more of my code and the way the flow will jump around, to have it all in front of my eyes kinda thing, and I wonder if it would be even better to add some visual tools in there to do conditional flow control.
  - flowerpot 11y ago
    Couldn't agree more. Code is highly dimensional while our text editors are two dimensional at best. In case you don't know these talks I think you will enjoy The Future of Programming and Inventing on Principle both by Bret Victor.
  - RyanZAG 11y ago
    Not sure about this. If we're writing a scientific study with nothing to do with computers, we still use the standard "write one line after another" to describe the processes and methods we use. Sequential lists and trees may be a natural property of our reality in the same way gravity is? As you say, when problems become more complex it becomes more difficult to reason about when dealing with a linear flow. But as with writing a report, the key is in the layout. The solution to a problem like that may be simply defining your abstractions better in your code so that each logical block is contained and understandable -- the same as with a section in a report. Basically it's the age-old programming logic: instead of having large chunks of code where you have to reason through complex logic, create abstractions so that the complex flow is defined in an obvious way. There will still be complex pieces, but they can be pushed to leaf nodes in other classes/files and can be backed by formal algorithms with logical proofs. So, well, standard best practices from the 1960s and still standard best practices today. Why? Because it seems to fit with the laws of reality.
    - vegabook 11y ago
      have to say - am not sure about it either! I'm simply intrigued by the question, namely, why do we still use linear tools for multidimensional problems? I think you have posited an excellent answer in that it's basically intrinsic to how we think and manage complexity, not only in CS.
- Twisell 11y ago
  Even in high level graphical "magical" interface like Tableau software visual BI tools, the real power come with the small scripting part you can put on some specific places. When I show my work people go crazy like "wohooo I need this magical too so I can do it too!". Then they ask to modify a pretty straigforward measurement, so I open the calculation script in front of them... they got scared as hell and suddenly think I'm some sort of wizard. Being allergic to code is a pathology for someone who work in IT, don't get it wrong kids!
- lordnacho 11y ago
  The closest I've come to visual programming is various UI designers and a couple of DB designers. They work OK up to a point, but as soon as you're doing something complicated you have a mass of arrows crisscrossing the surface. I think the problem is a visual designer is only a reasonable organising principle for 2D problems. You can get a nice global view. As soon as you need more dimensions, you might as well use something where the connections are only locally visible. By that I mean eg in a complex codebase, you can only see a few incoming/outgoing connections depending on where you're looking. A codebase can be arbitrarily complex, so chances are on any problem that isn't quite small, you aren't going to be able to represent it nicely in 2D.
- dennisgorelik 11y ago
  > nothing wrong with it inherently 1) Code diffs are pathetic with visual programming. 2) Sharing code examples is very limited with visual programming. 3) Full-text search capabilities are pathetic with visual programming.
rubenbos 11y ago
It's true that the 'dream' has been here for ages, but I do think that automation might force us to rethink our job in the digital industry. I recently published an extensive article about the current state of these 'code machines', if developers might lose their job to them and what our options are. If you're interested, you can read it here: https://medium.com/design-and-develop/code-machines-29b066b65716 https://medium.com/design-and-develop/code-machines-29b066b6... Bottom line is that I don't think that developers should feel intimidated by machines right now, but not be surprised by their rise either. Not your coding skills, but your business will define if you’re still needed. If you’re coding basic low-cost websites at a high pace, you might run out of business faster than you might expect. If you can do it by repetition, a machine certainly can do that too. If you’re building crucial online services with a lot of custom functionality, the machines will have a harder time to keep up. Don’t worry about the need for your skills, worry about the need for your current business.
- jules 11y ago
  The thing is, is making a website with those services faster than with code? Even if it is slighly faster, they only work well for the 80%. The last 20% of features are impossible and you're back to code. I'd rather worry about higher and higher level programming tools that make programmers more productive. Hobo comes to mind (http://www.hobocentral.net/ http://www.hobocentral.net/) and Meteor, both making roughly orthogonal aspects of web programming easier and faster.
- JDiculous 11y ago
  Right. It's not that software engineers are going to go away, just that more and more cookie-cutter software will be buildable by less-technical people (eg. like what Wordpress has done for basic websites and what Unity has done for game development). Advances in NLP and A.I. will probably make code more English-like (eg. like SQL), or at the very least abstract away all the syntax quirks and other tedious low-level bullshit. Most software engineers are constantly reinventing the wheel (even if they don't realize it because that wheel hasn't been open-sourced yet), and that is the work that will be automated away. But of course the cutting edge will always require programmers (like someone above me commented). But don't be surprised if programming looks a lot different in the future than it looks today. I think software engineers tend to glorify the act of typing lines of code into a text editor. Code is simply a means to an end. http://www.jbernier.com/the-future-of-development-less-code http://www.jbernier.com/the-future-of-development-less-code
yason 11y ago
until all functionality required to build apps is available to consumers — without having to write a line of code. All functionality required to build old apps, that is. This is nothing new: most people can build a website these days without understanding anything about HTML. I suppose Graham's Viaweb was similar in its user experience. You can probably write simple games without writing code by weaving together parts, objects and modules graphically and wiring up some logical connections between them from a pool of supported interactions. But the thing is that all those are just using the machine. Programming is, by definition, creating and writing something that is new. If it wasn't new, it would've been written already and could be reused with minimal effort. Programming is about building that machine. Thus, programming is at the edge of new, and you can never automate that. However, the edge of new might certainly change, and also change bias. In the future, there might be less of the "new" that we do now (figuring out how to load and store data to physical devices) and more of the "new" that only a few people do now (for example, programming a deep neural network to do new things). Yet as long as humans and computers are inherently physical, someone has to care about the lowest level of new (where the bits go) and about all the intermediate levels up to the highest level of new (someone dumping his brain into a cloud computer). You can not free a human from having to deal with bits――or qubits, or whatever we will have――as much as you can not free a human from his physical existence.
wturner 11y ago
The way I like to phrase it is that humans are in a perpetual loop of creating things that make life easier in one way yet inherently more complicated in others. Then the cycle repeats to compensate for the new situation. The more granular your understanding of this in a particular discipline ( it doesn't have to be programming but it can be ) the more valuable you will be. :)

_fizz_buzz_ 11y ago

This is very true. The idea of visual programming has been around forever and there is nothing wrong with it inherently. It certainly hasn't quite delivered as expected. But even established visual programming environments (e.g. LabView) are a skill itself now.

vegabook 11y ago
While I agree with you on visual programming, I think another issue raises itself: we are used to linear text editors - write one line after another - because they fit the way the computer works. Even breaking code down hierarchically as we do (functions, modules) still breaks a linear process into many linear processes. Yet increasingly as problems become more asynchronous / parallel, I sometimes wish for a more sophisticated code-creation paradigm, one where, for example, there would be some kind of two dimensional or even multidimensional visual representation of the logic of the program (even if those were each composed of linear text blocks). It's always possible to represent multiple dimensions in a lower-dimensional medium, but it becomes harder to conceptualize. So we have code folding tools, we have NERDTree etc to help us manage all the blocks, but sometimes I wonder if I could have some kind of multidimensional VIM that would allow the visual structure of my code more directly to map to the logic flow. I have taken to coding on a 4k 40 inch monitor (highly recommended - the BDM4065UC from Philips is so good I bought two) because it allows to me see so much more of my code and the way the flow will jump around, to have it all in front of my eyes kinda thing, and I wonder if it would be even better to add some visual tools in there to do conditional flow control.
- flowerpot 11y ago
  Couldn't agree more. Code is highly dimensional while our text editors are two dimensional at best. In case you don't know these talks I think you will enjoy The Future of Programming and Inventing on Principle both by Bret Victor.
- RyanZAG 11y ago
  Not sure about this. If we're writing a scientific study with nothing to do with computers, we still use the standard "write one line after another" to describe the processes and methods we use. Sequential lists and trees may be a natural property of our reality in the same way gravity is? As you say, when problems become more complex it becomes more difficult to reason about when dealing with a linear flow. But as with writing a report, the key is in the layout. The solution to a problem like that may be simply defining your abstractions better in your code so that each logical block is contained and understandable -- the same as with a section in a report. Basically it's the age-old programming logic: instead of having large chunks of code where you have to reason through complex logic, create abstractions so that the complex flow is defined in an obvious way. There will still be complex pieces, but they can be pushed to leaf nodes in other classes/files and can be backed by formal algorithms with logical proofs. So, well, standard best practices from the 1960s and still standard best practices today. Why? Because it seems to fit with the laws of reality.
  - vegabook 11y ago
    have to say - am not sure about it either! I'm simply intrigued by the question, namely, why do we still use linear tools for multidimensional problems? I think you have posited an excellent answer in that it's basically intrinsic to how we think and manage complexity, not only in CS.
Twisell 11y ago
Even in high level graphical "magical" interface like Tableau software visual BI tools, the real power come with the small scripting part you can put on some specific places. When I show my work people go crazy like "wohooo I need this magical too so I can do it too!". Then they ask to modify a pretty straigforward measurement, so I open the calculation script in front of them... they got scared as hell and suddenly think I'm some sort of wizard. Being allergic to code is a pathology for someone who work in IT, don't get it wrong kids!
lordnacho 11y ago
The closest I've come to visual programming is various UI designers and a couple of DB designers. They work OK up to a point, but as soon as you're doing something complicated you have a mass of arrows crisscrossing the surface. I think the problem is a visual designer is only a reasonable organising principle for 2D problems. You can get a nice global view. As soon as you need more dimensions, you might as well use something where the connections are only locally visible. By that I mean eg in a complex codebase, you can only see a few incoming/outgoing connections depending on where you're looking. A codebase can be arbitrarily complex, so chances are on any problem that isn't quite small, you aren't going to be able to represent it nicely in 2D.
dennisgorelik 11y ago
> nothing wrong with it inherently 1) Code diffs are pathetic with visual programming. 2) Sharing code examples is very limited with visual programming. 3) Full-text search capabilities are pathetic with visual programming.

rubenbos 11y ago

It's true that the 'dream' has been here for ages, but I do think that automation might force us to rethink our job in the digital industry. I recently published an extensive article about the current state of these 'code machines', if developers might lose their job to them and what our options are. If you're interested, you can read it here: https://medium.com/design-and-develop/code-machines-29b066b65716 https://medium.com/design-and-develop/code-machines-29b066b6... Bottom line is that I don't think that developers should feel intimidated by machines right now, but not be surprised by their rise either. Not your coding skills, but your business will define if you’re still needed. If you’re coding basic low-cost websites at a high pace, you might run out of business faster than you might expect. If you can do it by repetition, a machine certainly can do that too. If you’re building crucial online services with a lot of custom functionality, the machines will have a harder time to keep up. Don’t worry about the need for your skills, worry about the need for your current business.

jules 11y ago
The thing is, is making a website with those services faster than with code? Even if it is slighly faster, they only work well for the 80%. The last 20% of features are impossible and you're back to code. I'd rather worry about higher and higher level programming tools that make programmers more productive. Hobo comes to mind (http://www.hobocentral.net/ http://www.hobocentral.net/) and Meteor, both making roughly orthogonal aspects of web programming easier and faster.
JDiculous 11y ago
Right. It's not that software engineers are going to go away, just that more and more cookie-cutter software will be buildable by less-technical people (eg. like what Wordpress has done for basic websites and what Unity has done for game development). Advances in NLP and A.I. will probably make code more English-like (eg. like SQL), or at the very least abstract away all the syntax quirks and other tedious low-level bullshit. Most software engineers are constantly reinventing the wheel (even if they don't realize it because that wheel hasn't been open-sourced yet), and that is the work that will be automated away. But of course the cutting edge will always require programmers (like someone above me commented). But don't be surprised if programming looks a lot different in the future than it looks today. I think software engineers tend to glorify the act of typing lines of code into a text editor. Code is simply a means to an end. http://www.jbernier.com/the-future-of-development-less-code http://www.jbernier.com/the-future-of-development-less-code

yason 11y ago

until all functionality required to build apps is available to consumers — without having to write a line of code. All functionality required to build old apps, that is. This is nothing new: most people can build a website these days without understanding anything about HTML. I suppose Graham's Viaweb was similar in its user experience. You can probably write simple games without writing code by weaving together parts, objects and modules graphically and wiring up some logical connections between them from a pool of supported interactions. But the thing is that all those are just using the machine. Programming is, by definition, creating and writing something that is new. If it wasn't new, it would've been written already and could be reused with minimal effort. Programming is about building that machine. Thus, programming is at the edge of new, and you can never automate that. However, the edge of new might certainly change, and also change bias. In the future, there might be less of the "new" that we do now (figuring out how to load and store data to physical devices) and more of the "new" that only a few people do now (for example, programming a deep neural network to do new things). Yet as long as humans and computers are inherently physical, someone has to care about the lowest level of new (where the bits go) and about all the intermediate levels up to the highest level of new (someone dumping his brain into a cloud computer). You can not free a human from having to deal with bits――or qubits, or whatever we will have――as much as you can not free a human from his physical existence.

wturner 11y ago

The way I like to phrase it is that humans are in a perpetual loop of creating things that make life easier in one way yet inherently more complicated in others. Then the cycle repeats to compensate for the new situation. The more granular your understanding of this in a particular discipline ( it doesn't have to be programming but it can be ) the more valuable you will be. :)