That said, you can do something like the following: Use wget to grab the correct time zone from www.time.gov. Use sed or perl or whatever to pull out the time using a regexp. Reformat that and pass it to 'date'.
Make this a nightly cron job and you're all set. (Of course, you should be careful about the interaction between cron and changing the system time!)
The problem with null is that it's yet another unnecessary run-time check. Suppose having a value of class Integer meant that you really had an integer object (instead of including the possibility that it is null). Sometimes we want to return a value plus the possibility of an error condition, in which case null is useful, so we'd have some other type for "possibly null" objects.
You might have something built in to the language like this, like writing "Integer?" as the class name (the language Popcorn does this), you might also just have a powerful enough language that it can be coded up easily (SML has this with its polymorphic 'option' type).
With the old null, you might write this:
Integer x = something();
if (x != null) {... code involving x...
} else {... }
Note that if you pass x to another function, that function probably needs to check to see if x is null, too. Similarly, the bytecode interpreter needs to check for null whenever you do a method invocation on x. Without null, you might write (I am just making up the syntax; you might want to see how Nice does it):
The important thing here is that we've statically captured the fact that we've done a null check (y would have type 'Integer', not type 'Integer?'). Now, the byte code interpreter never needs to check y to see if it's null (efficiency gain), the programmer is never allowed to use a value unless he's checked that it's null (program robustness), the potential for a function to return null is reflected in its type (modularity), and the programmer has to insert fewer checks, because once it's an Integer, it is not necessary (and doesn't make sense!) to check for nullness (saves typing).
In my own Java programming, and experience with using other folks' Java programs, the Null Pointer Exception is much more common than the Class Cast Exception. However, in my experience with Object Oriented Programmers, the love of "null" runs deep, so it might be a harder sell than generics!
It doesn't just reduce the keystrokes needed to do the type casts, it reduces their possible mis-use and therefore means that if your program compiles, it is more likely to be correct. This is good. It also means that good generic programming techniques will be used more often because they are more convenient.
Missing from the language...
on
Java Gets Templates
·
· Score: 3, Insightful
> So, what else is still missing from the language? It seems almost ready to go mainstream.
Well, I don't know about most Java programmers, but the missing features that constantly bug me are:
- Higher-order functions (Seriously, you can't live in a language that doesn't have this once you get used to programming with them!)
- Algebraic Types and Pattern Matching (Vital for manipulating syntax trees, like in a compiler)
- Tuples
- Getting rid of 'null' (This is possible, in fact, easy, and would make the language much cleaner, less error prone, and even more efficient)
- Uniform typing discipline (ie, int vs. Integer... I think this is relieved a little bit by generics)
- Parameterized Modules (a la SML's functors)
There are also some bugs in the language itself, though those wouldn't really bother me day-to-day.
- Arrays are covariant, leading to class tag checks on every array write (in the general case)
- The description of binary compatibility is broken (It can lead to situations where recompliation of the class files either leads to a different program, or to a failure to compile!)
-...
A language that makes some of these strides is called Nice, though I've never used it.
There are loads of obsolete, insecure protocols that we still insist on using. Identd is the least of our worries. Let's take some examples:
SMTP! Mailbox filled with spam? Well, that's because we use a mail transfer protocol that makes it trivial to forge the from: address and to create thousands of messages from one!
FTP! Password in the cleartext? Carriage returns dropped? 3rd-party interceptible/forgeable downloads? That's FTP...
Identd is simple enough to fake, so it shouldn't really trouble anyone. But it's pretty hard to get by day-to-day without using SMTP.
If you want to do MIDI, then Reason is pretty good, though you should be able to get away with any program that has VST Instrument support (like Logic, Cubase, Nuendo). As far as I remember Reason doesn't have VST support. It's good to get a program that uses an open plugin standard, because then you aren't locked into one vendor to expand your sounds. There are lots of free VST instruments around, and plenty to buy.
If you get an SB Live! then you'll probably want to get the (free, but not open source) low-latency ASIO drivers from KX Project. I get 5ms latency from a $30 sound card, which is amazing.
Also, check out my collection of quality GPL VST plugins: destroyfx.org. (These are mostly plugins for modifying sound in-line, not generating it from midi keypresses.)
> Some features of Eiffel are debatable, one of which is covariance for parameters: This means that if you override a method in
It's good that you mention it, but I wouldn't say this "feature" is debatable, it's just wrong. The only way they can recover static safety with this bug is to do whole-program analysis! If they really want to take a structured and pure OO approach to programming, I think it's important to have a consistent theory, not to just provide features that "seem" to be intuitively useful. (But have some serious consequences...)
FWIW, Java makes a similar mistake in treating [] as a covariant type constructor. This means that in general they have to do dynamic class checks on every array access! Eiffel is mostly a better-designed language than Java, in my opinion.
No, the law doesn't work this way. The device has to be primarily designed for circumvention, or marketed for circumvention purposes. In the case of chmod, of course this isn't true. Also, "circumvention" only takes place when it is without the authority of the copyright holder, so even if chmod was only for making copyrighted files readable, it still wouldn't be a circumvention device since many people use it to make their own files readable (of course they do that with their own authority!).
I urge anyone who thinks like this to actually read the DMCA (the relevant section is 17 USC 1201) -- it's a bit more complicated than the average slashdotter seems to believe!
Well, considering that I am still engaging in the act that ITC/Monotype don't like (that is, sitting around letting CMU's web server give out copies of embed), a statute of limitations wouldn't help much. Also, they never actually did anything except to send me a few emails; it's not like there's a case pending...
Sure, but I think I am in a special situation. First, I've had similar legal threats before, so I know not to be scared off over a few emails. Second, my content is hosted by a (relatively) enlightened provider (my university). Third, I'm a grad student with no money and no particular responsibilities to family, job, etc.
If any of these things wasn't true, I think I'd have much more trouble keeping the program up. If my ISP took it down, as the safe harbor provisions of the DMCA make so tempting, what would I do? If I had money to lose or couldn't afford the court time because of job commitments or family, how could I risk going to court over something so silly? If I didn't realize that such mails are often just a bunch of hot air, how would I have reacted? I think that many more projects get taken down voluntarily precisely because hobbyists can't afford to provide defense, even if they are in the right.
The argument is essentially that programs are a form of expression (including machine code), and thus are protected speech. This has been upheld by courts, for instance (I believe) in the Bernstein crypto software case. (Personally, while source code as speech makes perfect sense to me, I'm a little bit reluctant to call compiler-generated machine code 'speech', though there is some remnants of speech in there.) In the 2600 case the judge rejected this argument because, though he held source is protected speech, the source code in this case was also simultaneously a "device" (ie, a circumvention device) under the DMCA. This is similar to considering a libelous poem to be simultaneously a creative work (ie, copyrightable) but also illegal because of its libelous content.
> The only real effect of the DMCA is that companies can't openly distribute stuff that violates the DMCA.
I don't think that's really true. The DMCA is used to intimidate and annoy regular well-intentioned folks like myself on a weekly basis. Check out my dmca troubles over a font program I wrote, for instance.
No, because the DMCA is about copy controls ("technological measures") that restrict access to copyrighted content. If this compression/security method does not primarily protect content that you own the copyright to, then the RIAA breaking it surely won't be circumvention of a copy control mechanism.
Also, as far as I know, just because information is obtained illegaly (by private citizens or corporations), that doesn't mean that it can't be used to sue you.
Yes, I often noticed that closing long-running network apps would blue-screen 2000 when I was running ZA. ZL's web site says that this is a known issue that they can't correct, so it may very well be a bug in Windows (or a misdesign...).
You are totally wrong. You do not need to write Copyright on something in order for it to be Copyrighted; such protection is automatic in the US. However, I think reproduction of these ads would clearly fall under fair use.
Well, the Spirits Within script wasn't any worse than, say, their video games... but they are not used to storytelling in "only" an hour and a half and without someone at the joystick!
It doesn't really matter whether the errors happen in chunks or in the individual bits. It's easy to simply store redundant chunks (like RAID does) so that the data can be recovered even if a block fails. Using a code based on solutions to linear equations, for instance, you can have it so that you only need (say) 6 out of every 9 blocks in order to recover the data perfectly. These numbers can be adjusted arbitrarily, and as I said you only need about the same amount of redundancy as you expect your tape to have failures.
Of course, if the errors really are on the tape from the start, then detecting bad areas of the tape and writing around them is even better!
I'm with you on this, but I don't see why you think error correction would take up a lot of the disk space. You usually don't need very much overhead (ie, more than the expected error rate on the tape) to get a good probability of being able to correct the data.
Well, you should read the DMCA (search for 17 USC 1201). That law essentially exists to outlaw mod chips, cable descramblers, etc. It's written with hardware in mind; that's why they're always talking about "circumvention devices" and not circumvention programs!
Now, I don't like the DMCA (especially after my own run-in) but what you say in your post is simply wrong; they have a fairly strong case against Lik-Sang. Here are the reasons I can think of that the case isn't completely clear-cut:
- The DMCA might be unconstitutional
- Lik Sang is in another country (China?) and is probably not really under the jurisdiction of the DMCA
- Mod chips have other non-circumvention uses: playing import games, hobbyist development
> I'm not sure about the C++ GC stuff. AFAICS, there's nothing to stop you writing your own full-blown GC, as long as your > platform supports suitable multithreading and sync'ing protocols to let you co-ordinate between a GC'd pointer and a GC > thread. You give up the portability and deterministic destruction, but such will always be the price of a GC system in a > language with low-level features anyway.
It's possible that you'd be able to create a GC library for C++. But, it would require you to use ONLY the special gc'd malloc and special smart pointers. That would mean that you wouldn't be able to link in library code and have that be garbage collected, and you'd have to be careful about what constructs you used if you wanted your program to work. (And it would most likely still be less efficient than one with langage and runtime support built-in.) Anyway, all I'm saying is that I think the cost of unsafe language features like C++ has can sometimes be more than what it seems on the surface, because they preclude you or the compiler writer from implementing something like Garbage Collection in a general way.
Also, there's no reason why GC needs multithreading -- most garbage collectors that I know of run at allocation time when space runs out. (If you need real-time guarantees or something then usually that means another GC thread.)
I'm with you on that except that I don't think it's easy to ignore manual memory management in C++. Sometimes it is nice to be able to do your own finalization, but most of the time I simply hate keeping track of the memory I've allocated. Snap-in garbage collectors are inefficient because they have to be conservative to preserve the C++ semantics. Reference counting can take care of this in some situations, but it's not as general as garbage collection and it has a higher overhead (I believe).
Except for manual memory management, O'Caml supports a lot of the useful low-level C stuff while having most of the nice features of a modern functional language... It's also very fast. Any reason not to use that, then?
Slashdot Mirror
I agree with the folks who say your ISP sucks.
That said, you can do something like the following:
Use wget to grab the correct time zone from www.time.gov.
Use sed or perl or whatever to pull out the time using a regexp.
Reformat that and pass it to 'date'.
Make this a nightly cron job and you're all set. (Of course, you should be careful about the interaction between cron and changing the system time!)
The problem with null is that it's yet another unnecessary run-time check. Suppose having a value of class Integer meant that you really had an integer object (instead of including the possibility that it is null). Sometimes we want to return a value plus the possibility of an error condition, in which case null is useful, so we'd have some other type for "possibly null" objects.
... code involving x ...
...
... break; ... same code involving y ...
You might have something built in to the language like this, like writing "Integer?" as the class name (the language Popcorn does this), you might also just have a powerful enough language that it can be coded up easily (SML has this with its polymorphic 'option' type).
With the old null, you might write this:
Integer x = something();
if (x != null) {
} else {
}
Note that if you pass x to another function, that function probably needs to check to see if x is null, too. Similarly, the bytecode interpreter needs to check for null whenever you do a method invocation on x. Without null, you might write (I am just making up the syntax; you might want to see how Nice does it):
Integer? x = something();
switch (x) {
null:
Integer(y):
}
The important thing here is that we've statically captured the fact that we've done a null check (y would have type 'Integer', not type 'Integer?'). Now, the byte code interpreter never needs to check y to see if it's null (efficiency gain), the programmer is never allowed to use a value unless he's checked that it's null (program robustness), the potential for a function to return null is reflected in its type (modularity), and the programmer has to insert fewer checks, because once it's an Integer, it is not necessary (and doesn't make sense!) to check for nullness (saves typing).
In my own Java programming, and experience with using other folks' Java programs, the Null Pointer Exception is much more common than the Class Cast Exception. However, in my experience with Object Oriented Programmers, the love of "null" runs deep, so it might be a harder sell than generics!
It doesn't just reduce the keystrokes needed to do the type casts, it reduces their possible mis-use and therefore means that if your program compiles, it is more likely to be correct. This is good. It also means that good generic programming techniques will be used more often because they are more convenient.
> So, what else is still missing from the language? It seems almost ready to go mainstream.
... I think this is relieved a little bit by generics)
...
Well, I don't know about most Java programmers, but the missing features that constantly bug me are:
- Higher-order functions (Seriously, you can't live in a language that doesn't have this once you get used to programming with them!)
- Algebraic Types and Pattern Matching (Vital for manipulating syntax trees, like in a compiler)
- Tuples
- Getting rid of 'null' (This is possible, in fact, easy, and would make the language much cleaner, less error prone, and even more efficient)
- Uniform typing discipline (ie, int vs. Integer
- Parameterized Modules (a la SML's functors)
There are also some bugs in the language itself, though those wouldn't really bother me day-to-day.
- Arrays are covariant, leading to class tag checks on every array write (in the general case)
- The description of binary compatibility is broken (It can lead to situations where recompliation of the class files either leads to a different program, or to a failure to compile!)
-
A language that makes some of these strides is called Nice , though I've never used it.
There are loads of obsolete, insecure protocols that we still insist on using. Identd is the least of our worries. Let's take some examples:
SMTP! Mailbox filled with spam? Well, that's because we use a mail transfer protocol that makes it trivial to forge the from: address and to create thousands of messages from one!
FTP! Password in the cleartext? Carriage returns dropped? 3rd-party interceptible/forgeable downloads? That's FTP...
Identd is simple enough to fake, so it shouldn't really trouble anyone. But it's pretty hard to get by day-to-day without using SMTP.
If you want to do MIDI, then Reason is pretty good, though you should be able to get away with any program that has VST Instrument support (like Logic, Cubase, Nuendo). As far as I remember Reason doesn't have VST support. It's good to get a program that uses an open plugin standard, because then you aren't locked into one vendor to expand your sounds. There are lots of free VST instruments around, and plenty to buy.
If you get an SB Live! then you'll probably want to get the (free, but not open source) low-latency ASIO drivers from KX Project . I get 5ms latency from a $30 sound card, which is amazing.
Also, check out my collection of quality GPL VST plugins: destroyfx.org . (These are mostly plugins for modifying sound in-line, not generating it from midi keypresses.)
> Some features of Eiffel are debatable, one of which is covariance for parameters: This means that if you override a method in
It's good that you mention it, but I wouldn't say this "feature" is debatable, it's just wrong. The only way they can recover static safety with this bug is to do whole-program analysis! If they really want to take a structured and pure OO approach to programming, I think it's important to have a consistent theory, not to just provide features that "seem" to be intuitively useful. (But have some serious consequences...)
FWIW, Java makes a similar mistake in treating [] as a covariant type constructor. This means that in general they have to do dynamic class checks on every array access! Eiffel is mostly a better-designed language than Java, in my opinion.
No, the law doesn't work this way. The device has to be primarily designed for circumvention, or marketed for circumvention purposes. In the case of chmod, of course this isn't true. Also, "circumvention" only takes place when it is without the authority of the copyright holder, so even if chmod was only for making copyrighted files readable, it still wouldn't be a circumvention device since many people use it to make their own files readable (of course they do that with their own authority!).
I urge anyone who thinks like this to actually read the DMCA (the relevant section is 17 USC 1201) -- it's a bit more complicated than the average slashdotter seems to believe!
Well, considering that I am still engaging in the act that ITC/Monotype don't like (that is, sitting around letting CMU's web server give out copies of embed), a statute of limitations wouldn't help much. Also, they never actually did anything except to send me a few emails; it's not like there's a case pending...
Sure, but I think I am in a special situation. First, I've had similar legal threats before, so I know not to be scared off over a few emails. Second, my content is hosted by a (relatively) enlightened provider (my university). Third, I'm a grad student with no money and no particular responsibilities to family, job, etc.
If any of these things wasn't true, I think I'd have much more trouble keeping the program up. If my ISP took it down, as the safe harbor provisions of the DMCA make so tempting, what would I do? If I had money to lose or couldn't afford the court time because of job commitments or family, how could I risk going to court over something so silly? If I didn't realize that such mails are often just a bunch of hot air, how would I have reacted? I think that many more projects get taken down voluntarily precisely because hobbyists can't afford to provide defense, even if they are in the right.
The argument is essentially that programs are a form of expression (including machine code), and thus are protected speech. This has been upheld by courts, for instance (I believe) in the Bernstein crypto software case. (Personally, while source code as speech makes perfect sense to me, I'm a little bit reluctant to call compiler-generated machine code 'speech', though there is some remnants of speech in there.) In the 2600 case the judge rejected this argument because, though he held source is protected speech, the source code in this case was also simultaneously a "device" (ie, a circumvention device) under the DMCA. This is similar to considering a libelous poem to be simultaneously a creative work (ie, copyrightable) but also illegal because of its libelous content.
> The only real effect of the DMCA is that companies can't openly distribute stuff that violates the DMCA.
I don't think that's really true. The DMCA is used to intimidate and annoy regular well-intentioned folks like myself on a weekly basis. Check out my dmca troubles over a font program I wrote, for instance.
No, because the DMCA is about copy controls ("technological measures") that restrict access to copyrighted content. If this compression/security method does not primarily protect content that you own the copyright to, then the RIAA breaking it surely won't be circumvention of a copy control mechanism.
Also, as far as I know, just because information is obtained illegaly (by private citizens or corporations), that doesn't mean that it can't be used to sue you.
Yes, I often noticed that closing long-running network apps would blue-screen 2000 when I was running ZA. ZL's web site says that this is a known issue that they can't correct, so it may very well be a bug in Windows (or a misdesign...).
You are totally wrong. You do not need to write Copyright on something in order for it to be Copyrighted; such protection is automatic in the US. However, I think reproduction of these ads would clearly fall under fair use.
They've been making Dragon Warrior games since forever, and still do. Just search some web store for it...
Well, the Spirits Within script wasn't any worse than, say, their video games... but they are not used to storytelling in "only" an hour and a half and without someone at the joystick!
Kissing is legal
It doesn't really matter whether the errors happen in chunks or in the individual bits. It's easy to simply store redundant chunks (like RAID does) so that the data can be recovered even if a block fails. Using a code based on solutions to linear equations, for instance, you can have it so that you only need (say) 6 out of every 9 blocks in order to recover the data perfectly. These numbers can be adjusted arbitrarily, and as I said you only need about the same amount of redundancy as you expect your tape to have failures.
Of course, if the errors really are on the tape from the start, then detecting bad areas of the tape and writing around them is even better!
Yeah, just put a Faraday cage around it. Get rid of the antenna, too; that gives off all sorts of fucken signals.
I think you want to add abstraction, not remove it. If you remove abstraction, then the computer is a bunch of spinning metal and electrons.
I'm with you on this, but I don't see why you think error correction would take up a lot of the disk space. You usually don't need very much overhead (ie, more than the expected error rate on the tape) to get a good probability of being able to correct the data.
Well, you should read the DMCA (search for 17 USC 1201). That law essentially exists to outlaw mod chips, cable descramblers, etc. It's written with hardware in mind; that's why they're always talking about "circumvention devices" and not circumvention programs!
Now, I don't like the DMCA (especially after my own run-in ) but what you say in your post is simply wrong; they have a fairly strong case against Lik-Sang. Here are the reasons I can think of that the case isn't completely clear-cut:
- The DMCA might be unconstitutional
- Lik Sang is in another country (China?) and is probably not really under the jurisdiction of the DMCA
- Mod chips have other non-circumvention uses: playing import games, hobbyist development
> I'm not sure about the C++ GC stuff. AFAICS, there's nothing to stop you writing your own full-blown GC, as long as your
> platform supports suitable multithreading and sync'ing protocols to let you co-ordinate between a GC'd pointer and a GC
> thread. You give up the portability and deterministic destruction, but such will always be the price of a GC system in a
> language with low-level features anyway.
It's possible that you'd be able to create a GC library for C++. But, it would require you to use ONLY the special gc'd malloc and special smart pointers. That would mean that you wouldn't be able to link in library code and have that be garbage collected, and you'd have to be careful about what constructs you used if you wanted your program to work. (And it would most likely still be less efficient than one with langage and runtime support built-in.) Anyway, all I'm saying is that I think the cost of unsafe language features like C++ has can sometimes be more than what it seems on the surface, because they preclude you or the compiler writer from implementing something like Garbage Collection in a general way.
Also, there's no reason why GC needs multithreading -- most garbage collectors that I know of run at allocation time when space runs out. (If you need real-time guarantees or something then usually that means another GC thread.)
I'm with you on that except that I don't think it's easy to ignore manual memory management in C++. Sometimes it is nice to be able to do your own finalization, but most of the time I simply hate keeping track of the memory I've allocated. Snap-in garbage collectors are inefficient because they have to be conservative to preserve the C++ semantics. Reference counting can take care of this in some situations, but it's not as general as garbage collection and it has a higher overhead (I believe).
Except for manual memory management, O'Caml supports a lot of the useful low-level C stuff while having most of the nice features of a modern functional language... It's also very fast. Any reason not to use that, then?