"I have this pencil which can also be used to commit a crime. The goverment ought to outlaw that, by the same logic they use in DeCSS. Now we don't have pencils! The goverment sure is stupid!"
Okay kids, now I'm not a fan of the way IP is handled in the US either. But seriously...DeCSS is not a pencil. It is a tool designed to remove copyright protection from someone's IP.
Are guns a right? Yes. But we don't allow people to own nukes, or certain kinds of guns, either. Why? Because they're explicity designed to do Bad Things, as opposed to possibly being used for Bad Things.
The argument that DeCSS is explicity designed to get around a (questionable) law is CORRECT.
You're not listening. I never said MS didn't add functionality that was lightweight. I said that if you take old code you'll find it runs significantly slower on the CLR than it used to, because there are fundamental problems in VB5 that MS had to change in VB6 for speed.
And no, VB6 is not faster than 5 at UI. Believe me.
The way they deal with file handlers is a mess too. I'll leave it at that.
Yes, any language can run just fine on the CLR. However, not all.net-tweaked languages are created equal: C# is the only language that does not carry a performance penalty for writing managed code...the others are either ports or are inherently limited.
For example:
Visual Basic makes use of exceptions as part of control-flow manipulations. Those are very expensive in the.net world (as they should be), so MS changed a lot in the language to allow people to write performant apps. However, old VB code is still dog-slow.
Managed C++ isn't bad for performance, though the syntax is ever worse than regular C++. If you want anything approaching native speed though, you will want to stay away from the garbage collector (virtual method invocations are very expensive in GC'd objects, since they require a jump out of the managed world into the vtable and then back in again).
The problem with functional languages on.net is pretty obvious: you lose tail-call optimizations, since the security model depends on the stack. This is one of the biggest drawbacks to writing fast functional code on.net, and it seems that there's no way around it without ripping up the security infrastructure and putting in a new one.
Slashdot Mirror
"I have this pencil which can also be used to commit a crime. The goverment ought to outlaw that, by the same logic they use in DeCSS. Now we don't have pencils! The goverment sure is stupid!"
Okay kids, now I'm not a fan of the way IP is handled in the US either. But seriously...DeCSS is not a pencil. It is a tool designed to remove copyright protection from someone's IP.
Are guns a right? Yes. But we don't allow people to own nukes, or certain kinds of guns, either. Why? Because they're explicity designed to do Bad Things, as opposed to possibly being used for Bad Things.
The argument that DeCSS is explicity designed to get around a (questionable) law is CORRECT.
You're not listening. I never said MS didn't add functionality that was lightweight. I said that if you take old code you'll find it runs significantly slower on the CLR than it used to, because there are fundamental problems in VB5 that MS had to change in VB6 for speed.
And no, VB6 is not faster than 5 at UI. Believe me.
The way they deal with file handlers is a mess too. I'll leave it at that.
Yes, any language can run just fine on the CLR. However, not all .net-tweaked languages are created equal: C# is the only language that does not carry a performance penalty for writing managed code...the others are either ports or are inherently limited.
.net world (as they should be), so MS changed a lot in the language to allow people to write performant apps. However, old VB code is still dog-slow.
.net is pretty obvious: you lose tail-call optimizations, since the security model depends on the stack. This is one of the biggest drawbacks to writing fast functional code on .net, and it seems that there's no way around it without ripping up the security infrastructure and putting in a new one.
For example:
Visual Basic makes use of exceptions as part of control-flow manipulations. Those are very expensive in the
Managed C++ isn't bad for performance, though the syntax is ever worse than regular C++. If you want anything approaching native speed though, you will want to stay away from the garbage collector (virtual method invocations are very expensive in GC'd objects, since they require a jump out of the managed world into the vtable and then back in again).
The problem with functional languages on
E