Probably the place where debuggers are most useful to me lately is when I have to track down bug in a huge blob of poorly written, undocumented code.
Sounds like a description of the typical AI project (possibly leaving out the "poorly written" aspect). I was going to put something in my original post about ill-specified problems being common back then, too.
This is really a reverse-engineering task, and for sufficiently inscrutable code, a debugger can be a (relatively) efficient way to go.
Yep. Another way to say it is that the program itself is the most accurate specification of its own behavior. A good debugger lets you see what's happening, while it's happening, and change it in mid-flight if necessary.
I've been doing CGI programming in both Lisp and Perl (spit) lately, and the different styles I've used are related to debugger value.
The Perl was standard Apache receive-and-dispatch stuff. Debug printing was the only way to go. Yech.
The Lisp stuff was based on portable AllegroServe - the web server and the logic code live together in an image that persists between web transactions, and each incoming form spins a new Lisp thread. If something goes wrong during a transaction, the thread can land in the Lisp debugger, and you can examine the entrails and fix it right there. The only odd thing you have to do is configure your testing web browser to wait a long time before timing out, so it won't close the connection and jerk the rug out from under you while you're looking around...
Most languages are designed primarily to run programs fast. Features that make debuggers useful (symbols, data structure descriptions) are not available by default, and have to be grafted on afterwards with special compiler options that can sometimes change program behavior (remember when -g in gcc would turn -O off?).
Most Lisp implementations grew up in AI environments - there was a lot of experimental programming done on problems where it wasn't clear the task could be done at all. Also, machines were a lotslower back then - you might land in the debugger after a run of hours or days, and you really didn't want to start over from scratch if you could possibly avoid it.
So, Lisp implementations were (and still are) designed to "get it right, then make it fast". If you land in the debugger, you can almost always examine the whole stack, modify pretty much anything, change code and data structures, and continue the program, backing up a few stack frames if necessary.
And so, Common Lisp exceptions can be handled two different ways - handlers can run in the context where they are established (like Java and C++) or they can run in the context where the exception is created (and where a debugger/handler has the best chance of fixing things transparently). Stroustrup considered allowing this second type of error handling in C++, and rejected it because it could allow bad, non-modular coding styles, without considering the effect not having it would have on C++ debugging.
In most other languages, debugging is evil, intrusive, and slows your code down. In Lisp, the debugger is good, always there, and an extension of your basic interaction tools.
It seems to me that the usefulness of lots-n-lots of remote storage for email depends on more than just how much you get. In particular, you also need to know:
How fast you can up/download it
What you can do to your mail without downloading it
Did the internet suddenly get a lot faster while I wasn't looking? Even at cable modem speeds, it would take at least an hour to move 1 GB up or down from a remote server.
... would be a virus/Trojan/worm that spread fast, was hard to spot (used very little system resources), and had a payload that modified documents in small ways:
Word processing documents - randomly deleted words like 'no' and 'not', or flipped words like 'always' and 'never'.
Spreadsheets - zeroed out one or two cells
Presentations - Inserted random obscenities and links to unappetizing images
Imagine what would happen if nobody could trust their computers any more. Microsoft would be sued into oblivion, EULA or no EULA.
Contrary to popular belief, having a monopoly is not illegal. The specific thing MS was charged with, both in the US and the EU, was using their OS monopoly to create other unrelated monopolies (browser and media player, respectively).
In the US, the penalty was essentially MS saying "we won't do it again" and accepting some oversight. Hasn't worked very well, has it? In the EU, the proposed penalty is a fine and required unbundling of media playing software - this may be a little more effective, if it ever gets past the appeals and enforced.
What the US should have done was to break MS up into at least three companies - OS, Office, and EverythingElse. That way, the EverythingElse company couldn't give the browser away for free, or get away with saying "the browser can't be removed, it's part of the OS". The opportunity to do that was lost between Judge Jackson's bad handling of the case, and the Bush administration's unwillingness to smack MS.
The nice part about structural remedies is that they can tolerate a fair amount of delay, and still hurt when applied.
Buried in the middle of a section talking about CMOS, we find this:
Thus, in the days when computing was still so primitive that people thought that digital watches were a neat idea, it was CMOS chips that powered them.
My question to you is this. Is there a dialect of lisp that is syntacticly cleaner (yes I mean without all those parens).
You probably want to look at Dylan. It was designed by Lisp hackers, and you can think of it as Java, but not dumbed down - it's got decent multiple inheritance and non-crippled closures.
For several reasons, Dylan never really took off - the Lisp people saw no reason to change, and the non-Lisp people didn't really understand how much better it was than Java/C++. It deserves a lot more exposure than it gets, in my opinion.
Does Common Lisp lend itself easily to kernel, systems, or real-time programming on mass-market computer architectures?
Not easily. But, writing programs in those areas is hard in any language. C makes it easy to tell if your code will be fast or slow, since its primitives map pretty directly to normal machine operations. Since its primitives are so low-level, it's also much more verbose and error-prone.
With Common Lisp, the primitives are higher-level, and are safe/slow by default, but you can add declarations as needed to speed things up. In combination with a good profiler, this allows developers to put optimization effort only where it's really needed. The philosophy is definitely "First make it work, then make it fast."
Before you go off and try to code up the Next Big Thing, please do all of us a favor and learn a little bit about Lisp.
Don't learn about it from your officemate, or your college instructor, especially if they say they haven't used it in over ten years. You wouldn't believe the opinions of someone who learned C from K&R without upgrading their knowledge, would you?
If you do this right, you will learn that computer languages:
are not inherently fast or slow - implementations are fast or slow, not languages
can be both dynamic and have good performance
can be cross-platform without swallowing POSIX whole
can have multiple inheritance without damaging your brain
can be object-oriented without being object-obsessed
If you like, you can quit as soon as you understand how static scoping and closures work - at least that way you will avoid the primary mistake in pretty much every recent scripting language.
There is a small risk you will become a SmugLispWeenie by doing this, so be forwarned.
The definitive statement on this subject is here at Dork Tower.
If anything, the mini iPod price was too LOW
on
iPod Mini Sells Out
·
· Score: 4, Insightful
To an economist, "demand is far greater than supply" is just another way of saying "the price is too low".
Can you imagine the Slashdot collective opinion, though, if Apple had priced it at $300? "You can get three times as much storage for the same price? Apple is insane!"
Goes to show that geeks are not Apple's target market, at least for consumer gear.
The prize is shared amongst two ex-Xerox people, with MIT and HP also making a showing.
Please note that all the honorees (Kay, Lampson, Taylor, Thacker) did the work in question at PARC - not at MIT, not at HP, not at Microsoft (where two of them currently work).
The "MIT and HP also making a showing" just shows the wisdom of those institutions for giving these guys a job after they've changed the world. It also shows typical Slashdot thinking - why mention HP and MIT, and leave Microsoft out, other than because Microsoft is Satan, even when they also hire the best and brightest after they've distinguished themselves elsewhere?
... DSL service is not available in many older suburban areas, much less rural areas.
My suburban subdivision, 5 miles from NASA/Goddard, can't get DSL, and my neighborhood is less than 15 years old. Around here, "new" phone wires have digital concentrators between your home and the COLO points where DSL hardware lives. These concentrators not only screw up DSL, they break V.90 modems too - the fastest I've ever seen on dialup from my house is 28000.
Currently my only reasonable broadband choice is cable via Comcast. I dearly hope broadband via powerline works someday soon, as Comcast could use the competition.
The original article quotes the code-morphing guy as saying:
And the increase in processing overhead is trivial. PSCP, if done right, costs almost nothing.
I don't believe it. This stuff can't cost "almost nothing" if it works with threads. If you have multiple paths of execution running through the same code, and the code is being dynamically morphed as the threads run, then either:
The morpher is fully thread-aware, to keep morph operations for thread A from pulling the rug out from under thread B (or C, D,...). This implies extra sempahores, locking, unlocking, and the overhead of handling them.
The morhper is not fully thread-aware, and every so often the morpher for one thread will clobber another thread.
Business people won't believe viruses really cost money until they lose business because of them. Microsoft's stuff is so pervasive that when the virus/worm-du-jour comes around, everybody gets hit pretty much evenly. As long as everyone suffers mostly evenly, there's little reason to switch, especially if the perceived cost of switching is higher than the hard-to-quantify cost of virus cleanup.
Switching away from Microsoft could become a real competitive advantage in the right circumstances, though. Consider a business sector that has a lot of knowledge workers who live and die on their workstations (brokerage houses, big law firms, high-tech R&D). If a few firms in such a sector got off of Microsoft, they would be in a position to take business from the rest when viruses knocked them off the net.
This effect would be more pronounced with more destructive viruses, of course. If, say, Dell, HP, and Gateway were crippled for a day, the effect on market share would be nil. If they were offline, unable to take orders for a week, or a month, though, I guarantee you Apple's market share would go up.
Any sane observer knows that Microsoft will do what it must to please its current Xbox consumers. In doing so, the company may learn that a low price can come at a high cost.
Low price versus high cost - so Microsoft is thinking the same way Windows customers do!
We need to get people to stop buying products advertised through spam
I know how to do that, and make money in the process! We can even enlist Scott Richter to help!
All we have to do is get him to send out spam advertising Pills That Kill, a new dietary supplement containing arsenic, potassium cyanide, and ricin, guaranteed to reduce your hunger pangs to ZERO within 30 seconds of ingestion! Scientifically proven to work! $9.95 for a lifetime supply!
Stupid spam recipients die off, improving the human gene pool. Richter makes money in the short term, but eventually goes bankrupt as he runs out of customers.
Or at least, all generalities about "cultural differences" need to be checked against the individuals in question. Making assumptions based on imputed culture is roughly equivalent to racism/sexism/you-name-it-ism.
If so, scratch everything I said above, or redirect my ire at netgear (I have them for my router/wireless point at home, and would love to move that up to WPA).
Slashdot Mirror
Sounds like a description of the typical AI project (possibly leaving out the "poorly written" aspect). I was going to put something in my original post about ill-specified problems being common back then, too.
Yep. Another way to say it is that the program itself is the most accurate specification of its own behavior. A good debugger lets you see what's happening, while it's happening, and change it in mid-flight if necessary.
I've been doing CGI programming in both Lisp and Perl (spit) lately, and the different styles I've used are related to debugger value.
The Perl was standard Apache receive-and-dispatch stuff. Debug printing was the only way to go. Yech.
The Lisp stuff was based on portable AllegroServe - the web server and the logic code live together in an image that persists between web transactions, and each incoming form spins a new Lisp thread. If something goes wrong during a transaction, the thread can land in the Lisp debugger, and you can examine the entrails and fix it right there. The only odd thing you have to do is configure your testing web browser to wait a long time before timing out, so it won't close the connection and jerk the rug out from under you while you're looking around...
Debuggers that suck
Languages whose features make debuggers suck
Most languages are designed primarily to run programs fast. Features that make debuggers useful (symbols, data structure descriptions) are not available by default, and have to be grafted on afterwards with special compiler options that can sometimes change program behavior (remember when -g in gcc would turn -O off?).
Most Lisp implementations grew up in AI environments - there was a lot of experimental programming done on problems where it wasn't clear the task could be done at all. Also, machines were a lotslower back then - you might land in the debugger after a run of hours or days, and you really didn't want to start over from scratch if you could possibly avoid it.
So, Lisp implementations were (and still are) designed to "get it right, then make it fast". If you land in the debugger, you can almost always examine the whole stack, modify pretty much anything, change code and data structures, and continue the program, backing up a few stack frames if necessary.
And so, Common Lisp exceptions can be handled two different ways - handlers can run in the context where they are established (like Java and C++) or they can run in the context where the exception is created (and where a debugger/handler has the best chance of fixing things transparently). Stroustrup considered allowing this second type of error handling in C++, and rejected it because it could allow bad, non-modular coding styles, without considering the effect not having it would have on C++ debugging.
In most other languages, debugging is evil, intrusive, and slows your code down. In Lisp, the debugger is good, always there, and an extension of your basic interaction tools.
How fast you can up/download it
What you can do to your mail without downloading it
Did the internet suddenly get a lot faster while I wasn't looking? Even at cable modem speeds, it would take at least an hour to move 1 GB up or down from a remote server.
Word processing documents - randomly deleted words like 'no' and 'not', or flipped words like 'always' and 'never'.
Spreadsheets - zeroed out one or two cells
Presentations - Inserted random obscenities and links to unappetizing images
Imagine what would happen if nobody could trust their computers any more. Microsoft would be sued into oblivion, EULA or no EULA.
Contrary to popular belief, having a monopoly is not illegal. The specific thing MS was charged with, both in the US and the EU, was using their OS monopoly to create other unrelated monopolies (browser and media player, respectively).
In the US, the penalty was essentially MS saying "we won't do it again" and accepting some oversight. Hasn't worked very well, has it? In the EU, the proposed penalty is a fine and required unbundling of media playing software - this may be a little more effective, if it ever gets past the appeals and enforced.
What the US should have done was to break MS up into at least three companies - OS, Office, and EverythingElse. That way, the EverythingElse company couldn't give the browser away for free, or get away with saying "the browser can't be removed, it's part of the OS". The opportunity to do that was lost between Judge Jackson's bad handling of the case, and the Bush administration's unwillingness to smack MS.
The nice part about structural remedies is that they can tolerate a fair amount of delay, and still hurt when applied.
You find Douglas Adams fans all over, don't you?
You probably want to look at Dylan. It was designed by Lisp hackers, and you can think of it as Java, but not dumbed down - it's got decent multiple inheritance and non-crippled closures.
For several reasons, Dylan never really took off - the Lisp people saw no reason to change, and the non-Lisp people didn't really understand how much better it was than Java/C++. It deserves a lot more exposure than it gets, in my opinion.
Not easily. But, writing programs in those areas is hard in any language. C makes it easy to tell if your code will be fast or slow, since its primitives map pretty directly to normal machine operations. Since its primitives are so low-level, it's also much more verbose and error-prone.
With Common Lisp, the primitives are higher-level, and are safe/slow by default, but you can add declarations as needed to speed things up. In combination with a good profiler, this allows developers to put optimization effort only where it's really needed. The philosophy is definitely "First make it work, then make it fast."
Don't learn about it from your officemate, or your college instructor, especially if they say they haven't used it in over ten years. You wouldn't believe the opinions of someone who learned C from K&R without upgrading their knowledge, would you?
Instead, start from places like the ALU web site or Cliki or Paul Graham's Lisp FAQ.
If you do this right, you will learn that computer languages:
are not inherently fast or slow - implementations are fast or slow, not languages
can be both dynamic and have good performance
can be cross-platform without swallowing POSIX whole
can have multiple inheritance without damaging your brain
can be object-oriented without being object-obsessed
If you like, you can quit as soon as you understand how static scoping and closures work - at least that way you will avoid the primary mistake in pretty much every recent scripting language.
There is a small risk you will become a SmugLispWeenie by doing this, so be forwarned.
... is that it is extremely short.
The definitive statement on this subject is here at Dork Tower.
To an economist, "demand is far greater than supply" is just another way of saying "the price is too low".
Can you imagine the Slashdot collective opinion, though, if Apple had priced it at $300? "You can get three times as much storage for the same price? Apple is insane!"
Goes to show that geeks are not Apple's target market, at least for consumer gear.
A couple of examples:
Smalltalk - took "everything is an object" to the extreme. Smalltalk's byte-coded portability worked, in 1980.
CLOS - its "meta-object protocol" lets developers change the language's object-model semantics.
The above is one Slashdot view on inertia in modern business, judging from its moderation value.
The other view, of course is that when it comes to outsourcing of tech jobs, inertia is good.
NOTE: I am commenting on the views of Slashdot as a whole, as reflected by its moderators. The parent poster may or may not believe this second view.
Apple once used Carl Sagan's name as an internal code name. Carl didn't like it, and sued, so Apple changed the name.
Please note that all the honorees (Kay, Lampson, Taylor, Thacker) did the work in question at PARC - not at MIT, not at HP, not at Microsoft (where two of them currently work).
The "MIT and HP also making a showing" just shows the wisdom of those institutions for giving these guys a job after they've changed the world. It also shows typical Slashdot thinking - why mention HP and MIT, and leave Microsoft out, other than because Microsoft is Satan, even when they also hire the best and brightest after they've distinguished themselves elsewhere?
My suburban subdivision, 5 miles from NASA/Goddard, can't get DSL, and my neighborhood is less than 15 years old. Around here, "new" phone wires have digital concentrators between your home and the COLO points where DSL hardware lives. These concentrators not only screw up DSL, they break V.90 modems too - the fastest I've ever seen on dialup from my house is 28000.
Currently my only reasonable broadband choice is cable via Comcast. I dearly hope broadband via powerline works someday soon, as Comcast could use the competition.
I don't believe it. This stuff can't cost "almost nothing" if it works with threads. If you have multiple paths of execution running through the same code, and the code is being dynamically morphed as the threads run, then either:
The morpher is fully thread-aware, to keep morph operations for thread A from pulling the rug out from under thread B (or C, D, ...). This implies extra sempahores, locking, unlocking, and the overhead of handling them.
The morhper is not fully thread-aware, and every so often the morpher for one thread will clobber another thread.
Am I missing something here?
Business people won't believe viruses really cost money until they lose business because of them. Microsoft's stuff is so pervasive that when the virus/worm-du-jour comes around, everybody gets hit pretty much evenly. As long as everyone suffers mostly evenly, there's little reason to switch, especially if the perceived cost of switching is higher than the hard-to-quantify cost of virus cleanup.
Switching away from Microsoft could become a real competitive advantage in the right circumstances, though. Consider a business sector that has a lot of knowledge workers who live and die on their workstations (brokerage houses, big law firms, high-tech R&D). If a few firms in such a sector got off of Microsoft, they would be in a position to take business from the rest when viruses knocked them off the net.
This effect would be more pronounced with more destructive viruses, of course. If, say, Dell, HP, and Gateway were crippled for a day, the effect on market share would be nil. If they were offline, unable to take orders for a week, or a month, though, I guarantee you Apple's market share would go up.
... would be dinosaurs.
Low price versus high cost - so Microsoft is thinking the same way Windows customers do!
I know how to do that, and make money in the process! We can even enlist Scott Richter to help!
All we have to do is get him to send out spam advertising Pills That Kill, a new dietary supplement containing arsenic, potassium cyanide, and ricin, guaranteed to reduce your hunger pangs to ZERO within 30 seconds of ingestion! Scientifically proven to work! $9.95 for a lifetime supply!
Stupid spam recipients die off, improving the human gene pool. Richter makes money in the short term, but eventually goes bankrupt as he runs out of customers.
What's not to like?
Or at least, all generalities about "cultural differences" need to be checked against the individuals in question. Making assumptions based on imputed culture is roughly equivalent to racism/sexism/you-name-it-ism.
Charge more for it than OS X on Apple hardware (to make up for the lost revenue)
Restrict the hardware it runs on (to keep the driver quality up)
Have some sort of product activation (to keep people from buying one copy and installing it N times)
If you're STILL willing to buy OS X on x86 under those conditions, let Apple know, preferrably with an open purchase order attached to your inquiry.
If not, then just shut up and either:
buy a Mac
use Linux and write open-source software that moves it in the Mac direction
OK?
If so, scratch everything I said above, or redirect my ire at netgear (I have them for my router/wireless point at home, and would love to move that up to WPA).