And here's my $.02: C syntax has been actively harmful in this regard. It's too easy to make a typo that compiles, or to introduce a statement/expression that has a different result than you expect (e.g. the Apple "extra break statement" bug.)
The new captain has set a new course, one that veers away from the rocks. But this ship will take a long time and a lot of leeway to make that turn.
(Of course, I thought the old captain should have been 'relieved for cause' years ago, but since personally I'm neither a customer/user nor a direct shareholder in MSFT, it really wasn't my business:-)
My school had a one afternoon per week gifted students program. Among other things we did programmed/self paced instruction and classroom work on boolean algebra and basic number theory. This was in the late 1960s in a middle class school district in suburban Pittsburgh (Avonworth.)
The other thing worth noting is how most mathematicians make their breakthrough discoveries before age 30. (Sorry don't have the reference for this, but I've seen it widely discussed.) So that means the earlier we expose kids "with the math gene" to more complex topics, the greater the possibility that stuff will 'stick'.
From http://appleinsider.com/articl... "The most glaring inconsistency is a disconnect between Gartner's 70.4 million iPad sales and Apple's self-reported 74 million unit sales for 2013. From the first quarter — Apple's second fiscal quarter — to the fourth, the company reported iPad sales of 19.5 million, 14.6 million, 14.1 million and 26 million, respectively. The total: 74.2 million iPads sold during 2013. "
Note these numbers are reported by Apple on SEC filings, not on press releases.
If I'm configuring a laptop that I'll use for both work and vacation:
Default Folder (an add-on/replacement for the Open File dialog) Graphic Converter (photo manipulation application) Aquamacs (very well done MacOS version of EMACS) HDRtist Pro (HDR processing application) OmniGraffle (Mac equivalent to Visio, drawing package) Aperture (Photo organizing) 1Password (Password safe) DiskWarrior (File system maintenance) Syncovery (front end to rsync)
This doesn't include the stuff I find essential that's built into Mac OS X (and its Unix foundations, such as ssh and bash.)
And for what it's worth, I've been using Graphic Converter and Default Folder for at least 20 years, back to Mac OS 7 days. It says something about the quality/utility of these two applications that they've "stood the test of time."
and say anyone that doesn't understand EBNF probably doesn't need to be granted SuperUser privilege. If there are specific actions that should be permitted for trusted but unsophisticated users, set up scripts to do only those actions.
And I'll demonstrate my age by saying that Unix derivatives, including Linux, BSD, etc, etc, -have a long way to go- to match VMS for a truly useful/administrator-friendly privilege model.
True, but if your company's product is, for example, software - and that software company is being run by someone with a legal, financial, hardware, operations, or non-software engineering background, the problem is much more difficult. And that's what I'm seeing. First the engineers need to be able to think in terms of business objectives (one of the best courses I ever had was a grad course in "engineering economics"). But second, the management community (starting with the business schools) need to figure out how to train CxOs that actually -understand the business they're in-.
For the last 30+ years, I've been in the large scale systems business. Most, but not all of that has been on projects for the US DoD. I've been appalled by the number of senior executives, military/government, large industry, small industry, who fundamentally don't understand software-intensive systems. As my earlier post said, their software experience is encapsulated in some small-scale programming task, rather than in large scale software engineering. On the one hand, they expect software to perform miracles because "it's software, you can change it," while on the other hand they refuse to invest in software. For the former, the best quote is from a former co-worker, "The software engineer is the system engineer of last resort."
I'm reminded of a system I once reviewed where they had a 'software problem'. But it turned out they had a -networking problem-. They were trying to move large volumes of images over a 10BaseT ethernet connection, and wondered why they weren't getting system throughput. Their ethernet was usually well over 50% loaded and couldn't handle the data. But they expected the software to 'fix' this.
I've had the good fortune to work for several good managers, either as direct supervisors or as senior managers, up to the Corporate VP level. That includes people in small companies, in Fortune 500 companies, and even active duty Army officers.
What I've observed is that the top levels of management DO NOT want to listen to what the good engineering managers try to tell them, about topics like staff training and retention, schedules or resources (e.g. hardware/capital expenditures.) Instead, the CxO level people promote those who tell them what they want to hear. It's not universal, but many of the good managers I've had are products of deliberate leadership/management training, rather than being promoted from 'nerd' to 'boss' and left to figure it out on their own. Part of that training is how to talk to the CxO level and how to make arguments in terms of corporate business case, objectives, etc.
The only good news is that at least in this millennium, the number of top managers/CxOs who actually know something about software, has increased. They're still a minority, but you may well find a VP who understands that software isn't "that crappy stuff that always makes our systems late, so we'll 'fix' it by throwing more cheap bodies at it." (I got really tired of the engineering VPs whose experience was in hardware, and whose ideas of software systems engineering was framed by "that FORTRAN course I took in college...")
One interesting model that was popular in the early '90s may deserve another look. Some research labs* split managerial duties, separating technical leadership from administration. Where some organizations got into trouble with that model was not treating both classes of managers as equals. The technical leaders too often got marginalized, because the administrators were the ones that talked about the kinds of stuff CEO/CFO wanted to discuss. It takes a tremendous investment at the CxO level to institute a program that recognizes and grows technical leadership as distinct from, frankly, beancounting.
* It runs in my mind that DEC's Western Research Labs was one of the organizations that implemented this approach successfully.
As predicted by John Brunner's "Stand on Zanzibar" (http://en.wikipedia.org/wiki/Stand_on_Zanzibar ): a video system where your face is superimposed on the screen, showing you visiting exotic locations, participating in dramas, etc, etc?
Well, I have no use for Twitter, so I guess that rules me out as a customer for the site. Unlike some others here, I actually like David Pogue's writing.
Am I the the last person in the world who uses RSS readers to browse news sites for stories that I actually want to read? After all, 90% of everything is crap and I'm looking for efficient ways to find the 10%.
The visual clutter on that site is appalling, I thought Pogue had more taste than that.
We bought support. But to get support from organization X, that organization has to first admit it is -their problem-. Please re-read my post to see that no organization wanted to take ownership of the problem.
"having source code wouldn't have changed anything" Disagree. Particularly at interfaces (e.g. cross-language/cross-compiler calls, APIs to COTS products, etc), sometimes you need to see inside the product to figure out what's failing at the interface. It's nice to talk about omniscient knowledge on the part of product developers, API specifiers (who might not be the same as the API implementers), and customers/users of that API for that product. Our specification techniques are by no means rigorous enough to prevent these kinds of problems.
"Risk" means just that. It's not a guarantee of failure. Rather it's the possibility of failure, coupled with (multiplied by:-) the consequences of the failure occurring.
Here's a real-world example, not related to compiler problems per-se, but relevant to your comment:
We had developed Unix RPC code that worked just fine on several systems, including the commercial product the hardware vendor was proposing. When we got to the installation for test, the code didn't work. After going up to the General Officer/SES level, and across to the vendor senior VP, I was given a copy of the vendor's source code for their RPC library. I was able to step through their code to the actual kernel syscall, and most importantly was able to see the failure value returned by the syscall. (The RPC library took that value, converted it into an ERRNO value of "EACCES", -which didn't tell us -why- the error actually happened.)
When I saw the value of the syscall, which indicated a non-privileged (not root) process was trying to do something that required 'root' privilege, I was able to go back to the vendor and ask, "Did you implement extra security features for RPC?" After some hemming and hawing, they came back and said, "Yes, you have to be root to install an RPC service." More importantly, that security feature WAS NOT DOCUMENTED. (And I can understand the rationale for saying that only privileged/root accounts can install public RPC services, so this was not an unreasonable restriction, but it was a change from standard practice in Unix systems of the time.)
This is an example of (a) a situation where the interface failed, even though all of the -code- was correct; (b) the only way I found this was to step through the vendor library to figure out the problem was -missing documentation-.
Well, in part that depends on your market. Most of my work has been in military systems or air traffic systems, where the cost of failure >> lost opportunity cost. That's a point a lot of people forget; not all markets (and therefore the risk calculations for bugs, etc) are created equal.
Unfortunately, that's not unique to GCC. I've seen this happen with several different compliers for different programming languages over the years. Worse, I've seen it with the same compiler, but different Optimizer settings.
In one case, our system didn't work (segfaulted) with the optimizer engaged, and didn't meet timing requirements without the optimizer. And the problem wasn't in our code, it was in a commercial product we bought. The compiler vendor, the commercial product vendor (and the developer of that product, not the same company as we bought it from) and our own people spent a year pointing fingers at each other. No one wanted to (a) release source code and then (b) spend the time stepping through things at the instruction level to figure out what was going on.
And the lesson I learned from this: Any commercial product for which you don't have access to source code is an integration and performance risk.
Unless you suspect and are trying to debug a code generator error (one of the least pleasant/most difficult debugging experiences I've had), the base assertion that you should understand your compiler's code generation is at best unrealistic, and probably just dumb. Code generation is extremely complex, requiring deep knowledge of both this specific compiler's design and this specific computer's instruction set architecture, how the caches work, pre-fetching approaches, timing dependencies in instruction pipelines, etc, etc. If you do suspect a code generator error, you're best off hiring a compiler expert at least as a consultant, and be prepared for a long hard slog.
Maybe 30 years ago, for a PDP-8, you could assert that the C code you wrote had some semblance to the generated machine code. That hasn't been true for a very long time, and C++ is most definitely not C in this regard.
Slashdot Mirror
"We will hear and they will be punished!!!"
http://www.crosstalkonline.org...
And here's my $.02: C syntax has been actively harmful in this regard. It's too easy to make a typo that compiles, or to introduce a statement/expression that has a different result than you expect (e.g. the Apple "extra break statement" bug.)
Fair enough, and that begs the question whether the passengers on the ship could ever tell the difference...
The new captain has set a new course, one that veers away from the rocks. But this ship will take a long time and a lot of leeway to make that turn.
(Of course, I thought the old captain should have been 'relieved for cause' years ago, but since personally I'm neither a customer/user nor a direct shareholder in MSFT, it really wasn't my business :-)
My school had a one afternoon per week gifted students program. Among other things we did programmed/self paced instruction and classroom work on boolean algebra and basic number theory. This was in the late 1960s in a middle class school district in suburban Pittsburgh (Avonworth.)
The other thing worth noting is how most mathematicians make their breakthrough discoveries before age 30. (Sorry don't have the reference for this, but I've seen it widely discussed.) So that means the earlier we expose kids "with the math gene" to more complex topics, the greater the possibility that stuff will 'stick'.
From http://appleinsider.com/articl...
"The most glaring inconsistency is a disconnect between Gartner's 70.4 million iPad sales and Apple's self-reported 74 million unit sales for 2013. From the first quarter — Apple's second fiscal quarter — to the fourth, the company reported iPad sales of 19.5 million, 14.6 million, 14.1 million and 26 million, respectively. The total: 74.2 million iPads sold during 2013. "
Note these numbers are reported by Apple on SEC filings, not on press releases.
If I'm configuring a laptop that I'll use for both work and vacation:
Default Folder (an add-on/replacement for the Open File dialog)
Graphic Converter (photo manipulation application)
Aquamacs (very well done MacOS version of EMACS)
HDRtist Pro (HDR processing application)
OmniGraffle (Mac equivalent to Visio, drawing package)
Aperture (Photo organizing)
1Password (Password safe)
DiskWarrior (File system maintenance)
Syncovery (front end to rsync)
This doesn't include the stuff I find essential that's built into Mac OS X (and its Unix foundations, such as ssh and bash.)
And for what it's worth, I've been using Graphic Converter and Default Folder for at least 20 years, back to Mac OS 7 days. It says something about the quality/utility of these two applications that they've "stood the test of time."
One of the best novels about a realistic and mostly dysfunctional future set in 2010. http://en.wikipedia.org/wiki/S...
and say anyone that doesn't understand EBNF probably doesn't need to be granted SuperUser privilege. If there are specific actions that should be permitted for trusted but unsophisticated users, set up scripts to do only those actions.
And I'll demonstrate my age by saying that Unix derivatives, including Linux, BSD, etc, etc, -have a long way to go- to match VMS for a truly useful/administrator-friendly privilege model.
True, but if your company's product is, for example, software - and that software company is being run by someone with a legal, financial, hardware, operations, or non-software engineering background, the problem is much more difficult. And that's what I'm seeing. First the engineers need to be able to think in terms of business objectives (one of the best courses I ever had was a grad course in "engineering economics"). But second, the management community (starting with the business schools) need to figure out how to train CxOs that actually -understand the business they're in-.
For the last 30+ years, I've been in the large scale systems business. Most, but not all of that has been on projects for the US DoD. I've been appalled by the number of senior executives, military/government, large industry, small industry, who fundamentally don't understand software-intensive systems. As my earlier post said, their software experience is encapsulated in some small-scale programming task, rather than in large scale software engineering. On the one hand, they expect software to perform miracles because "it's software, you can change it," while on the other hand they refuse to invest in software. For the former, the best quote is from a former co-worker, "The software engineer is the system engineer of last resort."
I'm reminded of a system I once reviewed where they had a 'software problem'. But it turned out they had a -networking problem-. They were trying to move large volumes of images over a 10BaseT ethernet connection, and wondered why they weren't getting system throughput. Their ethernet was usually well over 50% loaded and couldn't handle the data. But they expected the software to 'fix' this.
I've had the good fortune to work for several good managers, either as direct supervisors or as senior managers, up to the Corporate VP level. That includes people in small companies, in Fortune 500 companies, and even active duty Army officers.
What I've observed is that the top levels of management DO NOT want to listen to what the good engineering managers try to tell them, about topics like staff training and retention, schedules or resources (e.g. hardware/capital expenditures.) Instead, the CxO level people promote those who tell them what they want to hear. It's not universal, but many of the good managers I've had are products of deliberate leadership/management training, rather than being promoted from 'nerd' to 'boss' and left to figure it out on their own. Part of that training is how to talk to the CxO level and how to make arguments in terms of corporate business case, objectives, etc.
The only good news is that at least in this millennium, the number of top managers/CxOs who actually know something about software, has increased. They're still a minority, but you may well find a VP who understands that software isn't "that crappy stuff that always makes our systems late, so we'll 'fix' it by throwing more cheap bodies at it." (I got really tired of the engineering VPs whose experience was in hardware, and whose ideas of software systems engineering was framed by "that FORTRAN course I took in college...")
One interesting model that was popular in the early '90s may deserve another look. Some research labs* split managerial duties, separating technical leadership from administration. Where some organizations got into trouble with that model was not treating both classes of managers as equals. The technical leaders too often got marginalized, because the administrators were the ones that talked about the kinds of stuff CEO/CFO wanted to discuss. It takes a tremendous investment at the CxO level to institute a program that recognizes and grows technical leadership as distinct from, frankly, beancounting.
* It runs in my mind that DEC's Western Research Labs was one of the organizations that implemented this approach successfully.
and was recovering from all the partying and travel back to the Moon.
(Seriously, great news!)
and smiling... http://en.wikipedia.org/wiki/J...
Does this count as a Heisenfix?
As predicted by John Brunner's "Stand on Zanzibar" (http://en.wikipedia.org/wiki/Stand_on_Zanzibar ): a video system where your face is superimposed on the screen, showing you visiting exotic locations, participating in dramas, etc, etc?
Mod parent up +1 -Insightful- :-)
Well, I have no use for Twitter, so I guess that rules me out as a customer for the site. Unlike some others here, I actually like David Pogue's writing.
Mod parent up insightful. (My mod points ran out Monday...)
Am I the the last person in the world who uses RSS readers to browse news sites for stories that I actually want to read? After all, 90% of everything is crap and I'm looking for efficient ways to find the 10%.
The visual clutter on that site is appalling, I thought Pogue had more taste than that.
Obviously you believe you're more qualified in contract law than the lawyers who were involved. Good on you.
We bought support. But to get support from organization X, that organization has to first admit it is -their problem-. Please re-read my post to see that no organization wanted to take ownership of the problem.
"having source code wouldn't have changed anything" Disagree. Particularly at interfaces (e.g. cross-language/cross-compiler calls, APIs to COTS products, etc), sometimes you need to see inside the product to figure out what's failing at the interface. It's nice to talk about omniscient knowledge on the part of product developers, API specifiers (who might not be the same as the API implementers), and customers/users of that API for that product. Our specification techniques are by no means rigorous enough to prevent these kinds of problems.
"Risk" means just that. It's not a guarantee of failure. Rather it's the possibility of failure, coupled with (multiplied by :-) the consequences of the failure occurring.
Here's a real-world example, not related to compiler problems per-se, but relevant to your comment:
We had developed Unix RPC code that worked just fine on several systems, including the commercial product the hardware vendor was proposing. When we got to the installation for test, the code didn't work. After going up to the General Officer/SES level, and across to the vendor senior VP, I was given a copy of the vendor's source code for their RPC library. I was able to step through their code to the actual kernel syscall, and most importantly was able to see the failure value returned by the syscall. (The RPC library took that value, converted it into an ERRNO value of "EACCES", -which didn't tell us -why- the error actually happened.)
When I saw the value of the syscall, which indicated a non-privileged (not root) process was trying to do something that required 'root' privilege, I was able to go back to the vendor and ask, "Did you implement extra security features for RPC?" After some hemming and hawing, they came back and said, "Yes, you have to be root to install an RPC service." More importantly, that security feature WAS NOT DOCUMENTED. (And I can understand the rationale for saying that only privileged/root accounts can install public RPC services, so this was not an unreasonable restriction, but it was a change from standard practice in Unix systems of the time.)
This is an example of (a) a situation where the interface failed, even though all of the -code- was correct; (b) the only way I found this was to step through the vendor library to figure out the problem was -missing documentation-.
Mark parent -1 troll.
That comment just demonstrates you don't know much about these kinds of markets.
Well, in part that depends on your market. Most of my work has been in military systems or air traffic systems, where the cost of failure >> lost opportunity cost. That's a point a lot of people forget; not all markets (and therefore the risk calculations for bugs, etc) are created equal.
Unfortunately, that's not unique to GCC. I've seen this happen with several different compliers for different programming languages over the years. Worse, I've seen it with the same compiler, but different Optimizer settings.
In one case, our system didn't work (segfaulted) with the optimizer engaged, and didn't meet timing requirements without the optimizer. And the problem wasn't in our code, it was in a commercial product we bought. The compiler vendor, the commercial product vendor (and the developer of that product, not the same company as we bought it from) and our own people spent a year pointing fingers at each other. No one wanted to (a) release source code and then (b) spend the time stepping through things at the instruction level to figure out what was going on.
And the lesson I learned from this: Any commercial product for which you don't have access to source code is an integration and performance risk.
Mod parent up +1 insightful.
Unless you suspect and are trying to debug a code generator error (one of the least pleasant/most difficult debugging experiences I've had), the base assertion that you should understand your compiler's code generation is at best unrealistic, and probably just dumb. Code generation is extremely complex, requiring deep knowledge of both this specific compiler's design and this specific computer's instruction set architecture, how the caches work, pre-fetching approaches, timing dependencies in instruction pipelines, etc, etc. If you do suspect a code generator error, you're best off hiring a compiler expert at least as a consultant, and be prepared for a long hard slog.
Maybe 30 years ago, for a PDP-8, you could assert that the C code you wrote had some semblance to the generated machine code. That hasn't been true for a very long time, and C++ is most definitely not C in this regard.