Another security-through-obscurity device got broken, and what is the reaction of powers-that-be? Outlaw the devices that let people get around this measures. You could as well outlaw crime.
LOL. As if Crime isn't already outlawed! Oh, how would you define crime, if it wasn't illegal?
I mean, I could design several orders of magnitude better system while eating pizza, and I'm just stupid sysadm/programmer.
Yeah, I think we've heard this one before. And it's quite common for stupid people to have exaggerated opinions of themselves...
And pretty much every main-, mini- and real micro- computer design. I guess the computer industry is finally catching up to the 70s fashion mini-revival of a few years ago.
Yeah, and then a decade or two from now, they will soon find out that producing all these specialized units is a waste, when one general purpose processor can easily do the work of all of them.
Then, a decade or two after that, they will move more and more tasks into specialized circuitry, freeing the CPU to do real computation.
Untill, a few decades later, they realize this is a waste, and start eliminating circuitry, having a powerful general-purpose processor do all the work they previously did.
But then people will realize that by adding specialized processor for certain tasks, they free up computing power from the CPU, giving them potentially higher performance.
And so on...
Don't you realize that there is nothing right or wrong about either approach. It ends up as what is right or wrong for the current generation of technology, and this can soon enough change. The best thing we can do about it is producing modular software that can easily be changed to incorporate the advances in hardware.
I am not intimately familiar with the different steps of chip manufacturing, but even if the metal used for the gate was somewhat unusual (ie nickle), wouldn't it make sense to work towards eliminating one of these steps to reduce the overall manufacturing cost?
No.
What the article was speaking of was using a metal as insulator. Since this doesn't make any sense at all, what they probably meant is a metal-oxide. You don't want an insulator as interconnect, because it doesn't interconnect.
Power is really related to heat and volume, not heat alone. Ie, it may be as hot at a nuclear reactor, but it can't heat the same volume of water as a nuclear reactor can to boiling.
This is nitpicking. The chip vs nuclear reactor heat example came up by extrapolating how todays CPU's use power, and by assuming that we would use similar ways to achieve better performance in future CPU. You can extrapolate this as long as you want. Since the power grows exponentially, soon enough you will have a sun or a supernova. But most people would probably realize that something requiring more than a few nuclear power plants to power it would be unpractical. In fact, most people would probably reject owning a computer that consumed just a few kilowatts.
Processors are not designed to generate heat, this is just a byproduct, so the Power consumed by the chip is probably MUCH greater than the power delivered by the chip as heat.
I would then like to ask you a simple question: Where does the rest of the energy end up at? If it's not converted to heat, it needs to be converted to some other form of energy, such as kinetic energy, light, etc.. (which in turn will sooner or later end up at heat, but possible elsewhere). Since a CPU doesn't do much physically interesting stuff in meatspace, I think it's safe to say that they are very effective heaters.
Switzerland (currently joining, but earlier denied membership because of their neutrality), the Vatican City, Taiwan (China is a member though), East-Timor, Kiribati, Nauru, Tuvalu and Tonga, and maybe a few others.
Also, there are probably a few micronations that could be added to the list, e.g. Sealand.
And, as with KAMAS and Forth too, they are able to prevent a useful, simplified environment at the surface, but still making the power and complexity available to those who want to use it.
Extremely silly suggestion. This will never happen. For a few cents, you can buy your own stamp, and send snail-mail with full anonymity, unread by third-parties, etc.. Add a few cents more, and you can even get a receipt upon arrival, or failure to get to the right person.
I highly doubt there would be many of us that would be stupid enough to waste their time "forwarding" e-mail manually for others. If actual people have to do the forwarding, why use e-mail at all?
It might be that we end up in a world with only whitelists, but the moment that happens, e-mail is dead. It's an old-fashioned, arcane protocol, and the only reason it survives is because it's univeral. If it's not universal anymore, there are plenty of groupware and (instant-)messaging applications ready to take it's place.
if china has the metals and the formula, why would their 'pirate' version be inferior to the american version, beyond its not being american?
Yeah, bad choice of words. The only meaningful interpretation of "pirate" here, would be either the manufacturing process, or the application. The application is obvious, the manufacturing method should be patented, like any other chemical process.
I have no idea which book you are talking about. Nor why you want to talk about chaos theory, which is clearly inappropriate here (although a trendy word).
Even my fathers high-school math books had examples of populations of two animals, one predator, and one herbivore. This is about the simplest differential equation you can get, and has probably been well-known for quite a few centuries. If anyone has felt the need to use chaos theory here, they must clearly have worked with completely different examples.
Furthermore, nobody is surprised that lemming populations are chaotic. The reason is that lemming populations are not chaotic. And we are not surprised about this either, is we've had the chance to observe lemming populations out in the nature for several millennia, and so far, they've been pretty regular in their cycles.
There is one thing I can agree with you about. Yes, there were no news here. Anyone half-way educated about biology would know better than to believe that lemmings do mass-suicide. Unfortunately, I haven't got access to nature and the original article, but I assume the "breakthrough" if any, would be more akin to a more reliable model, or better insight into why some model already works well. Solving differential equations for populations with 3 or 4 species shouldn't exactly be beyond the abilities of most biologists working with population.
Yes, prototypes like the Moller Skycar. I heard the MSRP was going to be about a million dollars, when the FAA certifies it for sale.
Oh please. Mr Moller has been working on this skycar of his since the 1960s, and during that period he has always been just a few years from completion. In the meantime, he has used about any trick of deceptive advertising in the book in order to lure money from easily fooled investors and geeks.
Given the number of years Moller has been at this, and the lack of success so far (he hasn't even done one untethered flight, I have high doubts if Mr. Moller will ever reach the age where a skycar (his or someone else's) will ever fly.
If Kent Pitman said that, then it was very likely a real consideration. At the time those issues were discussed, I was still dreaming about getting a C64...
Except for using lots of silly parentheses, the differences are akin to Pascal and C++.
Scheme is small, elegant, orthogonal, and unpractical. Every user uses their own dialect, and there are about a gazillion different implementations (one per user, perhaps), none of which are perfect, and all having incompatible features.
It grew up in the academic environment, and was originally based on Algol 68, with a lispish syntax. It is a great language, with lot's of great ideas. The only problem is that it's a small language with a small community of users, each of which works on their own implementation, and with an incomplete standard. As a result, you don't write scheme-programs, you write programs for your particular implementation (DrScheme is a good one to start with).
Common Lisp is a larger language, with more practical considerations. It also includes a large library of useful functions. Because the full common lisp spec is huge (although manageable compared to C++ or java), if you want a full implementation, you'd better go for a commercial implementation (although sbcl is pretty nice).
It is more of a direct descendant of the original lisp 1.5 than Scheme (or to be more correct, based on three different commercial lisps, which in turn were pretty much based on 1.5), and therefore includes a little bit more weirdness due to backwards compatibility. But the little bits of weirdness that exists usually turn out to be quite practical, so most users don't worry too much about it (in any case, it is certainly *far* from being comparable to C++ or Perl).
In general, if you are interested in creating a working program, you choose Common Lisp. If you like programming in Scheme, you choose Scheme. There might be other considerations, such as memory footprint.
Imagine in C that you had a keyword callc taking two arguments, an identifier and an expression to be evaluated. The identifier would be assigned the current continuation of the expression where the callcc occured. Since C is typed, callcc would have to return the appropriate type, so let's use C++ template syntax, e.g. callcc<int> for a continuation that returns an int.
For this to work, g would have to accept a function pointer taking and returning an int.
void g(int (*cont)(int)) {
cont(7);
printf("you never reach this");
}
Since cont in g is not a normal function, but in fact a continuation, calling cont is analoguous to returning the place where the continuation where created (the place we used callcc. In this example, it would be analogous to return 7; , (except that g is declared void), and f would print 10.
This might not seem useful, and in fact, it isn't (at least if you have exceptions), but there's nothing stopping you from capturing a continuation and using it several times. Imagine the following extension (f is as before).
Calling weirdo later in the program would have the effect of rearranging the stack so that we would return to the (still) active instantiation of f, and print out 3 + the argument we gave to weirdo. When f returns, it would return to the function that originally called it (which is probably not what you expect at all, and not where you are now, but is why continuations are so powerful).
It is certainly not like delegates... It is a really tricky goto, and should be looked at with the same suspicion. Also, continuations tend to be an all-or-nothing decision, you either pass them around everywhere, or you don't. Still it has it's uses.
In many ways, continuations are the GOTO of functional programming - you can do just everything with it, but it's not guaranteed to improve readability.
In fact, they are even worse. Continuations are long goto's, you can jump from anywhere to anywhere, unrestricted by scopes and procedure invocations. In FORTRAN you could at least use your grep to find out where you ended up. Continuations are dynamic, and it's impossible to know where you end up unless you understand the logic of the program. Anyone using call/cc often deserve to be shot. But it has it's uses.
It's Scheme that has call/cc. Common Lisp didn't provide it (though it's not hard to write something similar if you really want it.)
First part correct. Second part wrong.
Common Lisp knowingly sacrificed continuations, and in general, you can't add "something similar", as continuations are hard to implement. If you can add continuations to your Common Lisp implementation without modifying the runtime, chances are it already has them as an extension.
The reasoning behind not adding continuations is that they make some optimizations harder, they are unintuitive and hard to use, and it's not really what people want. What people want is exceptions and co-routines, both which can be added with smaller overhead than continuations. Unfortunately, only exceptions are supported by the Common Lisp standard.
Re:moving towards bloatware or are these important
on
C# 2.0 Spec Released
·
· Score: 1
You've truely engineered something great not when you can't add anything more to it, but only when you can no longer remove anything from it.
Well, what do you mean by "can no longer remove anything from it"?
If you mean "can no longer remove anything from it, and still preserve the semantics of the language", you've just described Scheme. Suffice it to say that not everybody think Scheme is the end of all languages. Scheme is super-elegant, but so unpractical to program in that everybody uses their own dialect which adds the features you need to do real-world programming. In this sense, scheme is like Pascal.
If you mean "can no longer remove anything from it that can't be simulated through other mechanisms with adequate performance", then you are basically looking at a minimal Forth. While great for embedded CPU's and programming for special Forth-chips, the language isn't exactly the ideal software engineering language. Chuck Moore's most recent forth, colorForth does for example not have any stack underrun checking. And no forth will ever have any kind of type system, you are always working on raw bits.
If you are meaning "can no longer remove anything from it, without loosing the ability to do anything at all", then you are basically looking at an assembler for a one instruction set architecture chip. While useful as an april fools joke, it doesn't really have any practical purpose.
There are plenty of languages that have "bloat" as part of their design. The idea is that features are useful, and users want them. Some classic examples are Common Lisp, C++, Java, Visual Basic, and Ada. All of these languages are either hugely successfull in the real world, or has a large academic following (or both). (PS: Yes I hate VB myself, but don't tell me it isn't important in the real world...)
Either learn to turn on warnings in your compiler, or find a better compiler. In particular gcc will complain with -Wall. But that is little reason to advocate gcc, as I think you would have to look hard to find a compiler that doesn't.
I'm not familiar with C#, but given it's java heritage, I suspect it's not even legal.
Think about this one: I give you two glasses of water. One looks clean, the other one looks yellowish. But I garantee you that the yellowish one is as safe as the other one. However, you may choose freely either one of them. Are you going to go with the yellowish water? You would be crazy.
You mean everyone drinking lemonade is crazy? Do you want to talk about it?
It would certainly write on most things. Paper being one of the exceptions (as it would tear it apart). But writing on e.g. most metals by scratching a ridge in the surface is certainly possible.
...Are very annoying. Much like OSS-pirates. And GNU-communists.
I suspect that in the future we will also have gnome-burglars, KDE-murderers, Apache-rapists, xfree86-child-molesters, PostgreSQL-drug-dealers, and MySQL-torturists.
But then again, we have Microsoft-dictatorship and SCO-lawyers, so who cares.
By the way, isn't it funny that lawyers is the only legitimate profession that doesn't need to be replaced by another word to sound bad?
DLT is a good tape that doesn't loose your data. It can also be about twice as fast as your average harddrive. IBM has some nice stacked tapedrives which let's you insert a rack of 10 or so tapes. With two tapedrives, you can alternate between them while the other is rewinding and loading the next tape. If you need higher speed, add enough RAM for buffering, and use more tapedrives.
Of course, at this point, you may seriously want to consider using a SAN solution anyway:-)
Slashdot Mirror
LOL. As if Crime isn't already outlawed! Oh, how would you define crime, if it wasn't illegal?
I mean, I could design several orders of magnitude better system while eating pizza, and I'm just stupid sysadm/programmer.
Yeah, I think we've heard this one before. And it's quite common for stupid people to have exaggerated opinions of themselves...
Yeah, and then a decade or two from now, they will soon find out that producing all these specialized units is a waste, when one general purpose processor can easily do the work of all of them.
Then, a decade or two after that, they will move more and more tasks into specialized circuitry, freeing the CPU to do real computation.
Untill, a few decades later, they realize this is a waste, and start eliminating circuitry, having a powerful general-purpose processor do all the work they previously did.
But then people will realize that by adding specialized processor for certain tasks, they free up computing power from the CPU, giving them potentially higher performance.
And so on...
Don't you realize that there is nothing right or wrong about either approach. It ends up as what is right or wrong for the current generation of technology, and this can soon enough change. The best thing we can do about it is producing modular software that can easily be changed to incorporate the advances in hardware.
No.
What the article was speaking of was using a metal as insulator. Since this doesn't make any sense at all, what they probably meant is a metal-oxide. You don't want an insulator as interconnect, because it doesn't interconnect.
This is nitpicking. The chip vs nuclear reactor heat example came up by extrapolating how todays CPU's use power, and by assuming that we would use similar ways to achieve better performance in future CPU. You can extrapolate this as long as you want. Since the power grows exponentially, soon enough you will have a sun or a supernova. But most people would probably realize that something requiring more than a few nuclear power plants to power it would be unpractical. In fact, most people would probably reject owning a computer that consumed just a few kilowatts.
Processors are not designed to generate heat, this is just a byproduct, so the Power consumed by the chip is probably MUCH greater than the power delivered by the chip as heat.
I would then like to ask you a simple question: Where does the rest of the energy end up at? If it's not converted to heat, it needs to be converted to some other form of energy, such as kinetic energy, light, etc.. (which in turn will sooner or later end up at heat, but possible elsewhere). Since a CPU doesn't do much physically interesting stuff in meatspace, I think it's safe to say that they are very effective heaters.
Also, there are probably a few micronations that could be added to the list, e.g. Sealand.
And, as with KAMAS and Forth too, they are able to prevent a useful, simplified environment at the surface, but still making the power and complexity available to those who want to use it.
Look at the 12th word.
What kind of slow?
Extremely silly suggestion. This will never happen. For a few cents, you can buy your own stamp, and send snail-mail with full anonymity, unread by third-parties, etc.. Add a few cents more, and you can even get a receipt upon arrival, or failure to get to the right person.
I highly doubt there would be many of us that would be stupid enough to waste their time "forwarding" e-mail manually for others. If actual people have to do the forwarding, why use e-mail at all?
It might be that we end up in a world with only whitelists, but the moment that happens, e-mail is dead. It's an old-fashioned, arcane protocol, and the only reason it survives is because it's univeral. If it's not universal anymore, there are plenty of groupware and (instant-)messaging applications ready to take it's place.
Yeah, bad choice of words. The only meaningful interpretation of "pirate" here, would be either the manufacturing process, or the application. The application is obvious, the manufacturing method should be patented, like any other chemical process.
Even my fathers high-school math books had examples of populations of two animals, one predator, and one herbivore. This is about the simplest differential equation you can get, and has probably been well-known for quite a few centuries. If anyone has felt the need to use chaos theory here, they must clearly have worked with completely different examples.
Furthermore, nobody is surprised that lemming populations are chaotic. The reason is that lemming populations are not chaotic. And we are not surprised about this either, is we've had the chance to observe lemming populations out in the nature for several millennia, and so far, they've been pretty regular in their cycles.
There is one thing I can agree with you about. Yes, there were no news here. Anyone half-way educated about biology would know better than to believe that lemmings do mass-suicide. Unfortunately, I haven't got access to nature and the original article, but I assume the "breakthrough" if any, would be more akin to a more reliable model, or better insight into why some model already works well. Solving differential equations for populations with 3 or 4 species shouldn't exactly be beyond the abilities of most biologists working with population.
Oh please. Mr Moller has been working on this skycar of his since the 1960s, and during that period he has always been just a few years from completion. In the meantime, he has used about any trick of deceptive advertising in the book in order to lure money from easily fooled investors and geeks.
Given the number of years Moller has been at this, and the lack of success so far (he hasn't even done one untethered flight, I have high doubts if Mr. Moller will ever reach the age where a skycar (his or someone else's) will ever fly.
In practice too
If Kent Pitman said that, then it was very likely a real consideration. At the time those issues were discussed, I was still dreaming about getting a C64...
Scheme is small, elegant, orthogonal, and unpractical. Every user uses their own dialect, and there are about a gazillion different implementations (one per user, perhaps), none of which are perfect, and all having incompatible features.
It grew up in the academic environment, and was originally based on Algol 68, with a lispish syntax. It is a great language, with lot's of great ideas. The only problem is that it's a small language with a small community of users, each of which works on their own implementation, and with an incomplete standard. As a result, you don't write scheme-programs, you write programs for your particular implementation (DrScheme is a good one to start with).
Common Lisp is a larger language, with more practical considerations. It also includes a large library of useful functions. Because the full common lisp spec is huge (although manageable compared to C++ or java), if you want a full implementation, you'd better go for a commercial implementation (although sbcl is pretty nice).
It is more of a direct descendant of the original lisp 1.5 than Scheme (or to be more correct, based on three different commercial lisps, which in turn were pretty much based on 1.5), and therefore includes a little bit more weirdness due to backwards compatibility. But the little bits of weirdness that exists usually turn out to be quite practical, so most users don't worry too much about it (in any case, it is certainly *far* from being comparable to C++ or Perl).
In general, if you are interested in creating a working program, you choose Common Lisp. If you like programming in Scheme, you choose Scheme. There might be other considerations, such as memory footprint.
Yeah, but is it major or minor C sharp? *sigh*
void f() {
printf("%d", 3 + callcc<int>(cont, g(cont)));
}
For this to work, g would have to accept a function pointer taking and returning an int.
void g(int (*cont)(int)) {
cont(7);
printf("you never reach this");
}
Since cont in g is not a normal function, but in fact a continuation, calling cont is analoguous to returning the place where the continuation where created (the place we used callcc. In this example, it would be analogous to return 7; , (except that g is declared void), and f would print 10.
This might not seem useful, and in fact, it isn't (at least if you have exceptions), but there's nothing stopping you from capturing a continuation and using it several times. Imagine the following extension (f is as before).
int (*weirdo)(int) = NULL;
void g(int (*cont)()) {
weirdo = cont;
cont(7);
printf("you never reach this");
}
Calling weirdo later in the program would have the effect of rearranging the stack so that we would return to the (still) active instantiation of f, and print out 3 + the argument we gave to weirdo. When f returns, it would return to the function that originally called it (which is probably not what you expect at all, and not where you are now, but is why continuations are so powerful).
It is certainly not like delegates... It is a really tricky goto, and should be looked at with the same suspicion. Also, continuations tend to be an all-or-nothing decision, you either pass them around everywhere, or you don't. Still it has it's uses.
In fact, they are even worse. Continuations are long goto's, you can jump from anywhere to anywhere, unrestricted by scopes and procedure invocations. In FORTRAN you could at least use your grep to find out where you ended up. Continuations are dynamic, and it's impossible to know where you end up unless you understand the logic of the program. Anyone using call/cc often deserve to be shot. But it has it's uses.
First part correct. Second part wrong.
Common Lisp knowingly sacrificed continuations, and in general, you can't add "something similar", as continuations are hard to implement. If you can add continuations to your Common Lisp implementation without modifying the runtime, chances are it already has them as an extension.
The reasoning behind not adding continuations is that they make some optimizations harder, they are unintuitive and hard to use, and it's not really what people want. What people want is exceptions and co-routines, both which can be added with smaller overhead than continuations. Unfortunately, only exceptions are supported by the Common Lisp standard.
Well, what do you mean by "can no longer remove anything from it"?
If you mean "can no longer remove anything from it, and still preserve the semantics of the language", you've just described Scheme. Suffice it to say that not everybody think Scheme is the end of all languages. Scheme is super-elegant, but so unpractical to program in that everybody uses their own dialect which adds the features you need to do real-world programming. In this sense, scheme is like Pascal.
If you mean "can no longer remove anything from it that can't be simulated through other mechanisms with adequate performance", then you are basically looking at a minimal Forth. While great for embedded CPU's and programming for special Forth-chips, the language isn't exactly the ideal software engineering language. Chuck Moore's most recent forth, colorForth does for example not have any stack underrun checking. And no forth will ever have any kind of type system, you are always working on raw bits.
If you are meaning "can no longer remove anything from it, without loosing the ability to do anything at all", then you are basically looking at an assembler for a one instruction set architecture chip. While useful as an april fools joke, it doesn't really have any practical purpose.
There are plenty of languages that have "bloat" as part of their design. The idea is that features are useful, and users want them. Some classic examples are Common Lisp, C++, Java, Visual Basic, and Ada. All of these languages are either hugely successfull in the real world, or has a large academic following (or both). (PS: Yes I hate VB myself, but don't tell me it isn't important in the real world...)
Either learn to turn on warnings in your compiler, or find a better compiler. In particular gcc will complain with -Wall. But that is little reason to advocate gcc, as I think you would have to look hard to find a compiler that doesn't.
I'm not familiar with C#, but given it's java heritage, I suspect it's not even legal.
You mean everyone drinking lemonade is crazy? Do you want to talk about it?
It would certainly write on most things. Paper being one of the exceptions (as it would tear it apart). But writing on e.g. most metals by scratching a ridge in the surface is certainly possible.
I suspect that in the future we will also have gnome-burglars, KDE-murderers, Apache-rapists, xfree86-child-molesters, PostgreSQL-drug-dealers, and MySQL-torturists.
But then again, we have Microsoft-dictatorship and SCO-lawyers, so who cares.
By the way, isn't it funny that lawyers is the only legitimate profession that doesn't need to be replaced by another word to sound bad?
Ouch, that hurts! What is the fine for tossing you smoke detector?
Of course, at this point, you may seriously want to consider using a SAN solution anyway :-)