No, he will not die. The events in Transformers: The Movie should have taken place in the year 2005 (see scene two in the script). And, as best as I can recall, there wasn't an attack on Autobot City last year. Therefore, one can only assume that we are in an alternate timeline, one in which Optimus Prime will die in some other way.
Now, this may be a much more perilous timeline, as the attack on Autobot City led directly to the destruction of Unicron at the hands of the Autobots. Will he be destroyed before he reaches Earth or Cybertron? Only time will tell . ..
According to Transformers: The Movie, the Decepticons attack Autobot City in the year 2005. In the assault, Optimus Prime is destroyed, and the Autobots are left in the gravest situation yet.
To make matters worse Unicron is flying around eating planets.
Speaking of anti-intellectualism, I found several statements in Joel's essay both contradictory and anti-intellectual.
You need to spend at least a semester getting close to the machine or you'll never be able to create efficient code in higher level languages.
I agree that knowledge of the layers closest to the machine is very important, for a whollistic view of a computer system, for any programmer or computer scientist. However, the "efficiency" you learn using C isn't the really important kind of efficiency, the efficiency regarding analysis of asymptotic performance of algorithms. Knowing that a certain line of code in C translates to a single assembly instruction rather than two instructions really isn't important in the big picture, it is far more important that you choose quick sort, rather than bubble sort. In fact, higher level languages actually have an advantage here, because the abstractions they provide allow the programmer to code algorithms more quickly.
if you can't explain why while (*s++ = *t++); copies a string, or if that isn't the most natural thing in the world to you, well, you're programming based on superstition
This really isn't a very good example, that code is an ugly hack depending on arcane operator precedences and confusing order of execution. I do understand why it works, but I'd never write it in code (even though it'd increase my l33t h4x0r rating), nor would I expect someone to understand a statement like that if I did write it (even though I could mock them for their lack of l33t C skillz). Believing that this single obfuscated code statement is useful in determining programming skill is itself, superstition.
The anti-theory stance Joel takes in the "Take programming-intensive courses." (an assertion that I wouldn't argue with if you desire to be a software engineer), doesn't make a lick of sense. You shouldn't take courses involving programming to the exclusion of theory based courses, because they complement each other. Plus, you can always pick up experience coding working on your own projects, but learning logic and the formalisms in theoretical computer science are much harder to pick up in independent study.
Remember the importance Joel placed on "efficiency"? How can a programmer be confident that his algorithm is the most efficient if he doesn't know his theory? How can a programmer prove that his program actually does what it is supposed to if he doesn't know logic?
Now, I don't mean to flame here, I found the rest of his advice sound. I really hope he's right about the outsourcing thing, because having a job when I graduate would be a good thing!
Another thing that annoyed us about KDE's mail handling was the way it dealt with HTML messages. By default, every HTML message appears in source view, with a security warning and a link to render the HTML for viewing. We could opt instead to have all HTML messages render by default, but we'd prefer that Kontact provide the option of rendering the message in a "sanitized" form-one that doesn't fetch remote images or objects. Evolution and Thunderbird work this way by default.
KMail (and therefore Kontact) does provide "sanitized" HTML mail support. The KMail docs claim that sanitized is the default, but it is an easy change regardless. The check box is located in: Configure KMail -> Security -> "Allow messages to load external references from the Internet". It seems they didn't look too hard for the option that is default anyway.
As far as the warnings before rendering HTML messages, this is just a question of how paranoid you'd like to be (or, how important the integrity of you system is). HTML parsers/renderers are very complex software, and therefore they may have bugs. Look to the recent JPEG exploits for bad bugs in seemingly innocent software. If there were a bug found in the HTML renderer used by your mailreader, reading email messages might present a threat to the security and integrity of your computer.
Like the documentation in KMail says "Displaying the HTML part makes the message look better, but at the same time increases the risk of security holes being exploited"
Slashdot Mirror
No, he will not die. The events in Transformers: The Movie should have taken place in the year 2005 (see scene two in the script). And, as best as I can recall, there wasn't an attack on Autobot City last year. Therefore, one can only assume that we are in an alternate timeline, one in which Optimus Prime will die in some other way.
Now, this may be a much more perilous timeline, as the attack on Autobot City led directly to the destruction of Unicron at the hands of the Autobots. Will he be destroyed before he reaches Earth or Cybertron? Only time will tell . . .
That would be akin to saying that Nazi Germany was a good step forward because the trains ran on time.
It was Mussolini that supposedly made the trains run on time.
The more you tighten your grip, Mussolini, the more time tables will slip through your fingers.
Netcraft confirms: Moore's Law is dying!
According to Transformers: The Movie , the Decepticons attack Autobot City in the year 2005. In the assault, Optimus Prime is destroyed, and the Autobots are left in the gravest situation yet.
To make matters worse Unicron is flying around eating planets.
Isn't anybody else worried?
I agree that knowledge of the layers closest to the machine is very important, for a whollistic view of a computer system, for any programmer or computer scientist. However, the "efficiency" you learn using C isn't the really important kind of efficiency, the efficiency regarding analysis of asymptotic performance of algorithms. Knowing that a certain line of code in C translates to a single assembly instruction rather than two instructions really isn't important in the big picture, it is far more important that you choose quick sort, rather than bubble sort. In fact, higher level languages actually have an advantage here, because the abstractions they provide allow the programmer to code algorithms more quickly.
This really isn't a very good example, that code is an ugly hack depending on arcane operator precedences and confusing order of execution. I do understand why it works, but I'd never write it in code (even though it'd increase my l33t h4x0r rating), nor would I expect someone to understand a statement like that if I did write it (even though I could mock them for their lack of l33t C skillz). Believing that this single obfuscated code statement is useful in determining programming skill is itself, superstition.
The anti-theory stance Joel takes in the "Take programming-intensive courses." (an assertion that I wouldn't argue with if you desire to be a software engineer), doesn't make a lick of sense. You shouldn't take courses involving programming to the exclusion of theory based courses, because they complement each other. Plus, you can always pick up experience coding working on your own projects, but learning logic and the formalisms in theoretical computer science are much harder to pick up in independent study.
Remember the importance Joel placed on "efficiency"? How can a programmer be confident that his algorithm is the most efficient if he doesn't know his theory? How can a programmer prove that his program actually does what it is supposed to if he doesn't know logic?
Now, I don't mean to flame here, I found the rest of his advice sound. I really hope he's right about the outsourcing thing, because having a job when I graduate would be a good thing!
KMail (and therefore Kontact) does provide "sanitized" HTML mail support. The KMail docs claim that sanitized is the default, but it is an easy change regardless. The check box is located in: Configure KMail -> Security -> "Allow messages to load external references from the Internet". It seems they didn't look too hard for the option that is default anyway.
As far as the warnings before rendering HTML messages, this is just a question of how paranoid you'd like to be (or, how important the integrity of you system is). HTML parsers/renderers are very complex software, and therefore they may have bugs. Look to the recent JPEG exploits for bad bugs in seemingly innocent software. If there were a bug found in the HTML renderer used by your mailreader, reading email messages might present a threat to the security and integrity of your computer.
Like the documentation in KMail says "Displaying the HTML part makes the message look better, but at the same time increases the risk of security holes being exploited"
I've had this same issue, what do you do to "get around" it?