IMHO a "scripting language" is more about style of use than implementation strategy. They tend to play fast and loose with data types, declarations, and error handling. Perl is probably the canonical example, filled with quirks like "xyzzy" not being false even though it's equal to zero and zero is false. You can very quickly produce a script that usually works if its input is well-formed, but you have to be extemely paranoid to make it robust--which is about as much work as using a rigorous language would have been.
Unfortunately, every JVM will suffer a speed hit to implement 32-bit arithmetic on a 64-bit machine, all because a class of programmers out there have proven unable to cope with specifications like "at least 32 bits".
A microengine can take full advantage of all hardware resources that are actually present (register renaming, out-of-order and speculative execution, known pipeline depth) while a compiler can only use resources that are mandated by the instruction set. As for the drawbacks of having the instruction scheduler on the critical path (which imposes the window limit), Transmeta may be on to something....
Chunked supports keepalive for dynamic-length resources (which otherwise require TCP FIN to signal EOF). Resume is supported by Range headers (and ETag--unlike FTP, HTTP does the Right Thing if you try to resume a GET after the resource has been modified).
When NTSC color was added, the frequency was changed from 60 to 60*1000/1001 (about 59.94) fields/s. Something about bad interactions between colorburst and harmonics of exactly 60 Hz, but I can't find a good explanation right now.
Re:CRAP! (If it's not Scottish, it's...)
on
Cross-Site-TRACE
·
· Score: 1
Browsers routinely keep secrets from local scripts, like authentication responses or cookies for other realms. I wonder if Sun thought about this when they designed the sandbox (an applet needs to be granted the privilege of sending requests to any server other than the one it's hosted on).
The problem isn't that GPL'd code could possibly be modified so as to require a patent license (that would only be the modifier's problem, and they wouldn't have the right to redistribute). The problem is if a standard requires use of a patented algorithm that's licensed "for Web use only", all GPL'd code must be excluded from any implementation of that standard. That's a big step back from what most people expected of a standard that set out to be royalty-free.
Not quite contradictory. If you write code that depends on a patent license that's only sometimes available, and then you license your code under the GPL, you've granted me the right to redistribute it iff there are no encumberances. Straight out of the tarball, your source is encumbered (and can't be redistributed), but if I remove the patented code I can redistribute whatever remains.
It's a little bizzare that even if there's a large community who could use the software without restriction (if the patent didn't apply in some countries, for instance) I can't redistribute even just to them if use anywhere by anyone is restricted. I suppose there are a few loopholes that closes, though.
A free market is supposed to allocate resources to producers in proportion to their current efficiency in using them to meet demand. When a monopoly appears, even the more efficient producers (if any) are unable to compete. This is a sign that the market has failed and that resources are being diverted out of the productive economy (wasted, hoarded, or predating in other markets).
Any market is a means, not an end. We shouldn't blindly continue relying on them in circumstances where they demonstrably don't work.
Mandatory education has been used as de facto prohibition. The approved classes just didn't seem to have enough room for anyone more than politicians' bodyguards....
Competently written native code can be very portable. I can write native wrapper methods around useful libraries like zlib, openssl, libvorbis, or the Apache module API (I think most of these already exist, in fact) and my JNI code will compile and run with any available JVM on any platform those libraries themselves have been ported to.
RNI code will probably never run with anything other than Microsoft's old VM on Win32 (which is already at the end of its life AFAIK), mostly because it constrains optimization opportunities much more severely (the lack of write barrier support was one problem that leaps to mind).
I think Microsoft's VM also omitted RMI in favor of DCOM or something, though eventually they at least made that available as a separate download.
Circumvention devices will undoubtably be strictly banned but available to organized crime, so for legitimate purposes the whole design is just a weaker alternative to a gun safe.
With this proposed design, private citizens won't be able to buy, sell, or lend guns to each other except with the state's approval, and the state's confiscation list will always be up to date. If safety were the issue, programming the grip would be under the control of the owner.
OTOH for the price of one SCSI drive you can buy a larger IDE drive, a hot spare, and two or three standby spares, and by the time you have to spin up the last one the price of replacing it will be inconsequential (assuming you can still find a drive that small). With RAID, MTBF is only crucial if you deploy a box somewhere an admin can't lay hands on it. SCSI's typical spin rates are nice if price is no object.
Can't the OS do almost as well with reordering (assuming the physical geometry is broadly similar to the sector numbering)? Didn't Alan Cox or some other hacker put a good elevator algorithm into Linux only to discover it didn't make much difference?
STL's templates work because they're completely generic. What you can't do is write a template whose type parameter must be a class derived from vehicle (so you won't call similarly-named methods from unrelated classes by mistake).
That declares a template whose parameter is a value of type shape, not the name of a type derived from shape. And it's only allowed if shape is an integral, enum, pointer, or reference type. Class instances can't be template parameters because the linker can't be expected to call operator == to determine which instantiations are equivalent and should be merged.
That's just instantiating a totally generic template--it'll work with any type that has default and copy ctors and assignment.
Suppose you wanted a homogenous collection that's aware of the semantics of class shape. bounding_box<rectangle> and bounding_box<ellipse> should be allowed but bounding_box<company> should not, even if they all happen to have location() and size() methods. In C++ you can't specify that instantiating the template for a class that isn't derived from shape is an error, without some ugly circumlocutions.
Presumably that generic can only be used with shape or derived classes. That way when you call foo you know you're getting an override of shape's foo rather than some unrelated method with the same signature.
It's also an optimization hook. If the compiler can prove an assertion is fulfilled (because another assertion didn't fail, the caller's passing a value that's obviously correct, or nothing used in the invariant was modified) it can skip the machine code to check it.
Slashdot Mirror
IMHO a "scripting language" is more about style of use than implementation strategy. They tend to play fast and loose with data types, declarations, and error handling. Perl is probably the canonical example, filled with quirks like "xyzzy" not being false even though it's equal to zero and zero is false. You can very quickly produce a script that usually works if its input is well-formed, but you have to be extemely paranoid to make it robust--which is about as much work as using a rigorous language would have been.
You're right, with the caveat that char, short, and long will always be at least 8, 16 and 32 bits, respectively. Other bogus assumptions:
Unfortunately, every JVM will suffer a speed hit to implement 32-bit arithmetic on a 64-bit machine, all because a class of programmers out there have proven unable to cope with specifications like "at least 32 bits".
A microengine can take full advantage of all hardware resources that are actually present (register renaming, out-of-order and speculative execution, known pipeline depth) while a compiler can only use resources that are mandated by the instruction set. As for the drawbacks of having the instruction scheduler on the critical path (which imposes the window limit), Transmeta may be on to something....
Chunked supports keepalive for dynamic-length resources (which otherwise require TCP FIN to signal EOF). Resume is supported by Range headers (and ETag--unlike FTP, HTTP does the Right Thing if you try to resume a GET after the resource has been modified).
I thought a portable distributed app framework was mozilla.org's goal. At least that seems to be why they ceded the browser war.
When NTSC color was added, the frequency was changed from 60 to 60*1000/1001 (about 59.94) fields/s. Something about bad interactions between colorburst and harmonics of exactly 60 Hz, but I can't find a good explanation right now.
Browsers routinely keep secrets from local scripts, like authentication responses or cookies for other realms. I wonder if Sun thought about this when they designed the sandbox (an applet needs to be granted the privilege of sending requests to any server other than the one it's hosted on).
The problem isn't that GPL'd code could possibly be modified so as to require a patent license (that would only be the modifier's problem, and they wouldn't have the right to redistribute). The problem is if a standard requires use of a patented algorithm that's licensed "for Web use only", all GPL'd code must be excluded from any implementation of that standard. That's a big step back from what most people expected of a standard that set out to be royalty-free.
It's a little bizzare that even if there's a large community who could use the software without restriction (if the patent didn't apply in some countries, for instance) I can't redistribute even just to them if use anywhere by anyone is restricted. I suppose there are a few loopholes that closes, though.
I have heard a few CLR instructions allow certain optimizations a JVM can't do, though I don't remember what at the moment.
A free market is supposed to allocate resources to producers in proportion to their current efficiency in using them to meet demand. When a monopoly appears, even the more efficient producers (if any) are unable to compete. This is a sign that the market has failed and that resources are being diverted out of the productive economy (wasted, hoarded, or predating in other markets).
Any market is a means, not an end. We shouldn't blindly continue relying on them in circumstances where they demonstrably don't work.
Mandatory education has been used as de facto prohibition. The approved classes just didn't seem to have enough room for anyone more than politicians' bodyguards....
RNI code will probably never run with anything other than Microsoft's old VM on Win32 (which is already at the end of its life AFAIK), mostly because it constrains optimization opportunities much more severely (the lack of write barrier support was one problem that leaps to mind).
I think Microsoft's VM also omitted RMI in favor of DCOM or something, though eventually they at least made that available as a separate download.
Circumvention devices will undoubtably be strictly banned but available to organized crime, so for legitimate purposes the whole design is just a weaker alternative to a gun safe.
With this proposed design, private citizens won't be able to buy, sell, or lend guns to each other except with the state's approval, and the state's confiscation list will always be up to date. If safety were the issue, programming the grip would be under the control of the owner.
How is IBM's JVM better on Win32? VisualAge for Java isn't even up to JDK 1.3 yet, and their Developer Kit for Windows seems to still be in beta.
OTOH for the price of one SCSI drive you can buy a larger IDE drive, a hot spare, and two or three standby spares, and by the time you have to spin up the last one the price of replacing it will be inconsequential (assuming you can still find a drive that small). With RAID, MTBF is only crucial if you deploy a box somewhere an admin can't lay hands on it. SCSI's typical spin rates are nice if price is no object.
Can't the OS do almost as well with reordering (assuming the physical geometry is broadly similar to the sector numbering)? Didn't Alan Cox or some other hacker put a good elevator algorithm into Linux only to discover it didn't make much difference?
STL's templates work because they're completely generic. What you can't do is write a template whose type parameter must be a class derived from vehicle (so you won't call similarly-named methods from unrelated classes by mistake).
That doesn't do anything to prevent you from instantiating bounding_box<company>.
That declares a template whose parameter is a value of type shape, not the name of a type derived from shape. And it's only allowed if shape is an integral, enum, pointer, or reference type. Class instances can't be template parameters because the linker can't be expected to call operator == to determine which instantiations are equivalent and should be merged.
Suppose you wanted a homogenous collection that's aware of the semantics of class shape. bounding_box<rectangle> and bounding_box<ellipse> should be allowed but bounding_box<company> should not, even if they all happen to have location() and size() methods. In C++ you can't specify that instantiating the template for a class that isn't derived from shape is an error, without some ugly circumlocutions.
Presumably that generic can only be used with shape or derived classes. That way when you call foo you know you're getting an override of shape's foo rather than some unrelated method with the same signature.
It looks like the SmartEiffel compiler proper is already GPL'd. Is redistributing the other files under GPL not allowed?
It's also an optimization hook. If the compiler can prove an assertion is fulfilled (because another assertion didn't fail, the caller's passing a value that's obviously correct, or nothing used in the invariant was modified) it can skip the machine code to check it.