The following is an abridged and edited version of my full rant on the subject, available on my home page.
The following promises were made to us in the early days of the Shuttle: all these promises have failed to materialize.
The Shuttle is not a `space truck'.
It's more of a space Chevy pickup. When I think of trucks, I think of semis--things capable of carrying huge loads over long distances. The Saturn V rocket, the reliable workhorse of the Apollo program, could launch over 250,000 pounds to low Earth orbit or even put men on the moon. The Shuttle, by comparison, can only put 58,000 pounds into low Earth orbit and cannot reach higher orbits. Saturn V rockets made the 250,000-mile trip to the moon not once but several times, while the highest the Shuttle has ever gone is a meager 385 miles (335 nautical miles) during STS-82.
In fact, the Shuttle is so sharply limited that it rarely deploys a satellite directly. Instead, the satellite is mounted to yet another rocket, carried to low orbit in the Shuttle cargo bay, and the second rocket then kicks it into proper orbit. I don't understand the logic: we launch the Shuttle into orbit so we can have astronauts risk life and limb... launching another rocket into orbit?
The Shuttle is not reusable.
Endeavour cost $2.1 billion (source) and each launch costs $450 million (source) per mission. Most of that expense is taken up in refurbishing the Shuttle afterwards, where so much of the Shuttle is disassembled, inspected, replaced and reassembled that it's fair to declare it ``rebuilding'' instead of ``refurbishing''.
More than this, not one single flight component of the Shuttle--not one!--has met its original flight rating. For example, the Shuttle's main engines were originally rated for 27,000 seconds of thrust (about 55 flights). After that time, the engines would have to be replaced. This design goal has not been met. As Nobel Laureate Richard Feynman wrote in the official report on the Challenger disaster, ``[t]he engine now requires very frequent maintenance and replacement of important parts, such as turbopumps, bearings, sheet metal housings, etc.... [t]his is at most ten percent of the original specification.'' An engine with a life expectancy only a tenth what's expected may be replaceable and may be disposable, but it's not reusable.
Twenty-six launches per year?
Between maintenance, rebuilding and inspections, it's not uncommon for a given shuttle to only go up once a year. In Columbia's case, its final mission was its twenty--eighth flight in twenty--two years of service, and its second since 1999. We are nowhere near 26 launches per year per Shuttle; we aren't even close.
Cheap?
Hardly. Each launch costs $450 million. Even if the fleet were capable of 26 launches per shuttle per year, there's no way we could afford it. Instead of costing one hundred dollars to put a pound into orbit (as we were promised by NASA in the 1970s), it costs $7,750 ($450 million per flight, divided by 58,000 pounds of cargo). A 7,650%-cost overrun per flight can be read one and only one way: an engineering failure.
By comparison, the Saturn V rocket could put a pound into orbit for $3,500, and a Russian Proton-M for $2,062.
If the official NASA line of $450 million per flight isn't mind--boggling enough... try dividing the amount spent on the Space Shuttle from its conception through 1993 by the total number of flights over that time period. You get an amortized flight cost of over one billion dollars (``Space Shuttle Value Open to Interpretation'', Aviation Week Forum, July 26 1993).
Ten vehicles?
The first shuttles cost $1.7 billion. Endeavour cost $2.1 billion
C and C++ have templated containers -- Java's just now getting such genericity.
C does not, nor has it ever, supported either generics or standard containers. Yes, you can technically kludge something together with nasty preprocessor #defines, lots of void pointers and awful casts, but at that point you can say that C supports logic-based functional programming (ala PROLOG)... after all, with enough code any Turing-complete language can emulate any other.
"But there's an interesting Microsoft twist. During the days of the attack, Microsoft tried to deflect any blame by claiming that they issued a patch for the vulnerability six months previously, and that the only affected companies were the ones who didn't keep their patches up to date. A couple of days later, news leaked that Microsoft's own network was hit pretty badly by the worm because they didn't patch their own network."
From the parent:
"There's an interesting Microsoft twist to the recent Sapphire Worm, aka SQL Slammer. During the days of the attack, Microsoft tried to deflect any blame by claiming that they issued a patch for the vulnerability six months previously, and that the only affected companies were the ones who didn't keep their patches up to date. A couple of days later, news leaked that Microsoft's own network was hit pretty badly by the worm because they didn't patch their own network."
From Crypto-Gram:
"For a couple of years now I've been saying that the idea that we can achieve network security by finding and patching vulnerabilities in the field is fatally flawed. I don't blame Microsoft sysadmins for not having their patches up to date -- no one does -- but I don't like the hypocrisy out of the company.
The SQL Slammer worm also reopened the full disclosure debate. Microsoft announced the vulnerability in July 2002, at the same time they released the patch. A few days later, David Litchfield published exploit code that demonstrated how the vulnerability could be used to break into systems. January's SQL Slammer worm used that exact code. Some point to that and say that Litchfield should not have released the code, while others correctly say that the code wasn't hard to write, and that the worm author could have easily written it himself.
An amusing, but irrelevent, incident: A week after the worm, I was invited to speak about it live on CNN. The program was eventually preempted by the Columbia tragedy, but not before the CNN producers invited Microsoft to appear on the segment with me. Microsoft's spokesman -- I don't know who -- said that the company was unwilling to appear on CNN with me. They were willing to appear before me, they were willing to appear after me, but they were not willing to appear with me. Seems that it is official Microsoft corporate policy not to be seen in public with Bruce Schneier."
From the parent:
"The idea that we can achieve network security by finding and patching vulnerabilities in the field is fatally flawed. I've been saying this for a couple of years now. I don't blame Microsoft sysadmins for not having their patches up to date -- no one does -- but I don't like the hypocrisy out of the company. The answer lies in software programmers creating secure code.
The SQL Slammer worm also reopened the full disclosure debate. Microsoft announced the vulnerability in July 2002, at the same time they released the patch. A few days later, David Litchfield published exploit code that demonstrated how the vulnerability could be used to break into systems. January's SQL Slammer worm used that exact code. Some point to that and say that Litchfield should not have released the code, while others correctly say that the code wasn't hard to write, and that the worm author could have easily written it himself.
An amusing, but irrelevent, incident: A week after the worm, I was invited to speak about it live on CNN. The program was eventually preempted by the Columbia tragedy, but not before the CNN producers invited Microsoft to appear on the segment with me. Microsoft's spokesman -- I don't know who -- said that the company was unwilling to appear on CNN with me. They were willing to appear before me, they were willing to appear after me, but they were not willing to appear with me."
(Oh you haven't used an IDE before because all previous classes forced you to used gcc in a telnet session on our SunOS server? Well you'll figure it out, it's not like it's completely new and unfamilliar.)
Guy, I hate to be the one to tell you this, but it sounds like your prof is giving you an early start on the real world. I've seen the following things happen in the Real World:
A Perl guru who's never written a single line of C in his life gets the responsibility of code maintainer for a 1-MLOC C program.
A C++ programmer who doesn't know a single line of COBOL becomes responsible for white-box testing telco switching software written in COBOL.
A C++ programmer who's never touched Java before in his life gets thrown a JDK, an IDE, a copy of the codebase, and gets told there's a milestone next week.
... Ask anyone who's in industry and they'll tell you that one of the biggest, most important skills to develop is how to come up to speed in a completely new language/environment in three days flat. Not "become a guru of the language", but learn enough of the language to be a productive programmer.
So stop kvetching about how your prof expects you to know things you haven't been exposed to before. It's college. If you have enough intelligence to get the SAT scores required to get in, then you have enough intelligence to, on your own time, find someone who knows the IDE who's willing to give you an hour-long tutorial on it.
First--thank you for a wonderful response, even though I disagree with you.:)
ObDisclosure: I've been programming in LISP for about eight years. I learned CLOS early on, and found it to be too elephantine for my taste; it seemed like very few problems required an OOP approach and could be better solved in classic LISPing. This is purely my own personal taste, mind you, and I'm not claiming it's the One True LISP Way. It will go to show you my prejudices, though.
That said... I think before we go on we'll need to define what we mean by "operator overloading". As I showed in an earlier message, C overloads operators--practically every language engages in overloading. But anti-overloading partisans would take me to task for my C example, claiming... well, I'll let them make their claims themselves.:)
Here's my definition of "operator overloading": redefining existing compiler-supplied functions and operators is operator overloading. If + gets redefined to support string concatenation or complex math or what-have-you, that's overloading.
Why do I take this approach? There's not much difference between a function and an operator. In C, + is an operator which accepts two arguments and returns one returns. In LISP, + is a function which accepts arbitrary arguments and returns one value. Either way, they both take arguments and return values, which is the classical definition of a function. So given this, I consider an "operator" to be a function defined within the compiler and not its library.
So does LISP support operator overloading? LISP allows me to redefine read, eval and print. Thus, by my definition of operator overloading, LISP supports operator overloading.
Take away operator overloading and what you're really taking away is the programmer's ability to redefine the language. I don't think that enriches programmers; I think that impoverishes us.
Does the band own the rights to the the music?. if they do, then you will be clear.
Close. If the band owns the rights to the lyrics, AND if the original poster has, in writing, formal permission from the band to put tabulature and lyrics on his site, AND he's acting in complete accordance with the terms of the written agreement... then he's safe.
Anything else and he's in danger. The more of those AND clauses he's missing, the greater the danger. If he doesn't have a written agreement, then he's well and truly fucked. Oral agreements are almost totally unenforceable; they'll provide him with essentially no protection in a lawsuit.
What makes you think the Dave Matthews Band's knowledge and acceptance matters? It doesn't matter. The only question is who holds the copyright on the lyrics... and if you have the permission of the copyright holder, even that's not a sure thing.
After all, the MPA's lawyers can, if they so choose, make an argument that you're not acting in accordance with the permission granted to you by the copyright owner. They can make an argument that the person who you think holds the copyright really doesn't. They can... etcetera, etcetera, etcetera. And what have you done? You've just taunted them, dared them, "please, please, Mr. MPA Attorney, break out all the dirty and foul tricks you can to get even with me".
You're an idiot. Stop reading Slashdot. Get a lawyer. NOW.
If you've been part of two lawsuits already, then by God, you ought to know this already without being told.
Yes. Read the subject line again. You. Are. An. Idiot.
What's your goal here? To continue to run your Website? To not need to kneel down and kiss the MPA's boots? To make a stand and defend a sane interpretation of copyright law? All of them are admirable goals. In your shoes, I'd probably have the same ones.
How are you going about achieving your goal? By tweaking lawyers. By tweaking lawyers who have already implicitly threatened serious legal action. By tweaking lawyers who work for a massive and well-funded organization who have already implicitly threatened serious legal action.
FOR FUCK'S SAKE, WHAT DID YOU THINK YOU WERE DOING?
Immature and juvenile responses have a quick, immediate feel-good reaction, sure, I can understand that. But it doesn't keep them from being immature and juvenile and unwise.
Please, please, please, consider the following to be free legal advice:
When lawyers are threatening you with lawsuits, the proper response is not to write a snarky letter. The proper response is to get your own damn lawyer and let him write a snarky letter.
Why? Because he knows how to fight these chumps.
You don't.
And no, saying "well, I read the Constitution a few times and I read Slashdot" doesn't count for crap in a legal-education sense.
Get yourself a lawyer. Now. Stop reading Slashdot and call a lawyer.
ObWarning: I am not a lawyer and I am not licensed to practice law. I am the son of a judge. And I have seen, firsthand, what happens to people who think they can take on lawyers.
So I say that by limiting the options of all programmers you make it simpler for everyone, but at the expense of those few programers that actually know what they are doing.
So you think that since very few artists are capable of making good line art (line art is perhaps the hardest of the Western artistic styles), we should forbid artists to have pencils, in the name of improving the average quality of art?
The trick is not to lobotomize a language into something that even an idiot can use safely, because then only idiots will use it. The trick is to create a language in which the idiots won't need to know the advanced techniques (overloading, functional programming, generic programming, etc.) in order to accomplish their tasks, and in which the maestros won't need to resort to ugly kludges and hacks in order to use their advanced techniques.
My favorite language for this "good for idiots and for maestros" is currently Python. It's not perfect, though--I really, really miss true lexical scoping and strong lambda.
I think C++ went too far one way: in order to write nontrivial programs often requires a very nontrivial understanding of the language. I think Java went too far the other way: many extremely powerful programming techniques are simply not possible in Java, all in the name of making things simpler for the average programmer.
McCarthy's LISP 1.5 was never meant to be used by industry. (In fact, it was never meant to be a computer language at all; McCarthy's LISP was meant as a simpler model of the Turing Machine, and it was only turned into a proper programming language by an enterprising grad student.)
MacLISP, ZetaLISP, etc., were all attempts to take a purely theoretical language and turn it into a language useful for productive tasks. Why do you consider this to be an example of LISP's flexibility causing forks? If LISP wasn't that flexible, it would have never been able to make the leap out of the laboratory and into the real world.
Once people had experience at making LISP work in the Real World, then Common LISP came about. This is the way languages evolve, and that's just the way it should be.
No language ever springs from a designer's head full-blown and perfect, like Athena erupting from Zeus' skull. A cycle of languages diverging and then converging is a sure sign that the language is healthy and alive.
Ask any LISP programmer how well they could work if they weren't allowed to redefine the language (redefine it on-the-fly, even). Operator overloading is not bad; it's reckless use of overloading which is bad.
If you overload + so that it suddenly means "Multiply by 34 and truncate to the nearest prime", that's not the language's fault: that's your own fault for being a damnfool idiot. Just like if you overload + for complex numbers so that it does complex arithmetic, it's not to the language's credit: it's to your credit that you used an appropriate overload.
Look at LISP, in which pretty much any part of the language can be overloaded. Nobody's ever complained that this linguistic flexibility has harmed LISP; in fact, this linguistic flexibility is almost universally hailed as one of LISP's strengths.
Parting thought for the overloading-is-bad crowd:
C overloads, too.
After all, you can do:
float pi = 3.14159; float e = 2.71828; float result_float; float result_int; int constant = 1;
// + defined for addition of two floats result_float = pi + e; // + defined for addition of two ints result_int = constant + 0; // + defined for addition of a float and an int result_float = pi + constant;
... I mean, come on. C overloads, so "overloading is evil" is a meme which you really ought to know better than to propagate.
Overloading isn't evil.
Stupid overloading is evil.
And you will never, never, never, succeed in creating a programming language in which it is impossible to do stupid things.
On the contrary: it's not trivially true at all. If C++ was incapable of generating code with C's speed and resource footprint, then even if you programmed in the C-like subset of C++, you'd be unable to use C++ compilers in the C space. Just because a language is Turing-complete doesn't mean it can be used in all situations in place of another Turing-complete language.
But it's exactly the intrinsic complexity of C++ that limits the number of compilers that can be made for them.
You haven't seen C++ for the embedded space, have you? You're assuming that "embedded C++" necessarily means "full access to the huge spread of modern C++98 facilities". It doesn't. There are very few full ANSI/ISO C++98 environments for the embedded space, because it makes no economic sense to invest that much money producing a compiler where a large number of the features (STL, templates, exceptions, RTTI) not only will never be used, but literally cannot be used due to memory/time requirements. This is not the same thing as saying there are very few C++ environments for the embedded space; the Embedded C++ Technical Committee is rapidly approaching a standard and many manufacturers are promising to support it as soon as the standard is published.
And who's committing to C++ in the embedded space? A bunch of nobodies, like NEC, Toshiba, Hitachi, Mitsubishi, Red Hat, and Dinkumware. (Dinkumware is PJ Plauger's company, and is an extremely well-respected C++ outfit.) All have committed to using C++ in the embedded space.
(I think Red Hat's interest in Embedded C++ stems from their lack of success with iTRON, but don't quote me on that...)
Please, please, please, learn about C++ in the embedded space before you go about talking about how C++ in the embedded space is a foolish idea, or how C++ cannot be used profitably in the embedded space, or how it's the inherent complexity of C++ which will forever bar it from the embedded space.
(Of course, being simpler-to-write-an-interpreter-for doesn't mean simpler-to-think-in, so Lisp mainly attracts academians.)
LISP is a far simpler language, conceptually speaking, than C++ or even C. My copy of K&R has 272 pages. McCarthy's original LISP specification has 12. Scheme is even more terse. ANSI Common LISP has a larger spec, but all but about 100 pages deal with the semantics of CLOS.
Really? You can't do stuff like that in C or C++? I'd beg to differ.
Let me rephrase: in virtually any other language, I would need to write a function to do the additions. People who write functions in C-style macros are Evil. Re: inlining, that's only possible with C++; C89 doesn't support inlining.
And even then, there's no guarantee that the macros would make the code more comprehensible. For instance, try the following macro on for size:
C-style macros don't accept varargs, so if you want to do multiple modulo additions you've got to resort to that baroque syntax. In LISP, you just do something like the following:
(+mod32 a b c d)
... and +mod32 follows the same rules of associativity, grouping, etc., which the conventional LISP #'+ does. This is a Very Big Win: it permits you an astonishing amount of linguistic flexibility which can be applied towards making your code easy to understand.
Programs are, first and foremost, written for human beings. That they are compilable is just a fortunate happenstance. C-style macros are not Evil because they are inefficient; they are Evil because they sacrifice the first task of a program (to communicate its idea to whatever poor schmuck is stuck maintaining your code in six months) on the altar of the second, less important, task (efficiency), and completely disregard everything else (i.e., safety). . . . . . [*] Or, on IA32 platforms, you could just do a + b + c + d, since the C operator is really a modulo-addition operator. But grant me my example for sake of pedagogy.
Also, it's statically typed. It's so fucking annoying to have to typecast everything
You're confusing strong typing with static typing. Strong typing just means that it's very anal-retentive about type. Static typing means the checks are all done at compile-time.
It's pretty easy to come up with situations in which the typing is done dynamically (i.e., at run-time). So no, Java is no more a statically typed language than C++ is: both of them allow you to defer type analysis until runtime.
Java and C++ are strongly typed languages, but they're not clearly either statically typed nor dynamically typed. Some languages (Objective C, Smalltalk) are purely dynamically-typed; some are purely statically-typed; C++ and Java are hybrids.
I have yet to see any instance where C could be used, but C++ couldn't. Let me repeat that: I have yet to see any instance where C could be used, but C++ couldn't.
People keep on forgetting two very important things about C++. The first is, it has support for virtually all of ISO C90. The second is, one of the big maxims in C++ is you don't pay for what you don't use. If you write C90 code and compile it in C++, you don't incur any penalties for objects, for templates, for iostreams...
Take a look at Stroustrup's recommended books for learning C++. One of the first books listed is the K&R C book. According to Stroustrup, every program in K&R C is a well-written C++ program.
So no, there's actually very little out there which is based on C and only C. There are probably lots of embedded systems for which C89 compilers are the only ones available, but that's purely a limitation of economics (not enough money to spend on developing a C++ environment), not an inherent limitation of C++.
Fortunately, Bjarne Stroustrup has never--not once, not ever--claimed C++ is an object-oriented programming language. He says OO is one of the programming styles C++ supports... but that's not the same thing as saying C++ is an object-oriented language. (Long-time C++ programmers generally think the idea of C++ as an object-oriented language is silly: it has primitive data types and explicitly supports procedural programming. How can it be an OO language?)
Any language which cannot be redefined is, much like any programmer who says languages must not be redefined, fundamentally wrong. If you can't rewrite your language on the fly, then what good is it?:)
Signed,
A Very Happy LISP Programmer. . . . . . . . . . . No, really. Redefining the language is one of those things which sounds like a bad idea, up until the time you learn functional languages. Once you grok functional languages, redefining the language becomes second nature to you: for any given serious programming task, you modify the language into a special-purpose language meant specifically for solving your problem. For instance, I wrote a crypto library in LISP recently, and I needed to do a lot of addition modulo 2**32. In any other language, I'd have to write a function to do the additions... in LISP, I just wrote a macro.
Redefining the language is an astonishingly powerful technique, and once you grok it, the idea of a language forbidding you the ability to redefine itself seems like an Apocalyptically Bad Idea.
Good UNIX API bindings: I want POSIX/XOpen libraries which are (a) LISPy, (b) freely available, and (c) usable across different environments. Sure, you can use your environment's foreign function call interface to call pretty much any Cism that you want, but writing C-style code in LISP just offends my sense of aesthetics.
Good graphical toolkit: I'd be happy as a clam if there were good GTK+2.x/Qt3 bindings which were (a) LISPy, (b) freely available and (c) usable across different environments. Supposedly, there's work on a Common LISP GTK+2 binding, but I haven't seen much progress on it.
I wrote an essay about Language Holy Wars a while ago which, perhaps, you might find interesting. It's over here.
Personally, I find it nothing short of terrifying that C is still used as much as it is. When you're dealing with hard realtime constraints, or an embedded system which barely has a bit of memory to spare, etc., then I can see it... but otherwise, for God's sake, use something appropriate to the problem set.
Personally, I love LISP. If only there were good UNIX API bindings for it, and a good graphical toolkit...
DKM's own Website is found at www.queenofangels.com. It generally has more current information than the Kithrup site, and you can probably even find Dan's email address in the site somewhere...
Last I heard, Players: the AI War had actually been sold to a Russian publisher. So if you grok Russian, you're in luck...
Daniel Keys Moran wrote an extremely well-received SF trilogy: Emerald Eyes, The Long Run and The Last Dancer. Remarkable books, but due to a lot of Real Life stuff (divorce, birth of a son, new job, etc.) and the Woes of the Publishing Industry (contract disputes with Bantam, etc.), the succeeding novel, while written, has never been published.
Check out some of DKM's stuff, if you like. It's not hard SF--DKM doesn't hold a candle to Vernor Vinge or Robert Forward[*]--it's definitely pretty firm SF. Just not quite hard.
[*] Bob Forward is a great author of hard SF. Unfortunately, his dialog and characters are... *cough* painful. Fortunately, DKM doesn't have that problem.:)
The proposal would be for all MTAs too reject any messages without a proper hash. Any ip sending to many bad emails would be blacklisted. Any messages without a valid hash would be dropped.
As long as we're living in fantasyland, why not just say "the proposal is for all MTAs to disable anonymous relaying"? Isn't that a hell of a lot simpler?
Backward compatibility of the system could not be maintained, because it would make the whole idea pointless.... And it won't be adopted unless there's backwards compatibility. Standards get firmly entrenched and are infamously hard to get people away from. Look at how many ISPs are rolling out IPv6. Whatever solution you come up with has to (a) solve the problem and (b) be backwards compatible with everything else out there.
It doesn't open the door anymore for DDoS attacks anymore than it currently is. It actually improves the situation slightly since you have more information to use to decide if a message is legitimate
You really want to rethink this one. You get literally one bit of extra information: "did the originating MTA correctly fill out the X-SHA1-HASH field?" For this one bit of information, you have to compute a message hash. You don't get that information until you pay the tax. If you're paying the tax on millions of emails a day, then it's far, far more trouble than it's worth.
Please, please, please, read the literature.
Bruce Schneier has a bon mot about how there are so many completely useless algorithms out there because it's trivial to come up with an algorithm that you can't break. What's hard is coming up with an algorithm that nobody can break. The same applies to antispam proposals. You're coming up with ideas which you can't shoot down, and you're thinking they're new and inventive and potentially useful. What you don't see is that the X-SHA1-HASH idea is as old as the hills, and nobody takes it seriously because of all the damning flaws in it.
Slashdot Mirror
The following promises were made to us in the early days of the Shuttle: all these promises have failed to materialize.
It's more of a space Chevy pickup. When I think of trucks, I think of semis--things capable of carrying huge loads over long distances. The Saturn V rocket, the reliable workhorse of the Apollo program, could launch over 250,000 pounds to low Earth orbit or even put men on the moon. The Shuttle, by comparison, can only put 58,000 pounds into low Earth orbit and cannot reach higher orbits. Saturn V rockets made the 250,000-mile trip to the moon not once but several times, while the highest the Shuttle has ever gone is a meager 385 miles (335 nautical miles) during STS-82.
In fact, the Shuttle is so sharply limited that it rarely deploys a satellite directly. Instead, the satellite is mounted to yet another rocket, carried to low orbit in the Shuttle cargo bay, and the second rocket then kicks it into proper orbit. I don't understand the logic: we launch the Shuttle into orbit so we can have astronauts risk life and limb
Endeavour cost $2.1 billion (source) and each launch costs $450 million (source) per mission. Most of that expense is taken up in refurbishing the Shuttle afterwards, where so much of the Shuttle is disassembled, inspected, replaced and reassembled that it's fair to declare it ``rebuilding'' instead of ``refurbishing''.
More than this, not one single flight component of the Shuttle--not one!--has met its original flight rating. For example, the Shuttle's main engines were originally rated for 27,000 seconds of thrust (about 55 flights). After that time, the engines would have to be replaced. This design goal has not been met. As Nobel Laureate Richard Feynman wrote in the official report on the Challenger disaster, ``[t]he engine now requires very frequent maintenance and replacement of important parts, such as turbopumps, bearings, sheet metal housings, etc.
Between maintenance, rebuilding and inspections, it's not uncommon for a given shuttle to only go up once a year. In Columbia's case, its final mission was its twenty--eighth flight in twenty--two years of service, and its second since 1999. We are nowhere near 26 launches per year per Shuttle; we aren't even close.
Hardly. Each launch costs $450 million. Even if the fleet were capable of 26 launches per shuttle per year, there's no way we could afford it. Instead of costing one hundred dollars to put a pound into orbit (as we were promised by NASA in the 1970s), it costs $7,750 ($450 million per flight, divided by 58,000 pounds of cargo). A 7,650%-cost overrun per flight can be read one and only one way: an engineering failure.
By comparison, the Saturn V rocket could put a pound into orbit for $3,500, and a Russian Proton-M for $2,062.
If the official NASA line of $450 million per flight isn't mind--boggling enough
The first shuttles cost $1.7 billion. Endeavour cost $2.1 billion
C and C++ have templated containers -- Java's just now getting such genericity.
C does not, nor has it ever, supported either generics or standard containers. Yes, you can technically kludge something together with nasty preprocessor #defines, lots of void pointers and awful casts, but at that point you can say that C supports logic-based functional programming (ala PROLOG)... after all, with enough code any Turing-complete language can emulate any other.
There once was a professor named Fisk
Who made love with an action so brisk
The Lorentz Contraction
Came into action
And shortened his rod to a disk.
-- Isaac Asimov
The parent post is gratuitous plagiarism. See for yourself.
From Bruce Schneier's February 15 Crypto-Gram:
"But there's an interesting Microsoft twist. During the days of the attack, Microsoft tried to deflect any blame by claiming that they issued a patch for the vulnerability six months previously, and that the only affected companies were the ones who didn't keep their patches up to date. A couple of days later, news leaked that Microsoft's own network was hit pretty badly by the worm because they didn't patch their own network."
From the parent:
"There's an interesting Microsoft twist to the recent Sapphire Worm, aka SQL Slammer. During the days of the attack, Microsoft tried to deflect any blame by claiming that they issued a patch for the vulnerability six months previously, and that the only affected companies were the ones who didn't keep their patches up to date. A couple of days later, news leaked that Microsoft's own network was hit pretty badly by the worm because they didn't patch their own network."
From Crypto-Gram:
"For a couple of years now I've been saying that the idea that we can achieve network security by finding and patching vulnerabilities in the field is fatally flawed. I don't blame Microsoft sysadmins for not having their patches up to date -- no one does -- but I don't like the hypocrisy out of the company.
The SQL Slammer worm also reopened the full disclosure debate. Microsoft announced the vulnerability in July 2002, at the same time they released the patch. A few days later, David Litchfield published exploit code that demonstrated how the vulnerability could be used to break into systems. January's SQL Slammer worm used that exact code. Some point to that and say that Litchfield should not have released the code, while others correctly say that the code wasn't hard to write, and that the worm author could have easily written it himself.
An amusing, but irrelevent, incident: A week after the worm, I was invited to speak about it live on CNN. The program was eventually preempted by the Columbia tragedy, but not before the CNN producers invited Microsoft to appear on the segment with me. Microsoft's spokesman -- I don't know who -- said that the company was unwilling to appear on CNN with me. They were willing to appear before me, they were willing to appear after me, but they were not willing to appear with me. Seems that it is official Microsoft corporate policy not to be seen in public with Bruce Schneier."
From the parent:
"The idea that we can achieve network security by finding and patching vulnerabilities in the field is fatally flawed. I've been saying this for a couple of years now. I don't blame Microsoft sysadmins for not having their patches up to date -- no one does -- but I don't like the hypocrisy out of the company. The answer lies in software programmers creating secure code.
The SQL Slammer worm also reopened the full disclosure debate. Microsoft announced the vulnerability in July 2002, at the same time they released the patch. A few days later, David Litchfield published exploit code that demonstrated how the vulnerability could be used to break into systems. January's SQL Slammer worm used that exact code. Some point to that and say that Litchfield should not have released the code, while others correctly say that the code wasn't hard to write, and that the worm author could have easily written it himself.
An amusing, but irrelevent, incident: A week after the worm, I was invited to speak about it live on CNN. The program was eventually preempted by the Columbia tragedy, but not before the CNN producers invited Microsoft to appear on the segment with me. Microsoft's spokesman -- I don't know who -- said that the company was unwilling to appear on CNN with me. They were willing to appear before me, they were willing to appear after me, but they were not willing to appear with me."
Guy, I hate to be the one to tell you this, but it sounds like your prof is giving you an early start on the real world. I've seen the following things happen in the Real World:
So stop kvetching about how your prof expects you to know things you haven't been exposed to before. It's college. If you have enough intelligence to get the SAT scores required to get in, then you have enough intelligence to, on your own time, find someone who knows the IDE who's willing to give you an hour-long tutorial on it.
First--thank you for a wonderful response, even though I disagree with you. :)
:)
ObDisclosure: I've been programming in LISP for about eight years. I learned CLOS early on, and found it to be too elephantine for my taste; it seemed like very few problems required an OOP approach and could be better solved in classic LISPing. This is purely my own personal taste, mind you, and I'm not claiming it's the One True LISP Way. It will go to show you my prejudices, though.
That said... I think before we go on we'll need to define what we mean by "operator overloading". As I showed in an earlier message, C overloads operators--practically every language engages in overloading. But anti-overloading partisans would take me to task for my C example, claiming... well, I'll let them make their claims themselves.
Here's my definition of "operator overloading": redefining existing compiler-supplied functions and operators is operator overloading. If + gets redefined to support string concatenation or complex math or what-have-you, that's overloading.
Why do I take this approach? There's not much difference between a function and an operator. In C, + is an operator which accepts two arguments and returns one returns. In LISP, + is a function which accepts arbitrary arguments and returns one value. Either way, they both take arguments and return values, which is the classical definition of a function. So given this, I consider an "operator" to be a function defined within the compiler and not its library.
So does LISP support operator overloading? LISP allows me to redefine read, eval and print. Thus, by my definition of operator overloading, LISP supports operator overloading.
Take away operator overloading and what you're really taking away is the programmer's ability to redefine the language. I don't think that enriches programmers; I think that impoverishes us.
Does the band own the rights to the the music?. if they do, then you will be clear.
Close. If the band owns the rights to the lyrics, AND if the original poster has, in writing, formal permission from the band to put tabulature and lyrics on his site, AND he's acting in complete accordance with the terms of the written agreement... then he's safe.
Anything else and he's in danger. The more of those AND clauses he's missing, the greater the danger. If he doesn't have a written agreement, then he's well and truly fucked. Oral agreements are almost totally unenforceable; they'll provide him with essentially no protection in a lawsuit.
What makes you think the Dave Matthews Band's knowledge and acceptance matters? It doesn't matter. The only question is who holds the copyright on the lyrics... and if you have the permission of the copyright holder, even that's not a sure thing.
... etcetera, etcetera, etcetera. And what have you done? You've just taunted them, dared them, "please, please, Mr. MPA Attorney, break out all the dirty and foul tricks you can to get even with me".
After all, the MPA's lawyers can, if they so choose, make an argument that you're not acting in accordance with the permission granted to you by the copyright owner. They can make an argument that the person who you think holds the copyright really doesn't. They can
You're an idiot. Stop reading Slashdot. Get a lawyer. NOW.
If you've been part of two lawsuits already, then by God, you ought to know this already without being told.
Yes. Read the subject line again. You. Are. An. Idiot.
What's your goal here? To continue to run your Website? To not need to kneel down and kiss the MPA's boots? To make a stand and defend a sane interpretation of copyright law? All of them are admirable goals. In your shoes, I'd probably have the same ones.
How are you going about achieving your goal? By tweaking lawyers. By tweaking lawyers who have already implicitly threatened serious legal action. By tweaking lawyers who work for a massive and well-funded organization who have already implicitly threatened serious legal action.
FOR FUCK'S SAKE, WHAT DID YOU THINK YOU WERE DOING?
Immature and juvenile responses have a quick, immediate feel-good reaction, sure, I can understand that. But it doesn't keep them from being immature and juvenile and unwise.
Please, please, please, consider the following to be free legal advice:
When lawyers are threatening you with lawsuits, the proper response is not to write a snarky letter. The proper response is to get your own damn lawyer and let him write a snarky letter.
Why? Because he knows how to fight these chumps.
You don't.
And no, saying "well, I read the Constitution a few times and I read Slashdot" doesn't count for crap in a legal-education sense.
Get yourself a lawyer. Now. Stop reading Slashdot and call a lawyer.
ObWarning: I am not a lawyer and I am not licensed to practice law. I am the son of a judge. And I have seen, firsthand, what happens to people who think they can take on lawyers.
So I say that by limiting the options of all programmers you make it simpler for everyone, but at the expense of those few programers that actually know what they are doing.
So you think that since very few artists are capable of making good line art (line art is perhaps the hardest of the Western artistic styles), we should forbid artists to have pencils, in the name of improving the average quality of art?
The trick is not to lobotomize a language into something that even an idiot can use safely, because then only idiots will use it. The trick is to create a language in which the idiots won't need to know the advanced techniques (overloading, functional programming, generic programming, etc.) in order to accomplish their tasks, and in which the maestros won't need to resort to ugly kludges and hacks in order to use their advanced techniques.
My favorite language for this "good for idiots and for maestros" is currently Python. It's not perfect, though--I really, really miss true lexical scoping and strong lambda.
I think C++ went too far one way: in order to write nontrivial programs often requires a very nontrivial understanding of the language. I think Java went too far the other way: many extremely powerful programming techniques are simply not possible in Java, all in the name of making things simpler for the average programmer.
While technically right, this misses the point.
McCarthy's LISP 1.5 was never meant to be used by industry. (In fact, it was never meant to be a computer language at all; McCarthy's LISP was meant as a simpler model of the Turing Machine, and it was only turned into a proper programming language by an enterprising grad student.)
MacLISP, ZetaLISP, etc., were all attempts to take a purely theoretical language and turn it into a language useful for productive tasks. Why do you consider this to be an example of LISP's flexibility causing forks? If LISP wasn't that flexible, it would have never been able to make the leap out of the laboratory and into the real world.
Once people had experience at making LISP work in the Real World, then Common LISP came about. This is the way languages evolve, and that's just the way it should be.
No language ever springs from a designer's head full-blown and perfect, like Athena erupting from Zeus' skull. A cycle of languages diverging and then converging is a sure sign that the language is healthy and alive.
If you overload + so that it suddenly means "Multiply by 34 and truncate to the nearest prime", that's not the language's fault: that's your own fault for being a damnfool idiot. Just like if you overload + for complex numbers so that it does complex arithmetic, it's not to the language's credit: it's to your credit that you used an appropriate overload.
Look at LISP, in which pretty much any part of the language can be overloaded. Nobody's ever complained that this linguistic flexibility has harmed LISP; in fact, this linguistic flexibility is almost universally hailed as one of LISP's strengths.
Parting thought for the overloading-is-bad crowd:
C overloads, too.
After all, you can do:
... I mean, come on. C overloads, so "overloading is evil" is a meme which you really ought to know better than to propagate.
Overloading isn't evil.
Stupid overloading is evil.
And you will never, never, never, succeed in creating a programming language in which it is impossible to do stupid things.
On the contrary: it's not trivially true at all. If C++ was incapable of generating code with C's speed and resource footprint, then even if you programmed in the C-like subset of C++, you'd be unable to use C++ compilers in the C space. Just because a language is Turing-complete doesn't mean it can be used in all situations in place of another Turing-complete language.
But it's exactly the intrinsic complexity of C++ that limits the number of compilers that can be made for them.
You haven't seen C++ for the embedded space, have you? You're assuming that "embedded C++" necessarily means "full access to the huge spread of modern C++98 facilities". It doesn't. There are very few full ANSI/ISO C++98 environments for the embedded space, because it makes no economic sense to invest that much money producing a compiler where a large number of the features (STL, templates, exceptions, RTTI) not only will never be used, but literally cannot be used due to memory/time requirements. This is not the same thing as saying there are very few C++ environments for the embedded space; the Embedded C++ Technical Committee is rapidly approaching a standard and many manufacturers are promising to support it as soon as the standard is published.
And who's committing to C++ in the embedded space? A bunch of nobodies, like NEC, Toshiba, Hitachi, Mitsubishi, Red Hat, and Dinkumware. (Dinkumware is PJ Plauger's company, and is an extremely well-respected C++ outfit.) All have committed to using C++ in the embedded space.
(I think Red Hat's interest in Embedded C++ stems from their lack of success with iTRON, but don't quote me on that...)
Please, please, please, learn about C++ in the embedded space before you go about talking about how C++ in the embedded space is a foolish idea, or how C++ cannot be used profitably in the embedded space, or how it's the inherent complexity of C++ which will forever bar it from the embedded space.
(Of course, being simpler-to-write-an-interpreter-for doesn't mean simpler-to-think-in, so Lisp mainly attracts academians.)
LISP is a far simpler language, conceptually speaking, than C++ or even C. My copy of K&R has 272 pages. McCarthy's original LISP specification has 12. Scheme is even more terse. ANSI Common LISP has a larger spec, but all but about 100 pages deal with the semantics of CLOS.
Really? You can't do stuff like that in C or C++? I'd beg to differ.
Let me rephrase: in virtually any other language, I would need to write a function to do the additions. People who write functions in C-style macros are Evil. Re: inlining, that's only possible with C++; C89 doesn't support inlining.
And even then, there's no guarantee that the macros would make the code more comprehensible. For instance, try the following macro on for size:
PLUS_MOD32(a, PLUS_MOD32(b, PLUS_MOD32(c, PLUS_MOD32(d)))); [*]
C-style macros don't accept varargs, so if you want to do multiple modulo additions you've got to resort to that baroque syntax. In LISP, you just do something like the following:
(+mod32 a b c d)
... and +mod32 follows the same rules of associativity, grouping, etc., which the conventional LISP #'+ does. This is a Very Big Win: it permits you an astonishing amount of linguistic flexibility which can be applied towards making your code easy to understand.
Programs are, first and foremost, written for human beings. That they are compilable is just a fortunate happenstance. C-style macros are not Evil because they are inefficient; they are Evil because they sacrifice the first task of a program (to communicate its idea to whatever poor schmuck is stuck maintaining your code in six months) on the altar of the second, less important, task (efficiency), and completely disregard everything else (i.e., safety).
.
.
.
.
.
[*] Or, on IA32 platforms, you could just do a + b + c + d, since the C operator is really a modulo-addition operator. But grant me my example for sake of pedagogy.
Also, it's statically typed. It's so fucking annoying to have to typecast everything
You're confusing strong typing with static typing. Strong typing just means that it's very anal-retentive about type. Static typing means the checks are all done at compile-time.
It's pretty easy to come up with situations in which the typing is done dynamically (i.e., at run-time). So no, Java is no more a statically typed language than C++ is: both of them allow you to defer type analysis until runtime.
Java and C++ are strongly typed languages, but they're not clearly either statically typed nor dynamically typed. Some languages (Objective C, Smalltalk) are purely dynamically-typed; some are purely statically-typed; C++ and Java are hybrids.
I have yet to see any instance where C could be used, but C++ couldn't. Let me repeat that: I have yet to see any instance where C could be used, but C++ couldn't.
People keep on forgetting two very important things about C++. The first is, it has support for virtually all of ISO C90. The second is, one of the big maxims in C++ is you don't pay for what you don't use. If you write C90 code and compile it in C++, you don't incur any penalties for objects, for templates, for iostreams...
Take a look at Stroustrup's recommended books for learning C++. One of the first books listed is the K&R C book. According to Stroustrup, every program in K&R C is a well-written C++ program.
So no, there's actually very little out there which is based on C and only C. There are probably lots of embedded systems for which C89 compilers are the only ones available, but that's purely a limitation of economics (not enough money to spend on developing a C++ environment), not an inherent limitation of C++.
Fortunately, Bjarne Stroustrup has never--not once, not ever--claimed C++ is an object-oriented programming language. He says OO is one of the programming styles C++ supports... but that's not the same thing as saying C++ is an object-oriented language. (Long-time C++ programmers generally think the idea of C++ as an object-oriented language is silly: it has primitive data types and explicitly supports procedural programming. How can it be an OO language?)
:)
Java isn't OO, either. Primitive data types.
Any language which cannot be redefined is, much like any programmer who says languages must not be redefined, fundamentally wrong. If you can't rewrite your language on the fly, then what good is it? :)
Signed,
A Very Happy LISP Programmer.
.
.
.
.
.
.
.
.
.
.
No, really. Redefining the language is one of those things which sounds like a bad idea, up until the time you learn functional languages. Once you grok functional languages, redefining the language becomes second nature to you: for any given serious programming task, you modify the language into a special-purpose language meant specifically for solving your problem. For instance, I wrote a crypto library in LISP recently, and I needed to do a lot of addition modulo 2**32. In any other language, I'd have to write a function to do the additions... in LISP, I just wrote a macro.
Redefining the language is an astonishingly powerful technique, and once you grok it, the idea of a language forbidding you the ability to redefine itself seems like an Apocalyptically Bad Idea.
Haven't found GTK+/Qt/Swing bindings for it--or am I just not looking in the right place?
Good UNIX API bindings: I want POSIX/XOpen libraries which are (a) LISPy, (b) freely available, and (c) usable across different environments. Sure, you can use your environment's foreign function call interface to call pretty much any Cism that you want, but writing C-style code in LISP just offends my sense of aesthetics.
Good graphical toolkit: I'd be happy as a clam if there were good GTK+2.x/Qt3 bindings which were (a) LISPy, (b) freely available and (c) usable across different environments. Supposedly, there's work on a Common LISP GTK+2 binding, but I haven't seen much progress on it.
You forgot The Ring, which is a piece which Dan would probably like to forget he ever wrote. :)
I wrote an essay about Language Holy Wars a while ago which, perhaps, you might find interesting. It's over here.
Personally, I find it nothing short of terrifying that C is still used as much as it is. When you're dealing with hard realtime constraints, or an embedded system which barely has a bit of memory to spare, etc., then I can see it... but otherwise, for God's sake, use something appropriate to the problem set.
Personally, I love LISP. If only there were good UNIX API bindings for it, and a good graphical toolkit...
DKM's own Website is found at www.queenofangels.com. It generally has more current information than the Kithrup site, and you can probably even find Dan's email address in the site somewhere...
Last I heard, Players: the AI War had actually been sold to a Russian publisher. So if you grok Russian, you're in luck...
Daniel Keys Moran wrote an extremely well-received SF trilogy: Emerald Eyes, The Long Run and The Last Dancer. Remarkable books, but due to a lot of Real Life stuff (divorce, birth of a son, new job, etc.) and the Woes of the Publishing Industry (contract disputes with Bantam, etc.), the succeeding novel, while written, has never been published.
... *cough* painful. Fortunately, DKM doesn't have that problem. :)
Check out some of DKM's stuff, if you like. It's not hard SF--DKM doesn't hold a candle to Vernor Vinge or Robert Forward[*]--it's definitely pretty firm SF. Just not quite hard.
[*] Bob Forward is a great author of hard SF. Unfortunately, his dialog and characters are
The proposal would be for all MTAs too reject any messages without a proper hash. Any ip sending to many bad emails would be blacklisted. Any messages without a valid hash would be dropped.
... And it won't be adopted unless there's backwards compatibility. Standards get firmly entrenched and are infamously hard to get people away from. Look at how many ISPs are rolling out IPv6. Whatever solution you come up with has to (a) solve the problem and (b) be backwards compatible with everything else out there.
As long as we're living in fantasyland, why not just say "the proposal is for all MTAs to disable anonymous relaying"? Isn't that a hell of a lot simpler?
Backward compatibility of the system could not be maintained, because it would make the whole idea pointless.
It doesn't open the door anymore for DDoS attacks anymore than it currently is. It actually improves the situation slightly since you have more information to use to decide if a message is legitimate
You really want to rethink this one. You get literally one bit of extra information: "did the originating MTA correctly fill out the X-SHA1-HASH field?" For this one bit of information, you have to compute a message hash. You don't get that information until you pay the tax. If you're paying the tax on millions of emails a day, then it's far, far more trouble than it's worth.
Please, please, please, read the literature.
Bruce Schneier has a bon mot about how there are so many completely useless algorithms out there because it's trivial to come up with an algorithm that you can't break. What's hard is coming up with an algorithm that nobody can break. The same applies to antispam proposals. You're coming up with ideas which you can't shoot down, and you're thinking they're new and inventive and potentially useful. What you don't see is that the X-SHA1-HASH idea is as old as the hills, and nobody takes it seriously because of all the damning flaws in it.