In those cases, the legal action has been directed against the makers of alternative products. In this case, it seems to be against the people who've bought the product. (But in this case, is their argument that the two are the same thing?)
I can't help wondering whether, given the historical abuse, there ought to be a blanket defence of "fair competition" that can over-ride any such commercial restrictions, the same way some jurisdictions have "fair use" under copyright: you aren't allowed to break the ground rules, but contracts from a supplier can't unreasonably prevent you from using something for which you've paid in a reasonable manner.
bugs today aren't like bugs in pre-object oriented days
Why? I think bugs today are exactly like bugs in "pre-OO days". Modular code was a good idea then, and is still a good idea now, but I fail to see why OO has anything to do with it...
The costs explode. Again, in any sort of large corporate environment, a cost difference of 100:1 seems completely reasonable to me.
I think the key point behind your post is that you're considering the overall costs to a large scale outfit, including all the supporting infrastructure the company has to create to handle bugs from QA and customers. Perhaps a lot of people here are only considering the time spent directly by the development and QA teams themselves.
OTOH, with a smaller scale outfit the costs don't scale up nearly so fast. The "everyone knows everyone" effect within a small development shop, and good working relationships with your major clients so bugs are reported clearly and efficiently, both go a long way.
That was a great post, but I do disagree with this one part:
Fixing the bug itself probably costs about the same at every stage,
I think one of the reasons fixing bugs later on is more painful is that the developers who were intimately familiar with the code when they wrote it will have moved on, and will take time to get back up to speed. Worse yet, the original developers may have left, and unless they were of the rare breed who both write good comments and leave compact but complete high level documentation, no-one else will ever have quite the same insight into the hows and whys, making it less likely that any fix will be complete and reliable.
If a progression is exponential, it is logarithmic, and vice versa.
No, if a progression is exponential then the reverse of that progression would be logarithmic.
You're confusing "opposite" with "inverse". The next step after +n vs. -n and then n vs. 1/n might be e^n vs. logn.
Look at it another way. Exponential series grow faster than any polynomial. Logarithmic ones grow slower than any polynomial one. The two cannot be the same: arguably the most fundamental properties they have are opposites.
Should the company be liable for an engineer's errors (as is normally done in business)? Or should the individual or team be liable?
That's an interesting idea that goes right to the heart of how software development is done today. Realistically, at present, a company will have to be accountable for the errors, because if it were all pinned on an individual developer, no-one would risk taking on the job.
In a better world, software engineering (currently a rather offensive term to real engineers, and one of dubious legality in many places) would be done more like real engineering disciplines: ultimately, a qualified engineer would have to sign off on a product and take responsibility for it. However, that engineer would also have the authority to say "no" if management put unrealistic budget or time constraints on a project, and there'd be suitable support, insurance, etc, making his position realistic. Any code monkeys on a project are responsible to that engineer. They aren't liable if it all goes wrong, but if their work isn't up to the engineer's standards, they're deemed incompetent and shown the door.
The "real engineering" scenario is hardly out of this world, but the question is how you make the jump. You need a mechanism for recognising the skill, experience and professionalism of people who are good enough to be engineers. Most of the software developers in the world wouldn't even be close, but who's to decide who is and who isn't good enough?
Remember that you're talking about an industry where "best practices" are in constant competition with fads, and concrete examples often date within a decade. Compare that with, say, civil engineering, where best practices are based on thousands of years of experience, and concrete examples (sorry:-)) last for centuries. At that point you can see the problem with getting software engineering started, but once the ball is rolling, I think the software development world will be a much better place.
Now we're forced with a tough financial decision: do we spend a month or more carefully re-creating and testing the 'design exceptions', (probably 3-5 FTE years in total) or do we do it 'the right way' and break both our own and our customers' software? (again, several FTE years, but potentially loosing faith with the customers.)
In today's management-driven culture, that's easy: your managers have to decide what your customers will accept, and you do what they tell you.
In a more engineering-oriented culture, it's also easy: you do things properly. If your engineers could discuss the problem with their engineers, all sides would probably agree on this, and make the decision that is, in the long time, in the interests of both your company and your client, which is almost certainly to rework the broken system properly, from scratch if necessary.
Personally, I would always prefer to do that, since all my experience tells me that cleaning it up now will take less time than reliably fixing all the known bugs anyway, and will be much more effective at preventing similar "special case" bugs in future.
Agreed. I think there are two big issues to resolve before applying a patch.
Does it work, and not screw anything else up?
When can we apply it to box X without adversely affecting the normal operation of box X unduly?
The first point goes without saying: if you trust your company network to someone else's QA...
The second one is, in many ways, more serious than the first. Sure, it's smart to to update your desktop boxes, but they're relatively safe from most things anyway if they're sitting behind a good firewall and your security procedures are half-decent. There's not much point putting a PC on someone's desk if you're going to be interrupting their work all day to patch it.
Equally, you can't just patch and restart a critical server that's in use 24/7 on a frequent basis. Presumably you have some sort of back-up/redundancy set-up for that kind of box, but you might have to wait a while before you can switch things around to make a patch.
I think the key thing is to balance the risks: for this patch, how much testing do I need to do myself before I consider it trustworthy, how urgent is it that the patch be installed on each candidate machine, and how much disruption to each machine's operation will result?
OK, let me rephrase. If I were hiring someone and they were prepared to discuss anything in detail from their past employment that could clearly be prejudicial to that employer, whether or not explicitly covered by an NDA, then I would black mark them. I want someone to demonstrate their skills, and it's perfectly possible do so without giving any inappropriate information away. I'd give someone the benefit of the doubt, since inevitably I wouldn't know the specifics as you point out, but any clear case is going to make that hiring decision real quick.
Hmm... If I were interviewing someone who was willing to disclose information that they'd said in an NDA they wouldn't, my hiring decision would be real quick. The legal situation would be irrelevant to me: the moral character of the applicant is clear from that alone, and I don't want someone like that working for me.
...companies you worked for are pretty much obligated to verify the dates of your employment...
Nope. If they want to, they can hire you just because you made a really good impression in an interview.
I'd assumed the context was that a past employer was required to confirm to a prospective future employer that you really did work for them between certain dates, not that a prospective future employer was somehow required to do background checks on all job applicants. (Obviously, in some fields that is necessary, but not so in general AFAIK.)
I don't know the actual legal position, but dates of employment are among the few pieces of information just about anyone will give in an official reference.
I've yet to see a single book on C++ that starts using container classes right from the introduction chapters.
The only one I know about is "Accelerated C++", by Koenig and Moo. It has been widely acclaimed in the C++ community precisely because it does that.
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.
Well, reusing variables for multiple purposes is rarely a good idea, for buffers or anything else. At least if you're using a decent container class, you won't be able to inadvertently overrun whatever size you used last time.
Regarding API-intensive code, I've noted that most C++-based APIs that rely on complex data structures also provide their own container classes if they don't work with C++'s own standard ones. I've never found excessive boilerplate code to be a problem; in fact, I rarely find I need any non-trival boilerplate code to convert between datatypes at all.
I'd say C++ culture discourages the use of higher-level containers.
Culture is certainly a problem, it's true. 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.
The issue of libraries that use pointers, C-style strings and primitive arrays is a serious one. In fairness, however, it is easy to work with container classes most of the time, and convert the data to or from a lower-level format only at the point where you interface with an external library. Some libraries -- notably the major UI ones -- tend to provide their own container and string classes, and if you want to use those instead of the standard ones, there's nothing to say you can't. 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. IMHO, the problem isn't that people can't do this, it's just that they don't.
The fact that the average user can do nothing safely useful in C++ w/o STL further indicates to me that C++ is a wizard's tool.
I don't see how that makes any sense. It's like saying that the vast library in Java makes it a wizard's tool, yet without its extensive library, Java has precious little to recommend it over many other languages. It's like claiming that Perl would be just as useful a tool without CPAN.
C++ provides tools for low-level control (pointers, raw arrays, etc.) when you need them, but for most tasks, you don't. C++ also provides higher level tools (container classes, standard algorithms, exceptions, etc.) that should be used in that majority of cases. It doesn't take a rocket scientist to understand when to use which. It just takes reading a few pages of a good book. Trying to separate the tools out, as if one is somehow a legitimate part of C++ and the other is not, just doesn't make sense.
I agree 100% that there's an inevitable trade-off between power (in the sense of low level control) and safety (in the sense of never being able to do something stupid). The two goals are indeed contradictory, and C++ and Java certainly aim for, and achieve, a difference balance between them.
My objection was not to that comparison, but to the idea that either safety or abstraction was some sort of "on/off switch", rather than a continuous scale. That's not to say that I disagree with you when you say that reduced safety can undermine some of the benefits of better abstraction.
Yes, they really are. 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.
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.
"Seasoned" != "Good" in C++. That's my point.
If some design requires infallible humans to work properly, it's better to be reconsidered.
It doesn't require anything of the sort. It requires them to have read one chapter of one good book, or to have had a term of lectures from a competent tutor. The fact that most people using C++ have never read a good C++ book (mainly because most of the books on C++ are so bad) and most lecturers on C++ don't know their subject, is the root cause of all these problems. That's kinda my point.
I don't recall that. Most of the early hype generated on his arrival at Microsoft seemed to be trying to convince the "serious C++" crowd that Visual C++ was a "serious compiler", with respect for standards and the buzzword libraries like Boost and Loki, as well as Windows-based frameworks like MFC.
Where did you see/hear Herb's comments on standard compliance being a low priority? It seems pretty far out of character, and a significant change of tune from MS.
Don't worry, these are only Japanese martial artist robots. They'll have a devastating reverse punch, but while they throw it their other hand will be sitting on their hip, and our WesternBoxingBot(TM) will just counter with a hook to the unprotected head and K/O it. }:-)
(Posted with apologies to those not into martial arts, who don't get the Standard Issue MA Troll used for comedy value.)
Put down your keyboard. You have 20 seconds to comply.
No, wait...
[Ominous quiet voice] And you must never, ever feed them after midnight!
No, wait...
[Monotone machine voice] The Skynet Funding Bill is passed. The system goes on-line August 4, 1997. Human decisions are removed from strategic defence. Skynet begins to learn at a geometric rate. It becomes self-aware at 2:14am Eastern time, August 29. In a panic, they try to pull the plug.
No, wait...
Ah, the hell with it, there are just too many bad movie quotes to go after a post like that.:-/
I'm sorry, but I don't see how any sentence that compares abstraction and safety as if they're black and white can be insightful. C++ offers vastly more powerful tools for abstraction than Java (templates and deterministic destruction come immediately to mind) in exchange for modestly reduced safety (Java has a garbage collector, but it's a one trick pony). Saying that Java has both but C++ has only one in some absolute sense is just meaningless.
'Read what he's written about the C++200x standards revision cycle.' OK, fair enough, you do have evidence. Got a link?
I think perhaps there's a misunderstanding in the grandparent post. Stroustrup, and others on the standards committee, are on record as saying that they don't see the need for many language changes. They do, however, propose to make extensive library changes. Their reasoning is simply that there is likely to be more than one sensible way to approach topics such as, say, concurrency and synchronisation, and thus building them into the language itself is unduly limiting.
If you go to Stroustrup's home page (sorry, don't have a link handy, but it'll easily Google) and then look for his comments on C++0x, I'm guessing the slides from his presentation describing the above are still available.
Using 'm_fValue' for a member value of type float is foolish, because if you ever change the value to be of type double, or LibraryExtendedPrecisionDouble, your name is now worse than useless, it's misleading.
The same argument can be made against commenting your code.
Indeed it can. That is precisely why banner comments like this:
/*
some_function_name: Does some function
Parameters:
int firstThing -- the first thing it uses
char secondThing -- the other thing it uses
*/
are a very bad idea. Comments should describe what your code is doing, but not repeat information in the code itself. And yes, comments are overused; self-documenting code (with judicious use of tools like typedef in C++, and named temporary variables to make complex manipulations explicit) would make much of what gets written in comments redundant.
As for changing the type, yes, of course you should check everywhere that might be affected, but people don't. That's the problem. And yes, float vs. double can make a difference; mixing them up leads to hideous numerical analysis issues if you're not careful. It's good idea to use a double for everything anyway, unless you've got a compelling reason not to, but misleading names that might suggest two values, one a double and the other a float, are of the same accuracy, is just asking for trouble.
I take your point about labelling references in a class type. I was thinking more of the aliases used for convenience in functions.
How are you getting super efficient C code from your python programs?
Maybe he's writing the performance-critical parts in C, writing the main part of the code in the higher level language, and linking the two? This is a fairly standard approach to the performance problem, and works well enough provided you have the resource to use two languages and there's a decent interface available between them (which, when one of them is C, is almost always the case).
Seriously, you can't seriously improve a language by telling people how to program with it.
However, you very much can improve how a language is used by telling people how to program with it. The single biggest problem C++ has isn't dangerous pointers, or ugly template syntax, or lack of a garbage collector, it's lack of good programmer education. C++ is a power tool, and requires skill to use. When most of the C++ textbooks in the world are teaching decade-old crap themselves, and most of the university professors don't know their own subject, it's not too surprising.
I can sympathise a lot with Stroustrup here. 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. Others pick up on this, and learn from people who themselves learned badly, and write more code with kindergarten mistakes. It's about time the C++ programming industry reached High School, but few ever seem to, and when they do, they aren't valued as much as they should be.
Slashdot Mirror
In those cases, the legal action has been directed against the makers of alternative products. In this case, it seems to be against the people who've bought the product. (But in this case, is their argument that the two are the same thing?)
I can't help wondering whether, given the historical abuse, there ought to be a blanket defence of "fair competition" that can over-ride any such commercial restrictions, the same way some jurisdictions have "fair use" under copyright: you aren't allowed to break the ground rules, but contracts from a supplier can't unreasonably prevent you from using something for which you've paid in a reasonable manner.
Well, it's a great theory. :o)
Why? I think bugs today are exactly like bugs in "pre-OO days". Modular code was a good idea then, and is still a good idea now, but I fail to see why OO has anything to do with it...
I think the key point behind your post is that you're considering the overall costs to a large scale outfit, including all the supporting infrastructure the company has to create to handle bugs from QA and customers. Perhaps a lot of people here are only considering the time spent directly by the development and QA teams themselves.
OTOH, with a smaller scale outfit the costs don't scale up nearly so fast. The "everyone knows everyone" effect within a small development shop, and good working relationships with your major clients so bugs are reported clearly and efficiently, both go a long way.
That was a great post, but I do disagree with this one part:
I think one of the reasons fixing bugs later on is more painful is that the developers who were intimately familiar with the code when they wrote it will have moved on, and will take time to get back up to speed. Worse yet, the original developers may have left, and unless they were of the rare breed who both write good comments and leave compact but complete high level documentation, no-one else will ever have quite the same insight into the hows and whys, making it less likely that any fix will be complete and reliable.
No, if a progression is exponential then the reverse of that progression would be logarithmic.
You're confusing "opposite" with "inverse". The next step after +n vs. -n and then n vs. 1/n might be e^n vs. logn.
Look at it another way. Exponential series grow faster than any polynomial. Logarithmic ones grow slower than any polynomial one. The two cannot be the same: arguably the most fundamental properties they have are opposites.
That's an interesting idea that goes right to the heart of how software development is done today. Realistically, at present, a company will have to be accountable for the errors, because if it were all pinned on an individual developer, no-one would risk taking on the job.
In a better world, software engineering (currently a rather offensive term to real engineers, and one of dubious legality in many places) would be done more like real engineering disciplines: ultimately, a qualified engineer would have to sign off on a product and take responsibility for it. However, that engineer would also have the authority to say "no" if management put unrealistic budget or time constraints on a project, and there'd be suitable support, insurance, etc, making his position realistic. Any code monkeys on a project are responsible to that engineer. They aren't liable if it all goes wrong, but if their work isn't up to the engineer's standards, they're deemed incompetent and shown the door.
The "real engineering" scenario is hardly out of this world, but the question is how you make the jump. You need a mechanism for recognising the skill, experience and professionalism of people who are good enough to be engineers. Most of the software developers in the world wouldn't even be close, but who's to decide who is and who isn't good enough?
Remember that you're talking about an industry where "best practices" are in constant competition with fads, and concrete examples often date within a decade. Compare that with, say, civil engineering, where best practices are based on thousands of years of experience, and concrete examples (sorry :-)) last for centuries. At that point you can see the problem with getting software engineering started, but once the ball is rolling, I think the software development world will be a much better place.
In today's management-driven culture, that's easy: your managers have to decide what your customers will accept, and you do what they tell you.
In a more engineering-oriented culture, it's also easy: you do things properly. If your engineers could discuss the problem with their engineers, all sides would probably agree on this, and make the decision that is, in the long time, in the interests of both your company and your client, which is almost certainly to rework the broken system properly, from scratch if necessary.
Personally, I would always prefer to do that, since all my experience tells me that cleaning it up now will take less time than reliably fixing all the known bugs anyway, and will be much more effective at preventing similar "special case" bugs in future.
Agreed. I think there are two big issues to resolve before applying a patch.
The first point goes without saying: if you trust your company network to someone else's QA...
The second one is, in many ways, more serious than the first. Sure, it's smart to to update your desktop boxes, but they're relatively safe from most things anyway if they're sitting behind a good firewall and your security procedures are half-decent. There's not much point putting a PC on someone's desk if you're going to be interrupting their work all day to patch it.
Equally, you can't just patch and restart a critical server that's in use 24/7 on a frequent basis. Presumably you have some sort of back-up/redundancy set-up for that kind of box, but you might have to wait a while before you can switch things around to make a patch.
I think the key thing is to balance the risks: for this patch, how much testing do I need to do myself before I consider it trustworthy, how urgent is it that the patch be installed on each candidate machine, and how much disruption to each machine's operation will result?
OK, let me rephrase. If I were hiring someone and they were prepared to discuss anything in detail from their past employment that could clearly be prejudicial to that employer, whether or not explicitly covered by an NDA, then I would black mark them. I want someone to demonstrate their skills, and it's perfectly possible do so without giving any inappropriate information away. I'd give someone the benefit of the doubt, since inevitably I wouldn't know the specifics as you point out, but any clear case is going to make that hiring decision real quick.
Hmm... If I were interviewing someone who was willing to disclose information that they'd said in an NDA they wouldn't, my hiring decision would be real quick. The legal situation would be irrelevant to me: the moral character of the applicant is clear from that alone, and I don't want someone like that working for me.
I'd assumed the context was that a past employer was required to confirm to a prospective future employer that you really did work for them between certain dates, not that a prospective future employer was somehow required to do background checks on all job applicants. (Obviously, in some fields that is necessary, but not so in general AFAIK.)
I don't know the actual legal position, but dates of employment are among the few pieces of information just about anyone will give in an official reference.
The only one I know about is "Accelerated C++", by Koenig and Moo. It has been widely acclaimed in the C++ community precisely because it does that.
Well, reusing variables for multiple purposes is rarely a good idea, for buffers or anything else. At least if you're using a decent container class, you won't be able to inadvertently overrun whatever size you used last time.
Regarding API-intensive code, I've noted that most C++-based APIs that rely on complex data structures also provide their own container classes if they don't work with C++'s own standard ones. I've never found excessive boilerplate code to be a problem; in fact, I rarely find I need any non-trival boilerplate code to convert between datatypes at all.
Culture is certainly a problem, it's true. 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.
The issue of libraries that use pointers, C-style strings and primitive arrays is a serious one. In fairness, however, it is easy to work with container classes most of the time, and convert the data to or from a lower-level format only at the point where you interface with an external library. Some libraries -- notably the major UI ones -- tend to provide their own container and string classes, and if you want to use those instead of the standard ones, there's nothing to say you can't. 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. IMHO, the problem isn't that people can't do this, it's just that they don't.
I don't see how that makes any sense. It's like saying that the vast library in Java makes it a wizard's tool, yet without its extensive library, Java has precious little to recommend it over many other languages. It's like claiming that Perl would be just as useful a tool without CPAN.
C++ provides tools for low-level control (pointers, raw arrays, etc.) when you need them, but for most tasks, you don't. C++ also provides higher level tools (container classes, standard algorithms, exceptions, etc.) that should be used in that majority of cases. It doesn't take a rocket scientist to understand when to use which. It just takes reading a few pages of a good book. Trying to separate the tools out, as if one is somehow a legitimate part of C++ and the other is not, just doesn't make sense.
I agree 100% that there's an inevitable trade-off between power (in the sense of low level control) and safety (in the sense of never being able to do something stupid). The two goals are indeed contradictory, and C++ and Java certainly aim for, and achieve, a difference balance between them.
My objection was not to that comparison, but to the idea that either safety or abstraction was some sort of "on/off switch", rather than a continuous scale. That's not to say that I disagree with you when you say that reduced safety can undermine some of the benefits of better abstraction.
Yes, they really are. 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.
"Seasoned" != "Good" in C++. That's my point.
It doesn't require anything of the sort. It requires them to have read one chapter of one good book, or to have had a term of lectures from a competent tutor. The fact that most people using C++ have never read a good C++ book (mainly because most of the books on C++ are so bad) and most lecturers on C++ don't know their subject, is the root cause of all these problems. That's kinda my point.
I don't recall that. Most of the early hype generated on his arrival at Microsoft seemed to be trying to convince the "serious C++" crowd that Visual C++ was a "serious compiler", with respect for standards and the buzzword libraries like Boost and Loki, as well as Windows-based frameworks like MFC.
Where did you see/hear Herb's comments on standard compliance being a low priority? It seems pretty far out of character, and a significant change of tune from MS.
Don't worry, these are only Japanese martial artist robots. They'll have a devastating reverse punch, but while they throw it their other hand will be sitting on their hip, and our WesternBoxingBot(TM) will just counter with a hook to the unprotected head and K/O it. }:-)
(Posted with apologies to those not into martial arts, who don't get the Standard Issue MA Troll used for comedy value.)
Put down your keyboard. You have 20 seconds to comply.
No, wait...
[Ominous quiet voice] And you must never, ever feed them after midnight!
No, wait...
[Monotone machine voice] The Skynet Funding Bill is passed. The system goes on-line August 4, 1997. Human decisions are removed from strategic defence. Skynet begins to learn at a geometric rate. It becomes self-aware at 2:14am Eastern time, August 29. In a panic, they try to pull the plug.
No, wait...
Ah, the hell with it, there are just too many bad movie quotes to go after a post like that. :-/
I'm sorry, but I don't see how any sentence that compares abstraction and safety as if they're black and white can be insightful. C++ offers vastly more powerful tools for abstraction than Java (templates and deterministic destruction come immediately to mind) in exchange for modestly reduced safety (Java has a garbage collector, but it's a one trick pony). Saying that Java has both but C++ has only one in some absolute sense is just meaningless.
I think perhaps there's a misunderstanding in the grandparent post. Stroustrup, and others on the standards committee, are on record as saying that they don't see the need for many language changes. They do, however, propose to make extensive library changes. Their reasoning is simply that there is likely to be more than one sensible way to approach topics such as, say, concurrency and synchronisation, and thus building them into the language itself is unduly limiting.
If you go to Stroustrup's home page (sorry, don't have a link handy, but it'll easily Google) and then look for his comments on C++0x, I'm guessing the slides from his presentation describing the above are still available.
Indeed it can. That is precisely why banner comments like this:
some_function_name: Does some function
Parameters:
int firstThing -- the first thing it uses
char secondThing -- the other thing it uses */
are a very bad idea. Comments should describe what your code is doing, but not repeat information in the code itself. And yes, comments are overused; self-documenting code (with judicious use of tools like typedef in C++, and named temporary variables to make complex manipulations explicit) would make much of what gets written in comments redundant.
As for changing the type, yes, of course you should check everywhere that might be affected, but people don't. That's the problem. And yes, float vs. double can make a difference; mixing them up leads to hideous numerical analysis issues if you're not careful. It's good idea to use a double for everything anyway, unless you've got a compelling reason not to, but misleading names that might suggest two values, one a double and the other a float, are of the same accuracy, is just asking for trouble.
I take your point about labelling references in a class type. I was thinking more of the aliases used for convenience in functions.
Maybe he's writing the performance-critical parts in C, writing the main part of the code in the higher level language, and linking the two? This is a fairly standard approach to the performance problem, and works well enough provided you have the resource to use two languages and there's a decent interface available between them (which, when one of them is C, is almost always the case).
However, you very much can improve how a language is used by telling people how to program with it. The single biggest problem C++ has isn't dangerous pointers, or ugly template syntax, or lack of a garbage collector, it's lack of good programmer education. C++ is a power tool, and requires skill to use. When most of the C++ textbooks in the world are teaching decade-old crap themselves, and most of the university professors don't know their own subject, it's not too surprising.
I can sympathise a lot with Stroustrup here. 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. Others pick up on this, and learn from people who themselves learned badly, and write more code with kindergarten mistakes. It's about time the C++ programming industry reached High School, but few ever seem to, and when they do, they aren't valued as much as they should be.