Re:What exactly is a "pattern"? Need good def
on
Design Patterns
·
· Score: 2
This implies that the other two cannot solve/contribute to such goals.
No it doesn't. It's you who insist on them being separate, while in reality patterns and algorithms are more like american and us citizen. Not all concepts need to be entirely different to have different names, you know... Overlapping is ok.
IOW, there is too much "political" stuff in your def IMO.
You think so? Well, I couldn't find any. Could you please explain me why this is "political"? Or maybe it's your brain playing tricks with you again?
What distinquishes mathematical symbols from non-mathematical symbols? Does this include functions?
I've got one answer: context. Whenever you read a mathematical formula, you will find it meaningless unless you already know the meaning of the squigglies and symbols.
Consider the formula for Newtons second law: F = ma. For it to make sense, the reader must know that F is the vector sum of all external forces on a point-like object measured in Newton, a is the second derivative of the point-like objects vector position with respect to time, meausered in meters per second squared, m is the scalar mass of the point-like object measured in kilograms, concatenation of symbols mean multiplication, and = mean equality.
How does this differ from "pattern"?
Patterns aren't there for solving problems in the algorithmic sense (shure, they could do that, but then you would typically call it an algorithm). They are there to solve problems for the programmer/designer. And the problems is not of the type "how do I sort?", but of the kind "how do I manage to have a large class-hierarchy in sync with my fifteen tree-walkers without getting bogged down in complexity". Sure, the programmer already knows how to solve the problem, what he is looking for is a solution to the problem of also making it reusable, maintainable, flexible, simple, etc...
That is a little stringent. Shouldn't we then have a category for non-proved algorithms? Or do you consider such worthless?
This is the common way to define an algorithm in the literature. Deal with it. But since you asked, yes it is possible to relax the demand for a proof. Probabilistic algorithms do just that. Instead they demand a proof that the probability of the algorithm failing can be made arbitrarily small by tuning some parameter of the algorithm. There are probably other examples as well. (In particular, heuristics is not algorithms, unless they are simply used to speed up the common case...)
The category of non-proven algorithms is called "frontier of research". You wouldn't want to be there as a normal programmer. When you publish a newly discovered algorithm in a journal, you submit a proof, or you don't get published.
If so, then why are unproven patterns not "worthless"?
Because, for an algorithm you can easily state and prove something to the effect of "algorithm A actually sorts the input, and it uses O(n log n) time and space in doing so".
For a pattern it would be much harder to prove something to the effect of "pattern A makes it much easier to keep large classe hierarchies in sync with tree-walker functions, the reduced overall complexity also makes it easier to add new tree-walkers, and to extend the class-hierarchy when needed". Therefore patterns usually aren't formally proven.
But I'm sure the pattern community (and everyone else too) would be very happy if you could come up with a formal way of proving statements to the effect of "is much easier", "makes it more maintainable", "reduces complexity", and especially "9 out of 10 programmers working on project X prefers to do it this way..."
Ok, I'm missing something, what's wrong with that?
It isn't standard C.
(Although in practice you would be hard pressed to find a unix where it isn't supported (I would probably go so far as to say that it wouldn't really be unix then...))
But if a collection has a GetItemAtIndex(int i) method, I fail to
see why I need the cursor object except as a wrapper around an int i.
There are two possible answers. 1: You don't. 2: Because you have other code that uses the iterator (e.g. because of templates (STL) or inheritance (Java collection framework)).
So the Iterator pattern needs to give the cursor access to some of the non-public workings of the collection, so as to not break
encapsulation of the collection while making the cursor efficient in its access.
Why do you not want to break the encapsulation of the collection? Ok, I guess you want to do for some reason. If so, then yes, a friend class would be ok. And so would a nested class, which according to the latest C++ standard suddenly was allowed to see all members in the parent class.
but I would like to see
the GoF show what implementations they have in mind and to comment on usage of, say C++ friend declaration
It is too bad then that the book fails to satisfy you. Personally, I have no wish for even further C++ bias in the book.
Re:What exactly is a "pattern"? Need good def
on
Design Patterns
·
· Score: 2
I'll bite. Here's my try:
1. Patterns: A way of structuring a computer program to achieve various goals such as robustness, maintainability, flexibility, ease of development, or whatever the author thinks is important. A pattern may or may not be obvious to different people, but usually some degree of non-obviousness is needed for somebody to actually write it down.
2. Algorithm: A recipe for solving a specific class of problems. It must be possible to prove that the algorithm always solves the input problem (if it is of the right class), and that it terminates in finite time. It must also be possible to write the algorithm in some imaginable computer language for some imaginable hardware.
3. Formula: A set of mathematical symbols thrown together in a syntactically meaningful way, intended to convey some meaning to the reader of the formula. It may also be used as the basis for a computation.
The story I heard was that the beta version of WfW threw up a message that said "you are running Dr Dos". It was just a
message, it didn't crash. It was confusing to people, though.
Well, I would never imagine it would have crashed. That would have been dead embarassing. But simply not starting is not much better (considering that the user probably wanted to run WfW even though it came from MS).
If that's true then MS had every reason to do that. They had no idea how compatible DrDos was with Windows, and they
weren't going to fix it for somebody else's product.
Well, you may say that is a good reason. But if you really think that, then you probably have to mean that every other non-microsoft software should make a similar message appear when running a microsoft product. E.g. "I see your system is running winzip. Note that this is untrusted software that is not written by Microsoft. Your system may not work as a result of this." Depending on whether your or mine memory was right, you may append to the message: "For security reasons, Windows 2000 will shutdown now".
No, it isn't. Neither ANSI nor ISO C allows main to return anything but an int.
On most systems, that will even link and run without complaint.
I shudder to think about what you consider acceptable C, if you have to qualify "link and run without complaint" with "even".
But your system isn't the C standard, and the fact that it runs there doesn't mean it is valid C. Most systems allow i = i++ += ++i as well. The result is undefined, and that means that anything is allowed to happen (including program crash, spontaneous massive existence failure, making demons run out of your nose, or simply set i to some guessable value).
The fact that most calling conventions are sane enough for it not to matter defining a function returning nothing when the run-time-system really expects one returning success or failure as an integer, doesn't mean that it is valid (or that it makes sense, i.e.: what will your C program return to the OS after running?)
Some systems with ancient preludes
won't take it.
So what you are saying is that, even though it is explicitly not allowed by the standard, it also doesn't work at all on some systems?
Such systems generally won't like the perfectly valid int main(int argc, char **argv, char **env)
convention either.
Surprise. It isn't perfectly valid C. I'm not even shure if it's POSIX (although extern char **environ is). But it is pretty common among unixes.
Does anyone else think there could be an argument made that calling MS Office "productive software" might be stretching
things a bit?
Yes, but that is true for almost any kind of software. An operating system doesn't operate (a surgeon does). A word processor doesn't process words (the brain does), a spreadsheet isn't a sheet at all (and it doesn't it spread much), a data base doesn't have any data, a compiler doesn't compile and an assembler doesn't assemble (they both translate), a text editor doesn't edit (although you may use it for editing), a web browser doesn't browse (although you can use it to browse, although some people also read from it), most utilities aren't utilities (in the economic sense), and so on...
For me, the main feature of PDF is probably portability, yes. For 95% of the computing world, it's the fact that it's a distribution format that sucks less than office documents, has a free reader, and works on Windows.
Except DR-DOS didn't work with WfW 3.11 (If I remember correctly. Of course, this was because Microsoft deliberately crippled WfW, not because of technical reasons).
Well, on the other hand, most so-called tech companies aren't competitors to Microsoft. They make software that relies on Microsoft products to work. (i.e. windows, office, vb, ie, etc...) So what's bad for Microsoft is bad for them as well. Not everyone can be making OSes and Office-suites...
That being said, the stock market is designed to be unstable and fluctuate. Why it doesn't fluctuate even more is beyond my understanding, but there must be some factors that stabilize it as well (they are called long-term investors, I guess).
Both XEmacs and GNU Emacs work just fine in tty, thanks for asking, but admittedly vi loads faster.
And it also works better on a bad serial line, which is often the case when you need to use one over a serial line (or at least often my case). Emacs really likes having a somewhat predictable connection over the serial line it is using.
Then again, you're only
supposed to start emacs once per session.
Well, when working mostly at the command-line, and only rarely need to edit a file, when you remote-login to many different computers to find out who is misbehaving, etc, you are not going to start an emacs session in the background each time, just in case you need it. Having vi available is sometimes good. Although for actual programming work, I prefer emacs (although I can live with XEmacs).
Unfortunately I can't since I have never heard of JaM.
On the other hand, the idea that an early ancestor of PostScript was more Forth-like doesn't sound too unlikely. Most likely it was, it seems like an obvious thing to use Forth for (embedded software, building a domain-specific language, etc...). Obviously, I wasn't around at that time, so I can't actually judge the truthfullness of your tale.
I set the colors on my monitor dark to minimize eye strain and a bright white pixel glares at me. I loathe it. I use my CRT when I have serious work to do. Is there anything I can do about to minimize the distraction
My only point is that these language features are nothing more than syntax.
I disagree wholeheartedly. While it's true that very many languages don't differ in anything but syntax (e.g. C, Pascal), the interesting differences are the semantic ones (e.g. C++, Prolog, Scheme, Forth, ML, Haskell, Mozart, Perl, M4, Icon). While many features superficially look the same, the meaning of two programs with similar-looking syntax or structure can be radically different. Syntax matters little beyond the initiall "sell".
But I really haven't seen a new concept in computer languages in 20 years.
Interesting. I find new interesting concepts in new languages every day. But I haven't been here for 20 years, and to some degree I believe what you are saying (if you are talking of major new concepts!). Few of the languages on the list above are very young. On the other hand, I guess template metaprogramming and constraint programming are both pretty new.
Paradoxically enough, that is true. While Forth is a completely unsafe, ridiculously simple to implement, machine near-language, Common Lisp is a big and complex language, trying to abstract away from the underlying machine as much as possible. Yet, they share this unique strength together, although in very different ways.
You are using wires and transistors? I'm preferring to use something I have complete control of, not to be at the whim of wire and transistor manufacturers. My computer is made out of a bunch of buckets, ropes, and a large supply or running water. Of course, it takes me years to do what you can do in a second, but at least I'm in complete control of every liter of water.
Don't know why a non-printer driver person would want to, but you can...
Mainly because it's fun. But also because you can make some useful scripts to process postscript. E.g. 2-up, double-sided to single-sided, adding page numbers, etc...
But back to the first point. Postscript is to Forth as Python is to C (roughly). While Forth is an extremely low-level lanugage, Postscript requires a relatively heavy interpreter. A simple forth implementation can be made in a day, and a useful one in a week. PostScript requires much more effort (at least if you want it to be useful with a typical PostScript file). Forth is untyped, PostScript is dynamically typed. Forth has some nifty features making it a reflective extensible language (create does>), PostScript does not. In Forth, everything is a cell (pointer or signed or unsigned integer), PostScript has high-level datatypes like lists, code-blocks (anonymous functions), strings, fonts, etc... In Forth you typically allocate data on a stack, or once at the start of the program. PostScript is garbage collected. Forth is consistently minimal (whether you like it or not), PostScript is mostly high-level, but has some relatively unfriendly features such as fixed-size dictionaries to make it feel more unusable. Forth is easy to debug, and easy to crash your machine with. PostScript is hopeless to debug, but will rarely break anything serious. Forth is inherently unsafe, and is allowed to read/write any memory location, PostScript can be made safe enough to view random files on the web.
I could go on, but it should be clear by now that about the only resemblance the two languages share is postfix syntax.
If you are a big company that needs lots of computing power, this is only going to increase your costs. If you only occasionally need lots of computing power you can already rent it. I'm not sure what the benefits are here for the consumer. However, if IBM can actually make people pay for this, they will earn a lot of money, but I doubt they can sell it to many...
E.g. the example with the car-industry is wrong (I don't work in the car industry, but I can guess). By the time they are finished with their design, the group will move on to the next model, and they will still need their big iron. It's not like the researchers and engineers will first design the car, and then get transferred to the production halls where they will be producing it, untill management decides it's time to make the next model!
The only problem is a conflict.. say... gaim doesn't compile with, say, GCC. Then, the task would be to determine if gaim is non-compliant, or if gcc is non-compliant (or both).
Oh, but that's easy! Simply become an expert in whatever language is used, and you can easily file bug-reports:-)
But seriously, sending to both is probably easier and just as effective if you have made sure it's not reported several times before.
Because then you'd have to understand Oracle/PostgreSQL/MySQL/MS SQL/whatever to be able to fix it. Furthermore, you need it to be available to deploy it. And you rely on continued support from the company/individuals in question for it to last more than a few years. If it can be done with a simple text-file, or as a hierarchical database using the file-system, that will make the product simpler, smaller, and less reliant on third-party software. Sometimes reinventing the wheel is a good thing, if the wheel is sufficiently simple...
Why would it be so bad to have sane laws and regulations where a gallon of diesel is taxed like a gallon of diesel, regardless of its purpose? The reason for the tax is to reduce pollution, and to make money for the government. Every other consideration are there as a result of the endless bickering between different political views.
Sometimes I loose faith in democracy, producing more and more complex rules and regulations, making it less and less possible to make any sense of it at all...
As for email, I think the only solution is to make the sender pay for each email sent, like it is with phones, faxes, and snail-mail. The question is just how to do that, and who should receive the money:-)
Daniel Bernstein has a new email-system where the sender stores outgoing messages, not the reciever. That would help somewhat, but not enough (disk-space is cheap). Two other alternatives is hash-cash or micropayments. The reciever remains free to charge whatever he wants from any recipient, but must of course announce the amount before the email is sent. Typically, one would set this to something relatively low (say, one CPU second, or 10 cent) for unknown senders, and nothing at all to well-known senders (and something ridiculously high for really determined spammers;-)
Slashdot Mirror
No it doesn't. It's you who insist on them being separate, while in reality patterns and algorithms are more like american and us citizen. Not all concepts need to be entirely different to have different names, you know... Overlapping is ok.
IOW, there is too much "political" stuff in your def IMO.
You think so? Well, I couldn't find any. Could you please explain me why this is "political"? Or maybe it's your brain playing tricks with you again?
What distinquishes mathematical symbols from non-mathematical symbols? Does this include functions?
I've got one answer: context. Whenever you read a mathematical formula, you will find it meaningless unless you already know the meaning of the squigglies and symbols.
Consider the formula for Newtons second law: F = ma. For it to make sense, the reader must know that F is the vector sum of all external forces on a point-like object measured in Newton, a is the second derivative of the point-like objects vector position with respect to time, meausered in meters per second squared, m is the scalar mass of the point-like object measured in kilograms, concatenation of symbols mean multiplication, and = mean equality.
How does this differ from "pattern"?
Patterns aren't there for solving problems in the algorithmic sense (shure, they could do that, but then you would typically call it an algorithm). They are there to solve problems for the programmer/designer. And the problems is not of the type "how do I sort?", but of the kind "how do I manage to have a large class-hierarchy in sync with my fifteen tree-walkers without getting bogged down in complexity". Sure, the programmer already knows how to solve the problem, what he is looking for is a solution to the problem of also making it reusable, maintainable, flexible, simple, etc...
That is a little stringent. Shouldn't we then have a category for non-proved algorithms? Or do you consider such worthless?
This is the common way to define an algorithm in the literature. Deal with it. But since you asked, yes it is possible to relax the demand for a proof. Probabilistic algorithms do just that. Instead they demand a proof that the probability of the algorithm failing can be made arbitrarily small by tuning some parameter of the algorithm. There are probably other examples as well. (In particular, heuristics is not algorithms, unless they are simply used to speed up the common case...)
The category of non-proven algorithms is called "frontier of research". You wouldn't want to be there as a normal programmer. When you publish a newly discovered algorithm in a journal, you submit a proof, or you don't get published.
If so, then why are unproven patterns not "worthless"?
Because, for an algorithm you can easily state and prove something to the effect of "algorithm A actually sorts the input, and it uses O(n log n) time and space in doing so".
For a pattern it would be much harder to prove something to the effect of "pattern A makes it much easier to keep large classe hierarchies in sync with tree-walker functions, the reduced overall complexity also makes it easier to add new tree-walkers, and to extend the class-hierarchy when needed". Therefore patterns usually aren't formally proven.
But I'm sure the pattern community (and everyone else too) would be very happy if you could come up with a formal way of proving statements to the effect of "is much easier", "makes it more maintainable", "reduces complexity", and especially "9 out of 10 programmers working on project X prefers to do it this way..."
It isn't standard C.
(Although in practice you would be hard pressed to find a unix where it isn't supported (I would probably go so far as to say that it wouldn't really be unix then...))
There are two possible answers. 1: You don't. 2: Because you have other code that uses the iterator (e.g. because of templates (STL) or inheritance (Java collection framework)).
So the Iterator pattern needs to give the cursor access to some of the non-public workings of the collection, so as to not break encapsulation of the collection while making the cursor efficient in its access.
Why do you not want to break the encapsulation of the collection? Ok, I guess you want to do for some reason. If so, then yes, a friend class would be ok. And so would a nested class, which according to the latest C++ standard suddenly was allowed to see all members in the parent class.
but I would like to see the GoF show what implementations they have in mind and to comment on usage of, say C++ friend declaration
It is too bad then that the book fails to satisfy you. Personally, I have no wish for even further C++ bias in the book.
1. Patterns: A way of structuring a computer program to achieve various goals such as robustness, maintainability, flexibility, ease of development, or whatever the author thinks is important. A pattern may or may not be obvious to different people, but usually some degree of non-obviousness is needed for somebody to actually write it down.
2. Algorithm: A recipe for solving a specific class of problems. It must be possible to prove that the algorithm always solves the input problem (if it is of the right class), and that it terminates in finite time. It must also be possible to write the algorithm in some imaginable computer language for some imaginable hardware.
3. Formula: A set of mathematical symbols thrown together in a syntactically meaningful way, intended to convey some meaning to the reader of the formula. It may also be used as the basis for a computation.
Well, I would never imagine it would have crashed. That would have been dead embarassing. But simply not starting is not much better (considering that the user probably wanted to run WfW even though it came from MS).
If that's true then MS had every reason to do that. They had no idea how compatible DrDos was with Windows, and they weren't going to fix it for somebody else's product.
Well, you may say that is a good reason. But if you really think that, then you probably have to mean that every other non-microsoft software should make a similar message appear when running a microsoft product. E.g. "I see your system is running winzip. Note that this is untrusted software that is not written by Microsoft. Your system may not work as a result of this." Depending on whether your or mine memory was right, you may append to the message: "For security reasons, Windows 2000 will shutdown now".
No, it isn't. Neither ANSI nor ISO C allows main to return anything but an int.
On most systems, that will even link and run without complaint.
I shudder to think about what you consider acceptable C, if you have to qualify "link and run without complaint" with "even".
But your system isn't the C standard, and the fact that it runs there doesn't mean it is valid C. Most systems allow i = i++ += ++i as well. The result is undefined, and that means that anything is allowed to happen (including program crash, spontaneous massive existence failure, making demons run out of your nose, or simply set i to some guessable value).
The fact that most calling conventions are sane enough for it not to matter defining a function returning nothing when the run-time-system really expects one returning success or failure as an integer, doesn't mean that it is valid (or that it makes sense, i.e.: what will your C program return to the OS after running?)
Some systems with ancient preludes won't take it.
So what you are saying is that, even though it is explicitly not allowed by the standard, it also doesn't work at all on some systems?
Such systems generally won't like the perfectly valid int main(int argc, char **argv, char **env) convention either.
Surprise. It isn't perfectly valid C. I'm not even shure if it's POSIX (although extern char **environ is). But it is pretty common among unixes.
Yes, but that is true for almost any kind of software. An operating system doesn't operate (a surgeon does). A word processor doesn't process words (the brain does), a spreadsheet isn't a sheet at all (and it doesn't it spread much), a data base doesn't have any data, a compiler doesn't compile and an assembler doesn't assemble (they both translate), a text editor doesn't edit (although you may use it for editing), a web browser doesn't browse (although you can use it to browse, although some people also read from it), most utilities aren't utilities (in the economic sense), and so on...
For me, the main feature of PDF is probably portability, yes. For 95% of the computing world, it's the fact that it's a distribution format that sucks less than office documents, has a free reader, and works on Windows.
Except DR-DOS didn't work with WfW 3.11 (If I remember correctly. Of course, this was because Microsoft deliberately crippled WfW, not because of technical reasons).
That being said, the stock market is designed to be unstable and fluctuate. Why it doesn't fluctuate even more is beyond my understanding, but there must be some factors that stabilize it as well (they are called long-term investors, I guess).
#include <stdio.h>
void main(){
printf("Hello, World!\n");
}
Why it is so hard for educators and book-authors to actually read the standard is beyond me...
And it also works better on a bad serial line, which is often the case when you need to use one over a serial line (or at least often my case). Emacs really likes having a somewhat predictable connection over the serial line it is using.
Then again, you're only supposed to start emacs once per session.
Well, when working mostly at the command-line, and only rarely need to edit a file, when you remote-login to many different computers to find out who is misbehaving, etc, you are not going to start an emacs session in the background each time, just in case you need it. Having vi available is sometimes good. Although for actual programming work, I prefer emacs (although I can live with XEmacs).
ObDisclaimer: Yes, I know what you mean, but this was actually the first thing that came to my mind...
On the other hand, the idea that an early ancestor of PostScript was more Forth-like doesn't sound too unlikely. Most likely it was, it seems like an obvious thing to use Forth for (embedded software, building a domain-specific language, etc...). Obviously, I wasn't around at that time, so I can't actually judge the truthfullness of your tale.
Paint it black!
Please send one to me, preferably one I can use in 1280x1024 on my desktop, and I'll tell you whether I like it...
Huh? I've already got several CD-players, so I think it's safe to say, they are already out.
I disagree wholeheartedly. While it's true that very many languages don't differ in anything but syntax (e.g. C, Pascal), the interesting differences are the semantic ones (e.g. C++, Prolog, Scheme, Forth, ML, Haskell, Mozart, Perl, M4, Icon). While many features superficially look the same, the meaning of two programs with similar-looking syntax or structure can be radically different. Syntax matters little beyond the initiall "sell".
But I really haven't seen a new concept in computer languages in 20 years.
Interesting. I find new interesting concepts in new languages every day. But I haven't been here for 20 years, and to some degree I believe what you are saying (if you are talking of major new concepts!). Few of the languages on the list above are very young. On the other hand, I guess template metaprogramming and constraint programming are both pretty new.
Paradoxically enough, that is true. While Forth is a completely unsafe, ridiculously simple to implement, machine near-language, Common Lisp is a big and complex language, trying to abstract away from the underlying machine as much as possible. Yet, they share this unique strength together, although in very different ways.
You are using wires and transistors? I'm preferring to use something I have complete control of, not to be at the whim of wire and transistor manufacturers. My computer is made out of a bunch of buckets, ropes, and a large supply or running water. Of course, it takes me years to do what you can do in a second, but at least I'm in complete control of every liter of water.
No, it isn't.
You can "program" Postscript...
Yes
Don't know why a non-printer driver person would want to, but you can...
Mainly because it's fun. But also because you can make some useful scripts to process postscript. E.g. 2-up, double-sided to single-sided, adding page numbers, etc...
But back to the first point. Postscript is to Forth as Python is to C (roughly). While Forth is an extremely low-level lanugage, Postscript requires a relatively heavy interpreter. A simple forth implementation can be made in a day, and a useful one in a week. PostScript requires much more effort (at least if you want it to be useful with a typical PostScript file). Forth is untyped, PostScript is dynamically typed. Forth has some nifty features making it a reflective extensible language (create does>), PostScript does not. In Forth, everything is a cell (pointer or signed or unsigned integer), PostScript has high-level datatypes like lists, code-blocks (anonymous functions), strings, fonts, etc... In Forth you typically allocate data on a stack, or once at the start of the program. PostScript is garbage collected. Forth is consistently minimal (whether you like it or not), PostScript is mostly high-level, but has some relatively unfriendly features such as fixed-size dictionaries to make it feel more unusable. Forth is easy to debug, and easy to crash your machine with. PostScript is hopeless to debug, but will rarely break anything serious. Forth is inherently unsafe, and is allowed to read/write any memory location, PostScript can be made safe enough to view random files on the web.
I could go on, but it should be clear by now that about the only resemblance the two languages share is postfix syntax.
E.g. the example with the car-industry is wrong (I don't work in the car industry, but I can guess). By the time they are finished with their design, the group will move on to the next model, and they will still need their big iron. It's not like the researchers and engineers will first design the car, and then get transferred to the production halls where they will be producing it, untill management decides it's time to make the next model!
Oh, but that's easy! Simply become an expert in whatever language is used, and you can easily file bug-reports :-)
But seriously, sending to both is probably easier and just as effective if you have made sure it's not reported several times before.
Because then you'd have to understand Oracle/PostgreSQL/MySQL/MS SQL/whatever to be able to fix it. Furthermore, you need it to be available to deploy it. And you rely on continued support from the company/individuals in question for it to last more than a few years. If it can be done with a simple text-file, or as a hierarchical database using the file-system, that will make the product simpler, smaller, and less reliant on third-party software. Sometimes reinventing the wheel is a good thing, if the wheel is sufficiently simple...
Sometimes I loose faith in democracy, producing more and more complex rules and regulations, making it less and less possible to make any sense of it at all...
As for email, I think the only solution is to make the sender pay for each email sent, like it is with phones, faxes, and snail-mail. The question is just how to do that, and who should receive the money :-)
Daniel Bernstein has a new email-system where the sender stores outgoing messages, not the reciever. That would help somewhat, but not enough (disk-space is cheap). Two other alternatives is hash-cash or micropayments. The reciever remains free to charge whatever he wants from any recipient, but must of course announce the amount before the email is sent. Typically, one would set this to something relatively low (say, one CPU second, or 10 cent) for unknown senders, and nothing at all to well-known senders (and something ridiculously high for really determined spammers ;-)