This book is without question the best science book I have ever read. But maybe it was too thick for Entertainment Weekly and its readership to consider...
Other candidates include just about anything from Stephen Jay Gould, Steven Hawking or Richard Feynman. I'm not into biology, but I'm sure there are great titles from biology/medicine.
If you include math as a 'science' for science writing, Mario Livio writes brilliantly, too. "Godel, Escher, Bach" actually doesn't qualify, since I bought my copy more than 25 years ago. (I had to special-order it and got a really weird look from the bookseller when it came in. A couple months later it was on the best-seller list. I just smiled...)
Also if you cover engineering in the category, then anything from Henry Petrosky would also have to be on the intelligent person's shortlist.
In retribution, the US will start sending unsolicited bills to Canadians for US cultural imperialistic products such as the Swimsuit Edition of SportsIlustrated, etc...
And if that doesn't work, we'll impound your hockey teams:-)
Yeah, I agree with this assessment. It would have been -very helpful- if they provided something like port numbers or other manifestations of infection. I was also looking for some understanding of the distribution of vulnerabilities, in particular any evidence that this mess has gone beyond Windows desktops.
To me it seems that the primary thing we need to do is figure out how to patch all those vulnerable Windows machines that facilitate this kind of crap.
Okay, so calling HyperStudio "programming" is a stretch, but it was definitely a gateway drug for it.
I remember building some fairly complex things in Hypercard, and I'd certainly call Hypertalk a rich and also fascinating programming language. When we were looking at SOA orchestration approaches, I used Hypertalk as an alternative to the current set of XML-based, damned-impossible-to-read set of popular orchestration languages.
Hypertalk is 'object oriented' in a way that I haven't seen in main-line languages, and that in some respects (IMHO) reflects the poor state of language design as much as anything else.
Of course Hypertalk begat AppleScript, and although I find Applescript frustrating at times, it's worth the effort.
It is interesting to contemplate a merger of Python and Hypertalk/AppleScript...
I had an APS clone that used the Motorola board, and I had no problems with that machine. Since that wasn't an Apple product, I didn't count that as one of my 15 machines...
I used good-quality RAM and drives (including a "hot drive" for the time, an enterprise-class fast-wide SCSI drive and Adaptec board:-)
Seriously, one would think that the substantial investment in IT support and consulting in India would result in a national capability to defend itself against this kind of stuff...
What is the real requirement that would make you pick Macs over Linux or Windows? 1. Ease of use.
2. Reliability, both HW and SW. (See my earlier posting on HW experiences.)
3. NO fscking viruses, spyware, etc to worry about. (When there's a real threat -and- a counter shown to be -safe and effective-, I'll buy it. Until then, no point screwing up the machine with anti-virus software that doesn't protect against any serious threats...)
4. Expertise on the platform. I can use Windows, but I'm much better on the Mac for GUI-like things, and when I need to, there's always the Terminal for all the Unix commands I know. (And Aquamacs is my preferred text editor, a great Mac port of Emacs...)
5. Ease of customization. This is related to ease of use, but is worthy of a comment itself. I can set things up the way I want to, in part because of the Mac's support for doing so, and in part because the corporate IT Nazis don't understand them well enough to prevent me... Don't get me started on Corporate IT departments, whose primary goal it seems to be to make everyone else's jobs harder to make their jobs easier; the opposite of 'service'...
6. Software/Hardware investment. I have -a lot- of stuff for the Mac, both commercial and shareware. Duplicating that in Windows would cost more than the computer itself.
When I changed jobs, I told my new boss that I did not want to use Windows. He responded, "Look, you get what makes -you productive-. You're the one making money for the company, not corporate IT."
All this dates to before the Intel Mac and the rise of virtualization. I have -one- customer application that I'm required to run on Windows. I also have occasional problems opening supposedly compatible Microsoft documents created on Windows Office on the Mac (but NewOffice usually opens them when Mac Office crashes... Go figure!)
I still don't understand why IT departments pay $$$$ for Exchange Server when the Open Source/Open Standards alternatives are
(a) A LOT cheaper
(b) A LOT more reliable
Well, out of the 15 Macs I've owned, only 3 have ever needed repairs. The two laptops were covered under AppleCare extended warranty, and the desktop failed within the 1 year standard warranty:
My previous Powerbook lost a motherboard while I was on the road. I dropped it off at the Newport Beach CA Apple Store about 7:00 PM Thursday night, and it was shipped back to my Tyson's Corner VA store by the following Tuesday afternoon.
That same Powerbook had its screen latch break twice. Both times I drove from Northern VA to a Mac authorized repair place in Bethesda for a while-you-wait repair.
Considering that PowerBook lasted 3 1/2 years of 80% travel, it was entitled to have a few problems. The latch was more than cosmetic, but did not prevent me from using it.
A refurb G5 had a motherboard problem that was repaired in 48 hours, again at the Tyson's VA Apple Store.
A couple of weeks ago, my MacBook Pro hard drive failed. They had the replacement in stock at the Tyson's Apple Store and I got it back in about 4 hours. (A good thing, since I was getting ready to leave for CA again the next day...)
I have had 3rd party memory and 3rd party disk drives go bad, but that's not Apple's fault.
I've also had 2 PowerBook power supplies replaced under extended warranty.
During the same period that I had that PowerBook, I don't think -anyone- with a Windows laptop (Dell, Toshiba, etc) had one last more than about 2 1/2 years under the same travel regime. And when theirs failed, there was no Dell store/Toshiba store to go for help.
Of course, your mileage may vary, but I get pretty good service out of my Macs. The desktops last an average of 4-5 years before I replace them, the laptops are supposedly on a 3 year replacement schedule but I'll usually keep them a bit longer since they're bought from company overhead.
People rarely add apples to oranges. But they often screw up and add count-of-apples to count-of-oranges, i.e. most type errors are made with scalar types. And that's a problem I have with Java. In Ada everything can be strongly typed (and you learn from experience just how valuable typing scalars can be after a while...)
In C, things like typedef and lint can be your friends here.
But in Java, scalars are weakly typed, and I haven't seen any practical way to add this on, e.g. with a standardized pre-processor. I think that's a significant weakness in Java.
dave
Productivity (or the lack thereof)
on
The Return of Ada
·
· Score: 1
Here's another Ada experience:
Where I used to work, we did an IR&D project on incremental formal verification, using SPARK (a provably correct subset of Ada, see http://www.praxis-his.com/sparkada/ ) We were implementing a subset of the SCPS protocol, a variation on TCP designed for satellites and large latency networks. I coded the sequential processing in SPARK, and added 'normal Ada' for the concurrent/timing related aspects. (This is before SPARK added support for concurrency.) As our control, another guy with experience doing protocols coded the same stuff in C.
One thing we needed to code was the timeout in TCP/SCPS, i.e. "send a message and wait N milliseconds. If you timeout, generate an error." I knew this should be doable with Ada95 Asynchronous Transfer of Control, a feature of the language I hadn't used before. I read the RM, talked to Ben Brosgol:-), and then wrote 5 lines of code. The 'control' doing his code in C spent the same amount of time writing 200 lines of code.
Guess which implementation had a bug in it?
But by conventional cost/size/effort/productivity models, he was 40 times more productive that week than I...
What happens with experience in Ada is that you learn how to code to let hte computer do a lot of these kinds of checks. You concentrate on what the compiler canNOT check. Then when you think you're done with your work, you start running code through the compiler, working off the errors that the compiler catches.
When both you and the compiler agree the code is correct, it -usually is-, because you let the compiler take care of some stuff so you don't have to.
That's not surprising, since the use of '42' is an artifact of the Ada binding, and those systems do not by default contain an implementation of 1003.5/9945. They should, but that's another story. Ada actually meshes very nicely with Unix, and is a good choice for system-level programming above the kernel level. Strong Typing -is your friend-! (I've been doing library level system programming on Unix systems, starting with Ultrix in 1984...)
The standard Linux/Solaris Ada compiler is the GNU Ada Compiler, http://www.gnat.com
But at least it's good to know there isn't a conflict.
Many studies (e.g. the Bell Labs 5-ESS fault analysis) and anecdotal stories indicate that failing to check the error return on a system call (or any other function, for that matter) is all-too-common. Adding to this problem, when a system call fails, often the manifestation/error/seg fault is not at that point of call, but further down, when a pointer/variable you expect to have meaningful data is null/garbage...
That's why, when we did the Ada Binding to POSIX (IEEE 1003.5/ ISO 9945), we decided to accept the overhead of imposing exceptions for system call error returns (in most cases). You can't ignore the exception!
This raised two interesting concerns that we discussed when developing the standard:
1. What about tasking/threads/concurrency? The requirement on the implementation was to set up per-task errno values. From an implementation perspective, this meant that you needed to go outside of the standard interface to correctly implement POSIX/Ada, as you needed to grab the errno value and load it into task-specific storage, or require that your underlying POSIX threads implementation (if that's how you built the Ada runtime) do that for you. In practice, this is not too onerous, and it's proven to be a real boon for ensuring proper behavior (including debugging) in a multithreaded/multitasking environment.
2. We also needed to think about the situation (usually representing really poor programming) where an unhandled exception (from a system call, an application call, or a language predefined exception) rips up the callstack and terminates the process. We wanted a return value from the process exit that would be 'close to 1 but not collide with commonly used values.' The number we chose: 42 (with the appropriate citation in the bibliography:-)
So sure, a C++ program can use the C binding, but I think defining and using C++ exceptions in a better C++ interface would be preferred.
dave (Tech Editor for the original IEEE P1003.5 project...)
First, since I'm running a Mac, I'm frankly not worried about all that shit that impacts Windows PCs. And there have been times when I've had to rebuild my Mac, back in OS9 days, usually due to low level disk problems. The key word there is "I", as in "I've had to rebuild my Mac." Whenever Corporate gave me a new machine, the first thing I'd do is strip it to bare metal, reformat the disk drive to the way I wanted it, and then ran successfully from there. (I'd reformat to 2 partitions, the second holding a shadow copy of the OS that I would use for standalone tools and as a boot partition to rebuild the primary user partition, if that become necessary...)
Second, as a responsible technically informed user, I accept the responsibility. If you treat people like children, don't be surprised when they act that way. In 20 years of Mac usage, the only real problems I had with viruses are Microsoft Word macro viruses. I have had unstable software combinations, but that's generally been of my own doing, so I'd go fix it. And if I didn't understand how to fix it, that's where the 'group support' came in. That worked -a lot better- than the support people were getting on their Windows PCs from the so-called experts who got paid by the hour to manage them.
I object to being billed either explicitly or implicitly (as overhead charges or worse as the Nazification of my machine) by the IT department for services that I don't need, didn't ask for, and would prefer to not have. As I said, I'd rather the IT people spend their times writing quality applications than having to screw around with desktops...
Case in point: Y2K remediation. Corporate IT charged 1 hour for Macs, 2 for Windows. Most Mac users I know did it themselves in 1/2 hour or less (not trusting the Corporate Windows-based IT staff to mess with the Macs.) I don't know of anyone in our department who got his Windows computer completely done in less than 4 hours (by Corporate IT or by himself, and we did have some very knowledgeable Windows 'power users') A lot of that time was spent in searching for new things to be updated, then suffering through multiple reboots to apply the patches.
This was in a group of software and systems engineer. In an office where everyone is doing the same function with the same set of applications, things could well work differently. But again I don't want Corporate IT to treat me like a moron.
Hell, I'll take the CIO's money! In exchange, he has to deliver -working cross-platform applications-, and stop running my shop for his convenience.
Then I'll equip each user with the 'right machine', and 'right' here is specifically keyed to user's preference and ability to support that preference.
That reminds me of the under-the-table deal I had with my Unix system administrator. I had a trap door to root access and as long as I gave him no cause to ask "how did you do that?" he wouldn't ask me about it. (That placed the obligation on me to keep within my knowledge, usually fix file permissions, restart print and mail queues and kill runaway user processes. As soon as I screwed something up as root, he'd have to ask how I was able to do that, and then would take it away from me. It never happened... This was during the famous Morris Internet Worm, and since I was able to shut down my machine without a lot of overhead in 'mid infection', the forensics team started their analysis by looking at my machine and its "being infected" state.)
At least the last 3 places I've worked. The Mac community helped itself out, at the largest site we had one formally trained Mac tech support person covering probably 150 or more Macs.
Then another place I worked, the one time the tech support people touched my Mac, they screwed it up...
On the other side, I watched an employee of a Fortune 50 company visit another company's location, where the latter would assign you a specific IP address to use. This guy didn't have enough privileges on his Windows box to configure the IP address on it, and of course his corporate help(less) desk's attitude was that they had to have the machine hooked up to the internet to remotely administer it. Catch-22...
Dilbert's "Mordac, Preventer of Information Services" is unfortunately the way of life for most corporate IT departments. When I'm King, every CIO will provide each employee with a charge number against the CIO's budget, when an IT problem prevents that employee from doing productive work.
Just about anyone who learned Ada has written tasking programs, even if they're just little toys to learn the syntax for creating tasks and synchronizing them using rendezvous. That's a form of concurrency, based on MIMD. And it's one with substantial (25 years) experience in usage and implementation (as I mentioned in another post on this thread.)
On a related note, Ada facilitated a lot of the work on scheduling in the late 80s, such as Rate Monotonic, by providing a solid, well-defined, easy-to-use notation for concurrency that allowed people to quickly sketch out a problem (often explaining why they didn't like this feature or that feature of Ada), and then concentrate on a solution for that problem.
So all-of-a-sudden people have discovered parallelism? Gee, one of the really interesting things about Ada in the late 80s was its use on multiprocessor systems such as those produced by Sequent and Encore. There was a lot of work on the language itself (that went into Ada95) and on compiler technologies to support 'safe parallelism'. "Safe" here means 'correct implementation' against the language standard, considering things like cache consistency as parts of programs get implemented in different CPUs, each with its own cache.
Here are a couple of lessons learned from that Ada experience: 1. Sometimes you want synchronization, and sometimes you want avoidance. Ada83 Tasking/Rendezvous provided synchronization, but was hard to use for avoidance. Ada95 added protected objects to handle avoidance. 2. In Ada83, aliasing by default was forbidden, which made it a lot easier for the compiler to reason about things like cache consistency. Ada95 added more pragmas, etc, to provide additional control on aliasing and atomic operations. 3. A lot of the early experience with concurrency and parallelism in Ada learned (usually the hard way) that there's a 'sweet spot' in the number of concurrent actions. Too many, and the machine bogs down in scheduling and synchronization. Too few, and you don't keep all of the processors busy. One of the interesting things that Karl Nyberg worked on in his Sun T1000 contest review was the tuning necessary to keep as many cores as possible running. (http://www.grebyn.com/t1000/ ) (Disclosure: I don't work for Grebyn, but I do have an account on grebyn.com as a legacy of the old days when they were in the ISP business in the '80s, and Karl is an old friend of very long standing....)
All this reminds me of a story from Tracy Kidder's Soul of a New Machinehttp://en.wikipedia.org/wiki/The_Soul_of_a_New_Machine. There was an article in the trade press pointing to an IBM minicomputer, with the title "IBM legitimizes minicomputers". Data General proposed (or ran, I forget which) an ad that built on that article, saying "The bastards say, 'welcome' ".
I am not a Lawyer, but... It sure seems to me that the clearly related actions that associate RIAA & their investigators -with the subsequent lawsuits by one of the Big 4' would make a reasonable case for a -linked conspiracy-. Clearly the actions of the record companies in the actual filing of the lawsuits is not independent/coincidental from the RIAA actions or the actions of the investigators (and it's not clear who those investigators work for. If they're under contract to RIAA and then RIAA transfers the info to a record company, and does this routinely, that's a pretty strong connection...)
But maybe someone with more knowledge of the law can comment on the 'burden of proof' to connect RIAA to the record labels, for the sake of punitive actions (damages and maybe even better/worse...)
Microsoft Labs has done some really great stuff. But you don't see it in their products. That's why I have a really hard time believing MS can -execute- what Bill Gates proposed.
If you look at MS's desktop products, in particular, you see a pattern of buying a good product and then as part of integrating it, making it more and more baroque and buggy and security-vulnerable.
Reminds me of the comment I read somewhere during the MS anti-trust debates: "If Microsoft is so keen on innovation, fine. The decision of the court should be that Microsoft is free to innovate using ONLY their internal resources, but is restricted from acquiring any technology from other sources. This enables the Market to work better, by allowing innovations to move freely." I had friends working on a start-up, when Microsoft announced a potential competitor piece of -vapor-ware-, their funding dried up immediately, and MS never did deliver the goods...
Slashdot Mirror
This book is without question the best science book I have ever read. But maybe it was too thick for Entertainment Weekly and its readership to consider...
Other candidates include just about anything from Stephen Jay Gould, Steven Hawking or Richard Feynman. I'm not into biology, but I'm sure there are great titles from biology/medicine.
If you include math as a 'science' for science writing, Mario Livio writes brilliantly, too. "Godel, Escher, Bach" actually doesn't qualify, since I bought my copy more than 25 years ago. (I had to special-order it and got a really weird look from the bookseller when it came in. A couple months later it was on the best-seller list. I just smiled...)
Also if you cover engineering in the category, then anything from Henry Petrosky would also have to be on the intelligent person's shortlist.
dave
So when do we see Denon $500 CD blanks?
I bare my registry at you!
I portscan in your full IP subnet range!
Your father was an Atari, and your GUI smells of X Windows!
No go away or I will CERT you a Second Time, you silly Mac Person You!
dave
Well the question is, when Microsoft embraces you, are you facing forward or backward?
dave
But the question is whether the Canadian Parliament voted him any money to buy ammunition...
dave
In retribution, the US will start sending unsolicited bills to Canadians for US cultural imperialistic products such as the Swimsuit Edition of SportsIlustrated, etc...
:-)
And if that doesn't work, we'll impound your hockey teams
dave
Yeah, I agree with this assessment. It would have been -very helpful- if they provided something like port numbers or other manifestations of infection. I was also looking for some understanding of the distribution of vulnerabilities, in particular any evidence that this mess has gone beyond Windows desktops.
To me it seems that the primary thing we need to do is figure out how to patch all those vulnerable Windows machines that facilitate this kind of crap.
dave
Okay, so calling HyperStudio "programming" is a stretch, but it was definitely a gateway drug for it.
I remember building some fairly complex things in Hypercard, and I'd certainly call Hypertalk a rich and also fascinating programming language. When we were looking at SOA orchestration approaches, I used Hypertalk as an alternative to the current set of XML-based, damned-impossible-to-read set of popular orchestration languages.Hypertalk is 'object oriented' in a way that I haven't seen in main-line languages, and that in some respects (IMHO) reflects the poor state of language design as much as anything else.
Of course Hypertalk begat AppleScript, and although I find Applescript frustrating at times, it's worth the effort.
It is interesting to contemplate a merger of Python and Hypertalk/AppleScript...
dave
Just providing a pointer to this summary on Macworld: [http://www.macworld.com/article/133293/2008/05/consumer.html]
dave
I had an APS clone that used the Motorola board, and I had no problems with that machine. Since that wasn't an Apple product, I didn't count that as one of my 15 machines...
:-)
I used good-quality RAM and drives (including a "hot drive" for the time, an enterprise-class fast-wide SCSI drive and Adaptec board
dave
Seriously, one would think that the substantial investment in IT support and consulting in India would result in a national capability to defend itself against this kind of stuff...
dave
2. Reliability, both HW and SW. (See my earlier posting on HW experiences.)
3. NO fscking viruses, spyware, etc to worry about. (When there's a real threat -and- a counter shown to be -safe and effective-, I'll buy it. Until then, no point screwing up the machine with anti-virus software that doesn't protect against any serious threats...)
4. Expertise on the platform. I can use Windows, but I'm much better on the Mac for GUI-like things, and when I need to, there's always the Terminal for all the Unix commands I know. (And Aquamacs is my preferred text editor, a great Mac port of Emacs...)
5. Ease of customization. This is related to ease of use, but is worthy of a comment itself. I can set things up the way I want to, in part because of the Mac's support for doing so, and in part because the corporate IT Nazis don't understand them well enough to prevent me... Don't get me started on Corporate IT departments, whose primary goal it seems to be to make everyone else's jobs harder to make their jobs easier; the opposite of 'service'...
6. Software/Hardware investment. I have -a lot- of stuff for the Mac, both commercial and shareware. Duplicating that in Windows would cost more than the computer itself.
When I changed jobs, I told my new boss that I did not want to use Windows. He responded, "Look, you get what makes -you productive-. You're the one making money for the company, not corporate IT."
All this dates to before the Intel Mac and the rise of virtualization. I have -one- customer application that I'm required to run on Windows. I also have occasional problems opening supposedly compatible Microsoft documents created on Windows Office on the Mac (but NewOffice usually opens them when Mac Office crashes... Go figure!)
I still don't understand why IT departments pay $$$$ for Exchange Server when the Open Source/Open Standards alternatives are
(a) A LOT cheaper
(b) A LOT more reliable
dave
Well, out of the 15 Macs I've owned, only 3 have ever needed repairs. The two laptops were covered under AppleCare extended warranty, and the desktop failed within the 1 year standard warranty:
My previous Powerbook lost a motherboard while I was on the road. I dropped it off at the Newport Beach CA Apple Store about 7:00 PM Thursday night, and it was shipped back to my Tyson's Corner VA store by the following Tuesday afternoon.
That same Powerbook had its screen latch break twice. Both times I drove from Northern VA to a Mac authorized repair place in Bethesda for a while-you-wait repair.
Considering that PowerBook lasted 3 1/2 years of 80% travel, it was entitled to have a few problems. The latch was more than cosmetic, but did not prevent me from using it.
A refurb G5 had a motherboard problem that was repaired in 48 hours, again at the Tyson's VA Apple Store.
A couple of weeks ago, my MacBook Pro hard drive failed. They had the replacement in stock at the Tyson's Apple Store and I got it back in about 4 hours. (A good thing, since I was getting ready to leave for CA again the next day...)
I have had 3rd party memory and 3rd party disk drives go bad, but that's not Apple's fault.
I've also had 2 PowerBook power supplies replaced under extended warranty.
During the same period that I had that PowerBook, I don't think -anyone- with a Windows laptop (Dell, Toshiba, etc) had one last more than about 2 1/2 years under the same travel regime. And when theirs failed, there was no Dell store/Toshiba store to go for help.
Of course, your mileage may vary, but I get pretty good service out of my Macs. The desktops last an average of 4-5 years before I replace them, the laptops are supposedly on a 3 year replacement schedule but I'll usually keep them a bit longer since they're bought from company overhead.
dave
People rarely add apples to oranges. But they often screw up and add count-of-apples to count-of-oranges, i.e. most type errors are made with scalar types. And that's a problem I have with Java. In Ada everything can be strongly typed (and you learn from experience just how valuable typing scalars can be after a while...)
In C, things like typedef and lint can be your friends here.
But in Java, scalars are weakly typed, and I haven't seen any practical way to add this on, e.g. with a standardized pre-processor. I think that's a significant weakness in Java.
dave
Here's another Ada experience:
:-), and then wrote 5 lines of code. The 'control' doing his code in C spent the same amount of time writing 200 lines of code.
Where I used to work, we did an IR&D project on incremental formal verification, using SPARK (a provably correct subset of Ada, see http://www.praxis-his.com/sparkada/ ) We were implementing a subset of the SCPS protocol, a variation on TCP designed for satellites and large latency networks. I coded the sequential processing in SPARK, and added 'normal Ada' for the concurrent/timing related aspects. (This is before SPARK added support for concurrency.) As our control, another guy with experience doing protocols coded the same stuff in C.
One thing we needed to code was the timeout in TCP/SCPS, i.e. "send a message and wait N milliseconds. If you timeout, generate an error." I knew this should be doable with Ada95 Asynchronous Transfer of Control, a feature of the language I hadn't used before. I read the RM, talked to Ben Brosgol
Guess which implementation had a bug in it?
But by conventional cost/size/effort/productivity models, he was 40 times more productive that week than I...
dave
What happens with experience in Ada is that you learn how to code to let hte computer do a lot of these kinds of checks. You concentrate on what the compiler canNOT check. Then when you think you're done with your work, you start running code through the compiler, working off the errors that the compiler catches.
When both you and the compiler agree the code is correct, it -usually is-, because you let the compiler take care of some stuff so you don't have to.
dave
That's not surprising, since the use of '42' is an artifact of the Ada binding, and those systems do not by default contain an implementation of 1003.5/9945. They should, but that's another story. Ada actually meshes very nicely with Unix, and is a good choice for system-level programming above the kernel level. Strong Typing -is your friend-! (I've been doing library level system programming on Unix systems, starting with Ultrix in 1984...)
The standard Linux/Solaris Ada compiler is the GNU Ada Compiler, http://www.gnat.com
But at least it's good to know there isn't a conflict.
dave
Many studies (e.g. the Bell Labs 5-ESS fault analysis) and anecdotal stories indicate that failing to check the error return on a system call (or any other function, for that matter) is all-too-common. Adding to this problem, when a system call fails, often the manifestation/error/seg fault is not at that point of call, but further down, when a pointer/variable you expect to have meaningful data is null/garbage...
That's why, when we did the Ada Binding to POSIX (IEEE 1003.5/ ISO 9945), we decided to accept the overhead of imposing exceptions for system call error returns (in most cases). You can't ignore the exception!
This raised two interesting concerns that we discussed when developing the standard:
1. What about tasking/threads/concurrency? The requirement on the implementation was to set up per-task errno values. From an implementation perspective, this meant that you needed to go outside of the standard interface to correctly implement POSIX/Ada, as you needed to grab the errno value and load it into task-specific storage, or require that your underlying POSIX threads implementation (if that's how you built the Ada runtime) do that for you. In practice, this is not too onerous, and it's proven to be a real boon for ensuring proper behavior (including debugging) in a multithreaded/multitasking environment.
2. We also needed to think about the situation (usually representing really poor programming) where an unhandled exception (from a system call, an application call, or a language predefined exception) rips up the callstack and terminates the process. We wanted a return value from the process exit that would be 'close to 1 but not collide with commonly used values.' The number we chose: 42 (with the appropriate citation in the bibliography:-)
So sure, a C++ program can use the C binding, but I think defining and using C++ exceptions in a better C++ interface would be preferred.
dave (Tech Editor for the original IEEE P1003.5 project...)
First, since I'm running a Mac, I'm frankly not worried about all that shit that impacts Windows PCs. And there have been times when I've had to rebuild my Mac, back in OS9 days, usually due to low level disk problems. The key word there is "I", as in "I've had to rebuild my Mac." Whenever Corporate gave me a new machine, the first thing I'd do is strip it to bare metal, reformat the disk drive to the way I wanted it, and then ran successfully from there. (I'd reformat to 2 partitions, the second holding a shadow copy of the OS that I would use for standalone tools and as a boot partition to rebuild the primary user partition, if that become necessary...)
Second, as a responsible technically informed user, I accept the responsibility. If you treat people like children, don't be surprised when they act that way. In 20 years of Mac usage, the only real problems I had with viruses are Microsoft Word macro viruses. I have had unstable software combinations, but that's generally been of my own doing, so I'd go fix it. And if I didn't understand how to fix it, that's where the 'group support' came in. That worked -a lot better- than the support people were getting on their Windows PCs from the so-called experts who got paid by the hour to manage them.
I object to being billed either explicitly or implicitly (as overhead charges or worse as the Nazification of my machine) by the IT department for services that I don't need, didn't ask for, and would prefer to not have. As I said, I'd rather the IT people spend their times writing quality applications than having to screw around with desktops...
Case in point: Y2K remediation. Corporate IT charged 1 hour for Macs, 2 for Windows. Most Mac users I know did it themselves in 1/2 hour or less (not trusting the Corporate Windows-based IT staff to mess with the Macs.) I don't know of anyone in our department who got his Windows computer completely done in less than 4 hours (by Corporate IT or by himself, and we did have some very knowledgeable Windows 'power users') A lot of that time was spent in searching for new things to be updated, then suffering through multiple reboots to apply the patches.
This was in a group of software and systems engineer. In an office where everyone is doing the same function with the same set of applications, things could well work differently. But again I don't want Corporate IT to treat me like a moron.
dave
Hell, I'll take the CIO's money! In exchange, he has to deliver -working cross-platform applications-, and stop running my shop for his convenience.
Then I'll equip each user with the 'right machine', and 'right' here is specifically keyed to user's preference and ability to support that preference.
That reminds me of the under-the-table deal I had with my Unix system administrator. I had a trap door to root access and as long as I gave him no cause to ask "how did you do that?" he wouldn't ask me about it. (That placed the obligation on me to keep within my knowledge, usually fix file permissions, restart print and mail queues and kill runaway user processes. As soon as I screwed something up as root, he'd have to ask how I was able to do that, and then would take it away from me. It never happened... This was during the famous Morris Internet Worm, and since I was able to shut down my machine without a lot of overhead in 'mid infection', the forensics team started their analysis by looking at my machine and its "being infected" state.)
dave
At least the last 3 places I've worked. The Mac community helped itself out, at the largest site we had one formally trained Mac tech support person covering probably 150 or more Macs.
Then another place I worked, the one time the tech support people touched my Mac, they screwed it up...
On the other side, I watched an employee of a Fortune 50 company visit another company's location, where the latter would assign you a specific IP address to use. This guy didn't have enough privileges on his Windows box to configure the IP address on it, and of course his corporate help(less) desk's attitude was that they had to have the machine hooked up to the internet to remotely administer it. Catch-22...
Dilbert's "Mordac, Preventer of Information Services" is unfortunately the way of life for most corporate IT departments. When I'm King, every CIO will provide each employee with a charge number against the CIO's budget, when an IT problem prevents that employee from doing productive work.
dave
Just about anyone who learned Ada has written tasking programs, even if they're just little toys to learn the syntax for creating tasks and synchronizing them using rendezvous. That's a form of concurrency, based on MIMD. And it's one with substantial (25 years) experience in usage and implementation (as I mentioned in another post on this thread.)
On a related note, Ada facilitated a lot of the work on scheduling in the late 80s, such as Rate Monotonic, by providing a solid, well-defined, easy-to-use notation for concurrency that allowed people to quickly sketch out a problem (often explaining why they didn't like this feature or that feature of Ada), and then concentrate on a solution for that problem.
dave
So all-of-a-sudden people have discovered parallelism? Gee, one of the really interesting things about Ada in the late 80s was its use on multiprocessor systems such as those produced by Sequent and Encore. There was a lot of work on the language itself (that went into Ada95) and on compiler technologies to support 'safe parallelism'. "Safe" here means 'correct implementation' against the language standard, considering things like cache consistency as parts of programs get implemented in different CPUs, each with its own cache.
Here are a couple of lessons learned from that Ada experience:
1. Sometimes you want synchronization, and sometimes you want avoidance. Ada83 Tasking/Rendezvous provided synchronization, but was hard to use for avoidance. Ada95 added protected objects to handle avoidance.
2. In Ada83, aliasing by default was forbidden, which made it a lot easier for the compiler to reason about things like cache consistency. Ada95 added more pragmas, etc, to provide additional control on aliasing and atomic operations.
3. A lot of the early experience with concurrency and parallelism in Ada learned (usually the hard way) that there's a 'sweet spot' in the number of concurrent actions. Too many, and the machine bogs down in scheduling and synchronization. Too few, and you don't keep all of the processors busy. One of the interesting things that Karl Nyberg worked on in his Sun T1000 contest review was the tuning necessary to keep as many cores as possible running. (http://www.grebyn.com/t1000/ ) (Disclosure: I don't work for Grebyn, but I do have an account on grebyn.com as a legacy of the old days when they were in the ISP business in the '80s, and Karl is an old friend of very long standing....)
All this reminds me of a story from Tracy Kidder's Soul of a New Machine http://en.wikipedia.org/wiki/The_Soul_of_a_New_Machine. There was an article in the trade press pointing to an IBM minicomputer, with the title "IBM legitimizes minicomputers". Data General proposed (or ran, I forget which) an ad that built on that article, saying "The bastards say, 'welcome' ".
dave
I am not a Lawyer, but... It sure seems to me that the clearly related actions that associate RIAA & their investigators -with the subsequent lawsuits by one of the Big 4' would make a reasonable case for a -linked conspiracy-. Clearly the actions of the record companies in the actual filing of the lawsuits is not independent/coincidental from the RIAA actions or the actions of the investigators (and it's not clear who those investigators work for. If they're under contract to RIAA and then RIAA transfers the info to a record company, and does this routinely, that's a pretty strong connection...)
But maybe someone with more knowledge of the law can comment on the 'burden of proof' to connect RIAA to the record labels, for the sake of punitive actions (damages and maybe even better/worse...)
dave
Microsoft Labs has done some really great stuff. But you don't see it in their products. That's why I have a really hard time believing MS can -execute- what Bill Gates proposed.
If you look at MS's desktop products, in particular, you see a pattern of buying a good product and then as part of integrating it, making it more and more baroque and buggy and security-vulnerable.
Reminds me of the comment I read somewhere during the MS anti-trust debates: "If Microsoft is so keen on innovation, fine. The decision of the court should be that Microsoft is free to innovate using ONLY their internal resources, but is restricted from acquiring any technology from other sources. This enables the Market to work better, by allowing innovations to move freely." I had friends working on a start-up, when Microsoft announced a potential competitor piece of -vapor-ware-, their funding dried up immediately, and MS never did deliver the goods...
dave