Cobol is also largely self-documenting, another factor that helped projects live on longer than the careers of their instigators. Companies could start planning IT strategies that weren't tied to the lifetime of one product, or the wishes of one hardware manufacturer.
That's funny - I've always heard the opposite about COBOL. In 1994, I was hired as a free-lancer by a big company that makes copiers. Their sales force had a problem - their system for pricing big copier installations was a mainframe-based nightmare first written in the early 70's and gradually mutated to the point where their sales force couldn't use it without taking a two month course. Their IT people were barely able to keep its pricing tables in sync with reality, much less reliably track purchasing patterns or add incentive pricing logic. The guy who hired me characterized the situation like this:
When they computerized the sales system, they essentially took their business practices of the 1970's and poured cement over them.
Our project was not to replace the sales tool, but to put a 1994-modern GUI over it using screen scraping to hide the mainframe green screens, and Common Lisp to change the presentation and bury some of the complexity. It was a very small effort, and the four of us ran out of money after delivering a partial prototype, but it shows how paralyzing the sheer dead weight of a large COBOL system can be, "largely self-documenting" or not.
Diet Pepsi Slurpees have been out for about three years now. A 32-ounce drink has essentially zero calories, and since it's mostly ice, it should take about 100 calories to drink one:
900 grams of Slurpee * 80 cal/g (to melt the ice to 0 celsius) = 72000
900 grams of Slurpee * 1 cal/g/degree * 37 degrees (to raise the fluid to body heat) = 33596
total 105596 calories or 105 Kcal (the food calorie)
Besides, has Hormel really actively protected their trademark ever since people started using the word "Spam" for unsolicited e-mail?
Quoting from the Hormel-created SPAM & the Internet page (which has been around for quite some time now):
We do not object to use of this slang term to describe UCE, although we do object to the use of the word "spam" as a trademark and to the use of our product image in association with that term. Also, if the term is to be used, it should be used in all lower-case letters to distinguish it from our trademark SPAM, which should be used with all uppercase letters.
Their attitude toward the Internet community's use of their trademark has been fairly enlightened to date.
First of all, that page never mentions that the 'success' was a result of using any particular programming language.
True - you have to go beyond the press release for details like that. Here you go. Among other things:
* They debugged the system during flight by essentially dropping into a Lisp prompt. They could have patched it that way, too, but chose not to after analyzing the problem and determining that it wouldn't have interfered with the planned tests.
* I don't know if this is mentioned in the paper above, but Garret has said elsewhere that the development environment and the flying system were different implementations of Common Lisp (Franz Allegro on ground workstations, Harlequin Lispworks on ground prototype and flying hardware). They had no cross-platform or cross-implementation problems due to this - they did have some problems interfacing Lispworks to the underlying VxWorks, but no more than you might expect interfacing any high-level language to C.
So they had buggy spaceflight software (bad synchronization) resulting in forgetting to turn an engine off and still managed to call it a success?
Everything on that spacecraft was a prototype - that's what the mission was for. To NASA, "success" for this mission meant "the spacecraft met all of its planned objectives, despite the harsh environment and limited resources". This mission was during NASA's big "faster, cheaper, better" push, and we know how that ultimately turned out (in an impact crater on Mars, among other places).
Please note that he was also responsible for this paper describing a Lisp-based system that successfully flew a NASA spacecraft. He knows exactly how difficult it is to make things work from an engineering standpoint.
In terms of writing software that deals with real-world problems, Ron Garret is a lot closer to the Paul Graham end of the spectrum than he is to the pointy-headed academic end.
Anyone who saw these episodes when they originally appeared (I was 10 at the time - I got a special dispensation from my parents to see the third season even though it was past my bedtime) knows they came out on NBC. How did CBS get to show them, much less get permission to tart them up?
Google knows the only thing they have to sell me is good service - everything they offer is available somewhere else, and I can change away from them at a moment's notice (mod moving any data they may be holding for me). Every second they're off line, they're losing revenue - they'll work hard to be as reliably available as possible.
Comcast knows they have me over a barrel - in my neighborhood, they're really the only choice for broadband, and they behave like a minimally regulated monopoly where reliability is concerned (as I type this, I'm waiting for a call to go home and let in a technician to get me back on line). Comcast would love for me to dump my land line and get a VOIP phone through them. I might consider it when they come within an order of magnitude of the reliability of my land line.
I trust the parts of the cloud where competition keeps things honest.
Bottom line, assuming the demo is not a hoax, it will work against *nix, Windows, and Mac equally.
The easiest way to show that would have been to demo it on more than one platform. It would have been more work for them, but not much more. Going from OS X to Linux or BSD should be easy compared to the effort of doing the exploit the first time.
At the moment, if the demo can be trusted, we know the exploit works against OS X with a third-party card installed. Everything else is speculation.
... are still unsolved. The problems of data inconsistency (from bogus or fraudulent data entry) are bad enough, but the semantic web idea has problems even if you assume all the data is valid. There are some theoretical results on inheritance networks (a classic AI predecessor to semantic web representation) from the 1980's and 90's that are rather depressing:
Touretzky's dissertation where he shows that if you allow exceptions, it's hard to keep inheritance networks globally consistent
Another result I can't locate right now which proved certain basic inferencing techniques in inheritance networks to be NP-complete
That last one means that straightforward, guaranteed-to-reason-correctly searchers for semantic webs won't scale, which means their use on the global internet is problematic. Failure to scale was one of the major causes of AI winter, guys.
Existing high-level languages, such as LISP, provided too much abstraction for implementing an operating system
Huh? I would argue that commercially successful (as in boxes sold to Fortune 500 companies and used in production) operating systems have been written in three languages:
Most truly high-level languages, like LISP (which was mentioned directly in TFA), are interpreted,...
Programming languages are not "interpreted". A language IMPLEMENTATION may be based on an interpreter. Every major implementation of Common Lisp today has a complier, and most of them don't even have an interpreter any more - everything, including command-line/evaluator input, is compiled on-the-fly before being executed.
... and the interpreters are almost always written in C. It is impossible for an interpreted language written in C (or even a compiled one that is converted to C) to go faster than C.
Again, this is a property of implementations, not of languages. The highest-performance Common Lisp implementations have scaffolding written in C and assembly, but they do not use a C compiler when they compile Lisp code. They often use non-C ABI conventions for argument passing and stack handling, to make their style of function calling faster.
I don't mean to be harsh, but the "Lisp is slow because it's interpreted" meme is about twenty years out of date. It tends to be spread primarliy by college professors whose last exposure to Lisp was pre-1980, and it really grates on those of us who know better.
Apple has a contract with Microsoft, signed way back in 1997, that gave them rights to use the Windows API through 2002 (see here about two-thirds of the way down). Windows XP came out just before that contract ended, so theoretically Apple has access to the XP API.
Despite that, you're probably right that it would be easier and safer to require a real Windows install underneath. Apple has always been about things Just Working, and using the real Windows code is the surest path to that.
One reason to aim at a smaller market is to take advantage of knowledge you may have about that market. If you knew that BigCorp had some data you wanted, and that BigCorp had switched to OS X, you'd attack them using OS X vulnerabilities. If you knew that BigCorp used multiple platforms, you'd attack them using cross-platform strategies like fake websites.
I work at NASA. We've been hit with several spear-phishing attacks recently - broadcast emails telling us our NASA Credit Union accounts had been compromised, with a convenient link for logging in and changing our passwords. A broadcast attack aimed solely at Windows wouldn't work very well here - too many people with Macs and Linux boxes on their desks.
The rental aspect of software like Exchange is that you can really only use it while Microsoft supports it. Once they stop supporting a particular version, any new security holes in it stay open, making it way unsafe to continue to use it.
How many times have we all heard that the proper way to develop software is:
First make it work, then make it fast
Specifically:
Write it as simply and cleanly as you can,
THEN check performance,
THEN optimize, but ONLY where measurement tells you to.
Judging by the performance improvements over time, this is what the OS X team has been doing. Their stuff has been getting bigger, with more functionality, AND faster on the same hardware, with each release. If anyone else has been doing that, I haven't heard of it.
This "restart" ad is false advertising -- Windows XP is an extremely stable platform (unless Apple is referring to people who are still using Windows 98 and Windows ME -- but I don't think so).
XP is pretty stable these days - I've never seen a BSOD on my Thinkpad running XP. However, you do have to reboot XP:
* After every Windows Update
* After every driver install (and it seems every USB device has its own funny drivers)
* After most malware scans
* After most non-trivial software installs
And often more than once per event. All of the events above are much less frequent or non-existent with OS X. The recent 10.4.6 update was the first OS X update I recall that required more than one reboot to install, and I've been using it since 10.0.
Take a look at the Aliceprogramming project. The current 2.0 release gives you a Java-like programming language controlling objects in 3-D rendered worlds. The development environment is designed to be attractive to beginners - program construction is mostly drag-and-drop. Download it (available for Windows and OS X (PPC - Intel is in the works) and give it a whirl.
And, the next major release is being done in collaboration with Electronic Arts, and will have Sims-level graphics.
We'd consider it wildly unacceptable if 1 in 10,000 people died over the course of 5 years.
Well, the number of people dying from auto accidents in the US is a little over 1 in 10,000. per year (see here. We tolerate that, primarily because driving is so useful to us.
I have a vague memory of a Popular Science article ages ago that described variable-focus eyeglasses. They did it with two lenses and a chamber between them - a slider on the eyeglass temple controlled a piston that forced clear liquid into the chamber, changing the shape of the lens assembly.
The Machavellian aspect is this: a significant fraction of those dual-boot Macs will get their Windows partitions infected by some nasty malware or virus, thus FORCING USERS TO BOOT INTO LOVING AND SENSUOUS ARMS OF MAC OS X. And as we all know, once you go Mac, you DON'T GO BACK.
The only way to be sure you get a rootkit out of an installed OS (short of wiping and reinstalling) is to boot from something you trust, mount the infected OS as another drive, and clean it from your trusted platform. When your Windows partition gets hosed, the natural thing to do would be to boot OS X and run a scanner on the Windows install from there. Assuming a scanner gets ported to OS X, and it can read NTFS.
I could believe a lot of people who would dual-boot Windows as a last resort would also be paranoid enough about Windows malware to buy an OS X native scanner.
Testing drugs, that is. In the US drugs are tested in vitro, in animals, in small clinical trials (hundreds of patients) and in big clinical trials (thousands) before being certified by the FDA as safe enough for sale.
When they go on sale, the size of the population taking them goes up by a factor of at least 100. Things that had a 1/10000 chance of happening were all but invisible in the final clinical trial, and now tens or hundreds of patients may show bad effects.
The analogy to computer manufacturing (hundreds of prototypes vs. hundreds of thousands of sold units) is obvious.
Slashdot Mirror
That's funny - I've always heard the opposite about COBOL. In 1994, I was hired as a free-lancer by a big company that makes copiers. Their sales force had a problem - their system for pricing big copier installations was a mainframe-based nightmare first written in the early 70's and gradually mutated to the point where their sales force couldn't use it without taking a two month course. Their IT people were barely able to keep its pricing tables in sync with reality, much less reliably track purchasing patterns or add incentive pricing logic. The guy who hired me characterized the situation like this:
Our project was not to replace the sales tool, but to put a 1994-modern GUI over it using screen scraping to hide the mainframe green screens, and Common Lisp to change the presentation and bury some of the complexity. It was a very small effort, and the four of us ran out of money after delivering a partial prototype, but it shows how paralyzing the sheer dead weight of a large COBOL system can be, "largely self-documenting" or not.
The Design and Evolution of C++
as
The Design Rationalization and Evolution^WMutation of C++
for just that reason.
Diet Pepsi Slurpees have been out for about three years now. A 32-ounce drink has essentially zero calories, and since it's mostly ice, it should take about 100 calories to drink one:
900 grams of Slurpee * 80 cal/g (to melt the ice to 0 celsius) = 72000
900 grams of Slurpee * 1 cal/g/degree * 37 degrees (to raise the fluid to body heat) = 33596
total 105596 calories or 105 Kcal (the food calorie)
Quoting from the Hormel-created SPAM & the Internet page (which has been around for quite some time now):
Their attitude toward the Internet community's use of their trademark has been fairly enlightened to date.
True - you have to go beyond the press release for details like that. Here you go. Among other things:
* They debugged the system during flight by essentially dropping into a Lisp prompt. They could have patched it that way, too, but chose not to after analyzing the problem and determining that it wouldn't have interfered with the planned tests.
* I don't know if this is mentioned in the paper above, but Garret has said elsewhere that the development environment and the flying system were different implementations of Common Lisp (Franz Allegro on ground workstations, Harlequin Lispworks on ground prototype and flying hardware). They had no cross-platform or cross-implementation problems due to this - they did have some problems interfacing Lispworks to the underlying VxWorks, but no more than you might expect interfacing any high-level language to C.
So they had buggy spaceflight software (bad synchronization) resulting in forgetting to turn an engine off and still managed to call it a success?
Everything on that spacecraft was a prototype - that's what the mission was for. To NASA, "success" for this mission meant "the spacecraft met all of its planned objectives, despite the harsh environment and limited resources". This mission was during NASA's big "faster, cheaper, better" push, and we know how that ultimately turned out (in an impact crater on Mars, among other places).
The author was indeed responsible for this comparison between Lisp and Java which will be in line with your "real academic/Lisp-lover" crack.
Please note that he was also responsible for this paper describing a Lisp-based system that successfully flew a NASA spacecraft. He knows exactly how difficult it is to make things work from an engineering standpoint.
In terms of writing software that deals with real-world problems, Ron Garret is a lot closer to the Paul Graham end of the spectrum than he is to the pointy-headed academic end.
Anyone who saw these episodes when they originally appeared (I was 10 at the time - I got a special dispensation from my parents to see the third season even though it was past my bedtime) knows they came out on NBC. How did CBS get to show them, much less get permission to tart them up?
Google knows the only thing they have to sell me is good service - everything they offer is available somewhere else, and I can change away from them at a moment's notice (mod moving any data they may be holding for me). Every second they're off line, they're losing revenue - they'll work hard to be as reliably available as possible.
Comcast knows they have me over a barrel - in my neighborhood, they're really the only choice for broadband, and they behave like a minimally regulated monopoly where reliability is concerned (as I type this, I'm waiting for a call to go home and let in a technician to get me back on line). Comcast would love for me to dump my land line and get a VOIP phone through them. I might consider it when they come within an order of magnitude of the reliability of my land line.
I trust the parts of the cloud where competition keeps things honest.
Bottom line, assuming the demo is not a hoax, it will work against *nix, Windows, and Mac equally.
The easiest way to show that would have been to demo it on more than one platform. It would have been more work for them, but not much more. Going from OS X to Linux or BSD should be easy compared to the effort of doing the exploit the first time.
At the moment, if the demo can be trusted, we know the exploit works against OS X with a third-party card installed. Everything else is speculation.
Yeah, I had a feeling that if any OS were in C++, it would be something in the embedded space.
That last one means that straightforward, guaranteed-to-reason-correctly searchers for semantic webs won't scale, which means their use on the global internet is problematic. Failure to scale was one of the major causes of AI winter, guys.
Huh? I would argue that commercially successful (as in boxes sold to Fortune 500 companies and used in production) operating systems have been written in three languages:
* Assembly
* C
* Lisp
Are there any commercially successful OSs written in C++ yet?
(revealing my ignorance and posting flamebait, all in one)
Most truly high-level languages, like LISP (which was mentioned directly in TFA), are interpreted, ...
... and the interpreters are almost always written in C. It is impossible for an interpreted language written in C (or even a compiled one that is converted to C) to go faster than C.
Programming languages are not "interpreted". A language IMPLEMENTATION may be based on an interpreter. Every major implementation of Common Lisp today has a complier, and most of them don't even have an interpreter any more - everything, including command-line/evaluator input, is compiled on-the-fly before being executed.
Again, this is a property of implementations, not of languages. The highest-performance Common Lisp implementations have scaffolding written in C and assembly, but they do not use a C compiler when they compile Lisp code. They often use non-C ABI conventions for argument passing and stack handling, to make their style of function calling faster.
I don't mean to be harsh, but the "Lisp is slow because it's interpreted" meme is about twenty years out of date. It tends to be spread primarliy by college professors whose last exposure to Lisp was pre-1980, and it really grates on those of us who know better.
Apple has a contract with Microsoft, signed way back in 1997, that gave them rights to use the Windows API through 2002 (see here about two-thirds of the way down). Windows XP came out just before that contract ended, so theoretically Apple has access to the XP API.
Despite that, you're probably right that it would be easier and safer to require a real Windows install underneath. Apple has always been about things Just Working, and using the real Windows code is the surest path to that.
One reason to aim at a smaller market is to take advantage of knowledge you may have about that market. If you knew that BigCorp had some data you wanted, and that BigCorp had switched to OS X, you'd attack them using OS X vulnerabilities. If you knew that BigCorp used multiple platforms, you'd attack them using cross-platform strategies like fake websites.
I work at NASA. We've been hit with several spear-phishing attacks recently - broadcast emails telling us our NASA Credit Union accounts had been compromised, with a convenient link for logging in and changing our passwords. A broadcast attack aimed solely at Windows wouldn't work very well here - too many people with Macs and Linux boxes on their desks.
Discover has a Windows app and a web-based Java/Flash thing (not sure which, but it runs fine under Safari) which gives you one-time numbers.
The rental aspect of software like Exchange is that you can really only use it while Microsoft supports it. Once they stop supporting a particular version, any new security holes in it stay open, making it way unsafe to continue to use it.
How many times have we all heard that the proper way to develop software is:
First make it work, then make it fast
Specifically:
Write it as simply and cleanly as you can,
THEN check performance,
THEN optimize, but ONLY where measurement tells you to.
Judging by the performance improvements over time, this is what the OS X team has been doing. Their stuff has been getting bigger, with more functionality, AND faster on the same hardware, with each release. If anyone else has been doing that, I haven't heard of it.
XP is pretty stable these days - I've never seen a BSOD on my Thinkpad running XP. However, you do have to reboot XP:
* After every Windows Update
* After every driver install (and it seems every USB device has its own funny drivers)
* After most malware scans
* After most non-trivial software installs
And often more than once per event. All of the events above are much less frequent or non-existent with OS X. The recent 10.4.6 update was the first OS X update I recall that required more than one reboot to install, and I've been using it since 10.0.
Take a look at the Aliceprogramming project. The current 2.0 release gives you a Java-like programming language controlling objects in 3-D rendered worlds. The development environment is designed to be attractive to beginners - program construction is mostly drag-and-drop. Download it (available for Windows and OS X (PPC - Intel is in the works) and give it a whirl.
And, the next major release is being done in collaboration with Electronic Arts, and will have Sims-level graphics.
Isn't is obvious which programming language is designed to be spoken?
Once we all have RSI, the next step is to turn us all into business-rule-encoding drones...
We'd consider it wildly unacceptable if 1 in 10,000 people died over the course of 5 years.
Well, the number of people dying from auto accidents in the US is a little over 1 in 10,000. per year (see here. We tolerate that, primarily because driving is so useful to us.
I have a vague memory of a Popular Science article ages ago that described variable-focus eyeglasses. They did it with two lenses and a chamber between them - a slider on the eyeglass temple controlled a piston that forced clear liquid into the chamber, changing the shape of the lens assembly.
The liquid crystal approach is a lot slicker!
The Machavellian aspect is this: a significant fraction of those dual-boot Macs will get their Windows partitions infected by some nasty malware or virus, thus FORCING USERS TO BOOT INTO LOVING AND SENSUOUS ARMS OF MAC OS X. And as we all know, once you go Mac, you DON'T GO BACK.
The only way to be sure you get a rootkit out of an installed OS (short of wiping and reinstalling) is to boot from something you trust, mount the infected OS as another drive, and clean it from your trusted platform. When your Windows partition gets hosed, the natural thing to do would be to boot OS X and run a scanner on the Windows install from there. Assuming a scanner gets ported to OS X, and it can read NTFS.
I could believe a lot of people who would dual-boot Windows as a last resort would also be paranoid enough about Windows malware to buy an OS X native scanner.
Testing drugs, that is. In the US drugs are tested in vitro, in animals, in small clinical trials (hundreds of patients) and in big clinical trials (thousands) before being certified by the FDA as safe enough for sale.
When they go on sale, the size of the population taking them goes up by a factor of at least 100. Things that had a 1/10000 chance of happening were all but invisible in the final clinical trial, and now tens or hundreds of patients may show bad effects.
The analogy to computer manufacturing (hundreds of prototypes vs. hundreds of thousands of sold units) is obvious.