but I usually do a real parser for even trivial lexical data since trivial hacks have a way of becoming notrivial with time. But, hey, to each his own.:)
whether on not physicians are more "dangerous" than gun owners has absolutely no bearing whatsoever on whether increased gun control would decrease the number of gun-related deaths. None.
That is why your statistics are meaningless. Come back when you can argue that your statistics actually mean anything. Hint: Repeating them doesn't work.
Oh, and by the way: I didn't state whether I am for or against gun control, so please stop assuming that you know what my opinion is, mkay?
Whether it's a trick or not is irrelevant. A GIF user could employ a trick to achieve the same goal (ease of global modification) with ease, so touting easy updates as an advantage is not "fair" when comparing the transparent pixel approach with the class="indent" approach. That was my point.
I'm referring to that last bit about increasing indents. The transparent-GIF-using webmaster could just as easily have a 20x1 transparent GIF called "indent.gif" used only for indentation. Then they could change indentation just as easily as you could. So there.:)
Just to be clear: I'm not arguing that using transparent GIFs is better than CSS, I'm just saying your last argument is based on the unfair assumption that the GIF-user couldn't use a similar trick to class="indent".
50 bytes and 100 bytes is utterly irrelevant; 99% of the wait the user experiences is caused by network latency (which remains the same). Still, since the patent expired there probably aren't any good reasons not to use GIF for this -- except maybe the Feel-good Factor(TM).
So you argue that the regular expressions in Emacs searching should be replaced with a spec of an LR parser?:-)
I realize you're semi-joking, but that's not at all what I was saying. I was talking about regexes as a programmer interface, not a user interface. As a programmer interface GLR parsing is by far superior to regexes, even though optimization may sometimes require that you to actually use state machines and/or regexes for implementation. In those cases you should still document the state machine and/or regex by using a context-free grammar.
As a user interface regexes are sometimes very convenient, especially because searches etc. usually are NOT repeated very often or meant for others to read/understand (and so don't suffer too much from the syntax). But even when you try to do relatively simple (conceptually) searches regexes sometimes explode into ridiculously complicated one-liners (granted, the escaping is a large part of this, but the point still stands). A great example of this is shell wildcards vs. regexes. Why do think shell wildcards are still used in shells? Because the syntax is more convenient, that's why.
Regex is logically equivalent (i.e. there is a polynomial time mapping between the regular expression language and the BNF) to a LR grammar,
No, it is not. Regex cannot handle arbitrarily balanced/nested constructs while LR grammars can. Just try to implement a regex to match every '(' in the input with a corresponding ')'. See what I mean?
Therefore, doctors are approximately 9,000 times more dangerous than gun
owners.
Even if the statistics are true, what's the point? Some people are more dangerous to the general public than others? Fuckin' duh -- they're fucking doctors, they make lots of life and death decisions on a daily basis -- that means that it is meaningless to compare the statistics on a per-doctor/per-owner basis. If we were to compare, then we would have to compare to the number of accidental deaths per incident (ie. treatment/unholstering). As they stand, the statistics are utterly meaningless.
Anyway, whether on not physicians are more "dangerous" than gun owners has absolutely no bearing whatsoever on whether increased gun control would decrease the number of gun-related deaths. None.
Just brilliant. Now, I'm not claiming that the parent to your post is anywhere near right with his "statistics", but I seem to recall some numbers indicating that a person is more likely to be wounded/killed by one of their own family members rather than an unknown assailant -- in that setting you're probably very unlikely to be carrying a gun (who carries a gun at home?) or even being able to defend yourself (since you'd presumably be taken by surprise). But I digress...
However, law enforcement is usually NOT part of the statistics for civilian gun-related deaths/injuries because they are: 1) trained in the use of firearms (hopefully much better than the average person), 2) much more likely to end up in violent confrontations, and 3) much more likely to be carrying firearms. So you cannot "use" cops to "disprove" his statistic.
Just to get back on topic: I agree, that most people probably don't care all that much about the concrete case of modchips, but are more worried about the precedent it sets (esp. when precedent is weighted so heavily in American/British-style courts).
it's easier [...] to debug perl than many languages simply because you have less lines you have to look at to figure out whats going on.
Take a look at some K code (there are examples in the user manual) and then come back and say that. If K is too exotic, then try looking at some macro-heavy LISP code -- it has the same problem just slightly less so.
Code density can be good when you're trying to see the big picture (fewer screenfulls of code is a good thing in this case), but it can work against you when you're trying to understand the little details.
since you get to look at regex patterns to figure out what's going on (looks to hard to manage? get over it. Regex is a small, orthogonal set of commands).
Regular expressions are nothing more than a hack to make up for the fact that generalized LR parsers were quite inefficient up until a few years ago. Just compare a reasonably complex regular expression to the BNF form of a grammar for parsing the same input to see how much easier GLR is to use -- you can see some examples of just how easy GLR parsing is to use here. And it can actually handle more general patterns with nesting, etc. I really think regexes are really just a question of premature optimization -- with GLR you just start out with an incredibly readable and simple grammar, and if it proves to be slow (i.e. if there are lots of points of ambiguity along certain parse trees) you can optimize it towards a purely LR(k) grammar.
[...] mean data that is stored today, will be accessible in 200 years time.
and a huge part of this is hardware support and, interestingly enough, storage bandwidth. You see, you have to migrate data from obsolete hardware/media to newer hardware/media, but in the near future the amount of data stored on obsolete hardware/media may become too large to transfer to newer hardware/media before it dies/decays/whatever, simply because the throughput of the transfer mechanism is too low.
However, I do have an idealogical problem with the Freenet project's approach to defining free speech.
Well, the problem with anonymous, encrypted free speech is that it's all or nothing. There is no way to distinguish different types of material from each other (since it's all encrypted), and there is no "responsible" person who can be tracked down by law enforcement. So neither content-based nor after-the-fact censorship works. So it's not so much that the Freenet project defines free speech in a particular way, there is just no way to implement more restricted speech while still providing anonymity and encryption.
I feel that kiddy porn has a strong, negative effect on the children involved.
Certainly, creation of images has a negative effect ("actual harm" in legalese, IIRC), but one can argue that distribution might not have the same effect (one might even argue that it has a benefitial effect for others would-be victims by providing an outlet for would-be paedophiles, but I don't know of any research to support any of this). Frankly, I don't want to be a party to either, but I believe the benefits of Freenet outweigh its drawbacks, so I would probably be running a node if the implementation wasn't so shitty. But I can certainly respect your choice to not run a node because of this -- not everyone can "stomach" it.
Many people haven't heard of LabView, even though it has been around since the late 80s.
Maybe, just maybe, there's a reason for that.
While "graph" programming may be useful for data flow programming, it's absolutely useless for general purpose programming. For general purpose programming the devil's in the details and introducing a "graph" programming language just moves you further away from the details without actually giving you control of the details (see Joel Spolsky's article about "leaky abstractions" as to why this is a bad idea).
I don't think so. At least mine doesn't show anything except Gstreamer and Arts. The latter probably sucks the most from the user's perspective, but dear $DEITY why did the Gstreamer people have to use the bad, bad, bad idea of trying to shoehorn object-orientedness into C with a mess of macros??? Best way to ruin what could have been very promising with a crummy implementation, IMHO.
File sharing is already legal as long as you own the copyright or have permission from the copyright holder (or if it's public domain). Granted, lots of infringe on copyright, but that has always been the case (maybe not with the same ease as with digital media, but that's beside the point...) and current legeslation already forbids that.
Should we abolish copyright?
False dichotomy. File sharing and copyright can coexist (as they currently do).
If we do, what will be the incentive for creators to publish their work? The desire to create?
Believe it or not, most artists (hint: I'm not talking about Britney Spears here) become artists because they have a desire to create, not for financial gain. Just try to imagine how many struggling artists there are for each famous/wealthy artist.
then you could take it to mean : The most heavily used language is either C or C++ (but not a combination of the two). Such is the curse of natural language.:) I know this doesn't square with the original poster's second sentence, so I'll concede that you're probably right that TheCoop doesn't grasp that C and C++ are indeed quite different languages (syntax notwithstanding).
But just to get back on topic: It seems to me that Free/OSS server code is heavily slanted in favour of C and not C++ or Java. Actually, I can't think of a single Free/OSS server that's written in C++. And I can only think of one Free/OSS server written in Java, namely Freenet. Quite sad, really, since there are still lots and lots of buffer overflows and sprintf vulnerabilities being found every day.
Maybe you are unfamiliar with the concept of the '/' character, but where I come from it is commonly used to denote alternatives. As in: most people use either C or C++.
Slashdot Mirror
you see, the free beer offer was just to register to vote, it had nothing to do with how you voted.
CALCULON!
mount /home with the noexec option.
I read it while inside your iPaq 4150. So there.
but I usually do a real parser for even trivial lexical data since trivial hacks have a way of becoming notrivial with time. But, hey, to each his own. :)
That is why your statistics are meaningless. Come back when you can argue that your statistics actually mean anything. Hint: Repeating them doesn't work.
Oh, and by the way: I didn't state whether I am for or against gun control, so please stop assuming that you know what my opinion is, mkay?
Umm... that's why the example was unfair.
Whether it's a trick or not is irrelevant. A GIF user could employ a trick to achieve the same goal (ease of global modification) with ease, so touting easy updates as an advantage is not "fair" when comparing the transparent pixel approach with the class="indent" approach. That was my point.
I'm referring to that last bit about increasing indents. The transparent-GIF-using webmaster could just as easily have a 20x1 transparent GIF called "indent.gif" used only for indentation. Then they could change indentation just as easily as you could. So there. :)
Just to be clear: I'm not arguing that using transparent GIFs is better than CSS, I'm just saying your last argument is based on the unfair assumption that the GIF-user couldn't use a similar trick to class="indent".
50 bytes and 100 bytes is utterly irrelevant; 99% of the wait the user experiences is caused by network latency (which remains the same). Still, since the patent expired there probably aren't any good reasons not to use GIF for this -- except maybe the Feel-good Factor(TM).
I realize you're semi-joking, but that's not at all what I was saying. I was talking about regexes as a programmer interface, not a user interface. As a programmer interface GLR parsing is by far superior to regexes, even though optimization may sometimes require that you to actually use state machines and/or regexes for implementation. In those cases you should still document the state machine and/or regex by using a context-free grammar.
As a user interface regexes are sometimes very convenient, especially because searches etc. usually are NOT repeated very often or meant for others to read/understand (and so don't suffer too much from the syntax). But even when you try to do relatively simple (conceptually) searches regexes sometimes explode into ridiculously complicated one-liners (granted, the escaping is a large part of this, but the point still stands). A great example of this is shell wildcards vs. regexes. Why do think shell wildcards are still used in shells? Because the syntax is more convenient, that's why.
No, it is not. Regex cannot handle arbitrarily balanced/nested constructs while LR grammars can. Just try to implement a regex to match every '(' in the input with a corresponding ')'. See what I mean?
The rest of your post is irrelvant and wrong.
Even if the statistics are true, what's the point? Some people are more dangerous to the general public than others? Fuckin' duh -- they're fucking doctors, they make lots of life and death decisions on a daily basis -- that means that it is meaningless to compare the statistics on a per-doctor/per-owner basis. If we were to compare, then we would have to compare to the number of accidental deaths per incident (ie. treatment/unholstering). As they stand, the statistics are utterly meaningless.
Anyway, whether on not physicians are more "dangerous" than gun owners has absolutely no bearing whatsoever on whether increased gun control would decrease the number of gun-related deaths. None.
Just brilliant. Now, I'm not claiming that the parent to your post is anywhere near right with his "statistics", but I seem to recall some numbers indicating that a person is more likely to be wounded/killed by one of their own family members rather than an unknown assailant -- in that setting you're probably very unlikely to be carrying a gun (who carries a gun at home?) or even being able to defend yourself (since you'd presumably be taken by surprise). But I digress...
However, law enforcement is usually NOT part of the statistics for civilian gun-related deaths/injuries because they are: 1) trained in the use of firearms (hopefully much better than the average person), 2) much more likely to end up in violent confrontations, and 3) much more likely to be carrying firearms. So you cannot "use" cops to "disprove" his statistic.
Just to get back on topic: I agree, that most people probably don't care all that much about the concrete case of modchips, but are more worried about the precedent it sets (esp. when precedent is weighted so heavily in American/British-style courts).
Take a look at some K code (there are examples in the user manual) and then come back and say that. If K is too exotic, then try looking at some macro-heavy LISP code -- it has the same problem just slightly less so.
Code density can be good when you're trying to see the big picture (fewer screenfulls of code is a good thing in this case), but it can work against you when you're trying to understand the little details.
Regular expressions are nothing more than a hack to make up for the fact that generalized LR parsers were quite inefficient up until a few years ago. Just compare a reasonably complex regular expression to the BNF form of a grammar for parsing the same input to see how much easier GLR is to use -- you can see some examples of just how easy GLR parsing is to use here. And it can actually handle more general patterns with nesting, etc. I really think regexes are really just a question of premature optimization -- with GLR you just start out with an incredibly readable and simple grammar, and if it proves to be slow (i.e. if there are lots of points of ambiguity along certain parse trees) you can optimize it towards a purely LR(k) grammar.
She verry stoopid mac user.
and a huge part of this is hardware support and, interestingly enough, storage bandwidth. You see, you have to migrate data from obsolete hardware/media to newer hardware/media, but in the near future the amount of data stored on obsolete hardware/media may become too large to transfer to newer hardware/media before it dies/decays/whatever, simply because the throughput of the transfer mechanism is too low.
Unfortunately, this doesn't work in all terminal emulators (konsole is one example).
Well, the problem with anonymous, encrypted free speech is that it's all or nothing. There is no way to distinguish different types of material from each other (since it's all encrypted), and there is no "responsible" person who can be tracked down by law enforcement. So neither content-based nor after-the-fact censorship works. So it's not so much that the Freenet project defines free speech in a particular way, there is just no way to implement more restricted speech while still providing anonymity and encryption.
Certainly, creation of images has a negative effect ("actual harm" in legalese, IIRC), but one can argue that distribution might not have the same effect (one might even argue that it has a benefitial effect for others would-be victims by providing an outlet for would-be paedophiles, but I don't know of any research to support any of this). Frankly, I don't want to be a party to either, but I believe the benefits of Freenet outweigh its drawbacks, so I would probably be running a node if the implementation wasn't so shitty. But I can certainly respect your choice to not run a node because of this -- not everyone can "stomach" it.
Maybe, just maybe, there's a reason for that.
While "graph" programming may be useful for data flow programming, it's absolutely useless for general purpose programming. For general purpose programming the devil's in the details and introducing a "graph" programming language just moves you further away from the details without actually giving you control of the details (see Joel Spolsky's article about "leaky abstractions" as to why this is a bad idea).
maybe because freecache is only for large (as in several megabytes) files?
I don't think so. At least mine doesn't show anything except Gstreamer and Arts. The latter probably sucks the most from the user's perspective, but dear $DEITY why did the Gstreamer people have to use the bad, bad, bad idea of trying to shoehorn object-orientedness into C with a mess of macros??? Best way to ruin what could have been very promising with a crummy implementation, IMHO.
File sharing is already legal as long as you own the copyright or have permission from the copyright holder (or if it's public domain).
Granted, lots of infringe on copyright, but that has always been the case (maybe not with the same ease as with digital media, but that's beside the point...) and current legeslation already forbids that.
False dichotomy. File sharing and copyright can coexist (as they currently do).
Believe it or not, most artists (hint: I'm not talking about Britney Spears here) become artists because they have a desire to create, not for financial gain. Just try to imagine how many struggling artists there are for each famous/wealthy artist.
Nothing. No new legeslation is necessary.
He's Danish.
then you could take it to mean : The most heavily used language is either C or C++ (but not a combination of the two). Such is the curse of natural language. :)
I know this doesn't square with the original poster's second sentence, so I'll concede that you're probably right that TheCoop doesn't grasp that C and C++ are indeed quite different languages (syntax notwithstanding).
But just to get back on topic: It seems to me that Free/OSS server code is heavily slanted in favour of C and not C++ or Java. Actually, I can't think of a single Free/OSS server that's written in C++. And I can only think of one Free/OSS server written in Java, namely Freenet. Quite sad, really, since there are still lots and lots of buffer overflows and sprintf vulnerabilities being found every day.
Maybe you are unfamiliar with the concept of the '/' character, but where I come from it is commonly used to denote alternatives. As in: most people use either C or C++.