9 ms·

The article’s position comes down to “no fundamentally new way to program would make sense for today’s programmers to switch to it”, and gives examples like the

The article’s position comes down to “no fundamentally new way to program would make sense for today’s programmers to switch to it”, and gives examples like the platforms of the no-code movement. From previous generational leaps, we’ve learned that the users post-leap don’t look like the pre-leap users at all. The iPod’s introduction brought about a generation of new digital music users that didn’t look like the Limewire generation, and the iPhone’s average user didn’t look like the average user of the BlackBerry before it. Modern programming is at the core of HN, and of most of SV, sure. That said, we should still be the first to realize that a successful, fundamentally new way to program would target a new generation and idea of software maker, one that won’t look like the modern developer at all.

andrewjl 6y ago
> That said, we should still be the first to realize that a successful, fundamentally new way to program would target a new generation and idea of software maker, one that won’t look like the modern developer at all. Channeling Gibson[1], do you see any potential successors already out there? [1] “The future is already here – it's just not evenly distributed."
- izuchukwu 6y ago
  I’d keep an eye on the no-code movement. Real leaps can be distinguished from hype by where the passion is coming from. The fact that the movement’s passion is coming from actual, paying users and not just no-code platform makers is key here. It’s rapidly creating a new generation of software creators that could not create software before, and it’s improving very, very fast.
KMag 6y ago
Former Limewire developer here. I definitely had an iPod mini prior to Limewire's peak years, counted by number of monthly peers reachable via crawling the Gnutella network.
- echelon 6y ago
  What's your take on how everything works these days? Do you miss p2p? Do you think we could ever get back to it?
  - KMag 6y ago
    > What's your take on how everything works these days? Mostly, I wish technologies to make unreliable P2P transfers more robust had been widely applied to point-to-point transfers. I wish my phone, for instance, used low-data-rate UDP (with TCP-friendly flow control and a low priority IPv6 QoS) with a rateless forward error code (such as Network Codes) to download updates. There's no reason an update download should just fail and start over if WiFi is spotty or you move between WiFi networks. Power, CO2, and cost efficiencies of scale due to centralization are nice. The shift to mobile makes P2P more challenging, see Skype switching to a more centralized architecture to make mobile conversations more stable. I wish we had somehow come to a point where users were incentivized to use P2P programs that marked P2P traffic using the IPv6 QoS field to flag P2P traffic, rather than relying on heuristics to try and shape traffic. Using heuristics to shape traffic incentivizes P2P traffic to use stenography and mimic VoIP or video chat, making everything less efficient. Monthly data quotas at different QoSes, after which all the traffic gets a low priority, would incentivize users to use programs that explicitly directly signal traffic prioritization to the routers. Comcast's traffic shaping attempts using heuristics seem to have caused it to forge RST packets when Lotus Notes (mostly used by enterprises) downloaded large attachments, breaking attachment downloads.[0] > Do you miss p2p? Sometimes. > Do you think we could ever get back to it? I think that really depends on corporate censorship (with and without government pressure) trends in the near future, and how hard the average person wants to push back. I think P2P is unlikely to see a major resurgence any time soon. [0] https://www.techdirt.com/articles/20071114/175325.shtml https://www.techdirt.com/articles/20071114/175325.shtml
  - 3131s 6y ago
    Get on Soulseek / Nicotine! It's still great...
- izuchukwu 6y ago
  That’s very interesting to note. I imagine that the popularity of the iPod led a lot of new people to Limewire before the iTunes Store and Spotify took off, pushing its true peak to be a lot later than most (including myself) might recall. The “Don’t steal music” label on every new iPod might as well have been a Limewire ad.
toyg 6y ago
I agree with the overall point but I think you're using the wrong example. Music consumption didn't really change with the ipod, it changed with abundant mobile data that removed the need for locally-stored files (and hence their management). You can argue that the introduction of iTunes changed the game, which it did a bit, but imho mobile data is what fundamentally altered the field. Imho the move really was cd -> mp3 (filesharing/iTunes) -> streaming to mobile.
- golergka 6y ago
  When I bought a 40gb music player in 2005, I stopped downloading songs and started downloading discographies of entire artists and labels. The change that came with streaming services wasn't the first one.
  - andai 6y ago
    I'd download entire music libraries (from Soulseek where you can browse people's shared files). I'd look up something I liked and assume someone who likes it has good taste :) And download whatever else seemed interesting. Thus my iPod became a vehicle for discovering new music.
benjaminjosephw 6y ago
Exactly. A paradigm shift implies new mental models and new metaphors for our abstractions that might not be valuable to people who think our current abstractions serve us well. A great example of this is the fact that we still use the metaphor of files and folders for organizing our source code. The Unison language works directly with an AST that is modified from a scratch file[0]. For people committed to new models of distributed computing, that makes sense; for everyone else, it might be seen as an idea that messes with their current tooling and changes existing and familiar workflows. I think the really big leaps forward are going to go well beyond this and they will look like sacrilege to the old guard. New programmers don't care if a programming language is Turing complete or if the type system has certain properties, they only care about working software but existing programmers are dogmatic about these concepts. I think the next leap forward in programming is going to offend the sensibilities of current programmers. Having to break with orthodoxy to get a job done won't worry people who don't know much about programming tradition to begin with. [0] - https://www.unisonweb.org/docs/tour#-to-the-unison-codebase-manager https://www.unisonweb.org/docs/tour#-to-the-unison-codebase-...
- waheoo 6y ago
  > Unison language There goes my Christmas break. Thanks.
- zupa-hu 6y ago
  Wow, thanks for sharing Unison, seems super interesting! I've been thinking about content addressed code compilation lately that could allow one to have all versions of a program within a single binary. Apparently there are other benefits to it. Can't wait to learn what they have discovered!
  - brabel 6y ago
    I've played a little bit with Unison and it's definitely very interesting and a little bit of a new paradigm (some people compare their "images" to Smalltalk images, but I think they differ enough to be considered as distinct paradigms)... but they're still working on very basic things, like how to enable people to do code reviews when the committed code is an AST, not just text... and how to actually distribute such software (I asked in their very friendly chat but apparently you can't run the code outside the interpreter for now, which I think is written in Haskell)... also, the only help you can get writing code is some syntax highlighting, even though the ucm CLI can display function docs and look up functions by type, for example, similar to Haskell's Hoogle (but in the CLI!!). ... so just be aware it's very early days for Unison (and they do make that clear by "forcing" you to join the #alphatesting Slack chat to install it, which is a great idea IMO as it sets expectations early).
higerordermap 6y ago
I think no-code was not the right idea. Removing barriers of entry comes with its own problems. Today we see that horrible error-prone excel sheets that are created by non-programmers wasn't a great idea at all. Similarly, many web developers don't understand performance and we end up with bloated sites / electron apps. I think lot of progress will be incremental. Seemingly "revolutionary" ideas like light table break on modestly real world stuff. Function programming is elegant and all unless you hit a part of problem fundamentally imperative or if there's a performance problem. I think programming progress will be incremental, just as industry continues to mature.
- carlmr 6y ago
  >Function programming is elegant and all unless you hit a part of problem fundamentally imperative or if there's a performance problem. Most functional languages allow you to do imperative stuff. so this is not an issue. They just usually provide an environment where the defaults guide you to functional (immutable by default, option/result types instead of exceptions, making partial application of functions and piping easy, etc.). A prime example would be F#. You can program pretty much the same as in C# if you need to, but there are a lot of facilities for programming in a more functional style.
  - arrow7000 6y ago
    Exactly. F# does this really well imo.
flohofwoe 6y ago
IMHO programming language design is (or at least should be) guided by the underlying hardware. If the hardware dramatically changes, the way this new hardware is programmed will also need to change radically. But as long as the hardware doesn't radically change (which it didn't so far for the last 70 years or so), programming this hardware won't (and shouldn't) radically change either. It's really quite simple (or naive, your pick) :)
- vbezhenar 6y ago
  CPUs are progressing with more cores. Today a program should utilize 100+ cores to fully saturate modern server CPU (or 32 cores for consumer CPU). GPU computations are a thing for many years and their hardware drastically differs from conventional CPUs. There are neural accelerators in the latest computers. I have no idea what they do, but may be they warrant new programming approaches as well.
- scotty79 6y ago
  It is guided by hardware changes and changed over the last 70 years a lot. GPUs spawned shader languages and network cards spawned html and javascript.
  - flohofwoe 6y ago
    Yes indeed, and after had hit the reply button I was thinking about GPUs. But if you look at how a single GPU core is programmed, this is still served pretty well with the traditional programming model, just slightly enhanced for the different memory architecture. With "radical changes" I mean totally moving away from the von Neumann architecture, e.g. "weird stuff" like quantum-, biochemical- or analog-computers.
grumple 6y ago
I think you are taking the weakest possible extrapolation of the article's position and attacking that. This article is about changing techs for an existing product. And the author is correct; tech changes are very costly for existing products. You have to weigh the cost of the rewrite. Swapping out your markdown parsing library is probably relatively low-cost. Swapping out your web framework is potentially years of work for no practical gain. Most of us aren't working on new things. Day 2 of a company's existence, you already have legacy code and have to deal with things that were built before.
BariumBlue 6y ago
I think I know of an example: I work with some folks who use Brewlytics (https://brewlytics.com/ https://brewlytics.com/). It's basically a way to use logical modeling to automate tasks, actions, and pull and push data for said automation. It's parallel to programming - these folks are using iterators, splitting and recombining fields, creating reusable parts out of smaller parts. They basically ARE programming, but almost none of them know anything more about programming than Hello World in Python. I find the situation absolutely bizarre
Forge36 6y ago
I wonder how much of this comes from how tightly "programming" has been defined as/synonymous with "writing code". I have two family members who brought up much of their job was "custom formulas in excel". They would not call themselves programmers, but they'd learned some basic programming for their job. I wonder how much "Microsoft Flow Implementer" will become its own job focus with more and more people getting access to Teams.
oblio 6y ago
Science advances, one burial at a time :-)
hodgesrm 6y ago
Excel and spreadsheets in general are one of the best examples of a generational leap that expands the programming market to new users.
- username90 6y ago
  We don't call people working in excel programmers though, not even themselves do that. That is the thing, we create a ton of wonderful no/low code tools, but then we create different jobs from programming since the programming is no longer the hard part the role is no longer a programmer.
  - hodgesrm 6y ago
    Right. We call them accountants. That's why the market expanded. ;)
Siira 6y ago
This claim is resting upon flimsy metaphors only. Of course, tautologically, each new wave of tech has some differences in demographics, and old people are slow to learn new paradigms, and generations differ, BUT ultimately we have no idea if/when there will be a new wave and how different its users will be. It might very well happen that the demographics don’t change as much, as the programming profession is already one of the most fragmented and eclectic, and attracts people whose primary virtue is manipulating logical abstractions.
AnimalMuppet 6y ago
I notice, though, that your examples are not from programming at all. Your examples are about users of devices. True, programmers use languages, but programming is far more complicated than using a music service. Something like "no code" may make programming easier... until it doesn't. That is, you get to the point where either you can't do what you need to do, or where it would be easier to do it by just writing the code. If the "no code" approach lets you write significant parts of your program that way, it may still be a net win, but it's not the way we're going to do all of programming in the future.
- izuchukwu 6y ago
  Generational leaps emerge in the same ways everywhere. For any space, if you provide a large enough net win for a large enough number of people, you introduce a generational leap. Very often, those people are completely new to the space. The measure here isn’t how many growing companies that started with no-code adopt code as they grow. The measure here is how many growing companies that started with no-code wouldn’t have been started otherwise.
- EricE 6y ago
  "I notice, though, that your examples are not from programming at all. Your examples are about users of devices. " Just to level set - as a program manager when I engage with programmers it's not because I want to buy programmers. I want the fruits of their labors. Let me put it another way - programmers love to bemoan the way users abuse Excel. Users abuse Excel because it meets their needs best, given all other factors in their environments. If things like no code environments progress where they can provide at a minimum the level of functionality Excel can for many tasks then it will take off. No, it won't be "all of programming" but enough to be a paradigm shif? You betcha.
  - AnimalMuppet 6y ago
    OK, take Excel. It provided a way for a lot of non-programmers, who didn't want to become programmers, to program enough to get their work done. And that's great! But if you look at a graph of the number of people employed as programmers, and you look for the point where that number started to decline because Excel made them unnecessary, well, you don't find it. Excel made simpler stuff available for simpler problems, but it didn't address bigger problems, and there were plenty of bigger problems to go around. And when we talk about fundamentally improving programming, we aren't talking about improving it for those trying to solve Excel-level problems. (That's still worth doing! It's just not what we're talking about.) So if you can create a new Excel for some area, it will take off. And that's great, for the people who can use it. It won't be all of programming, but it will be a paradigm shift for those who use it. Will that be a paradigm shift for all of programming? Depends on how many people use it. My bet would be that there is no Excel-like shift (or no-code shift) in, say, the next 20 years, that will affect even 30% of what we currently recognize as programmers. (If you introduce a great no-code thing, and 10% of current programmers shift to use it, and a ton of newcomers join them, that still only counts as 10% by my metric, in the same way that we don't really count Excel jockeys as professional programmers.)
miki123211 6y ago
I think the next paradigm shift in programming is the shift from local to cloud IDEs. I see a lot of backlash against that idea these days, but it seems inevitable. I don't think we can predict the full consequences of that, but one I see already is massively lowering friction. If the cloud knows how to run your code anyway, there's no reason why the fork button couldn't immediately spin up a dev environment. No Docker, no hunting for dependencies, just one click, and you have the thing running. The next generation of programmers (mostly young teenagers at this point) is often using repl.it apparently, and building cool stuff with it. This is definitely promising for this approach, as the old generation will pass away eventually.

andrewjl 6y ago

> That said, we should still be the first to realize that a successful, fundamentally new way to program would target a new generation and idea of software maker, one that won’t look like the modern developer at all. Channeling Gibson[1], do you see any potential successors already out there? [1] “The future is already here – it's just not evenly distributed."

izuchukwu 6y ago
I’d keep an eye on the no-code movement. Real leaps can be distinguished from hype by where the passion is coming from. The fact that the movement’s passion is coming from actual, paying users and not just no-code platform makers is key here. It’s rapidly creating a new generation of software creators that could not create software before, and it’s improving very, very fast.

KMag 6y ago

Former Limewire developer here. I definitely had an iPod mini prior to Limewire's peak years, counted by number of monthly peers reachable via crawling the Gnutella network.

echelon 6y ago
What's your take on how everything works these days? Do you miss p2p? Do you think we could ever get back to it?
- KMag 6y ago
  > What's your take on how everything works these days? Mostly, I wish technologies to make unreliable P2P transfers more robust had been widely applied to point-to-point transfers. I wish my phone, for instance, used low-data-rate UDP (with TCP-friendly flow control and a low priority IPv6 QoS) with a rateless forward error code (such as Network Codes) to download updates. There's no reason an update download should just fail and start over if WiFi is spotty or you move between WiFi networks. Power, CO2, and cost efficiencies of scale due to centralization are nice. The shift to mobile makes P2P more challenging, see Skype switching to a more centralized architecture to make mobile conversations more stable. I wish we had somehow come to a point where users were incentivized to use P2P programs that marked P2P traffic using the IPv6 QoS field to flag P2P traffic, rather than relying on heuristics to try and shape traffic. Using heuristics to shape traffic incentivizes P2P traffic to use stenography and mimic VoIP or video chat, making everything less efficient. Monthly data quotas at different QoSes, after which all the traffic gets a low priority, would incentivize users to use programs that explicitly directly signal traffic prioritization to the routers. Comcast's traffic shaping attempts using heuristics seem to have caused it to forge RST packets when Lotus Notes (mostly used by enterprises) downloaded large attachments, breaking attachment downloads.[0] > Do you miss p2p? Sometimes. > Do you think we could ever get back to it? I think that really depends on corporate censorship (with and without government pressure) trends in the near future, and how hard the average person wants to push back. I think P2P is unlikely to see a major resurgence any time soon. [0] https://www.techdirt.com/articles/20071114/175325.shtml https://www.techdirt.com/articles/20071114/175325.shtml
- 3131s 6y ago
  Get on Soulseek / Nicotine! It's still great...
izuchukwu 6y ago
That’s very interesting to note. I imagine that the popularity of the iPod led a lot of new people to Limewire before the iTunes Store and Spotify took off, pushing its true peak to be a lot later than most (including myself) might recall. The “Don’t steal music” label on every new iPod might as well have been a Limewire ad.

toyg 6y ago

I agree with the overall point but I think you're using the wrong example. Music consumption didn't really change with the ipod, it changed with abundant mobile data that removed the need for locally-stored files (and hence their management). You can argue that the introduction of iTunes changed the game, which it did a bit, but imho mobile data is what fundamentally altered the field. Imho the move really was cd -> mp3 (filesharing/iTunes) -> streaming to mobile.

golergka 6y ago
When I bought a 40gb music player in 2005, I stopped downloading songs and started downloading discographies of entire artists and labels. The change that came with streaming services wasn't the first one.
- andai 6y ago
  I'd download entire music libraries (from Soulseek where you can browse people's shared files). I'd look up something I liked and assume someone who likes it has good taste :) And download whatever else seemed interesting. Thus my iPod became a vehicle for discovering new music.

benjaminjosephw 6y ago

Exactly. A paradigm shift implies new mental models and new metaphors for our abstractions that might not be valuable to people who think our current abstractions serve us well. A great example of this is the fact that we still use the metaphor of files and folders for organizing our source code. The Unison language works directly with an AST that is modified from a scratch file[0]. For people committed to new models of distributed computing, that makes sense; for everyone else, it might be seen as an idea that messes with their current tooling and changes existing and familiar workflows. I think the really big leaps forward are going to go well beyond this and they will look like sacrilege to the old guard. New programmers don't care if a programming language is Turing complete or if the type system has certain properties, they only care about working software but existing programmers are dogmatic about these concepts. I think the next leap forward in programming is going to offend the sensibilities of current programmers. Having to break with orthodoxy to get a job done won't worry people who don't know much about programming tradition to begin with. [0] - https://www.unisonweb.org/docs/tour#-to-the-unison-codebase-manager https://www.unisonweb.org/docs/tour#-to-the-unison-codebase-...

waheoo 6y ago
> Unison language There goes my Christmas break. Thanks.
zupa-hu 6y ago
Wow, thanks for sharing Unison, seems super interesting! I've been thinking about content addressed code compilation lately that could allow one to have all versions of a program within a single binary. Apparently there are other benefits to it. Can't wait to learn what they have discovered!
- brabel 6y ago
  I've played a little bit with Unison and it's definitely very interesting and a little bit of a new paradigm (some people compare their "images" to Smalltalk images, but I think they differ enough to be considered as distinct paradigms)... but they're still working on very basic things, like how to enable people to do code reviews when the committed code is an AST, not just text... and how to actually distribute such software (I asked in their very friendly chat but apparently you can't run the code outside the interpreter for now, which I think is written in Haskell)... also, the only help you can get writing code is some syntax highlighting, even though the ucm CLI can display function docs and look up functions by type, for example, similar to Haskell's Hoogle (but in the CLI!!). ... so just be aware it's very early days for Unison (and they do make that clear by "forcing" you to join the #alphatesting Slack chat to install it, which is a great idea IMO as it sets expectations early).

higerordermap 6y ago

I think no-code was not the right idea. Removing barriers of entry comes with its own problems. Today we see that horrible error-prone excel sheets that are created by non-programmers wasn't a great idea at all. Similarly, many web developers don't understand performance and we end up with bloated sites / electron apps. I think lot of progress will be incremental. Seemingly "revolutionary" ideas like light table break on modestly real world stuff. Function programming is elegant and all unless you hit a part of problem fundamentally imperative or if there's a performance problem. I think programming progress will be incremental, just as industry continues to mature.

carlmr 6y ago
>Function programming is elegant and all unless you hit a part of problem fundamentally imperative or if there's a performance problem. Most functional languages allow you to do imperative stuff. so this is not an issue. They just usually provide an environment where the defaults guide you to functional (immutable by default, option/result types instead of exceptions, making partial application of functions and piping easy, etc.). A prime example would be F#. You can program pretty much the same as in C# if you need to, but there are a lot of facilities for programming in a more functional style.
- arrow7000 6y ago
  Exactly. F# does this really well imo.

flohofwoe 6y ago

IMHO programming language design is (or at least should be) guided by the underlying hardware. If the hardware dramatically changes, the way this new hardware is programmed will also need to change radically. But as long as the hardware doesn't radically change (which it didn't so far for the last 70 years or so), programming this hardware won't (and shouldn't) radically change either. It's really quite simple (or naive, your pick) :)

vbezhenar 6y ago
CPUs are progressing with more cores. Today a program should utilize 100+ cores to fully saturate modern server CPU (or 32 cores for consumer CPU). GPU computations are a thing for many years and their hardware drastically differs from conventional CPUs. There are neural accelerators in the latest computers. I have no idea what they do, but may be they warrant new programming approaches as well.
scotty79 6y ago
It is guided by hardware changes and changed over the last 70 years a lot. GPUs spawned shader languages and network cards spawned html and javascript.
- flohofwoe 6y ago
  Yes indeed, and after had hit the reply button I was thinking about GPUs. But if you look at how a single GPU core is programmed, this is still served pretty well with the traditional programming model, just slightly enhanced for the different memory architecture. With "radical changes" I mean totally moving away from the von Neumann architecture, e.g. "weird stuff" like quantum-, biochemical- or analog-computers.

grumple 6y ago

I think you are taking the weakest possible extrapolation of the article's position and attacking that. This article is about changing techs for an existing product. And the author is correct; tech changes are very costly for existing products. You have to weigh the cost of the rewrite. Swapping out your markdown parsing library is probably relatively low-cost. Swapping out your web framework is potentially years of work for no practical gain. Most of us aren't working on new things. Day 2 of a company's existence, you already have legacy code and have to deal with things that were built before.

BariumBlue 6y ago

I think I know of an example: I work with some folks who use Brewlytics (https://brewlytics.com/ https://brewlytics.com/). It's basically a way to use logical modeling to automate tasks, actions, and pull and push data for said automation. It's parallel to programming - these folks are using iterators, splitting and recombining fields, creating reusable parts out of smaller parts. They basically ARE programming, but almost none of them know anything more about programming than Hello World in Python. I find the situation absolutely bizarre

Forge36 6y ago

I wonder how much of this comes from how tightly "programming" has been defined as/synonymous with "writing code". I have two family members who brought up much of their job was "custom formulas in excel". They would not call themselves programmers, but they'd learned some basic programming for their job. I wonder how much "Microsoft Flow Implementer" will become its own job focus with more and more people getting access to Teams.

oblio 6y ago

Science advances, one burial at a time :-)

hodgesrm 6y ago

Excel and spreadsheets in general are one of the best examples of a generational leap that expands the programming market to new users.

username90 6y ago
We don't call people working in excel programmers though, not even themselves do that. That is the thing, we create a ton of wonderful no/low code tools, but then we create different jobs from programming since the programming is no longer the hard part the role is no longer a programmer.
- hodgesrm 6y ago
  Right. We call them accountants. That's why the market expanded. ;)

Siira 6y ago

This claim is resting upon flimsy metaphors only. Of course, tautologically, each new wave of tech has some differences in demographics, and old people are slow to learn new paradigms, and generations differ, BUT ultimately we have no idea if/when there will be a new wave and how different its users will be. It might very well happen that the demographics don’t change as much, as the programming profession is already one of the most fragmented and eclectic, and attracts people whose primary virtue is manipulating logical abstractions.

AnimalMuppet 6y ago

I notice, though, that your examples are not from programming at all. Your examples are about users of devices. True, programmers use languages, but programming is far more complicated than using a music service. Something like "no code" may make programming easier... until it doesn't. That is, you get to the point where either you can't do what you need to do, or where it would be easier to do it by just writing the code. If the "no code" approach lets you write significant parts of your program that way, it may still be a net win, but it's not the way we're going to do all of programming in the future.

izuchukwu 6y ago
Generational leaps emerge in the same ways everywhere. For any space, if you provide a large enough net win for a large enough number of people, you introduce a generational leap. Very often, those people are completely new to the space. The measure here isn’t how many growing companies that started with no-code adopt code as they grow. The measure here is how many growing companies that started with no-code wouldn’t have been started otherwise.
EricE 6y ago
"I notice, though, that your examples are not from programming at all. Your examples are about users of devices. " Just to level set - as a program manager when I engage with programmers it's not because I want to buy programmers. I want the fruits of their labors. Let me put it another way - programmers love to bemoan the way users abuse Excel. Users abuse Excel because it meets their needs best, given all other factors in their environments. If things like no code environments progress where they can provide at a minimum the level of functionality Excel can for many tasks then it will take off. No, it won't be "all of programming" but enough to be a paradigm shif? You betcha.
- AnimalMuppet 6y ago
  OK, take Excel. It provided a way for a lot of non-programmers, who didn't want to become programmers, to program enough to get their work done. And that's great! But if you look at a graph of the number of people employed as programmers, and you look for the point where that number started to decline because Excel made them unnecessary, well, you don't find it. Excel made simpler stuff available for simpler problems, but it didn't address bigger problems, and there were plenty of bigger problems to go around. And when we talk about fundamentally improving programming, we aren't talking about improving it for those trying to solve Excel-level problems. (That's still worth doing! It's just not what we're talking about.) So if you can create a new Excel for some area, it will take off. And that's great, for the people who can use it. It won't be all of programming, but it will be a paradigm shift for those who use it. Will that be a paradigm shift for all of programming? Depends on how many people use it. My bet would be that there is no Excel-like shift (or no-code shift) in, say, the next 20 years, that will affect even 30% of what we currently recognize as programmers. (If you introduce a great no-code thing, and 10% of current programmers shift to use it, and a ton of newcomers join them, that still only counts as 10% by my metric, in the same way that we don't really count Excel jockeys as professional programmers.)

miki123211 6y ago

I think the next paradigm shift in programming is the shift from local to cloud IDEs. I see a lot of backlash against that idea these days, but it seems inevitable. I don't think we can predict the full consequences of that, but one I see already is massively lowering friction. If the cloud knows how to run your code anyway, there's no reason why the fork button couldn't immediately spin up a dev environment. No Docker, no hunting for dependencies, just one click, and you have the thing running. The next generation of programmers (mostly young teenagers at this point) is often using repl.it apparently, and building cool stuff with it. This is definitely promising for this approach, as the old generation will pass away eventually.