There are positive and negative electric charges, but only one kind of gravity "charge". This makes it possible to block EMF using a faraday cage, but impossible to block gravity.
It also makes electromagnetic and gravitational fields completely incomparable, dimwit.
Not that functional languages don't have their merits, of course, but I honestly don't see why they should suddenly take over and obsolete other programming paradigms now.
I think that everybody who has had serious exposure to functional programming gets hooked. Be it in Lisp, Scheme, Haskell, ML, Erlang, it doesn't matter. Users of these languages rarely go back to C, Java or P-something. There's another, more abundant, kind of programmers, too. Those never learn more than two or three languages (most often C, Java, Basic), then argue endlessly how much better Java is compared to everything else (read: C and Basic) and invent stupid arguments along the lines of "If Lisp is so great, why is nobody using it?!". Well, because (nearly) everybody is stupid, that's why!
True, Haskell has been around since 1987 and hasn't taken over the world since. However, four significant things have happened in the meantime: the "Monadic Revolution" around 1994, which took the embarrassment of I/O out of Haskell; the FFI, formally defined in 2001, which allows really easy interfacing to C code; the Haskell Cabal, which is evolving into something like a cross of apt-get and CPAN; and last but not least Autrijus Tang, who will single-handedly convert every Perl programmer on the planet into a Haskell programmer. Or he might not. Who knows?...a language that combines functional and logical programming
There are some crosses of functional and logic programming out there, the canonical example probably being Mercury. On the other hand, one can embed logic programming in Haskell using a small library - no need for a logic programming language anymore!
Unless you do something to localize it, a variable is global;
Oh, I know what "my" and "local" do, and I do use them. I don't know where globals got into your... uhm... scope, but what I meant is this: An argument to a function can be anything, scalar or list, but no file handle. This works:
%a = { foo => bar }
fun( %a )
The same doesn't work with a file handle:
open FILE, "test.txt"
fun( FILE )
(There may be a comma too much in there.) To make it work, I would have to pass a reference to the symbol table entry containing the handle, of all things. Come on, even if you know about that, it is surprising and anything but orthogonal! And there's no intrinsic difficulty, even C can pass file descriptors around.
Perl 5 provides a clean, almost infinitely flexible OO environment
No, it doesn't. There's support for doing what is usually termed OOP (though nobody has an exact definition), and it certainly is flexible, too flexible for some peoples tastes, but it most definitely is not clean. Years after using this I feel the need for a shower just thinking of it.
segfaults from an over-eager garbage collector - excuse me??
We were using CORBA from Perl. The two don't go together very well, or maybe the implementation sucked. Whatever, Perl routinely threw my servants away while they were still needed. The next incoming request sent the application down with a segfault. I "fixed" it by giving each servant a reference to itself, effectively playing another bug in the GC against the first. Actually, Perl5 has no garbage collector, just reference counting (or something very close to that).
As for the memory leak... well, my variables were local. The problem was Parse::RecDescent, which leaves junk in the global symbol table each time it runs (it evals lots of subs). The GC cannot clean symbols, so this memory leaks. Granted, using a recdescent parser for ini-files was a stupid design anyway, but beyond my control.
When I finally had it with the crashing server, I wrote a wrapper in C(!) that checked if the CORBA servants where still alive and then restarted the server. Most people would write a Perl wrapper when they don't trust their C code... You see, I'm not that stupid and have been programming for years in various languages, but Perl was the only one I positively hated afterwards.
And if you're paying, feel free to foist some of that horror my way:)
I don't think so. I have found my panacea in Haskell (you know, that strange language Pugs6 is implemented in). It's far more regular, is easier on the eye and - believe it or not - it is more concise.
...it's more likely that's what you want most of the time anyway.
And such a comment regarding to the language where there's "more than one way to do it"?
My last real contact dates a while back, but it was Perl5, definitely. I distinctly remember that I certainly wanted the array. In list context. If I need that, I need that. Definitely, not unlikely. And the unpronounceable @{$...} was really annoying.
$a[0][0]
Nice. Works for array-of-references-to-arrays, but not for reference-to-array-of-references-to-arrays. Didn't you tell me it was the latter which I was more likely to want anyway? And why did the other poster put an arrow between the brackets? Just for fun or does it do something sometimes?
...or you will need to take special measures to avoid polluting the global namespace (just like in any other language that allows you to use globals for your own ends).
That's exactly the point! WTF do I need special measures?! What globals?! I hate global state, that's why I want to pass the filehandle to a function. If it works with a goddamn hash table, it has to work with a friggin filehandle as well!
Really, I have no prejudices against perl. I worked with it, together with coworkers who allegedly knew much, much more about it than I did. The application was unreliable. Everytime it broke, it broke in subtle, unpredictable ways, including algorithms that worked only "most of the time", HTML code visible to the user, because someone put a backslash too much somewhere, gross memory leaks and even segfaults due to an overeager garbage collector.
It was a horrifying experience. This agony should not be foisted on anyone, really.
If I had any idea where to start, I know I would have.
Nobody has any idea where to start, because grammar is hard. Grammar doesn't seem to follow simple rules, there are always exceptions. Whatever formalism you use, it will either accept almost anything as grammatical or reject perfectly valid sentences. What is "ungrammatical" depends a lot on context.
Here's the most absurd example, given by Steven Abney: "the a are of I". Word salad, isn't it? No, sometimes not. Sometimes "a" is a variable as in math, "are" is a measure of area and "I" is the name of an island or something. Then the word salad denotes the unknown area of an island.
Abney basically gave up on formal grammar checking or, equivalently, parsing. Heck, parsing might even be easier, as a parser can try to accept bad grammar. A grammar checker would need a notion of good taste. Well, not impossible, but definitely a research problem, not a programming problem.
Helps an awful lot against gibberish like @{$a[0]} to get the first row of a matrix.
Tell me again, how do i get the first element of the first array contained in the array of (references to) arrays? Was it ${$a[0]}[0] or probably @{$a[0]}}->[0] or a different permutation or another diacritical mark somewhere in there? Remind me, how do i pass a filehandle to a function? Something about \ or * or both and somehow I wouldn't pass a filehandle at all, but rather a "symbol table entry".
Neither is Haskell. Hell, one year ago most would have argued that Haskell is a research language, not meant for anything at all.
Perl is about... all the little scripts.
Perl is only good for scripting as long as you don't know anything better. One nice option is Scheme (via scsh). I'd really rather put up with nested parens than with the multitude of unpronounceable special characters in Perl. And I really dislike Perl's design principle of The Maximum Astonishment, too.
Even when the exposure level is very low, and there are no apparent symptoms for the irradiated person, the potential for cancer and mutation of genetic material increases.
This is actually unsupported. The knowledge about the effects of radiation basically originates at Hiroshima and Nagasaki, where it was possible to study the effects of high radiation doses. There's no data for low doses. Therefore the findings for high doses have been linearly extrapolated, this is the so called "linear, no threshold" (LNT) hypothesis. It's the most pessimistic assumption. For all kinds of chemical poisoning, low doses are less than proportionally dangerous.
The Chernobyl accident is the first opportunity to study the effects of low radiation doses. So far, it seems there is no measurable effect besides thyroid cancers caused by ingestion of I-131.
So what? Can you provide different numbers? "Everybody knows that radiation always causes cancer" is not only a very weak argument, it's also not supported by measured facts and probably wrong.
For example in Ukraine the number of Thyroid Cancer cases increased 10 times after the incident
This is a total of just 1800 cases of cancer. These people were treated and only about 10 of them died. In absolute numbers it doesn't sound as bad anymore, does it? Even those 1800 cases might be occult cancers discovered due to increased scrutiny.
What about the children... with very serious birth defects? What about the increased cancer rate?
Well, what about them? The total incidence rate of all types of cancer in the Ukraine has decreased after the accident. Mind you, it's probably a statistical anomaly, but it is also no increase.
The only study I've seen that linked Chernobyl and birth defects (Down's syndrome in this case) turned out to be misapplied statistics.
we may have made parts of the world unliveable for decades to come in the past
Not "we", rather "they", the Russians who built a cheap and unsafe plutonium production reactor and then scaled it up for civilian use. But even though, the unlivable part of the world is just half a square kilometer.
when nuke plants fail they fail really, really badly.
Incorrect overgeneralization. RBMK type plant fail really, really badly in that they don't reliably shut off and may burn after the accident. PWR fail by shutting off, at worst (nearly impossible) by melting without releasing anything into the environment. More modern designs (MSR, pebble bed reactor) cannot even melt by design.
Even TMI (an old BWR) actually failed by simply breaking without releasing anything. Only some stupid asshole thought the hydrogen in the pressure vessel could explode (it couldn't, there was no oxygen) and vented it, thereby releasing small amounts of radioactivity.
Really, I wish people acquired some basic understanding before making sweeping generalizations.
...would put such a giant system in a single place? Multiple mail servers don't have scalability problems.
Put one mail server in each department. Universities have done this nearly thirty years ago and it still works. It also saves bandwidth as intra-department email doesn't need to be routed. Everything works out of the box, they invented SMTP back in the 80ies to make this sort of thing possible.
If you really must give people their firstname.surname@company.com address, put the mapping into a database and have central routers forward accordingly.
Honestly, what's wrong with the tried and proven low tech solutions?
Why don't you give... to an administrative assistant... and see?
This has been done. With LaTeX, 80% of the work can be done in 20% of the time. Unfortunately, the remaining 20% of work take the remaining 80% of time... I wish I knew what kind of work that was (Cliparts maybe?). The impact on the sanity of the workers has not been assessed.
Anyway, AAs are not as stupid as you seem to imply, you insensitive clod.
Lisp, Scheme, ML, Haskell. There were Lisp operating systems twenty years ago, there's a Haskell OS today.
But anyway, who cares for "systems programming"? Do it in C if it works. Every language on the planet can interface to C code. Code the high level logic in something else. The performance bottlenecks aren't in "systems programming", but in heavy numerical work, in DSP like code or in traversing complex data structures.
Please explain... What effort? How is this beneficial?
C is too low level, almost assembly. A C program hides your intentions. As an example take image manipulation. You want to apply a simple operation to every pixel. In C, you use loop. Your original intention, that every pixel has to be visited exactly once and the order doesn't matter, is lost. The compiler could have used that information. In Haskell I simply use "map", which expresses my intention to the compiler.... C++ a NEWER language and see why new isn't always better.
C++ is no modern language... but you seem to imply that C++ makes optimization even more difficult than C. Well, it doesn't get easier, that's for sure. Could you explain what is harder?
Oh darn it, you're right on both accounts. Yes, there are independent instructions to be found over even larger distances than the number of instructions in flight. However, somewhere in there will be jumps, these make branch prediction and speculative execution necessary, this in turn means lots of work done and discarded, and so on. Okay, register renaming works... but I really can't see anything resembling beauty in that system.
The latter point is moot, I mixed up the names, but PA-RISC and PowerPc are similar enough that it doesn't matter. Anyway, Dynamo does what the compiler couldn't do: reorder instructions, fill delay slots, and so on.
This is not nearly as important as it is sometimes made to look. Sure complex logic uses a lot of transistors...
This is important. More transistors means larger chips, lower yield, higher price, more power consumption, need for more cooling with associated noise, and more room for (hardware!) bugs to creep in. Literally every processor on the market takes far less energy per work unit than ix86. Don't you think there's a reason for that?
Oh, I *do* think, 8 registers are a problem. Consider a superscalar processor with just two execution units and a four cycle deep pipeline. This isn't far fetched: modern processors have _more_ execution units and their pipelines are even _deeper_ (14 clocks for the K7 or something?).
In the simple example, up to 8 instructions are "in flight". At this point the register file of the ix86 is already exhausted, the next instruction definitely depends on one of the incomplete instructions. So even these few short pipes don't get filled. You need more registers to actually express more independent instructions.
Register renaming helps (otherwise Intel wouldn't have invented it). It does help by allowing speculative execution, but that work is often wasted, still tying up silicon and producing waste heat. Beyond that, renaming only helps if registers are renamed to memory locations. Now the CPU has to track which memory locations are actually saved registers, with all the complications caused when the memory is accessed by indexing from a pointer. (And again, the C programming style bites.)
This is simply nuts. So much effort, so many bugs, so much heat and noise - only to keep compatibility.
The x86 has a very space-efficient instruction encoding
This is true to some extent. Factor in spill code (remember that ix86 doesn't have the movem of the 68k) and the advantage is no longer obvious. Worse than that, a compact ISA is irrelevant.
Bandwidth between L1 cache and CPU is plentiful. So instead of a compact ISA, use a simple and regular instruction set and Huffman-encode it. Decoding (with a fixed table) is done when loading code into cache. I don't think this has ever been tried, so I can only imagine that it would be worthwhile.
But this line of thought can be extended. Why not have a truly large register file? Encoding the instructions is a non-issue, using Huffman-coding, only code that actually uses many registers needs full-width instructions. After decoding, software translation maps virtual registers to 16 to 32 real registers, whatever is deemed practical.
Such a CPU (even if it is actually two CPUs on one chip) could even execute multiple instruction sets simultaneously. Somehow this strikes me as far more elegant that millions of transistors patching up what was already obsolete in 1979.
BTW, "code morphing" has been proved in practice. Dynamo is a CPU emulator (aka VM) that emulates a PowerPC on a PowerPC. Sounds stupid? Yeah, that's what I thought, too. But the virtual CPU runs faster than the real CPU. Sounds impossible? Yeah, it does. There seems to be an awful lot of slack in the compiled code. Blame it on C, blame it on the compilers, whatever. But Dynamo simply works.
Hmpf. Actually Intel buggered nearly everything in its history but the ix86 line and the StrongArm. They built interesting things in the 80s and 90s, like the i860 and i960. Both of them were broken in some way and then a budget cut killed them.
Ix86 was broken from the beginning. Crappy instruction set, stupid addressing, the 80286 made everything even worse (just 4 bits more address space and then the A20 gate). The most astonishing thing in ix86 history is how they saved the i386, which really is a new processor with a compatibility mode... Intel only stayed on top in this market, because they had backwards compatibility working in their favor.
That leaves the StrongArm/XScale as real success. And that design was bought (ah, litigated, actually) from DEC.
Should we be pleased that Itanium failed?
Maybe not, but it may be inevitable. The design may indeed be subtly broken.
If AMD hadn't stepped up... would we be dropping x86 all together?
No, we wouldn't. Windows doesn't run anywhere else, MSFT seems too inept to port it, and the world doesn't seem to like going on without Windows. Instead we would invent "enhancements" to the Pentium, new addressing modes like those in the most despicable 80286, kludge support for them into Windows, like the abomination that was "i386 enhanced support" in Windows 3.0, and go on addressing terabytes on a geriatric processor architecture.
Come to think about it, this has already happened (PSE or whatever Intel calls it), it just isn't in widespread use yet. Meanwhile the Alpha and PA-RISC died. What an ugly economy...
Well, _C_ compilers are bad. That's not a fault of the compilers, it's to blame on C. If only people would put some effort into modern languages and actually using them...
In the meantime the sensible thing to do is not throwing yet more silicon on OoO execution, but doing this in software _at_runtime_. That is, Transmeta's code morphing is right. HP's Dynamo is also the right thing.
A sensible instruction set is also of benefit. On an ix86 with its measly 8 almost-general-purpose registers, a lot of instructions depend on each other. You get better results with more registers.
4. A kid gets a locked device handed to him with the key dangling on a chain. a) Obviously an invitation to open the device and use it. b) Obviously an oversight, the kid should immediately point this out to his supervisor and hand him the key. Kids aren't supposed to possess keys anyway.
Are you fucking out of your mind comparing this to the rape of a helpless victim? (And you too, mods! You should stop smoking this bad stuff.)
Pardon? You just put a keyfile on the flash drive. If the correct key is there, the car starts, if it isn't, it doesn't. You don't need any crypto, b/c the channel is secure (man-in-the-middle between you and your car? there's no room for that...). Who would intercept your key and copy it? YOUR CAR? That's ridiculous.
Will cops knock on your door because you parked in a mall, next to a store that had shoplifters?
Well yes, they will. How are they gonna find you? Oh, they use amazing high technology! They read a globally unique identifier from your car using an advanced optical scanner. You wouldn't believe it, but your car offers its identifier to anyone possessing the right kind of scanner, and billions of them exist worldwide. That high tech part is mass produced and installed in literally every car worldwide. It is called a licence plate.
Come on, just because you can copy your key without being a locksmith doesn't enable the Black Hats to steal your car. It's only the key, fercrissake!!!
Nature, as a whole moves in very slow patterns and makes very slow changes. It's not in a hurry. However, suddenly we analyse weather for what... 100 years?
See, that's exactly the problem. Nature moves slowly, so if we witness a rapid change, there has to be a reason for it. If nature doesn't present the reason, it's probably man-made. Just think of smog and acid-rain; they are very clearly man-made.
That said, the debate on global warming would certainly cool down if we had measuments showing a significant increase in temperature. The problem is, when we'll be able to measure it, it will probably be too late to stop it.
Slashdot Mirror
There are positive and negative electric charges, but only one kind of gravity "charge". This makes it possible to block EMF using a faraday cage, but impossible to block gravity.
It also makes electromagnetic and gravitational fields completely incomparable, dimwit.
Not that functional languages don't have their merits, of course, but I honestly don't see why they should suddenly take over and obsolete other programming paradigms now.
...a language that combines functional and logical programming
I think that everybody who has had serious exposure to functional programming gets hooked. Be it in Lisp, Scheme, Haskell, ML, Erlang, it doesn't matter. Users of these languages rarely go back to C, Java or P-something. There's another, more abundant, kind of programmers, too. Those never learn more than two or three languages (most often C, Java, Basic), then argue endlessly how much better Java is compared to everything else (read: C and Basic) and invent stupid arguments along the lines of "If Lisp is so great, why is nobody using it?!". Well, because (nearly) everybody is stupid, that's why!
True, Haskell has been around since 1987 and hasn't taken over the world since. However, four significant things have happened in the meantime: the "Monadic Revolution" around 1994, which took the embarrassment of I/O out of Haskell; the FFI, formally defined in 2001, which allows really easy interfacing to C code; the Haskell Cabal, which is evolving into something like a cross of apt-get and CPAN; and last but not least Autrijus Tang, who will single-handedly convert every Perl programmer on the planet into a Haskell programmer. Or he might not. Who knows?
There are some crosses of functional and logic programming out there, the canonical example probably being Mercury. On the other hand, one can embed logic programming in Haskell using a small library - no need for a logic programming language anymore!
Unless you do something to localize it, a variable is global;
Oh, I know what "my" and "local" do, and I do use them. I don't know where globals got into your... uhm... scope, but what I meant is this: An argument to a function can be anything, scalar or list, but no file handle. This works:
The same doesn't work with a file handle:
(There may be a comma too much in there.) To make it work, I would have to pass a reference to the symbol table entry containing the handle, of all things. Come on, even if you know about that, it is surprising and anything but orthogonal! And there's no intrinsic difficulty, even C can pass file descriptors around.
Perl 5 provides a clean, almost infinitely flexible OO environment
No, it doesn't. There's support for doing what is usually termed OOP (though nobody has an exact definition), and it certainly is flexible, too flexible for some peoples tastes, but it most definitely is not clean. Years after using this I feel the need for a shower just thinking of it.
segfaults from an over-eager garbage collector - excuse me??
We were using CORBA from Perl. The two don't go together very well, or maybe the implementation sucked. Whatever, Perl routinely threw my servants away while they were still needed. The next incoming request sent the application down with a segfault. I "fixed" it by giving each servant a reference to itself, effectively playing another bug in the GC against the first. Actually, Perl5 has no garbage collector, just reference counting (or something very close to that).
As for the memory leak... well, my variables were local. The problem was Parse::RecDescent, which leaves junk in the global symbol table each time it runs (it evals lots of subs). The GC cannot clean symbols, so this memory leaks. Granted, using a recdescent parser for ini-files was a stupid design anyway, but beyond my control.
When I finally had it with the crashing server, I wrote a wrapper in C(!) that checked if the CORBA servants where still alive and then restarted the server. Most people would write a Perl wrapper when they don't trust their C code... You see, I'm not that stupid and have been programming for years in various languages, but Perl was the only one I positively hated afterwards.
And if you're paying, feel free to foist some of that horror my way :)
I don't think so. I have found my panacea in Haskell (you know, that strange language Pugs6 is implemented in). It's far more regular, is easier on the eye and - believe it or not - it is more concise.
And such a comment regarding to the language where there's "more than one way to do it"?
My last real contact dates a while back, but it was Perl5, definitely. I distinctly remember that I certainly wanted the array. In list context. If I need that, I need that. Definitely, not unlikely. And the unpronounceable @{$...} was really annoying.
$a[0][0]
Nice. Works for array-of-references-to-arrays, but not for reference-to-array-of-references-to-arrays. Didn't you tell me it was the latter which I was more likely to want anyway? And why did the other poster put an arrow between the brackets? Just for fun or does it do something sometimes?
That's exactly the point! WTF do I need special measures?! What globals?! I hate global state, that's why I want to pass the filehandle to a function. If it works with a goddamn hash table, it has to work with a friggin filehandle as well!
Really, I have no prejudices against perl. I worked with it, together with coworkers who allegedly knew much, much more about it than I did. The application was unreliable. Everytime it broke, it broke in subtle, unpredictable ways, including algorithms that worked only "most of the time", HTML code visible to the user, because someone put a backslash too much somewhere, gross memory leaks and even segfaults due to an overeager garbage collector.
It was a horrifying experience. This agony should not be foisted on anyone, really.
If I had any idea where to start, I know I would have.
Nobody has any idea where to start, because grammar is hard. Grammar doesn't seem to follow simple rules, there are always exceptions. Whatever formalism you use, it will either accept almost anything as grammatical or reject perfectly valid sentences. What is "ungrammatical" depends a lot on context.
Here's the most absurd example, given by Steven Abney: "the a are of I". Word salad, isn't it? No, sometimes not. Sometimes "a" is a variable as in math, "are" is a measure of area and "I" is the name of an island or something. Then the word salad denotes the unknown area of an island.
Abney basically gave up on formal grammar checking or, equivalently, parsing. Heck, parsing might even be easier, as a parser can try to accept bad grammar. A grammar checker would need a notion of good taste. Well, not impossible, but definitely a research problem, not a programming problem.
Helps an awful lot against gibberish like @{$a[0]} to get the first row of a matrix.
Tell me again, how do i get the first element of the first array contained in the array of (references to) arrays? Was it ${$a[0]}[0] or probably @{$a[0]}}->[0] or a different permutation or another diacritical mark somewhere in there? Remind me, how do i pass a filehandle to a function? Something about \ or * or both and somehow I wouldn't pass a filehandle at all, but rather a "symbol table entry".
Astonishing.
You know, in Nethack, when you apply your bag of tricks, you pull a monster out of it.
I find this kinda fitting.
I don't think there's any language that can be fully understood after a 2-semester course.
Scheme and Forth, maybe even Smalltalk don't count?
Perl just isn't meant for systems programming.
Neither is Haskell. Hell, one year ago most would have argued that Haskell is a research language, not meant for anything at all.
Perl is about... all the little scripts.
Perl is only good for scripting as long as you don't know anything better. One nice option is Scheme (via scsh). I'd really rather put up with nested parens than with the multitude of unpronounceable special characters in Perl. And I really dislike Perl's design principle of The Maximum Astonishment, too.
Even when the exposure level is very low, and there are no apparent symptoms for the irradiated person, the potential for cancer and mutation of genetic material increases.
This is actually unsupported. The knowledge about the effects of radiation basically originates at Hiroshima and Nagasaki, where it was possible to study the effects of high radiation doses. There's no data for low doses. Therefore the findings for high doses have been linearly extrapolated, this is the so called "linear, no threshold" (LNT) hypothesis. It's the most pessimistic assumption. For all kinds of chemical poisoning, low doses are less than proportionally dangerous.
The Chernobyl accident is the first opportunity to study the effects of low radiation doses. So far, it seems there is no measurable effect besides thyroid cancers caused by ingestion of I-131.
So what? Can you provide different numbers? "Everybody knows that radiation always causes cancer" is not only a very weak argument, it's also not supported by measured facts and probably wrong.
For example in Ukraine the number of Thyroid Cancer cases increased 10 times after the incident
This is a total of just 1800 cases of cancer. These people were treated and only about 10 of them died. In absolute numbers it doesn't sound as bad anymore, does it? Even those 1800 cases might be occult cancers discovered due to increased scrutiny.
What about the children... with very serious birth defects? What about the increased cancer rate?
Well, what about them? The total incidence rate of all types of cancer in the Ukraine has decreased after the accident. Mind you, it's probably a statistical anomaly, but it is also no increase.
The only study I've seen that linked Chernobyl and birth defects (Down's syndrome in this case) turned out to be misapplied statistics.
we may have made parts of the world unliveable for decades to come in the past
Not "we", rather "they", the Russians who built a cheap and unsafe plutonium production reactor and then scaled it up for civilian use. But even though, the unlivable part of the world is just half a square kilometer.
when nuke plants fail they fail really, really badly.
Incorrect overgeneralization. RBMK type plant fail really, really badly in that they don't reliably shut off and may burn after the accident. PWR fail by shutting off, at worst (nearly impossible) by melting without releasing anything into the environment. More modern designs (MSR, pebble bed reactor) cannot even melt by design.
Even TMI (an old BWR) actually failed by simply breaking without releasing anything. Only some stupid asshole thought the hydrogen in the pressure vessel could explode (it couldn't, there was no oxygen) and vented it, thereby releasing small amounts of radioactivity.
Really, I wish people acquired some basic understanding before making sweeping generalizations.
...would put such a giant system in a single place? Multiple mail servers don't have scalability problems.
Put one mail server in each department. Universities have done this nearly thirty years ago and it still works. It also saves bandwidth as intra-department email doesn't need to be routed. Everything works out of the box, they invented SMTP back in the 80ies to make this sort of thing possible.
If you really must give people their firstname.surname@company.com address, put the mapping into a database and have central routers forward accordingly.
Honestly, what's wrong with the tried and proven low tech solutions?
Why don't you give... to an administrative assistant... and see?
This has been done. With LaTeX, 80% of the work can be done in 20% of the time. Unfortunately, the remaining 20% of work take the remaining 80% of time... I wish I knew what kind of work that was (Cliparts maybe?). The impact on the sanity of the workers has not been assessed.
Anyway, AAs are not as stupid as you seem to imply, you insensitive clod.
Lisp, Scheme, ML, Haskell. There were Lisp operating systems twenty years ago, there's a Haskell OS today.
... C++ a NEWER language and see why new isn't always better.
But anyway, who cares for "systems programming"? Do it in C if it works. Every language on the planet can interface to C code. Code the high level logic in something else. The performance bottlenecks aren't in "systems programming", but in heavy numerical work, in DSP like code or in traversing complex data structures.
Please explain... What effort? How is this beneficial?
C is too low level, almost assembly. A C program hides your intentions. As an example take image manipulation. You want to apply a simple operation to every pixel. In C, you use loop. Your original intention, that every pixel has to be visited exactly once and the order doesn't matter, is lost. The compiler could have used that information. In Haskell I simply use "map", which expresses my intention to the compiler.
C++ is no modern language... but you seem to imply that C++ makes optimization even more difficult than C. Well, it doesn't get easier, that's for sure. Could you explain what is harder?
You miss the beauty of register renaming
Dynamo runs PA-RISC on PA-RISC actually
Oh darn it, you're right on both accounts. Yes, there are independent instructions to be found over even larger distances than the number of instructions in flight. However, somewhere in there will be jumps, these make branch prediction and speculative execution necessary, this in turn means lots of work done and discarded, and so on. Okay, register renaming works... but I really can't see anything resembling beauty in that system.
The latter point is moot, I mixed up the names, but PA-RISC and PowerPc are similar enough that it doesn't matter. Anyway, Dynamo does what the compiler couldn't do: reorder instructions, fill delay slots, and so on.
This is not nearly as important as it is sometimes made to look. Sure complex logic uses a lot of transistors...
This is important. More transistors means larger chips, lower yield, higher price, more power consumption, need for more cooling with associated noise, and more room for (hardware!) bugs to creep in. Literally every processor on the market takes far less energy per work unit than ix86. Don't you think there's a reason for that?
Oh, I *do* think, 8 registers are a problem. Consider a superscalar processor with just two execution units and a four cycle deep pipeline. This isn't far fetched: modern processors have _more_ execution units and their pipelines are even _deeper_ (14 clocks for the K7 or something?).
In the simple example, up to 8 instructions are "in flight". At this point the register file of the ix86 is already exhausted, the next instruction definitely depends on one of the incomplete instructions. So even these few short pipes don't get filled. You need more registers to actually express more independent instructions.
Register renaming helps (otherwise Intel wouldn't have invented it). It does help by allowing speculative execution, but that work is often wasted, still tying up silicon and producing waste heat. Beyond that, renaming only helps if registers are renamed to memory locations. Now the CPU has to track which memory locations are actually saved registers, with all the complications caused when the memory is accessed by indexing from a pointer. (And again, the C programming style bites.)
This is simply nuts. So much effort, so many bugs, so much heat and noise - only to keep compatibility.
The x86 has a very space-efficient instruction encoding
This is true to some extent. Factor in spill code (remember that ix86 doesn't have the movem of the 68k) and the advantage is no longer obvious. Worse than that, a compact ISA is irrelevant.
Bandwidth between L1 cache and CPU is plentiful. So instead of a compact ISA, use a simple and regular instruction set and Huffman-encode it. Decoding (with a fixed table) is done when loading code into cache. I don't think this has ever been tried, so I can only imagine that it would be worthwhile.
But this line of thought can be extended. Why not have a truly large register file? Encoding the instructions is a non-issue, using Huffman-coding, only code that actually uses many registers needs full-width instructions. After decoding, software translation maps virtual registers to 16 to 32 real registers, whatever is deemed practical.
Such a CPU (even if it is actually two CPUs on one chip) could even execute multiple instruction sets simultaneously. Somehow this strikes me as far more elegant that millions of transistors patching up what was already obsolete in 1979.
BTW, "code morphing" has been proved in practice. Dynamo is a CPU emulator (aka VM) that emulates a PowerPC on a PowerPC. Sounds stupid? Yeah, that's what I thought, too. But the virtual CPU runs faster than the real CPU. Sounds impossible? Yeah, it does. There seems to be an awful lot of slack in the compiled code. Blame it on C, blame it on the compilers, whatever. But Dynamo simply works.
Hmpf. Actually Intel buggered nearly everything in its history but the ix86 line and the StrongArm. They built interesting things in the 80s and 90s, like the i860 and i960. Both of them were broken in some way and then a budget cut killed them.
... would we be dropping x86 all together?
Ix86 was broken from the beginning. Crappy instruction set, stupid addressing, the 80286 made everything even worse (just 4 bits more address space and then the A20 gate). The most astonishing thing in ix86 history is how they saved the i386, which really is a new processor with a compatibility mode... Intel only stayed on top in this market, because they had backwards compatibility working in their favor.
That leaves the StrongArm/XScale as real success. And that design was bought (ah, litigated, actually) from DEC.
Should we be pleased that Itanium failed?
Maybe not, but it may be inevitable. The design may indeed be subtly broken.
If AMD hadn't stepped up
No, we wouldn't. Windows doesn't run anywhere else, MSFT seems too inept to port it, and the world doesn't seem to like going on without Windows. Instead we would invent "enhancements" to the Pentium, new addressing modes like those in the most despicable 80286, kludge support for them into Windows, like the abomination that was "i386 enhanced support" in Windows 3.0, and go on addressing terabytes on a geriatric processor architecture.
Come to think about it, this has already happened (PSE or whatever Intel calls it), it just isn't in widespread use yet. Meanwhile the Alpha and PA-RISC died. What an ugly economy...
Well, _C_ compilers are bad. That's not a fault of the compilers, it's to blame on C. If only people would put some effort into modern languages and actually using them...
In the meantime the sensible thing to do is not throwing yet more silicon on OoO execution, but doing this in software _at_runtime_. That is, Transmeta's code morphing is right. HP's Dynamo is also the right thing.
A sensible instruction set is also of benefit. On an ix86 with its measly 8 almost-general-purpose registers, a lot of instructions depend on each other. You get better results with more registers.
No other scheme than with mechanical keys. In fact, you really need a copy, breaking the lock and hotwiring doesn't get you anywhere.
4. A kid gets a locked device handed to him with the key dangling on a chain.
a) Obviously an invitation to open the device and use it.
b) Obviously an oversight, the kid should immediately point this out to his supervisor and hand him the key. Kids aren't supposed to possess keys anyway.
Are you fucking out of your mind comparing this to the rape of a helpless victim? (And you too, mods! You should stop smoking this bad stuff.)
Pardon? You just put a keyfile on the flash drive. If the correct key is there, the car starts, if it isn't, it doesn't. You don't need any crypto, b/c the channel is secure (man-in-the-middle between you and your car? there's no room for that...). Who would intercept your key and copy it? YOUR CAR? That's ridiculous.
Will cops knock on your door because you parked in a mall, next to a store that had shoplifters?
Well yes, they will. How are they gonna find you? Oh, they use amazing high technology! They read a globally unique identifier from your car using an advanced optical scanner. You wouldn't believe it, but your car offers its identifier to anyone possessing the right kind of scanner, and billions of them exist worldwide. That high tech part is mass produced and installed in literally every car worldwide. It is called a licence plate.
Come on, just because you can copy your key without being a locksmith doesn't enable the Black Hats to steal your car. It's only the key, fercrissake!!!
Nature, as a whole moves in very slow patterns and makes very slow changes. It's not in a hurry. However, suddenly we analyse weather for what... 100 years?
See, that's exactly the problem. Nature moves slowly, so if we witness a rapid change, there has to be a reason for it. If nature doesn't present the reason, it's probably man-made. Just think of smog and acid-rain; they are very clearly man-made.
That said, the debate on global warming would certainly cool down if we had measuments showing a significant increase in temperature. The problem is, when we'll be able to measure it, it will probably be too late to stop it.