You don't undestand what REST is. There is nothing about REST that disallows the posting of an XML document. The question is how you use URLs and HTTP verbs, not what syntax you use.
You say that "surely submitting a SOAP document that wraps an XML document is..." There is no question that XML is the right choice in some cases. That's why REST and XML are so often used together. But if you're going to claim that there is some benefit in "wrapping" the XML in SOAP, you'll have to back it up. In my experience, the vast majority of people "wrap" XML in SOAP but don't have any reason for doing so other than buzzword compliance.
Violent agreement. The term "engineer" is meaningless except as a prestige thing. Civil engineers know certain things. Genetic engineers know other things. Licensing them is useful and important. So what if someone puts "Domestic Engineer" on their resume? Nobody is going to hire such a person thinking they are a civil engineer.
As far as the word "lawyer": there is no debate about that word because it has always had a clear meaning. Nobody wants to see it evolve because it is useful as it is. To the general public, a lawyer is someone who has passed the bar and is allowed to argue their case, invoke client-attorney priviledge etc.
That is not the case for the word engineer. PEngs want to take the word and narrow it. But the word long predates the creation of engineering societies as we know them. To the general public, an engineer is a very technical person doing some very technical job involving the creation or maintenance of something. That's what the word has always meant and will probably mean for a very long time.
I'm sorry, but this is a case where the state has every right to set some standards. Otherwise, what's next? Doctor of IIS Surgery?
Don't you think that it is already possible to be a Doctor of Computer Science? What do you think happens when you get your PhD in computer science? Does anyone confuse Doctors of Literatures with MDs?
Now I know a bunch of computer engineers, most of those guys are hardware, not software, but these guys wouldn't want to be engineers under Canadian law if they were doing programming.
It should be major news that Joe Somebody's computer crashed today, an event greeted with grim commentary and TV specials.
I think its hilarious to hear this from a hardware engineer. Do you know how many bugs hardware has? Do you think that the Pentium bug was some kind of rare event?
Evolution of terms? OK well, unlike the rest of the general population you and I may be able to appreciate the subject of linguistics and the gradual "evolution of terms" in language. The fact of the matter is that people are dumb. People are so dumb that if you tell them you're an engineer, they'll trust you.
What does it matter? Do people at cocktail parties hire engineers? Look, if a guy with an MCSE goes to a job interview and presents himself as a civil engineer, he'll probably go to jail. But the same goes if a Chemical Engineer presents himself as a Civil Engineer or a Doctor of History presents himself as a medical doctor. The fact that the guy who isn't what the public calls an engineer or a doctor happens to use that term does not hurt anyone. The people who hire need to know the difference or we are in deep shit regardless of what the law says.
If the public at large gets to define what "engineer" means then it means "guy who runs the train."
It is 100% the government's responsibility to intervene and as a soon-to-be ACREDITED software engineer in the province of Ontario, I'm glad they are doing it! I'm sick of these 2 years in IT college also-rans calling themselves software engineers!
And now we come down to the real issue. It has nothing to do with protecting the public. It's simple elitism. You've worked hard for a particular designation and you're afraid it will come to be seen as less prestigious. Boo hoo. It's too late. To the general public, an engineer is the guy who runs the train.
I can't agree with that. People DO hire the wrong people to do certain jobs. (Usually based on the cost of the bid alone).
Non-sequtier. The question is whether people hire MCSE's thinking that they are something that they are not (i.e. "real engineers"). I think the answer is: "of course not."
If you can't legally call someone an engineer, they have no liability within the framework of the law.
The liability comes with the certification, not the title. A PhD and an MD are both "doctors" but their liability is totally different. If a PhD picks up the phone and answers "Dr. Draknonian" that doesn't make him an MD. It is only a problem if he presents himself as an MD in a confusing manner.
Sure your bridge may fall, but you don't have a legal avenue to sue the person unless they are a professional engineer.
There is a thing called "gross negligence" that applies to all human beings, engineers or not. And more to the point, people tend to sue corporations, not individuals. This would be especially true for software "engineering". Do you really think that before suing Microsoft you're going narrow down a crash in Windows XP to some particular guy and then check whether he has an engineering certification?
Wrong. The biggest problem is while our society becomes more and more technology dependent, the general public's interpretation of the difference between a chemical engineer and an MCSE will become clouded.
"The public" in a vague sense is irrelevant to the discussion. The question is whether people hiring and firing "engineers" will be confused about the actual level of certification of those engineers. If yes, that's a problem. If no, the government shouldn't get involved.
I personally GUARANTEE you there wouldn't be so many security flaws in software today if software coders were held to the same type of liabilty a professional engineer is.
There are so many issues here that I can't begin to address them all. Okay, I'll begin. Would the public accept much more expensive software that was also much more secure? Are they willing to wait years longer for more carefully written code? Would the public accept that they couldn't run their secure software on operating systems and hardware it hasn't been tested on? Professional engineers are said to be liable but how often does this actually happen? Did anyone get sued for the two shuttle crashes? If my NVidia graphics card doesn't display a page right and my doctor misreads a chart, is there some engineer at Nvidia who is going to be liable? I would bet that engineers only get sued for _gross negligence_ which more or less means that there is a solved problem and they didn't use the standard solution for it. I would also bet that they only get sued when they have their own private practices, not when they are inside of Boeing or NASA or something.
The problem is, the computer industry changes every week and advanced programmers (the ones most likely to get an "engineer" designation) spend most of their time thinking up new solutions to new problems.
Also, your standard civil engineer is dealing basically with Newton's laws. To verify structural soundness, they apply a bunch of equations to their design and see what happens. There is no equivalent for computer science. Godel's and Turings results prove that there will never be a mechanical algorithm for verifying that software meets its requirements specification...in the rare cases that there is actually a robust requirements specification.
But the most important point is: if Microsoft was held liable it would be entirely irrelevant whether Microsoft hired employees who were individually certified to a level that would allow them to also be liable. The indemnity of the corporations is what matters, not the indemnity of individuals.
I applaud Florida who makes it illegal to expand the term "MCSE" on a resume or in a business letter unless you are an actual engineer.
Whether or not these people are using the term engineer correctly or not, it is abhorrent for the government to use its energy to try and prevent the evolution of terms. Nobody would ever be endangered if an MSCE expanded his job title. He is a Microsoft Certified Engineer, not a Chemical Engineer or a Civil Engineer. Nobody would hire a Chemical Engineer to build a bridge and nobody would hire an MSCE to do it either. So the harm is just to your sense of propriety. Flame them if you like but leave the cops and courts out of it.
engineer
\En`gi*neer"\, n. [OE. enginer: cf. OF. engignier, F. ing['e]nieur. See Engine, n.] 1. A person skilled in the principles and practice of any branch of engineering.
engineering (nj-nîrng)
n.
1.
a. The application of scientific and mathematical principles to practical ends such as the design, manufacture, and operation of efficient and economical structures, machines, processes, and systems.
b. The profession of or the work performed by an engineer.
2. Skillful maneuvering or direction: geopolitical engineering; social engineering.
http://dictionary.reference.com/search?q=engineer
http://dictionary.reference.com/search?q=engineeri ng
People in the thread want to redefine the word "engineer" to mean "registered, professional, accredited engineer." But the word predates registration and accreditation.
"The last of the three words -- engineering -- comes from the Latin word ingeniare, which means to devise. A lot of other English words are related to this word: ingenuity, which means inventiveness, and engine, which can be taken to mean any machine of our devising -- any "engine of our ingenuity." So an engineer is, first and foremost, a deviser of machines.
http://www.uh.edu/engines/epi12.htm
In the public mind, the word "doctor" has a very specific meaning and calling yourself a doctor could have disastorous consequences. You could say the same of "mechnical engineer." But it is silly to say it of "engineer" in general. A so-called software engineer may not be fit to devise a school boiler, but neither is a chemical engineer. "Misusuing" the term engineer is not likely to have serious consequences and therefore the government should not waste its energy policing it.
\En`gi*neer"\, n. [OE. enginer: cf. OF. engignier, F. ing['e]nieur. See Engine, n.] 1. A person skilled in the principles and practice of any branch of engineering.
engineering (nj-nîrng) n.
1.
a. The application of scientific and mathematical principles to practical ends such as the design, manufacture, and operation of efficient and economical structures, machines, processes, and systems.
b. The profession of or the work performed by an engineer.
2. Skillful maneuvering or direction: geopolitical engineering; social engineering.
http://dictionary.reference.com/search?q=enginee r http://dictionary.reference.com/search?q=engine eri ng
Microsoft will tell corporate users that locked down desktops (locked down at the CPU level) are the solution to viruses, P2P music trading and other evils.
I hate C++ as much as the next guy, so I was hoping to read that Andkon page and find a good, well-thought-out flaming, but really it was pathetic. No real technical points whatsoever. Its embarassing that you use that as your justification for using Java over C++. There are many good critiques of C++ out there. This is not one of them.
And how, exactly, is this terribly ironic? The jobs aren't going to Europe; they're going to India, Taiwan, China, and other places that lack the benefits (costs) of the US, and particularly Europe.
It's ironic because Americans have been telling the Europeans that their social practices are economically unsustainable but its the American economy that's going down the tubes now, and American employees whining that they need protection from competition.
Mr. Bray makes a point about the longevity of XML based documents (where he says that tying up documents in a binary format is foolish), but this is a point that (La)TeX users have been arguing for years.
XML is vastly easier to parse than LaTeX. There are hundreds of generalized XML parsers out there for every language and a basic one can be written from scratch in a few days. XML's very popularity means that XML parsers will probably ship with operating systems for at least the next 20 years. LaTeX uses a syntax that is specific to exactly one problem and thus is less popular. LaTeX parsers don't ship with most operating systems and never will.
Given a reasonable budget, future archeologists will be able to deal with either. But one could imagine that ten years from now you want to convert your thesis into the display format du jour and it will be too much of a hassle to figure out how to parse all of those backslashes, square braces, etc. That could happen with XML too, but the fact that it is easier to parse could push you over the line.
That may be true, but I think your argument is bogus. We're talking about programmers developing their own code, here. Any code you write, in any language, is potentially at risk from other code it links to that you did not write.
The point is you end up spending a non-trivial amount of your time and effort doing string type conversions. The idea that the STL is a "defacto standard" is just wrong. Maybe it will be one day.
What are the problems you see with it? C++ string handling certainly sucks at times, as anyone who's tried to write an internationalised application can tell you, but what mysterious bunches of semantics are you thinking of here?
I'll leave the answer to this question to the experts:
"UnicodeString is a string class that stores Unicode characters directly and provides similar functionality as the Java String and StringBuffer classes."..."UnicodeString combines elements of both the Java String and StringBuffer classes. Many UnicodeString functions are named and work similar to Java String methods but modify the object (UnicodeString is "mutable")."
So there you go. Yet another "defacto standard" string class to convert to.
Well, C++ lacks one, it is provided by the standard library. I'm pretty sure that most functional languages like ML and Haskell do not have a built-in string type but instead get it from the standard library.
That's not true. Any language that has a string literal syntax has built-in strings, including C, C++, Haskell, ML, Python, Java, Scheme, etc. That's in the language...part of the grammar. The problem is that C's built-in string type is just a pointer-unsafe character array. That was probably not even the right choice in 1972, (even braniacs can make mistakes) but it certainly is not today.
There are tons of popular C++ libraries that don't use the STL...to say nothing of all of the C libraries that you must call into. Plus, I don't think that STL has decent unicode support. Wstring is not enough. Unicode has a bunch of semantics that are built-into the string classes of languages like Python and Java.
This sounds like Microsoft's philosophy - bloat because we can afford to.
Actually, his philosophy is "slightly reduced performance for security's sake." Doesn't sound like Microsoft at all, does it? Or maybe it does...that's surely part of the.NET CLR vision. It would be sad if they moved ahead and the open source world was too stuck in its habits to keep up. I don't think that's the case though: the open source world has lots of high level languages and they are starting to catch on even for serious development.
While I believe there is a need for the computing industry to move towards more responsibility for security, focusing just on C/C++ programmers will not do the job. There is plenty of improvement to be made by the end users, and the columnists as well!
Where in the article did he say that the only way to improve security is to use high level languages? As I read it, he said that one way to improve security is to do so.
The thrust of the article is that most programmers are not skilled enough to write secure code, so they should be using HLL's that do the security for them, and leave C/C++ code to the "experts."
No. The that is not the thrust of the argument. The thrust of the argument is that high level languages have automated features (memory management in particular) that can reduce the chance of security bugs just as there are features in airplanes to help pilots avoid mistakes.
Security is a process, not a product. HLL's can be misused just as effectively as LLL's
Imagine if Boeing said to a fighter pilot: "we've got this new feature that will reduce crashes by 5%." Would the pilot say: "your new planes can be driven into the ground if I fall asleep just as effectively as your old ones?" No, unless he is a macho cowboy, he's more likely to say: "thank you." Because he knows he isn't perfect and that every little bit helps.
That's what I'm saying. I mean he (the author of the article) even shot himself in the foot by claiming that he sees bugs in higher level web-languages like PHP.
No he didn't. The point is that a good programmer can reduce their risk by using a high level language. They can't eliminate it. According to your logic, because people can get killed in Volvos, Volvos are as safe as motorocycles.
Just because you use a high level language, if you suck at coding, your program will have security holes.
Brilliant insight. Unfortunately redundant.
Referring to the standard, minimal C string library. I used one in the past. I believe it was called APSTRING. It was a nice string object and and it had a method to make it compatible with those older functions that wanted char *'s.
Making one library that everyone will agree to support will be difficult, because they all have slightly different implementations of basically the same thing.
Another good reason to move on to a more modern language.
A defacto standard could be made if you started using one and kept on using it.
How would it be a defacto standard if only one person used it? After more than 10 years of C++ don't you think that such a thing would have arisen if it was going to?
Slashdot Mirror
You don't undestand what REST is. There is nothing about REST that disallows the posting of an XML document. The question is how you use URLs and HTTP verbs, not what syntax you use. You say that "surely submitting a SOAP document that wraps an XML document is..." There is no question that XML is the right choice in some cases. That's why REST and XML are so often used together. But if you're going to claim that there is some benefit in "wrapping" the XML in SOAP, you'll have to back it up. In my experience, the vast majority of people "wrap" XML in SOAP but don't have any reason for doing so other than buzzword compliance.
Violent agreement. The term "engineer" is meaningless except as a prestige thing. Civil engineers know certain things. Genetic engineers know other things. Licensing them is useful and important. So what if someone puts "Domestic Engineer" on their resume? Nobody is going to hire such a person thinking they are a civil engineer. As far as the word "lawyer": there is no debate about that word because it has always had a clear meaning. Nobody wants to see it evolve because it is useful as it is. To the general public, a lawyer is someone who has passed the bar and is allowed to argue their case, invoke client-attorney priviledge etc. That is not the case for the word engineer. PEngs want to take the word and narrow it. But the word long predates the creation of engineering societies as we know them. To the general public, an engineer is a very technical person doing some very technical job involving the creation or maintenance of something. That's what the word has always meant and will probably mean for a very long time.
I'm sorry, but this is a case where the state has every right to set some standards. Otherwise, what's next? Doctor of IIS Surgery?
Don't you think that it is already possible to be a Doctor of Computer Science? What do you think happens when you get your PhD in computer science? Does anyone confuse Doctors of Literatures with MDs?
Now I know a bunch of computer engineers, most of those guys are hardware, not software, but these guys wouldn't want to be engineers under Canadian law if they were doing programming.
Right. Because computer hardware is so reliable.
http://librenix.com/?inode=792
http://news.com.com/2100-1033-205157.html?legacy =cnet
http://librenix.com/?inode=792
http://news.com.com/2100-1001-250316.html?legacy =cnet
It should be major news that Joe Somebody's computer crashed today, an event greeted with grim commentary and TV specials.
I think its hilarious to hear this from a hardware engineer. Do you know how many bugs hardware has? Do you think that the Pentium bug was some kind of rare event?
Evolution of terms? OK well, unlike the rest of the general population you and I may be able to appreciate the subject of linguistics and the gradual "evolution of terms" in language. The fact of the matter is that people are dumb. People are so dumb that if you tell them you're an engineer, they'll trust you.
What does it matter? Do people at cocktail parties hire engineers? Look, if a guy with an MCSE goes to a job interview and presents himself as a civil engineer, he'll probably go to jail. But the same goes if a Chemical Engineer presents himself as a Civil Engineer or a Doctor of History presents himself as a medical doctor. The fact that the guy who isn't what the public calls an engineer or a doctor happens to use that term does not hurt anyone. The people who hire need to know the difference or we are in deep shit regardless of what the law says.
If the public at large gets to define what "engineer" means then it means "guy who runs the train."
It is 100% the government's responsibility to intervene and as a soon-to-be ACREDITED software engineer in the province of Ontario, I'm glad they are doing it! I'm sick of these 2 years in IT college also-rans calling themselves software engineers!
And now we come down to the real issue. It has nothing to do with protecting the public. It's simple elitism. You've worked hard for a particular designation and you're afraid it will come to be seen as less prestigious. Boo hoo. It's too late. To the general public, an engineer is the guy who runs the train.
I can't agree with that. People DO hire the wrong people to do certain jobs. (Usually based on the cost of the bid alone).
Non-sequtier. The question is whether people hire MCSE's thinking that they are something that they are not (i.e. "real engineers"). I think the answer is: "of course not."
If you can't legally call someone an engineer, they have no liability within the framework of the law.
The liability comes with the certification, not the title. A PhD and an MD are both "doctors" but their liability is totally different. If a PhD picks up the phone and answers "Dr. Draknonian" that doesn't make him an MD. It is only a problem if he presents himself as an MD in a confusing manner.
Sure your bridge may fall, but you don't have a legal avenue to sue the person unless they are a professional engineer.
There is a thing called "gross negligence" that applies to all human beings, engineers or not. And more to the point, people tend to sue corporations, not individuals. This would be especially true for software "engineering". Do you really think that before suing Microsoft you're going narrow down a crash in Windows XP to some particular guy and then check whether he has an engineering certification?
Wrong. The biggest problem is while our society becomes more and more technology dependent, the general public's interpretation of the difference between a chemical engineer and an MCSE will become clouded.
"The public" in a vague sense is irrelevant to the discussion. The question is whether people hiring and firing "engineers" will be confused about the actual level of certification of those engineers. If yes, that's a problem. If no, the government shouldn't get involved.
I personally GUARANTEE you there wouldn't be so many security flaws in software today if software coders were held to the same type of liabilty a professional engineer is.
There are so many issues here that I can't begin to address them all. Okay, I'll begin. Would the public accept much more expensive software that was also much more secure? Are they willing to wait years longer for more carefully written code? Would the public accept that they couldn't run their secure software on operating systems and hardware it hasn't been tested on? Professional engineers are said to be liable but how often does this actually happen? Did anyone get sued for the two shuttle crashes? If my NVidia graphics card doesn't display a page right and my doctor misreads a chart, is there some engineer at Nvidia who is going to be liable? I would bet that engineers only get sued for _gross negligence_ which more or less means that there is a solved problem and they didn't use the standard solution for it. I would also bet that they only get sued when they have their own private practices, not when they are inside of Boeing or NASA or something.
The problem is, the computer industry changes every week and advanced programmers (the ones most likely to get an "engineer" designation) spend most of their time thinking up new solutions to new problems.
Also, your standard civil engineer is dealing basically with Newton's laws. To verify structural soundness, they apply a bunch of equations to their design and see what happens. There is no equivalent for computer science. Godel's and Turings results prove that there will never be a mechanical algorithm for verifying that software meets its requirements specification...in the rare cases that there is actually a robust requirements specification.
But the most important point is: if Microsoft was held liable it would be entirely irrelevant whether Microsoft hired employees who were individually certified to a level that would allow them to also be liable. The indemnity of the corporations is what matters, not the indemnity of individuals.
I applaud Florida who makes it illegal to expand the term "MCSE" on a resume or in a business letter unless you are an actual engineer.
Whether or not these people are using the term engineer correctly or not, it is abhorrent for the government to use its energy to try and prevent the evolution of terms. Nobody would ever be endangered if an MSCE expanded his job title. He is a Microsoft Certified Engineer, not a Chemical Engineer or a Civil Engineer. Nobody would hire a Chemical Engineer to build a bridge and nobody would hire an MSCE to do it either. So the harm is just to your sense of propriety. Flame them if you like but leave the cops and courts out of it.
engineer \En`gi*neer"\, n. [OE. enginer: cf. OF. engignier, F. ing['e]nieur. See Engine, n.] 1. A person skilled in the principles and practice of any branch of engineering. engineering (nj-nîrng) n. 1. a. The application of scientific and mathematical principles to practical ends such as the design, manufacture, and operation of efficient and economical structures, machines, processes, and systems. b. The profession of or the work performed by an engineer. 2. Skillful maneuvering or direction: geopolitical engineering; social engineering. http://dictionary.reference.com/search?q=engineer http://dictionary.reference.com/search?q=engineeri ng
People in the thread want to redefine the word "engineer" to mean "registered, professional, accredited engineer." But the word predates registration and accreditation.
"The last of the three words -- engineering -- comes from the Latin word ingeniare, which means to devise. A lot of other English words are related to this word: ingenuity, which means inventiveness, and engine, which can be taken to mean any machine of our devising -- any "engine of our ingenuity." So an engineer is, first and foremost, a deviser of machines.
http://www.uh.edu/engines/epi12.htm
In the public mind, the word "doctor" has a very specific meaning and calling yourself a doctor could have disastorous consequences. You could say the same of "mechnical engineer." But it is silly to say it of "engineer" in general. A so-called software engineer may not be fit to devise a school boiler, but neither is a chemical engineer. "Misusuing" the term engineer is not likely to have serious consequences and therefore the government should not waste its energy policing it.
engineer
e re eri ng
\En`gi*neer"\, n. [OE. enginer: cf. OF. engignier, F. ing['e]nieur. See Engine, n.] 1. A person skilled in the principles and practice of any branch of engineering.
engineering (nj-nîrng)
n.
1.
a. The application of scientific and mathematical principles to practical ends such as the design, manufacture, and operation of efficient and economical structures, machines, processes, and systems.
b. The profession of or the work performed by an engineer.
2. Skillful maneuvering or direction: geopolitical engineering; social engineering.
http://dictionary.reference.com/search?q=engine
http://dictionary.reference.com/search?q=engin
What in your background earned you that right? Did you take exams administered by a professional engineer's society or something?
Microsoft will tell corporate users that locked down desktops (locked down at the CPU level) are the solution to viruses, P2P music trading and other evils.
I hate C++ as much as the next guy, so I was hoping to read that Andkon page and find a good, well-thought-out flaming, but really it was pathetic. No real technical points whatsoever. Its embarassing that you use that as your justification for using Java over C++. There are many good critiques of C++ out there. This is not one of them.
Here's a good article that describes the problem with LaTeX: http://www.ddj.com/documents/s=862/ddj0107e/0107e. htm
And how, exactly, is this terribly ironic? The jobs aren't going to Europe; they're going to India, Taiwan, China, and other places that lack the benefits (costs) of the US, and particularly Europe.
It's ironic because Americans have been telling the Europeans that their social practices are economically unsustainable but its the American economy that's going down the tubes now, and American employees whining that they need protection from competition.
Mr. Bray makes a point about the longevity of XML based documents (where he says that tying up documents in a binary format is foolish), but this is a point that (La)TeX users have been arguing for years.
XML is vastly easier to parse than LaTeX. There are hundreds of generalized XML parsers out there for every language and a basic one can be written from scratch in a few days. XML's very popularity means that XML parsers will probably ship with operating systems for at least the next 20 years. LaTeX uses a syntax that is specific to exactly one problem and thus is less popular. LaTeX parsers don't ship with most operating systems and never will.
Given a reasonable budget, future archeologists will be able to deal with either. But one could imagine that ten years from now you want to convert your thesis into the display format du jour and it will be too much of a hassle to figure out how to parse all of those backslashes, square braces, etc. That could happen with XML too, but the fact that it is easier to parse could push you over the line.
That may be true, but I think your argument is bogus. We're talking about programmers developing their own code, here. Any code you write, in any language, is potentially at risk from other code it links to that you did not write.
The point is you end up spending a non-trivial amount of your time and effort doing string type conversions. The idea that the STL is a "defacto standard" is just wrong. Maybe it will be one day.
What are the problems you see with it? C++ string handling certainly sucks at times, as anyone who's tried to write an internationalised application can tell you, but what mysterious bunches of semantics are you thinking of here?
I'll leave the answer to this question to the experts:
http://oss.software.ibm.com/icu/apiref/classUnic odeString.html#_details
"UnicodeString is a string class that stores Unicode characters directly and provides similar functionality as the Java String and StringBuffer classes."..."UnicodeString combines elements of both the Java String and StringBuffer classes. Many UnicodeString functions are named and work similar to Java String methods but modify the object (UnicodeString is "mutable")."
So there you go. Yet another "defacto standard" string class to convert to.
Well, C++ lacks one, it is provided by the standard library. I'm pretty sure that most functional languages like ML and Haskell do not have a built-in string type but instead get it from the standard library.
That's not true. Any language that has a string literal syntax has built-in strings, including C, C++, Haskell, ML, Python, Java, Scheme, etc. That's in the language...part of the grammar. The problem is that C's built-in string type is just a pointer-unsafe character array. That was probably not even the right choice in 1972, (even braniacs can make mistakes) but it certainly is not today.
There are tons of popular C++ libraries that don't use the STL...to say nothing of all of the C libraries that you must call into. Plus, I don't think that STL has decent unicode support. Wstring is not enough. Unicode has a bunch of semantics that are built-into the string classes of languages like Python and Java.
This sounds like Microsoft's philosophy - bloat because we can afford to.
Actually, his philosophy is "slightly reduced performance for security's sake." Doesn't sound like Microsoft at all, does it? Or maybe it does...that's surely part of the .NET CLR vision. It would be sad if they moved ahead and the open source world was too stuck in its habits to keep up. I don't think that's the case though: the open source world has lots of high level languages and they are starting to catch on even for serious development.
The article really touched a nerve, didn't it?
While I believe there is a need for the computing industry to move towards more responsibility for security, focusing just on C/C++ programmers will not do the job. There is plenty of improvement to be made by the end users, and the columnists as well!
Where in the article did he say that the only way to improve security is to use high level languages? As I read it, he said that one way to improve security is to do so.
The thrust of the article is that most programmers are not skilled enough to write secure code, so they should be using HLL's that do the security for them, and leave C/C++ code to the "experts."
No. The that is not the thrust of the argument. The thrust of the argument is that high level languages have automated features (memory management in particular) that can reduce the chance of security bugs just as there are features in airplanes to help pilots avoid mistakes.
Security is a process, not a product. HLL's can be misused just as effectively as LLL's
Imagine if Boeing said to a fighter pilot: "we've got this new feature that will reduce crashes by 5%." Would the pilot say: "your new planes can be driven into the ground if I fall asleep just as effectively as your old ones?" No, unless he is a macho cowboy, he's more likely to say: "thank you." Because he knows he isn't perfect and that every little bit helps.
It's not C and C++ which are at fault, it's the C *standard library*.
The language takes some of the blame. What other programming language in widespread usage lacks a built-in, pointer safe string class?
That's what I'm saying. I mean he (the author of the article) even shot himself in the foot by claiming that he sees bugs in higher level web-languages like PHP.
No he didn't. The point is that a good programmer can reduce their risk by using a high level language. They can't eliminate it. According to your logic, because people can get killed in Volvos, Volvos are as safe as motorocycles.
Just because you use a high level language, if you suck at coding, your program will have security holes.
Brilliant insight. Unfortunately redundant.
Referring to the standard, minimal C string library. I used one in the past. I believe it was called APSTRING. It was a nice string object and and it had a method to make it compatible with those older functions that wanted char *'s. Making one library that everyone will agree to support will be difficult, because they all have slightly different implementations of basically the same thing.
Another good reason to move on to a more modern language.
A defacto standard could be made if you started using one and kept on using it.
How would it be a defacto standard if only one person used it? After more than 10 years of C++ don't you think that such a thing would have arisen if it was going to?