The idea that the containers somehow aren't a core part of the language is a prime example; they are in the standard library, and available on all recent implementations. To view them as being somehow a disjoint part of C++ is to create an artificial barrier where none exists.
This is both historical and (as you have mentioned before) education issue. I've yet to see a single book on C++ that starts using container classes right from the introduction chapters. Usually one gets exposed to C types for the most part, and only later container classes are introduced, often in pile with the rest of STL and other functionality.
On the other side of spectrum there are early C++ adopters and people converted from C. Old habits die hard.
Either way, within your own code -- where you might inadvertently introduce memory leaks, buffer over-runs or any other nasties -- you are always protected by using a suitably robust high level tool.
Once you declare a buffer, there is a great temptation to reuse it. Also, if your code is API-intensive, the bolierplate for converting containers back and forth gets pretty irritating.
IMHO, the problem isn't that people can't do this, it's just that they don't.
People can do all sorts of amazing things:) It is however much easier to work when the tool doesn't let you shoot yourself in a foot, since (with rare exceptions) you really don't need it.
That wouldn't work either. If you use an object that implements a container, you can't pass it as a destination buffer to a function expecting raw memory pointer.
Buffer overflows are trivially avoided in the vast majority of cases, by simply using an appropriate higher level tool, such as a container class, instead of a primitive array.
I'd say C++ culture discourages the use of higher-level containers. Partly because they aren't within the core language, and partly because of the vast array of libraries that require supplied buffers to be 'primitive arrays'.
The Russian word Cosmonaut made a little bit of sense since that's the Russian word for Astronaut.
No, the Russian word Cosmonaut is the Russian word for Cosmonaut. Astronaut was coined later by Americans, but it is a word of its own in Russian language.
And both words were formed from Latin:
Cosmonaut = Space Traveller Astronaut = Stellar Traveller
His tool is unjustly battered by the ignorant more than perhaps any other mainstream language today, and it creates a self-fulfilling prophecy: most people who learn C++ learn it badly, and write code with buffer overflows and other kindergarten mistakes.
Buffer overflows are not kindergarten mistakes. It is a pattern that occurs constantly in code written both by rookie and seasoned C/C++ programmers, hence it highlights a problem with the tool, not with a skill.
If some design requires infallible humans to work properly, it's better to be reconsidered.
On your next trip to America, just remember this simple little mathmatical formula:
1 is less than 5 is less than 10 is less than 20 is less than 50 is less than 100
A lot of fake dollar bills worldwide are made just but cutting '0' out of 10-dollar bill, and sticking onto a $5 or $10 bill, thus making $50 and $100 respectively.
Works great when people in rush or the lighting is dim: it is very easy to mistake one dollar bill for another, esp. if you're a foreigner and not aware how much G. Washington portrait is worth.
Buffer underruns come to mind. Somebody has to be fairly slick to figure that one out. It's sort of like figuring out the exact sonic frequency it'd take to make a car's tires explode, and then figuring out a way to broadcast it in such a way that it affects cars all over the place. Is Firestone responsible for negligence for not protecting thier tires against this type of attack?
I mostly agree with your analysis, but your tire analogy is flawed. Buffer overrun problems are known for decades now, and tools that prevent them exist even longer.
Consider that a tire manufacturer had a choice among several production technologies. In theory, all could yield equally good tires, but one of them was reducing production costs (say, it allowed to use cheaper material, equipment, or less expensive labour). Albeit, that technology requires extreme precautions from the workers to make tires that wouldn't explode, while others were relatively safe. Still, the manufacturer have choosen the cheaper approach over safer ones.
Buffer overruns are the problems of the most fundamental design decisions, and are orthogonal to system architecture or qualification of developers. Still, they could be avoided.
But I agree that software vendors should not be liable for defects. Basically, we have to choose one: liable vendors or useful software.
I burned out because when I tried to work on open-source, there were too many people who insisted that for the project to succeed I had to do X, when what I was more interested in was Y.
I think it has more to do with social interaction than with IT.
And if you aren't happy putting up with this bullshit, some twit on Slashdot accuses you of having no passion for the trade.
If you went to study CS in colledge solely hoping for "easy 60K/year when you graduate", I call it no passion for the trade.
I (and many of my coworkers) moved to the field years before the dotcom rush. In fact, my relatives and friends suggested that I choose another topic that was hot at that time. We done it our way though, survived, seen the bubble, competed with hordes of cash-hungry wannabees who can't tell TCP from UDP, seen the burst, were doing 55 hours weeks for months, survived again and we'll stay in the field because *we like it*.
I've got enough in the bank to comfortably survive for the next year, with a bit of simple living, and by that time I hope to have recovered and have been accepted into a graduate school in a field that has NOTHING to do with IT.
So power to you. Just don't get mad when people call things with their names.
I want a real career. Without computers. Without the corporation.
So go for it man. The more people without passion for our trade leave, the more jobs will be available for those who genuinely interested in the field.
While free market and competition are usually good things, in some circumstances they result in suboptimal solutions. However, power distribution business is apt to emergence of monopolies, so while blackouts are extremely disturbing, in the end free market is perhaps more important there than reliability of supply.
Technically, the Soviet power grid was very close to optimal design: decentralised network encompassing the whole country, efficient, built with ability to sustain major damage (large-scale war) in mind. However, with the fall of Soviet Union all infrastructure has ended with a handful of individuals, who now have a perfect monopoly and use it to enforce prices they want. The end result is often similar: public schools and hospitals are getting cut off because they can't afford electricity.
They have to earn that money with the sales of their ideas.
No, they have to earn money by developing and selling software, not their ideas. At least that's what software shops I've been working at were doing.
And how to protect those ideas? Correctly, by patents.
98% of software patents out there are utter, nonsensical or trivial crap. There aren't really that much good ideas around worth patenting. Not enough to feed all patent lawyers for sure.
In other words: it's probably the only way for small enterprises to protect themselves against the large companies.
Wrong. Patents work very poorly against big fish: they can either over-sue you, or flood you with an impressive cache of their own patents. But small enterprises and especially individuals are extremely vulnerable.
Come on, you are a patent attorney, aren't you there for money? And whom do you expect to shell enough cash to keep you afloat? Garage shops, huh?
Imagine when graphical web browsing would have been patented by the NCSA or Netscape would have patented a lot of improvements. Who would know Microsoft Internet Explorer?
The mere suggestion that some asshole should patent something as obvious as hypertext drives me nuts.
No, I'd rather tolerate the existance of MS IE than stay locked into expensive, proprietary and patent-protected technology.
Why post it in Science section? This sofa is just a silly (though admittedly neat) hack; it isn't particularily mind-shaking even from mere engineering perspective.
Why write new protocols that are doing the same thing that SSH is doing? It's nonsensical.
Show me how to forward UDP traffic over SSH.
Vtun isn't "the same thing", and indeed has its uses. Discard vtun security features and wrap it into SSL, and you have a nice, secure, generic IP tunnel.
I'm willing to bet that the guys behind these protocols got flat-out laughed at by anyone doing real cryptography work, but still somehow felt that they were right all along.
They made a honest attempt and failed. Never bet on what other people feel.
This missive contains a few blaring warning signs of a guy who has not learned best practices for Java programming, and indeed is very naive about the needs of enterprise software development.
Well, the guy indeed was a founder of a (profitable) enterprise. Please adjust your buzzwords.
In the context of Web application programming, he declares: "Mostly what you get with Java are reams of repetitive declarations at the top of every script so that the relevant code for serving a page is buried several screens down." The rationale for this statement is nowhere to be found, and it's anybody's guess what in the world he's talking about.
If you look at a typical Java source file, you'll see that this is quite true. Excess of boilerplate code is quite usual for Java applications.
Again, no further comment, except to note that no one, I mean no one in business computing considers using Lisp.
Lisp is indeed considered, used, and deployed by businesses. Go and see it in action.
I expect that seniors and grads at MIT are very smart, but good software engineering discipline usually requires years to learn, even by the smartest cookies. To expect it after one semester is another clear sign of enormous naivete.
*moan*
I hear people using that argument to justify clumsy tools since the days when C++ became fashionable. Yes, you got to learn a lot to be a good developer, but when one tool takes eons longer to master (compared to existing alternatives) without any visible productivity boost in return, I say it is a poor tool.
I have no specific opinion on how viable Open Source software sales can or should be, but a sample size of one success is hardly scientific proof that it is a viable business for others to get into...
Yes, it makes no implications on how easy is to build a buisness around Open Source software, nor it illustrates what would be your chances of survival if you choose that path. It proves, however, that it possible to have a successful business selling OSS, which is fact of its own worth.
Remember the hordes of naysayers that predicted imminent death of RedHat, and all the armchair analysts declaring that there is no business model for Open Source.
There's probably a corollary of Henry Spencer's law about ignorant OS designers reinventing Unix (poorly) that applies to programming languages, although I haven't quite figured what the "target" language (the way Unix is the target OS) is.
"Any sufficiently-complicated C or Fortran program contains an ad-hoc, informally-specified bug-ridden slow implementation of half of Common Lisp."
Do they really burn O'Reilly Nutshell series there? Fascist pigs! As if they couldn't power it with 'The Road Ahead', 'Mein Kampf' or Clancy books instead..
You have the actual label on your boarding pass effectively saying that you are suspect? Ubelievably cynical! Even in late Soviet Uinon, where I happened to live good part of my life, authorities avoided to humiliate the citizens so openly. (And mind you, USSR wasn't exactly the place where personal freedoms were flourhising).
I sympathise you, and wish you best of luck. Hopefully your country will recover the freedoms and sanity that its dwellers were so proud of.
The original poster I replied to made the claim that no one should use older languages, and that everyone should use Java and C# because they solved all problems.
Well, that was of course an overstatement. However, while not all security issues can be addressed at language level, typesafe languages definitely eliminate a very broad class of security flaws (buffer overruns) that plagues modern applications. I think it is safe to say that 70-80% of vulnerabilites found in modern software relate to bad old buffer overflows, and the root cause for them is, indeed, the widespread use of C and C++. Such defects are often found in high-profile projects written by competent developers, so this clearly suggests that we have a problem with tools and not humans here. Hence, while existing Java and C# implementations may not be the best tools for writing sofware with, C/C++ definitely aren't any better.
The interpreted nature of the bytecode used by these interpreters allows the interpreter, while translating the bytecode, to perform at-runtime checks which are harder -- but not impossible -- to do in precompiled code, but it is not a magical solution to every problem.
Here I should note that proper type inference in compilers allows to mostly eliminate run-time type checking.
But yes, there's no silver bullet.
The bytecode is then interpreted by a VM, so I call the javac/JVM combination an interpreted system, dammit.
Well, on my Pentium, machine code instructions are interpreted by CPU microcode, so I guess all depends on your point of view:)
fixes some problems because the nature of interpreted code makes it possible to catch some things at runtime (a benefit you lose to some extent when you use tools like GCJ)
Bounds checks are a function of language's type system, and are completely orthogonal to whether a particular implementation is compiled or interpreted.
And no, you don't lose that benifit to any extent with GCJ.
I stand by my statement that I would not want to write a low level VXD device driver in Java.
In this domain other considerations become significant (e.g. the absence of real-time garbage collector in modern Java implementations, code footprint size, compiler optimisation quality, inherently C-oriented Windows API, etc.). This, however, says nothing about the language per se.
Slashdot Mirror
The idea that the containers somehow aren't a core part of the language is a prime example; they are in the standard library, and available on all recent implementations. To view them as being somehow a disjoint part of C++ is to create an artificial barrier where none exists.
:) It is however much easier to work when the tool doesn't let you shoot yourself in a foot, since (with rare exceptions) you really don't need it.
This is both historical and (as you have mentioned before) education issue. I've yet to see a single book on C++ that starts using container classes right from the introduction chapters. Usually one gets exposed to C types for the most part, and only later container classes are introduced, often in pile with the rest of STL and other functionality.
On the other side of spectrum there are early C++ adopters and people converted from C. Old habits die hard.
Either way, within your own code -- where you might inadvertently introduce memory leaks, buffer over-runs or any other nasties -- you are always protected by using a suitably robust high level tool.
Once you declare a buffer, there is a great temptation to reuse it. Also, if your code is API-intensive, the bolierplate for converting containers back and forth gets pretty irritating.
IMHO, the problem isn't that people can't do this, it's just that they don't.
People can do all sorts of amazing things
That wouldn't work either. If you use an object that implements a container, you can't pass it as a destination buffer to a function expecting raw memory pointer.
The Linux community claimed 90 minutes, when it was really two months.
They were right in their claims. The patch was available for download in 90 minutes.
And I don't bother when RedHat adopts patches, because I (and many other people) don't use that brand of Linux.
Using classes like std::vector and std::string and techniques like RAII remove most of the 'common' causes of buffer overflows and memory leaks.
Yeah, go pass your std::string as a destination buffer to a WinAPI function.
Software Engineering requires skill.
Software Engineering is a myth.
Buffer overflows are trivially avoided in the vast majority of cases, by simply using an appropriate higher level tool, such as a container class, instead of a primitive array.
I'd say C++ culture discourages the use of higher-level containers. Partly because they aren't within the core language, and partly because of the vast array of libraries that require supplied buffers to be 'primitive arrays'.
The Russian word Cosmonaut made a little bit of sense since that's the Russian word for Astronaut.
No, the Russian word Cosmonaut is the Russian word for Cosmonaut. Astronaut was coined later by Americans, but it is a word of its own in Russian language.
And both words were formed from Latin:
Cosmonaut = Space Traveller
Astronaut = Stellar Traveller
In this context, Taikonaut is a bit off.
His tool is unjustly battered by the ignorant more than perhaps any other mainstream language today, and it creates a self-fulfilling prophecy: most people who learn C++ learn it badly, and write code with buffer overflows and other kindergarten mistakes.
Buffer overflows are not kindergarten mistakes. It is a pattern that occurs constantly in code written both by rookie and seasoned C/C++ programmers, hence it highlights a problem with the tool, not with a skill.
If some design requires infallible humans to work properly, it's better to be reconsidered.
On your next trip to America, just remember this simple little mathmatical formula:
1 is less than 5 is less than 10 is less than 20 is less than 50 is less than 100
A lot of fake dollar bills worldwide are made just but cutting '0' out of 10-dollar bill, and sticking onto a $5 or $10 bill, thus making $50 and $100 respectively.
Works great when people in rush or the lighting is dim: it is very easy to mistake one dollar bill for another, esp. if you're a foreigner and not aware how much G. Washington portrait is worth.
And you don't even need a photocopier for that.
Buffer underruns come to mind. Somebody has to be fairly slick to figure that one out. It's sort of like figuring out the exact sonic frequency it'd take to make a car's tires explode, and then figuring out a way to broadcast it in such a way that it affects cars all over the place. Is Firestone responsible for negligence for not protecting thier tires against this type of attack?
I mostly agree with your analysis, but your tire analogy is flawed. Buffer overrun problems are known for decades now, and tools that prevent them exist even longer.
Consider that a tire manufacturer had a choice among several production technologies. In theory, all could yield equally good tires, but one of them was reducing production costs (say, it allowed to use cheaper material, equipment, or less expensive labour). Albeit, that technology requires extreme precautions from the workers to make tires that wouldn't explode, while others were relatively safe. Still, the manufacturer have choosen the cheaper approach over safer ones.
Buffer overruns are the problems of the most fundamental design decisions, and are orthogonal to system architecture or qualification of developers. Still, they could be avoided.
But I agree that software vendors should not be liable for defects. Basically, we have to choose one: liable vendors or useful software.
You're not even in the trade - judging by your website you just fuck around with computers as a hobby.
There's my resume referenced there, smartarse.
I burned out because when I tried to work on open-source, there were too many people who insisted that for the project to succeed I had to do X, when what I was more interested in was Y.
I think it has more to do with social interaction than with IT.
And if you aren't happy putting up with this bullshit, some twit on Slashdot accuses you of having no passion for the trade.
If you went to study CS in colledge solely hoping for "easy 60K/year when you graduate", I call it no passion for the trade.
I (and many of my coworkers) moved to the field years before the dotcom rush. In fact, my relatives and friends suggested that I choose another topic that was hot at that time. We done it our way though, survived, seen the bubble, competed with hordes of cash-hungry wannabees who can't tell TCP from UDP, seen the burst, were doing 55 hours weeks for months, survived again and we'll stay in the field because *we like it*.
I've got enough in the bank to comfortably survive for the next year, with a bit of simple living, and by that time I hope to have recovered and have been accepted into a graduate school in a field that has NOTHING to do with IT.
So power to you. Just don't get mad when people call things with their names.
I want a real career. Without computers. Without the corporation.
So go for it man. The more people without passion for our trade leave, the more jobs will be available for those who genuinely interested in the field.
There is always the military, nowadays that IS job security....They train too.
They also send you to a desert full of armed people who'd like to see you dead.
While free market and competition are usually good things, in some circumstances they result in suboptimal solutions. However, power distribution business is apt to emergence of monopolies, so while blackouts are extremely disturbing, in the end free market is perhaps more important there than reliability of supply.
Technically, the Soviet power grid was very close to optimal design: decentralised network encompassing the whole country, efficient, built with ability to sustain major damage (large-scale war) in mind. However, with the fall of Soviet Union all infrastructure has ended with a handful of individuals, who now have a perfect monopoly and use it to enforce prices they want. The end result is often similar: public schools and hospitals are getting cut off because they can't afford electricity.
They have to earn that money with the sales of their ideas.
No, they have to earn money by developing and selling software, not their ideas. At least that's what software shops I've been working at were doing.
And how to protect those ideas? Correctly, by patents.
98% of software patents out there are utter, nonsensical or trivial crap. There aren't really that much good ideas around worth patenting. Not enough to feed all patent lawyers for sure.
In other words: it's probably the only way for small enterprises to protect themselves against the large companies.
Wrong. Patents work very poorly against big fish: they can either over-sue you, or flood you with an impressive cache of their own patents. But small enterprises and especially individuals are extremely vulnerable.
Come on, you are a patent attorney, aren't you there for money? And whom do you expect to shell enough cash to keep you afloat? Garage shops, huh?
Imagine when graphical web browsing would have been patented by the NCSA or Netscape would have patented a lot of improvements. Who would know Microsoft Internet Explorer?
The mere suggestion that some asshole should patent something as obvious as hypertext drives me nuts.
No, I'd rather tolerate the existance of MS IE than stay locked into expensive, proprietary and patent-protected technology.
Why post it in Science section? This sofa is just a silly (though admittedly neat) hack; it isn't particularily mind-shaking even from mere engineering perspective.
What I don't see is if we really would like to live much longer. I for one feel that imortality would be more of a curse than a blessing.
One nice thing of immortality is that you always can opt-out.
Seriously, I don't mind living a spare century or two. YMMV, of course.
Why write new protocols that are doing the same thing that SSH is doing? It's nonsensical.
Show me how to forward UDP traffic over SSH.
Vtun isn't "the same thing", and indeed has its uses. Discard vtun security features and wrap it into SSL, and you have a nice, secure, generic IP tunnel.
I'm willing to bet that the guys behind these protocols got flat-out laughed at by anyone doing real cryptography work, but still somehow felt that they were right all along.
They made a honest attempt and failed. Never bet on what other people feel.
This missive contains a few blaring warning signs of a guy who has not learned best practices for Java programming, and indeed is very naive about the needs of enterprise software development.
Well, the guy indeed was a founder of a (profitable) enterprise. Please adjust your buzzwords.
In the context of Web application programming, he declares: "Mostly what you get with Java are reams of repetitive declarations at the top of every script so that the relevant code for serving a page is buried several screens down." The rationale for this statement is nowhere to be found, and it's anybody's guess what in the world he's talking about.
If you look at a typical Java source file, you'll see that this is quite true. Excess of boilerplate code is quite usual for Java applications.
Again, no further comment, except to note that no one, I mean no one in business computing considers using Lisp.
Lisp is indeed considered, used, and deployed by businesses. Go and see it in action.
I expect that seniors and grads at MIT are very smart, but good software engineering discipline usually requires years to learn, even by the smartest cookies. To expect it after one semester is another clear sign of enormous naivete.
*moan*
I hear people using that argument to justify clumsy tools since the days when C++ became fashionable. Yes, you got to learn a lot to be a good developer, but when one tool takes eons longer to master (compared to existing alternatives) without any visible productivity boost in return, I say it is a poor tool.
I have no specific opinion on how viable Open Source software sales can or should be, but a sample size of one success is hardly scientific proof that it is a viable business for others to get into...
Yes, it makes no implications on how easy is to build a buisness around Open Source software, nor it illustrates what would be your chances of survival if you choose that path. It proves, however, that it possible to have a successful business selling OSS, which is fact of its own worth.
Remember the hordes of naysayers that predicted imminent death of RedHat, and all the armchair analysts declaring that there is no business model for Open Source.
There's probably a corollary of Henry Spencer's law about ignorant OS designers reinventing Unix (poorly) that applies to programming languages, although I haven't quite figured what the "target" language (the way Unix is the target OS) is.
:-P
"Any sufficiently-complicated C or Fortran program contains an ad-hoc, informally-specified bug-ridden slow implementation of half of Common Lisp."
Do they really burn O'Reilly Nutshell series there? Fascist pigs! As if they couldn't power it with 'The Road Ahead', 'Mein Kampf' or Clancy books instead..
You have the actual label on your boarding pass effectively saying that you are suspect? Ubelievably cynical! Even in late Soviet Uinon, where I happened to live good part of my life, authorities avoided to humiliate the citizens so openly. (And mind you, USSR wasn't exactly the place where personal freedoms were flourhising).
I sympathise you, and wish you best of luck. Hopefully your country will recover the freedoms and sanity that its dwellers were so proud of.
The original poster I replied to made the claim that no one should use older languages, and that everyone should use Java and C# because they solved all problems.
:)
Well, that was of course an overstatement. However, while not all security issues can be addressed at language level, typesafe languages definitely eliminate a very broad class of security flaws (buffer overruns) that plagues modern applications. I think it is safe to say that 70-80% of vulnerabilites found in modern software relate to bad old buffer overflows, and the root cause for them is, indeed, the widespread use of C and C++. Such defects are often found in high-profile projects written by competent developers, so this clearly suggests that we have a problem with tools and not humans here. Hence, while existing Java and C# implementations may not be the best tools for writing sofware with, C/C++ definitely aren't any better.
The interpreted nature of the bytecode used by these interpreters allows the interpreter, while translating the bytecode, to perform at-runtime checks which are harder -- but not impossible -- to do in precompiled code, but it is not a magical solution to every problem.
Here I should note that proper type inference in compilers allows to mostly eliminate run-time type checking.
But yes, there's no silver bullet.
The bytecode is then interpreted by a VM, so I call the javac/JVM combination an interpreted system, dammit.
Well, on my Pentium, machine code instructions are interpreted by CPU microcode, so I guess all depends on your point of view
I concede that an interpreted language ..
:)
There are no interpreted languages
fixes some problems because the nature of interpreted code makes it possible to catch some things at runtime (a benefit you lose to some extent when you use tools like GCJ)
Bounds checks are a function of language's type system, and are completely orthogonal to whether a particular implementation is compiled or interpreted.
And no, you don't lose that benifit to any extent with GCJ.
I stand by my statement that I would not want to write a low level VXD device driver in Java.
In this domain other considerations become significant (e.g. the absence of real-time garbage collector in modern Java implementations, code footprint size, compiler optimisation quality, inherently C-oriented Windows API, etc.). This, however, says nothing about the language per se.