Yes, fine, I wasn't specific enough. The texts in question describe how to construct such queries using tainted data. Happy?
And, frankly, as an IT security professional I'm not satisfied with sanitization in this case. Sanitization tends to be fragile and more complicated than non-experts think, so it often fails to cover all cases. While it can be useful for defense in depth (particularly with whitelisting; whitelisting valid input patterns and rejecting everything else is far safer than approaches that rely on escaping), it's a poor approach to preventing injection. There's really no excuse for it, except when the vulnerable code is inaccessible - e.g. in a third-party binary that's no longer supported but can't be retired.
All database operations should use parameterized queries or stored procedures (and the stored procs should not be assembling unsafe queries either, of course). And they should be in a DAL, not mixed in with business or presentation logic. The textbooks I'm referring to utterly fail at separation of concerns, too.
functional programming is probably close to 50 years old
It was 50 years old nine years ago.
That's assuming you count from when a programming language with explicit functional constructs was introduced. Conceptually it goes back at least to lambda calculus.
But certainly you're correct that the promotion of functional programming is not new. The earliest example that comes to my mind is Friedman's The Little Lisper, and that was published in 1974 (and is still in print). That's the first widely-circulated text I can think of that embodied the idea that functional programming is a different paradigm (though I don't think Friedman used that word) from procedural programming.
So the bandwagon has been rolling for around 43 years.
The underlying problem is that too many programmers are willing to copy and paste code rather than think through what they need to code.
That's a problem; it is not the problem. Addressing it is necessary but nowhere near sufficient.
The simple fact is that a very experienced, knowledgeable, and thoughtful developer who's simply not familiar with, say, XSS or CSRF vulnerabilities, could read, understand, and implement ideas from a tutorial that is susceptible to and fails to cover them. No amount of "think[ing] through" is going to solve that.
It's not reasonable to expect people who haven't put considerable effort into identifying protocol vulnerabilities to rediscover XSS and CSRF. And the same goes for most other aspects of software security. At some point, even thoughtful developers will have to believe some of what they read.
Yes. And not just you-get-what-you-pay-for free online tutorials, either. I've seen more than one programming textbook (including for this very case - PHP applications with a MySQL database) that describe in loving detail how to construct ad hoc SQL queries using string concatenation and interpolation, say.
And on the output side, show interpolating user-controlled, unsanitized data from the database directly into the HTML output stream. Maybe there's a half-assed throwaway attempt at anti-XSS, at best.
These textbooks may have gotten better in recent years (it's been a few since I gave up on them), but of course students will often pick up used copies of old editions.
Now, I'll be the first to admit that we have a structural problem when it comes to teaching this material to students. There are plenty of undergrad "build a web application" classes which simply do not have time to deal with security in any reasonable way. That's a curriculum-development and academic-program-development issue, and it's not easy to solve. (You could easily spend most of the semester going over the OWASP Top 10+2 in an undergrad course.) But there's a ton of bad information out there.
I'm not a Tesla fan,[1] but it's true that they do at least make something, and they sell it, and they have assets. That's more than you can say for most Valley startups.
Whether they'll survive remains to be seen, of course. However sluggish and burdened their competitors are, they are also powerful and they have deep pockets.
[1] EVs don't meet my automotive needs, and I hate all the gadgets. And as a dedicated curmudgeon I hate anything popular, of course.
"Shackles"? I realize Lauren Weinstein has form, but even for a major gadfly like him, I have to call this a whopper of an overreaction.
Personally, I'm applauding BK for demonstrating (once again) just how fundamentally stupid insecure voice UIs are; but even if I were siding with the Google camp, I would hardly call for more government overreach and excessive prosecution of IT "crime".
"Internet Responsibility" cuts both ways, L.W. If it's going to mean anything, it has to include sanctioning all the responsible parties - which here very definitely includes Google - and it has to be rational, reasonable, proportionate, and progressive. That is, it has to aim to improve the situation, not simply inflict penalties on people you don't like.
Sigh. If their marketing team is at all competent, they'd love it. It would get them free press for weeks.
Some of you people really do not understand how this works. Oppositional marketing is all about creating controversy so other people circulate your name for you. It doesn't matter whether the message is positive, because the goal is to fire up your base. People who already like Burger King (presumably they're out there; BK continues to be in business) are inclined to take BK's side, and trying to associate them with something unpalatable will just cause their fans to dig in. You'd probably push BK sales up measurably.
Agreed. I, too, have been around for a while - professional developer since '88, and working with distributed applications and security since the early '90s. I find ewhac's arguments utterly unpersuasive. Criminal and civil penalties have done nothing to curb exploitation of IT security vulnerabilities.
Personally, I still hold out some hope that regulating manufacturers, and holding them liable, might help; but that's just an inducement to improve technological solutions (by converting security externalities into costs for the manufacturer).
Punishing BK - and as far as I can see, they did nothing ethically wrong, and the legal question is far from settled - achieves nothing in the long run. Or even in the short one.
I imagine the ad agency that orchestrated this campaign anticipated this - I certainly hope they did - and counted on it. Anyone who doesn't understand counter-message marketing doesn't deserve to be in the industry today.
Seriously, read Ryan Holiday's book. Wikipedia vandalism, like other reactions, play right into BK's hands. Protest is promotion.
I don't know about "laughing out loud", but there's certainly a healthy dose of schadenfreude.
When voice-activated interfaces started to get a lot of attention - say, in the mid-1990s with OS/2 Warp, or even earlier - many, many people pointed out that they were a Bad Idea. People continued to point that out, over and over and over, in the years since.
I think what BK did is a lovely thing. I applaud them for it, and I may even buy one of their burgers one of these days. The whining from folks like ewhac gets no sympathy from me.
I didn't say no one should have a gun, I said that I would advise against it
From your original post:
No one *needs* a gun in the US
"I would advise against it" is rather a gloss for "[n]o one needs". For that matter, "not a large portion of the population" is a rather different thing from "no one".
The simple fact of the matter is that your original statement was wrong. It wasn't ambiguous or poorly phrased; it was factually incorrect.
I'm not a gun owner myself, despite having a home in a rural area where critters can indeed be a problem. Guns are tools, and like most tools they're dangerous, and I prefer to hold off on acquiring, much less using, dangerous tools until I decide they're justified by my circumstances. I haven't reached that point with guns yet. (Bears are rare on my side of the mountain, and I have neighbors close by.) But that doesn't prevent me from assessing the need for guns properly and avoiding insupportable generalizations.
Agreed, which is why I now use a hands-free voice activated vim app. "f open-paren a i d x comma space colon n no wait damn it backspace backspace escape colon n enter..."
Also we still get in a lot of collisions, but fatalities are down thanks to seat belts, child car seats, collision testing, air bags, faster emergency response, frozen blood plasma, etc.
This is an excellent point. Fatalities are an important metric, but they are certainly not the whole story. Even injury-free collisions can cause tremendous difficulty for someone.
It's good that fatalities are down. It's bad that so many drivers are behaving foolishly. Those two facts can both be true.
kids in Wyoming need to carry rifles to school to shoot grizzly bears
I don't have any evidence for that, but sure, there are plenty of people in the US who need to defend themselves from critters of various sorts. There was a case a few years back, not so terribly far from my place in New Mexico, where a woman shot a bear that had broken into her house. And it's not just bears; if there's a rabid dog wandering about the property, it's best to address that from a little distance.
So, yeah, OP doesn't know what he's talking about. While the number of people in the US with a demonstrable need for firearms is small relative to the total population, it's not negligible. And that's regardless of whether you make any allowance for defense against other human beings (an application I am dubious about myself, except in the case of people in certain lines of work).
Betsy DuVos
DeVos. I know, it would have taken precious seconds to look that the fuck up.
And what about DeVos? She's a shill for the kickback-rich charter-school system. She doesn't know dick about education, and I doubt she knows anything significant about what kids in Wyoming need. That branch of the DeVos family is good at one thing: filling their own pockets.
Fuck you stupid people.
... writes AC who can't be bothered to formulate a coherent statement or look up the correct spelling of someone's name. This is why we can't have nice arguments.
In new cars, pretty much everything above the very bottom of the line is a usability nightmare.
This is one of the reasons my most recent car is a 2015 Volvo. The infotainment system has a screen, but it's not a touchscreen, and most of the functions are manipulated using separate physical controls. I pretty much never have to look at it while driving. I don't know if Volvo has caved into the touchscreen mania - in another decade or so I may be stuck with classic cars.
The people responsible for putting touchscreen controls in cars should be deeply ashamed. Ditto idiotic all-eggs-in-one-basket physical controls like the much-hated BMW iDrive.
Re TFA, I'm surprised that 90% of drivers own a smartphone. In the US, in 2015, there were around 218M drivers and 189M smartphone owners, so presumably some of the drivers shared a smartphone and passed it on to whoever was behind the wheel.
The only real farming left in the US are large industrial farms.
That will come as a shock to all the family farmers near my home in Michigan, who supply much of the food my wife and I eat.
And to all the family farmers near my vacation home in New Mexico, who supply much of the food my wife and I eat on vacation.
I'm pretty sure they think they're real. And their food has a certain... ontological robustness, shall we say. A material reliability. An utter lack of being imaginary.
COBOL has far fewer features than any modern language
That's a rather odd claim. Even COBOL-85 has a much, much longer specification than, say, C. COBOL-2002, at 879 pages, is probably longer than the Java 6 spec plus the standard Java framework docs. The core language chapters (Language Fundamentals through Intrinsic Functions) is nearly 600 pages. There are close to 400 reserved words.
And if you take a really modern COBOL dialect, with OO features and enhanced syntax, plus the preprocessors that are commonly used... well, it's a lot bigger. And it has most of the features of most of the major "modern" languages, functional-programming constructs being the biggest omission.
It's not just the COBOL language you have to learn, you also have to know JCL (Job Control Language) CICS (Customer Information Control System) and SQL (Structured Query Language) - most programmers will already know SQL - but you are going to have to deal with the little quirks of DB2 sql.
There are many COBOL applications which 1) are not run under JES; 2) do not run in CICS; and 3) don't use DB2.
Certainly all three of those things are common in COBOL applications, but they are hardly universal.
Indeed, while our mainframe offload dev/test business and our mainframe emulation business are both quite healthy, we also sell a lot of COBOL development to people who are building COBOL apps for native Windows, Linux, and UNIX, and a growing number of customers are building JVM or CLR (.NET) COBOL applications. Their concerns are more likely to be things like web front ends and invoking web services, and for the managed-code COBOL folks using the OO syntax correctly.
Embedded SQL is still big, but we probably see about as much Oracle and SQL Server as we do DB2.
Why don't they automatically translate them to something more modern then run them in the cloud?
That COBOL source can be compiled to CLR IL or JVM bytecode, if you want "something more modern". Such a translator is already available; it's called a "compiler".
And as native or managed code, there's nothing to stop you "run[ning] in the cloud". Why would you think there was?
Perhaps not many organizations do it because there's no reason to do so.
COBOL doesn't and shouldn't give a shit about drop downs, java, PDFs and all that other bullshit
Don't tell that to the application developers. A majority of the queries we get on the MF Community COBOL forums are for GUI issues. PDF output is a popular topic too. And COBOL for JVM is doing nicely, thanks.
One of the nice things about f77 and i presume cobol is that memory is allocated in a fixed way at compile time
All the major COBOL dialects have offered dynamic memory allocation for decades.
relatively speaking, its harder to find cases where typos are not also syntax errors
That's arguably true in COBOL-85 and later. Pre-85 COBOL suffers from its "sentence" syntactic construct and the use of the period (aka "full stop") punctuator as a scope delimiter. While the recommendation for the past thirty years has been to use ANSI scope delimiters (END-IF, etc) and avoid periods, there's still a huge legacy codebase using periods, and many COBOL programmers[1] still use archaic styles.
there are advantages to giving up features
These days you have nearly all the "features" anyone wants in COBOL. We've had OO COBOL for a couple of decades. Managed COBOL for CLR and JVM for over a decade. Generics? Sure. Anonymous inline delegates with closures? Yup. Type inference? In limited contexts, at least. Embedded SQL? Well, if that's your thing, then, yeah, we have that too. And mixed-case, free-format source arrived a long time ago.
Plenty of new applications being developed in COBOL these days, too. People aren't just maintaining legacy stuff.
[1] Yes, there are still many COBOL programmers. I know the news services love these "disappearing COBOL programmer" human-interest stories, but I deal with COBOL programmers at many companies and, believe me, there are a lot of them.
Slashdot Mirror
Yes, fine, I wasn't specific enough. The texts in question describe how to construct such queries using tainted data. Happy?
And, frankly, as an IT security professional I'm not satisfied with sanitization in this case. Sanitization tends to be fragile and more complicated than non-experts think, so it often fails to cover all cases. While it can be useful for defense in depth (particularly with whitelisting; whitelisting valid input patterns and rejecting everything else is far safer than approaches that rely on escaping), it's a poor approach to preventing injection. There's really no excuse for it, except when the vulnerable code is inaccessible - e.g. in a third-party binary that's no longer supported but can't be retired.
All database operations should use parameterized queries or stored procedures (and the stored procs should not be assembling unsafe queries either, of course). And they should be in a DAL, not mixed in with business or presentation logic. The textbooks I'm referring to utterly fail at separation of concerns, too.
functional programming is probably close to 50 years old
It was 50 years old nine years ago.
That's assuming you count from when a programming language with explicit functional constructs was introduced. Conceptually it goes back at least to lambda calculus.
But certainly you're correct that the promotion of functional programming is not new. The earliest example that comes to my mind is Friedman's The Little Lisper, and that was published in 1974 (and is still in print). That's the first widely-circulated text I can think of that embodied the idea that functional programming is a different paradigm (though I don't think Friedman used that word) from procedural programming.
So the bandwagon has been rolling for around 43 years.
The underlying problem is that too many programmers are willing to copy and paste code rather than think through what they need to code.
That's a problem; it is not the problem. Addressing it is necessary but nowhere near sufficient.
The simple fact is that a very experienced, knowledgeable, and thoughtful developer who's simply not familiar with, say, XSS or CSRF vulnerabilities, could read, understand, and implement ideas from a tutorial that is susceptible to and fails to cover them. No amount of "think[ing] through" is going to solve that.
It's not reasonable to expect people who haven't put considerable effort into identifying protocol vulnerabilities to rediscover XSS and CSRF. And the same goes for most other aspects of software security. At some point, even thoughtful developers will have to believe some of what they read.
Yes. And not just you-get-what-you-pay-for free online tutorials, either. I've seen more than one programming textbook (including for this very case - PHP applications with a MySQL database) that describe in loving detail how to construct ad hoc SQL queries using string concatenation and interpolation, say.
And on the output side, show interpolating user-controlled, unsanitized data from the database directly into the HTML output stream. Maybe there's a half-assed throwaway attempt at anti-XSS, at best.
These textbooks may have gotten better in recent years (it's been a few since I gave up on them), but of course students will often pick up used copies of old editions.
Now, I'll be the first to admit that we have a structural problem when it comes to teaching this material to students. There are plenty of undergrad "build a web application" classes which simply do not have time to deal with security in any reasonable way. That's a curriculum-development and academic-program-development issue, and it's not easy to solve. (You could easily spend most of the semester going over the OWASP Top 10+2 in an undergrad course.) But there's a ton of bad information out there.
Pfft. Negative Catholics have been observing Negative Mass for centuries.
(Well, to be fair, most are non-observant and only show up for Negative Easter.)
I'm not a Tesla fan,[1] but it's true that they do at least make something, and they sell it, and they have assets. That's more than you can say for most Valley startups.
Whether they'll survive remains to be seen, of course. However sluggish and burdened their competitors are, they are also powerful and they have deep pockets.
[1] EVs don't meet my automotive needs, and I hate all the gadgets. And as a dedicated curmudgeon I hate anything popular, of course.
"Shackles"? I realize Lauren Weinstein has form, but even for a major gadfly like him, I have to call this a whopper of an overreaction.
Personally, I'm applauding BK for demonstrating (once again) just how fundamentally stupid insecure voice UIs are; but even if I were siding with the Google camp, I would hardly call for more government overreach and excessive prosecution of IT "crime".
"Internet Responsibility" cuts both ways, L.W. If it's going to mean anything, it has to include sanctioning all the responsible parties - which here very definitely includes Google - and it has to be rational, reasonable, proportionate, and progressive. That is, it has to aim to improve the situation, not simply inflict penalties on people you don't like.
Sigh. If their marketing team is at all competent, they'd love it. It would get them free press for weeks.
Some of you people really do not understand how this works. Oppositional marketing is all about creating controversy so other people circulate your name for you. It doesn't matter whether the message is positive, because the goal is to fire up your base. People who already like Burger King (presumably they're out there; BK continues to be in business) are inclined to take BK's side, and trying to associate them with something unpalatable will just cause their fans to dig in. You'd probably push BK sales up measurably.
And that's still an advertisement for Burger King.
Oh, you kids, with your naive understanding of marketing.
Agreed. I, too, have been around for a while - professional developer since '88, and working with distributed applications and security since the early '90s. I find ewhac's arguments utterly unpersuasive. Criminal and civil penalties have done nothing to curb exploitation of IT security vulnerabilities.
Personally, I still hold out some hope that regulating manufacturers, and holding them liable, might help; but that's just an inducement to improve technological solutions (by converting security externalities into costs for the manufacturer).
Punishing BK - and as far as I can see, they did nothing ethically wrong, and the legal question is far from settled - achieves nothing in the long run. Or even in the short one.
Wikipedia vandalism
I imagine the ad agency that orchestrated this campaign anticipated this - I certainly hope they did - and counted on it. Anyone who doesn't understand counter-message marketing doesn't deserve to be in the industry today.
Seriously, read Ryan Holiday's book. Wikipedia vandalism, like other reactions, play right into BK's hands. Protest is promotion.
I, for one, will be laughing out loud at you.
I don't know about "laughing out loud", but there's certainly a healthy dose of schadenfreude.
When voice-activated interfaces started to get a lot of attention - say, in the mid-1990s with OS/2 Warp, or even earlier - many, many people pointed out that they were a Bad Idea. People continued to point that out, over and over and over, in the years since.
I think what BK did is a lovely thing. I applaud them for it, and I may even buy one of their burgers one of these days. The whining from folks like ewhac gets no sympathy from me.
I didn't say no one should have a gun, I said that I would advise against it
From your original post:
No one *needs* a gun in the US
"I would advise against it" is rather a gloss for "[n]o one needs". For that matter, "not a large portion of the population" is a rather different thing from "no one".
The simple fact of the matter is that your original statement was wrong. It wasn't ambiguous or poorly phrased; it was factually incorrect.
I'm not a gun owner myself, despite having a home in a rural area where critters can indeed be a problem. Guns are tools, and like most tools they're dangerous, and I prefer to hold off on acquiring, much less using, dangerous tools until I decide they're justified by my circumstances. I haven't reached that point with guns yet. (Bears are rare on my side of the mountain, and I have neighbors close by.) But that doesn't prevent me from assessing the need for guns properly and avoiding insupportable generalizations.
Agreed, which is why I now use a hands-free voice activated vim app. "f open-paren a i d x comma space colon n no wait damn it backspace backspace escape colon n enter..."
Also we still get in a lot of collisions, but fatalities are down thanks to seat belts, child car seats, collision testing, air bags, faster emergency response, frozen blood plasma, etc.
This is an excellent point. Fatalities are an important metric, but they are certainly not the whole story. Even injury-free collisions can cause tremendous difficulty for someone.
It's good that fatalities are down. It's bad that so many drivers are behaving foolishly. Those two facts can both be true.
kids in Wyoming need to carry rifles to school to shoot grizzly bears
I don't have any evidence for that, but sure, there are plenty of people in the US who need to defend themselves from critters of various sorts. There was a case a few years back, not so terribly far from my place in New Mexico, where a woman shot a bear that had broken into her house. And it's not just bears; if there's a rabid dog wandering about the property, it's best to address that from a little distance.
So, yeah, OP doesn't know what he's talking about. While the number of people in the US with a demonstrable need for firearms is small relative to the total population, it's not negligible. And that's regardless of whether you make any allowance for defense against other human beings (an application I am dubious about myself, except in the case of people in certain lines of work).
Betsy DuVos
DeVos. I know, it would have taken precious seconds to look that the fuck up.
And what about DeVos? She's a shill for the kickback-rich charter-school system. She doesn't know dick about education, and I doubt she knows anything significant about what kids in Wyoming need. That branch of the DeVos family is good at one thing: filling their own pockets.
Fuck you stupid people.
... writes AC who can't be bothered to formulate a coherent statement or look up the correct spelling of someone's name. This is why we can't have nice arguments.
In new cars, pretty much everything above the very bottom of the line is a usability nightmare.
This is one of the reasons my most recent car is a 2015 Volvo. The infotainment system has a screen, but it's not a touchscreen, and most of the functions are manipulated using separate physical controls. I pretty much never have to look at it while driving. I don't know if Volvo has caved into the touchscreen mania - in another decade or so I may be stuck with classic cars.
The people responsible for putting touchscreen controls in cars should be deeply ashamed. Ditto idiotic all-eggs-in-one-basket physical controls like the much-hated BMW iDrive.
Re TFA, I'm surprised that 90% of drivers own a smartphone. In the US, in 2015, there were around 218M drivers and 189M smartphone owners, so presumably some of the drivers shared a smartphone and passed it on to whoever was behind the wheel.
The only real farming left in the US are large industrial farms.
That will come as a shock to all the family farmers near my home in Michigan, who supply much of the food my wife and I eat.
And to all the family farmers near my vacation home in New Mexico, who supply much of the food my wife and I eat on vacation.
I'm pretty sure they think they're real. And their food has a certain ... ontological robustness, shall we say. A material reliability. An utter lack of being imaginary.
COBOL has far fewer features than any modern language
That's a rather odd claim. Even COBOL-85 has a much, much longer specification than, say, C. COBOL-2002, at 879 pages, is probably longer than the Java 6 spec plus the standard Java framework docs. The core language chapters (Language Fundamentals through Intrinsic Functions) is nearly 600 pages. There are close to 400 reserved words.
And if you take a really modern COBOL dialect, with OO features and enhanced syntax, plus the preprocessors that are commonly used ... well, it's a lot bigger. And it has most of the features of most of the major "modern" languages, functional-programming constructs being the biggest omission.
It's not just the COBOL language you have to learn, you also have to know JCL (Job Control Language) CICS (Customer Information Control System) and SQL (Structured Query Language) - most programmers will already know SQL - but you are going to have to deal with the little quirks of DB2 sql.
There are many COBOL applications which 1) are not run under JES; 2) do not run in CICS; and 3) don't use DB2.
Certainly all three of those things are common in COBOL applications, but they are hardly universal.
Indeed, while our mainframe offload dev/test business and our mainframe emulation business are both quite healthy, we also sell a lot of COBOL development to people who are building COBOL apps for native Windows, Linux, and UNIX, and a growing number of customers are building JVM or CLR (.NET) COBOL applications. Their concerns are more likely to be things like web front ends and invoking web services, and for the managed-code COBOL folks using the OO syntax correctly.
Embedded SQL is still big, but we probably see about as much Oracle and SQL Server as we do DB2.
Why don't they automatically translate them to something more modern then run them in the cloud?
That COBOL source can be compiled to CLR IL or JVM bytecode, if you want "something more modern". Such a translator is already available; it's called a "compiler".
And as native or managed code, there's nothing to stop you "run[ning] in the cloud". Why would you think there was?
Perhaps not many organizations do it because there's no reason to do so.
When you say rewriting is a good strategy, do you have ANY idea what that entails?
Or just look at the results. Rip-and-replace projects have a failure rate that makes greenfield development look good.
That's why the sales keep rollin' in. We had $206M in FY16 revenue from COBOL Development and Mainframe Solutions, which is basically all the COBOL stuff plus the mainframe environment (CICS, IMS, JES) emulation. That kind of money adds up.
COBOL doesn't and shouldn't give a shit about drop downs, java, PDFs and all that other bullshit
Don't tell that to the application developers. A majority of the queries we get on the MF Community COBOL forums are for GUI issues. PDF output is a popular topic too. And COBOL for JVM is doing nicely, thanks.
One of the nice things about f77 and i presume cobol is that memory is allocated in a fixed way at compile time
All the major COBOL dialects have offered dynamic memory allocation for decades.
relatively speaking, its harder to find cases where typos are not also syntax errors
That's arguably true in COBOL-85 and later. Pre-85 COBOL suffers from its "sentence" syntactic construct and the use of the period (aka "full stop") punctuator as a scope delimiter. While the recommendation for the past thirty years has been to use ANSI scope delimiters (END-IF, etc) and avoid periods, there's still a huge legacy codebase using periods, and many COBOL programmers[1] still use archaic styles.
there are advantages to giving up features
These days you have nearly all the "features" anyone wants in COBOL. We've had OO COBOL for a couple of decades. Managed COBOL for CLR and JVM for over a decade. Generics? Sure. Anonymous inline delegates with closures? Yup. Type inference? In limited contexts, at least. Embedded SQL? Well, if that's your thing, then, yeah, we have that too. And mixed-case, free-format source arrived a long time ago.
Plenty of new applications being developed in COBOL these days, too. People aren't just maintaining legacy stuff.
[1] Yes, there are still many COBOL programmers. I know the news services love these "disappearing COBOL programmer" human-interest stories, but I deal with COBOL programmers at many companies and, believe me, there are a lot of them.
I don't understand how your proposal would benefit AT&T and Comcast.