It's not that it demonstrates a bug in the shell; rather, this is the perfect example of shooting one's self in the foot. A single extra character (and an invisible one at that) changed the meaning of the command such that it wiped out all of someone's files.
Wow, was I ever wrong. Maybe you're playing a joke on me, but I'm going to assume your post is a serious attempt to explain inlining and the perils of metadata.
To begin with, I'm a JIT compiler developer. I know what inlining is. That's not what I was asking.
Second, your claims are wrong in almost every sentence. For instance, here is one particularly attrocious paragraph:
Inlining works like this. You write a function and assign it a variable name. Then, any place you want that function, you use the variable name. The "precompiler" converts any instance of the variable name into the original function. EX:
#DEFINE PISETUP int pi; pi = 22/7; #ENDDEF
Later, if you use the term PISETUP it will be replaced with that code by the precompiler.
What's wrong with this?
Functions are assigned function names. Variables are assigned variable names. They are two different things.
In C, it's called a "preprocessor", not a "precompiler", though I guess the latter makes just as much sense.
Your example is not a function. It is a variable declaration with an initialization. Therefore inlining doesn't apply.
The preprocessor has nothing to do with inlining. What you're describing is macro expansion.
pi is not 22/7!!:-)
A few more remarks:
One of the big "innovations" of Java was the elimination of the precompiler, which made sense. Java runs object code, not directly runnable byte code, so it is in essence already performing the tasks of the precompiler. The virtual machine "compiles" the code while it is running, to optimize for the individial physical machine, no matter what it may be.
Java is a language, and doesn't run anything. The Java Virtual Machine (JVM) runs bytecode, not directly runnable object code. The virtual machine may or may not use a JIT compiler to optimize for the individual machine. Any half-decent JIT compiler performs inlining, or else performance would be terrible; however, inlining is not what you think it is.
The idea worked IMO because, now that you can cut, paste, and find and replace (with regular and replace expressions), you don't really need these replacements. Might as well just be verbose as you want to be. Might as well use tiny little functions since inlining doesn't work anyway.
Hot damn, I hope I never need to deal with any code you write. This attitude is appalling. I'm going to go out on a limb and guess that you are not a professional software developer?
When you said "Java is not a language that inlines...that's the whole idea of the JIT" I thought you were correctly pointing out that Javac doesn't (and can't) do inlining. Apparently I was mistaken.
Anyway, thanks for taking the time to explain yourself.
Metadata is the only ingredient here that seems like it could cause trouble, and if it does it will be because people are using it wrong. Java is not a language that inlines...that's the whole idea of the JIT...and with today's cut and paste GUI IDEs, there's no need for programmers to use the lazy C declarations of the past. If people start doing so because it's neat, just nip it in the bud. Find/Replace when the code hits your desk. Eventually they'll get the hint.
I'm sorry, this whole paragraph just went over my head, but it sounds insightful, so I'd like to understand it.
What does "with today's cut and paste GUI IDEs, there's no need for programmers to use the lazy C declarations of the past" mean?
Right. So what languages need is the ability to make rules. Fred Brooks' visionary superstar programmer (with the brains of ten ordinary programmers) can make rules that the compiler enforces. The rest of the team then must follow the rules, or else (1) their code won't build, or (2) they must negotiate the rules with the superstar.
In your case, you need a rule like "overloading + is disallowed except in the following specific cases: (...)". Then the superstar could see to it that the few exceptions won't surprise anyone. If the compiler enforced this rule, you wouldn't constantly need to worry about that harebrained strangeness any dummy on the team might come up with.
Re:Mere logic screams that this is all oxdung.
on
Wall Street Meat
·
· Score: 1
I'm no expert, but it seems to me that advice is only one part of a stock broker's job. The other part is actually getting a trader to buy and sell the stock.
Your lottery analogy doesn't really apply. It's more like someone who knows how to get an edge on the house at a casino. Sure, he could go in there with his $100 and try to turn it into $1000, but suppose he gets clients with $1M, turns it into $10M, and then takes a 1% commission? Your way, he makes $900. My way, he makes $90k.
It's not that it was thought to be safe and then turned out not to be. If I recall, what happened is that they had this one type checking scheme that was safe, but it was too complicated to be practical, and involved whole-system analysis. So they came up with this second, simpler, incremental scheme (relating to "CAT calls", where CAT=Changed Availability or Type). However, even that's too complicated to be practical.
So no, Eiffel compilers still aren't statically typesafe. From practice, I can testify that it doesn't matter. Personally I don't use covariance (which is the one type hole) because I just don't think that way, but even if I did, the reliability from DbC more tham makes up for any reliability lost via the lack of static type safety.
64-bit ops can be more than twice as fast as 32-bit ops on 64-bit data. Consider multiplication, where you need to do four pairwise multiplies plus some adds. Or "neg", which is one instruction for 32-bit data, but three instructions for 64-bit data on a 32-bit machine. (neg low, adc high, neg high)
Look at the "success" IBM had making OS/2 run Win32 software. Result---developers only target Win32 because they get OS/2 for free, and so nobody is developing for OS/2 any more.
Though I suppose if it were an "add-on chip" that didn't ship with Mac boxes by default, that might prevent the OS/2 syndrome. People would be less likely to rely on the Windows software running on Macs if most Macs couldn't run it.
I think having to give away your software for free would appear pretty malicious to businesses. From their point of view, the virus analogy is a good one: don't touch GPL code if you want to keep your software proprietary.
Slashdot Mirror
Are you serious?
Sounds kind of like Eiffel's Design by Contract. Contracts are something like comments that can be evaluated at runtime to make sure they are true.
It's not that it demonstrates a bug in the shell; rather, this is the perfect example of shooting one's self in the foot. A single extra character (and an invisible one at that) changed the meaning of the command such that it wiped out all of someone's files.
It doesn't matter how good your names are; they can only describe what a thing is or what it does. You need comments to describe why.
Thanks.
You just reinvented Usenet. :-)
You mean, you can't do it in C++. I agree. I was speaking more generally about the kinds of things programming languages should be able to express.
To begin with, I'm a JIT compiler developer. I know what inlining is. That's not what I was asking.
Second, your claims are wrong in almost every sentence. For instance, here is one particularly attrocious paragraph:
What's wrong with this?-
Functions are assigned function names. Variables are assigned variable names. They are two different things.
-
In C, it's called a "preprocessor", not a "precompiler", though I guess the latter makes just as much sense.
-
Your example is not a function. It is a variable declaration with an initialization. Therefore inlining doesn't apply.
-
The preprocessor has nothing to do with inlining. What you're describing is macro expansion.
-
pi is not 22/7!!
:-)
A few more remarks: Java is a language, and doesn't run anything. The Java Virtual Machine (JVM) runs bytecode, not directly runnable object code. The virtual machine may or may not use a JIT compiler to optimize for the individual machine. Any half-decent JIT compiler performs inlining, or else performance would be terrible; however, inlining is not what you think it is. Hot damn, I hope I never need to deal with any code you write. This attitude is appalling. I'm going to go out on a limb and guess that you are not a professional software developer?When you said "Java is not a language that inlines...that's the whole idea of the JIT" I thought you were correctly pointing out that Javac doesn't (and can't) do inlining. Apparently I was mistaken.
Anyway, thanks for taking the time to explain yourself.
Hey, don't sweat it. Your kind of usage is so common that others have suggested that the meaning of "ironic" may have changed. :-)
What does "with today's cut and paste GUI IDEs, there's no need for programmers to use the lazy C declarations of the past" mean?
In your case, you need a rule like "overloading + is disallowed except in the following specific cases: (...)". Then the superstar could see to it that the few exceptions won't surprise anyone. If the compiler enforced this rule, you wouldn't constantly need to worry about that harebrained strangeness any dummy on the team might come up with.
Your lottery analogy doesn't really apply. It's more like someone who knows how to get an edge on the house at a casino. Sure, he could go in there with his $100 and try to turn it into $1000, but suppose he gets clients with $1M, turns it into $10M, and then takes a 1% commission? Your way, he makes $900. My way, he makes $90k.
Here's a timely article from The Onion.
Nowadays, the kind of activity described in the article would probably be contrary to the DMCA, since it's bypassing a protection scheme.
What is the syntactic overhead? You mean you don't like typing "do...end" instead of curly braces? Or "feature {ANY}" instead of "public"?
So no, Eiffel compilers still aren't statically typesafe. From practice, I can testify that it doesn't matter. Personally I don't use covariance (which is the one type hole) because I just don't think that way, but even if I did, the reliability from DbC more tham makes up for any reliability lost via the lack of static type safety.
No, there are more differences than that at the kernel level.
64-bit ops can be more than twice as fast as 32-bit ops on 64-bit data. Consider multiplication, where you need to do four pairwise multiplies plus some adds. Or "neg", which is one instruction for 32-bit data, but three instructions for 64-bit data on a 32-bit machine. (neg low, adc high, neg high)
Oops, I was wrong. Looks like I changed my settings and then forgot.
Um, he didn't, and it did.
Yes, I should have said "businesses that sell proprietary software".
Though I suppose if it were an "add-on chip" that didn't ship with Mac boxes by default, that might prevent the OS/2 syndrome. People would be less likely to rely on the Windows software running on Macs if most Macs couldn't run it.
You're right. When I said "proprietary" I meant software that a company wants to prevent people from copying. Obviously I used the wrong word.
I think having to give away your software for free would appear pretty malicious to businesses. From their point of view, the virus analogy is a good one: don't touch GPL code if you want to keep your software proprietary.