So, is that like a Python or D commitment to stability, or a C/C++ level commitment to stability? Exactly how committed are they to preserving to preserving backwards compatibility through hell and high water? Because that's why people trust C/C++ - they know that the language committees are not going to suddenly "fix" the language by making billions of lines of code obsolete, simply because it was written fifteen years ago before a bunch of new shiny features have been added.
I think widespread adoption is going to remain limited until it becomes clear how Mozilla plans to shepherd and develop this language as well. Will it become standardized? Will mature cross-platform tools become available? What will the performance penalties be to optimized C or C++ code?
I wish Rust all the best. It's going to be difficult to unseat C/C++ simply due to inertia, as well as convincing programmers of the merits of an entirely new language, but I like the idea of a memory-safe language that doesn't require a runtime or use managed memory.
A lot of people besides you also call C++'s backward compatibility "baggage", but it's unwavering backwards compatibility both with itself and with C (mostly) are one of the cornerstones of it's success and longevity, at least in my opinion. Maintaining strict compatibility, even though sometimes ugly, is one of the smartest thing the C++ committee has done.
When a language breaks compatibility, it tends to split the developer community (e.g. Python 2 vs Python 3), since people or organizations then have to decide whether a costly upgrade or rewrite is worthwhile. With C++, we can rest assured that even older C and C++ projects will continue to compile with modern compilers just fine, and we can move ahead with improved, modernized code at our leisure. This assurance of backwards compatibility gives confidence when in investing many millions of dollars in a code project.
Sure, backward compatibility definitely comes with downsides, such as the difficulty in creating effective tooling for C++ source code or slow compile/link speeds, but I have to laugh when people suggest breaking compatibility or switching languages as a serious alternative. When you're working with projects that have hundreds of thousands or even millions of lines of code, you don't just rewrite that stuff at the drop of a hat.
C++ isn't about productivity. It's really about performance. If your application isn't performance-critical, you probably don't have a good reason to be using C++. And actually, nowadays it's a lot easier to write much safer C++ than previously, especially with recent changes to the language. Overall, the language is a pretty good tradeoff between performance, productivity, and safety, with emphasis on the performance, of course. I'd imagine that's why game developers use C++ almost exclusively, at least for larger AAA games.
On the other hand, game development tools are often written in languages such as C# (plus a mix of various other languages), because productivity is typically more important than performance for those types of applications (after all, you can just buy faster machines for your developers).
So... why not write games / game engines in Rust, D, or some other arguably "better" language?
Simple answer: inertia. Because there's an entire industry's worth of game developers who know C++ extensively (like myself). Our libraries and game engines are all in C++, and are battle-hardened and well-optimized. Who wants to rewrite all of that? Sample code is in C++. Libraries are C or C++. Etc, etc. C++ is often derided for it's flaws, but it's a language that actually gets *used*, and like it or not, being reasonably popular as a language is also a merit. It means that every major platform for which you might want to port a game has a modern C++ compiler and C libraries to link against, and mature debugging development and debugging tools.
It's kind of a crappy chicken-and-egg problem for new languages to go up against, but that's the reality.
Really? Everything I dug up during research said you pretty much had to interop with Objective-C, since Swift classes are exported as Objective-C classes. I'm not doubting you, as I'm sure there's some horribly ugly way to do it, given that we're talking about C here.
Still, for my purposes, it doesn't really matter that much. I'd still prefer a "clean" interop, since I'll be doing a lot of that.
Speaking of C++... I'm currently learning Objective-C rather than Swift. Why? Because all I want is a thin interop layer between my cross-platform C++ code (the bulk of my game engine and game code) and the operating system APIs. Objective-C can iterop with C or C++ fairly easily, while Swift can only interop with Objective-C.
Frankly, I wish I could use Swift instead of Objective-C, whose syntax takes some real getting used to.
When I mentioned "entertainment platform", I was just talking about videogames or other forms of entertainment you'd find on a standalone PC, not a PC acting as a media center. I probably should have been more specific.
Honestly, I've never considered PCs a good fit in the living room. As far as I can tell, people who set up their own media or entertainment PCs connected to a TV have always been in the "enthusiast" camp, and probably are a fairly small minority. It's far easier nowadays to just subscribe to Netflix and stream to your TV or console or set top box than to set up a PC as a media device.
So, I totally agree with you there. The living room will likely remain the domain of purpose-built hardware for the foreseeable future.
You know what's going to happen of course, right? The official name will get completely ignored, and 99% of the world will know it by it's unique, catchy, culturally-insensitive and politically incorrect common name. Like it or not, someone will come up with a much catchier name for the disease in question, and the media will pick up on it, and it will unofficially be known by that name forevermore.
Language is hard to corral by rules, as anyone who rages against slang words being added to the dictionary well knows.
I happen to make videogames for a living, so I'm keeping a pretty close watch, thank you. PCs are still very much a factor in gaming largely thanks to MMOs, MOBAs, some die-hard industry hold-outs, and a gazillion indie and retro titles. Steam, GoG, and Origin are still going strong as the industry shifts to downloadable titles en masse. The PC is no longer the dominant gaming platform across the board, of course, but the death of PC gaming has been predicted every year for the last decade or so. It's getting old.
Do you remember how everyone was predicting the death of the videogame console near the end of the last generation of consoles, right when smartphone games were seemingly all the rage? It was equally rubbish. We now know that it didn't replace an existing market, but instead opened up a new one. People can't seem to understand the simple concept that some form factors work better for some types of applications than others.
I just recently saw a tragic story in the local news about a father who accidentally ran over and killed his own toddler while backing out of his driveway. That's probably one life that would have been saved and a family spared a tragedy had the vehicle been autonomous - or even had autonomous emergency braking.
Whenever I see these ridiculously improbably scenarios about a computer having to choose x or y, I have to remind people that everyday sorts of accidents (which typically involve mistakes in human judgement or limited perception) are far more likely to occur than these hypothetical scenarios. For the first generation of autonomous vehicles, there's no reason to have to make them 100% autonomous anyhow. Just alert the driver when they have to take control in the rare cases the computer can't figure out what to do, such as when being directed by a policeman.
If Microsoft is releasing "backwards-incompatible" changes to Windows 10 (probably meaning new APIs and features are available), then presumably Windows 10 users will be able to upgrade and patch their systems. This isn't completely unprecedented. For many years, if software was compatible with Windows XP at all, it was generally "XP Service Pack 2 or later". Windows 10 will probably be the same way. For better or worse, if you want to run modern software, you'll likely need to keep your system up to date, which will ensure you have the latest patches and any new APIs (like new versions of.NET, etc).
I don't see a corporate user typically wanting to use a 2016 version of Windows 10 in 2017, as this would also imply their OS is a year behind in security patches as well. Why would they not want to patch up their system? Corporations would only do that if there were some breaking issue in a patch, and MS tends to fix those reasonably quickly on the rare occasion they happen. Moreover, if the software was written before the point when they froze the image, it's guaranteed to be compatible. For new software written after that, it would only be incompatible if the the software made use of new APIs released in 2017. Stuff like that doesn't generally happen accidentally.
I suppose the big assumption I'm making is that there aren't going to be any radical internal changes going forward (like new driver models in Vista) that would cause incompatibility problems, or upgrades that would significantly increase the baseline hardware requirements, not at least while calling it "Windows 10", which hasn't been the trend since Vista anyhow. If they DO, then they'll have to start identifying those release points in some other fashion.
Of course, this is all speculation until we get a clearer picture of what Microsoft's strategy is with Windows 10 and how it works in practice. Honestly, though, I can't think of how this would be really hard to manage in practice. I guess we'll have to see.
Partially correct. However, don't forget the viability of the PC as an entertainment platform. A PC has a form-factor that makes it optimal for many types of games that no other form factor can really match. And people who create any sort of digital content, whether it's professional or a hobby, will probably want a PC at home for the task. Plugging a tablet into a docking station doesn't necessarily make it a PC-like system suitable for anything but the simplest content creation tasks.
I think what's more appropriate to say is that a PC won't be *required* in the home for people to use e-mail, Facebook, and light consumption-based tasks. For casual users or non-tech types, a tablet will be just fine. However, I still think many people will still choose to have a PC in the home for some time to come simply because of their sheer versatility.
Is anyone actually confused that you might be talking about Android when you say "Linux"? I really doubt it. I'm not going to call Linux "GNU/Linux", and neither are most people, because it's just too damned awkward. There's already enough confusion among many non-tech people about the distinction between Linux the kernel and the myriad Linux-based distributions.
Anyhow, I tend to disagree with Stallman 9 times out of 10, but I don't have any problems giving him props for what he's done and what he believes in. He's certainly been consistent in his message at least.
Well, when people talk about "Android" they tend to call it "Android", not "Linux". I'm pretty sure we're talking about PCs in this context, and since we need GPUs, that typically means desktop systems, not headless servers.
Maybe because it's a yawner of a story if Windows gets infected? Everyone sort of expects Windows to be infected with whatever new malware comes along first. Or maybe it's just that the researchers use Linux, so it's more of a "what you know" thing.
You're right though... No criminal would be stupid enough to release malware for an OS that commands 1.5% of the desktop market share. Real attacks against Linux would much more likely be against the LAMP stack or other server-related services.
Maybe that could account for a few cases, but there were other issues at least some researchers didn't think would be solved so quickly either. In the link I provided (unfortunately, the original article isn't found, just the summary), a researcher in 2002 was claiming that CMOS would end up at 45 nm and halt there because of the issues with thermal noise. I also remember these types of predictions being made by researches at Intel as well.
Look, I'll I'm saying is that *every* time so far the prediction was made, it's turned out that manufacturers figured out how to push the envelop a little further. Eventually, it's got to end at some point, but so far the scientists and researchers manage to surprise us each time. It's hard to predict when or how the next breakthrough will occur, because by nature, it's something that no one has though of yet.
Well he might be following Uncle Bob's Clean Code concepts and not filling his code with comments that could become crufty and misleading over time.
I've never bought that argument. Comments simply need to be properly maintained along with the code. If you're not updating the comments when you change the code, you're doing a half-assed job.
Besides, my take is that comments are generally most useful when they explain *what* you're attempt to do rather than *how* exactly you're doing it, and that tends to change far less frequently. The only exception to that general rule is when the code is particularly complex or tricky, and at that point, you should be writing comments in paragraphs.
Interesting, thanks for the response. I suppose it makes some amount of sense, because for every possible chip out there, it generally has a C/C++ compiler that supports it. And it's not surprising that you'd tend to find a lot more people well-versed in C or C++.
C++ gets a lot of hate (some deserved, some not), but you can actually use it in such a way that makes it very difficult for programmers to make silly mistakes like clobbering raw memory, and all in a way that requires little or no overhead beyond equivalent C code. I think that's part of why it's so popular in game development (my particular field).
And as you indicated, an effective strategy is to find a subset of the language that works well for your project and stick to that.
You don't need a "friend" inside Microsoft to actually try out the beta, you know. Anyone can sign up, download it, and use it. Millions of people are using it right now, and we've heard NOTHING about such stability problems. Buy all the popcorn you like. Windows 10 may have it's faults, but instability is not going to be one of them.
In the current Windows 10 beta, the only option you appear to have under the setting Choose How Updates Are Installed is "Automatic" and "Notify to schedule restart". It appears you have no choice but to get the patches as they're released, with the only exception being if you indicate you're on a metered connection (possibly useful loophole there).
I'll admit, I was a bit surprised by this as well. I understand the logic of pushing patches out as soon as they're ready to home users. "Patch Tuesday" was done entirely for the convenience of corporate users, not home users, but it has the downside of potentially delaying critical patches for many weeks that could otherwise be deployed much sooner. Even so, I'd prefer to see an option to allow home users to actually *install* the patches at their own leisure like with previous versions of Windows.
Question: is some other language actually replacing Ada for aerospace, DoD projects, and other mission-critical type projects, or is it you just don't want to work on those projects anymore?
I was under the impression that Ada is still widely used in many mission-critical systems. For example, the latest Boeing planes' software (777 and 787) is nearly all written in Ada. I haven't heard about another language making inroads in those applications, but I suppose it's possible. More likely IMO is that the relative percentage of mission-critical software has shrunk compared to the explosion of commercial software.
Keep in mind language "popularity" is very industry-specific, so it's often a bit misleading to look at global rankings of language popularity. For example, in my own industry (videogames), C++ is completely dominant for game code, C# is very popular for tools, and Lua is popular as an embedded scripting language. If you look at Lua on it's own, it typically ranks pretty low compared to most languages, but there's no doubt it would be much higher if constrained to just my industry.
Slashdot Mirror
So, is that like a Python or D commitment to stability, or a C/C++ level commitment to stability? Exactly how committed are they to preserving to preserving backwards compatibility through hell and high water? Because that's why people trust C/C++ - they know that the language committees are not going to suddenly "fix" the language by making billions of lines of code obsolete, simply because it was written fifteen years ago before a bunch of new shiny features have been added.
I think widespread adoption is going to remain limited until it becomes clear how Mozilla plans to shepherd and develop this language as well. Will it become standardized? Will mature cross-platform tools become available? What will the performance penalties be to optimized C or C++ code?
I wish Rust all the best. It's going to be difficult to unseat C/C++ simply due to inertia, as well as convincing programmers of the merits of an entirely new language, but I like the idea of a memory-safe language that doesn't require a runtime or use managed memory.
A lot of people besides you also call C++'s backward compatibility "baggage", but it's unwavering backwards compatibility both with itself and with C (mostly) are one of the cornerstones of it's success and longevity, at least in my opinion. Maintaining strict compatibility, even though sometimes ugly, is one of the smartest thing the C++ committee has done.
When a language breaks compatibility, it tends to split the developer community (e.g. Python 2 vs Python 3), since people or organizations then have to decide whether a costly upgrade or rewrite is worthwhile. With C++, we can rest assured that even older C and C++ projects will continue to compile with modern compilers just fine, and we can move ahead with improved, modernized code at our leisure. This assurance of backwards compatibility gives confidence when in investing many millions of dollars in a code project.
Sure, backward compatibility definitely comes with downsides, such as the difficulty in creating effective tooling for C++ source code or slow compile/link speeds, but I have to laugh when people suggest breaking compatibility or switching languages as a serious alternative. When you're working with projects that have hundreds of thousands or even millions of lines of code, you don't just rewrite that stuff at the drop of a hat.
How to avoid the tech support script runaround? The code word is "Shibboleet."
C++ isn't about productivity. It's really about performance. If your application isn't performance-critical, you probably don't have a good reason to be using C++. And actually, nowadays it's a lot easier to write much safer C++ than previously, especially with recent changes to the language. Overall, the language is a pretty good tradeoff between performance, productivity, and safety, with emphasis on the performance, of course. I'd imagine that's why game developers use C++ almost exclusively, at least for larger AAA games.
On the other hand, game development tools are often written in languages such as C# (plus a mix of various other languages), because productivity is typically more important than performance for those types of applications (after all, you can just buy faster machines for your developers).
So... why not write games / game engines in Rust, D, or some other arguably "better" language?
Simple answer: inertia. Because there's an entire industry's worth of game developers who know C++ extensively (like myself). Our libraries and game engines are all in C++, and are battle-hardened and well-optimized. Who wants to rewrite all of that? Sample code is in C++. Libraries are C or C++. Etc, etc. C++ is often derided for it's flaws, but it's a language that actually gets *used*, and like it or not, being reasonably popular as a language is also a merit. It means that every major platform for which you might want to port a game has a modern C++ compiler and C libraries to link against, and mature debugging development and debugging tools.
It's kind of a crappy chicken-and-egg problem for new languages to go up against, but that's the reality.
Really? Everything I dug up during research said you pretty much had to interop with Objective-C, since Swift classes are exported as Objective-C classes. I'm not doubting you, as I'm sure there's some horribly ugly way to do it, given that we're talking about C here.
Still, for my purposes, it doesn't really matter that much. I'd still prefer a "clean" interop, since I'll be doing a lot of that.
Speaking of C++... I'm currently learning Objective-C rather than Swift. Why? Because all I want is a thin interop layer between my cross-platform C++ code (the bulk of my game engine and game code) and the operating system APIs. Objective-C can iterop with C or C++ fairly easily, while Swift can only interop with Objective-C.
Frankly, I wish I could use Swift instead of Objective-C, whose syntax takes some real getting used to.
When I mentioned "entertainment platform", I was just talking about videogames or other forms of entertainment you'd find on a standalone PC, not a PC acting as a media center. I probably should have been more specific.
Honestly, I've never considered PCs a good fit in the living room. As far as I can tell, people who set up their own media or entertainment PCs connected to a TV have always been in the "enthusiast" camp, and probably are a fairly small minority. It's far easier nowadays to just subscribe to Netflix and stream to your TV or console or set top box than to set up a PC as a media device.
So, I totally agree with you there. The living room will likely remain the domain of purpose-built hardware for the foreseeable future.
You know what's going to happen of course, right? The official name will get completely ignored, and 99% of the world will know it by it's unique, catchy, culturally-insensitive and politically incorrect common name. Like it or not, someone will come up with a much catchier name for the disease in question, and the media will pick up on it, and it will unofficially be known by that name forevermore.
Language is hard to corral by rules, as anyone who rages against slang words being added to the dictionary well knows.
I happen to make videogames for a living, so I'm keeping a pretty close watch, thank you. PCs are still very much a factor in gaming largely thanks to MMOs, MOBAs, some die-hard industry hold-outs, and a gazillion indie and retro titles. Steam, GoG, and Origin are still going strong as the industry shifts to downloadable titles en masse. The PC is no longer the dominant gaming platform across the board, of course, but the death of PC gaming has been predicted every year for the last decade or so. It's getting old.
Do you remember how everyone was predicting the death of the videogame console near the end of the last generation of consoles, right when smartphone games were seemingly all the rage? It was equally rubbish. We now know that it didn't replace an existing market, but instead opened up a new one. People can't seem to understand the simple concept that some form factors work better for some types of applications than others.
I just recently saw a tragic story in the local news about a father who accidentally ran over and killed his own toddler while backing out of his driveway. That's probably one life that would have been saved and a family spared a tragedy had the vehicle been autonomous - or even had autonomous emergency braking.
Whenever I see these ridiculously improbably scenarios about a computer having to choose x or y, I have to remind people that everyday sorts of accidents (which typically involve mistakes in human judgement or limited perception) are far more likely to occur than these hypothetical scenarios. For the first generation of autonomous vehicles, there's no reason to have to make them 100% autonomous anyhow. Just alert the driver when they have to take control in the rare cases the computer can't figure out what to do, such as when being directed by a policeman.
Let's not let perfect be the enemy of good.
If Microsoft is releasing "backwards-incompatible" changes to Windows 10 (probably meaning new APIs and features are available), then presumably Windows 10 users will be able to upgrade and patch their systems. This isn't completely unprecedented. For many years, if software was compatible with Windows XP at all, it was generally "XP Service Pack 2 or later". Windows 10 will probably be the same way. For better or worse, if you want to run modern software, you'll likely need to keep your system up to date, which will ensure you have the latest patches and any new APIs (like new versions of .NET, etc).
I don't see a corporate user typically wanting to use a 2016 version of Windows 10 in 2017, as this would also imply their OS is a year behind in security patches as well. Why would they not want to patch up their system? Corporations would only do that if there were some breaking issue in a patch, and MS tends to fix those reasonably quickly on the rare occasion they happen. Moreover, if the software was written before the point when they froze the image, it's guaranteed to be compatible. For new software written after that, it would only be incompatible if the the software made use of new APIs released in 2017. Stuff like that doesn't generally happen accidentally.
I suppose the big assumption I'm making is that there aren't going to be any radical internal changes going forward (like new driver models in Vista) that would cause incompatibility problems, or upgrades that would significantly increase the baseline hardware requirements, not at least while calling it "Windows 10", which hasn't been the trend since Vista anyhow. If they DO, then they'll have to start identifying those release points in some other fashion.
Of course, this is all speculation until we get a clearer picture of what Microsoft's strategy is with Windows 10 and how it works in practice. Honestly, though, I can't think of how this would be really hard to manage in practice. I guess we'll have to see.
The desktop is going away in the home.
Partially correct. However, don't forget the viability of the PC as an entertainment platform. A PC has a form-factor that makes it optimal for many types of games that no other form factor can really match. And people who create any sort of digital content, whether it's professional or a hobby, will probably want a PC at home for the task. Plugging a tablet into a docking station doesn't necessarily make it a PC-like system suitable for anything but the simplest content creation tasks.
I think what's more appropriate to say is that a PC won't be *required* in the home for people to use e-mail, Facebook, and light consumption-based tasks. For casual users or non-tech types, a tablet will be just fine. However, I still think many people will still choose to have a PC in the home for some time to come simply because of their sheer versatility.
Is anyone actually confused that you might be talking about Android when you say "Linux"? I really doubt it. I'm not going to call Linux "GNU/Linux", and neither are most people, because it's just too damned awkward. There's already enough confusion among many non-tech people about the distinction between Linux the kernel and the myriad Linux-based distributions.
Anyhow, I tend to disagree with Stallman 9 times out of 10, but I don't have any problems giving him props for what he's done and what he believes in. He's certainly been consistent in his message at least.
Well, when people talk about "Android" they tend to call it "Android", not "Linux". I'm pretty sure we're talking about PCs in this context, and since we need GPUs, that typically means desktop systems, not headless servers.
Maybe because it's a yawner of a story if Windows gets infected? Everyone sort of expects Windows to be infected with whatever new malware comes along first. Or maybe it's just that the researchers use Linux, so it's more of a "what you know" thing.
You're right though... No criminal would be stupid enough to release malware for an OS that commands 1.5% of the desktop market share. Real attacks against Linux would much more likely be against the LAMP stack or other server-related services.
Did you say "yute"? What is a "yute"?
Maybe that could account for a few cases, but there were other issues at least some researchers didn't think would be solved so quickly either. In the link I provided (unfortunately, the original article isn't found, just the summary), a researcher in 2002 was claiming that CMOS would end up at 45 nm and halt there because of the issues with thermal noise. I also remember these types of predictions being made by researches at Intel as well.
Look, I'll I'm saying is that *every* time so far the prediction was made, it's turned out that manufacturers figured out how to push the envelop a little further. Eventually, it's got to end at some point, but so far the scientists and researchers manage to surprise us each time. It's hard to predict when or how the next breakthrough will occur, because by nature, it's something that no one has though of yet.
Pundits have been saying that at least since 90nm, you know. Then 65, and again at 45, 32, 33, and now at 14.
...until they get their personal data stolen because of a security flaw in the OS, which of course was long patched in later version of Android.
Well he might be following Uncle Bob's Clean Code concepts and not filling his code with comments that could become crufty and misleading over time.
I've never bought that argument. Comments simply need to be properly maintained along with the code. If you're not updating the comments when you change the code, you're doing a half-assed job.
Besides, my take is that comments are generally most useful when they explain *what* you're attempt to do rather than *how* exactly you're doing it, and that tends to change far less frequently. The only exception to that general rule is when the code is particularly complex or tricky, and at that point, you should be writing comments in paragraphs.
Interesting, thanks for the response. I suppose it makes some amount of sense, because for every possible chip out there, it generally has a C/C++ compiler that supports it. And it's not surprising that you'd tend to find a lot more people well-versed in C or C++.
C++ gets a lot of hate (some deserved, some not), but you can actually use it in such a way that makes it very difficult for programmers to make silly mistakes like clobbering raw memory, and all in a way that requires little or no overhead beyond equivalent C code. I think that's part of why it's so popular in game development (my particular field).
And as you indicated, an effective strategy is to find a subset of the language that works well for your project and stick to that.
You don't need a "friend" inside Microsoft to actually try out the beta, you know. Anyone can sign up, download it, and use it. Millions of people are using it right now, and we've heard NOTHING about such stability problems. Buy all the popcorn you like. Windows 10 may have it's faults, but instability is not going to be one of them.
In the current Windows 10 beta, the only option you appear to have under the setting Choose How Updates Are Installed is "Automatic" and "Notify to schedule restart". It appears you have no choice but to get the patches as they're released, with the only exception being if you indicate you're on a metered connection (possibly useful loophole there).
I'll admit, I was a bit surprised by this as well. I understand the logic of pushing patches out as soon as they're ready to home users. "Patch Tuesday" was done entirely for the convenience of corporate users, not home users, but it has the downside of potentially delaying critical patches for many weeks that could otherwise be deployed much sooner. Even so, I'd prefer to see an option to allow home users to actually *install* the patches at their own leisure like with previous versions of Windows.
Question: is some other language actually replacing Ada for aerospace, DoD projects, and other mission-critical type projects, or is it you just don't want to work on those projects anymore?
I was under the impression that Ada is still widely used in many mission-critical systems. For example, the latest Boeing planes' software (777 and 787) is nearly all written in Ada. I haven't heard about another language making inroads in those applications, but I suppose it's possible. More likely IMO is that the relative percentage of mission-critical software has shrunk compared to the explosion of commercial software.
Keep in mind language "popularity" is very industry-specific, so it's often a bit misleading to look at global rankings of language popularity. For example, in my own industry (videogames), C++ is completely dominant for game code, C# is very popular for tools, and Lua is popular as an embedded scripting language. If you look at Lua on it's own, it typically ranks pretty low compared to most languages, but there's no doubt it would be much higher if constrained to just my industry.