Correct, but entrapping someone is a surefire way to secure an acquittal.
An undercover police officer can offer to sell you drugs, and arrest you if you accept and hand him...
This is entrapment if you would never have attempted to buy the drugs in the first place without the police officer offering them (i.e. they are actually indirectly causing you to commit the crime when you would not have committed said crime under normal circumstances). Whether or not this is the case is a judgement call on the part of the judge/jury, but in cases of clear entrapment (for instance a PO calling you out of the blue, offering drugs for sale) the case would immediately be thrown out of court.
Your argument only supports the notion that Java references and C/C++ pointers are not the same. That, however, is rather obvious since Java and C/C++ are not the same.
Whether or not pointer arithmetic is allowed is irrelevant.
A pointer is a reference is a pointer. They both embody the notion of pointing to (or equivalently referencing) something. The fact that the C/C++ type system is broken and lets you do stupid things with pointers is irrelevant. C/C++ also lets you typecast any random struct to an int (note: not pointers to...) -- which means that pointers are not special in this regard.
Re:assembly language is for pansies
on
Hardcore Java
·
· Score: 1
That is like saying hardcore is writing an english novel using only one vowel. There are a lot of novels you couldn't write that way.
Nonsense! You just need to find a suitable encoding.
(Yes, that was a joke. A lame one, but still a joke.)
but you're still blocking zombies on the >95% (a wild guesstimate) of hosts who don't run mail servers (and would thus not have any interest in being unblocked). Even if every single unblocked host were compromised, you would still be blocking a huge number of zombies.
These are both sort of combined configuration and build systems (which is the way it should be IMHO). Scons requires Python (>=1.5.2, IIRC), so it is as "only" as portable as Python itself (which is to say "very") while cmake doesn't require anything except a C++ compiler. The actual "language" in Scons is just regular python while cmake uses a hideous custom language.
When people here speak of a "database" they really mean a "database system".
Technically, you're correct, though. But I would content that the definition of "database" is so wide as to make it completely worthless to refer to a "database" and not "database system" in any technical context -- which is why people use "database" as shorthand for referring to a database system.
It's a perfectly valid test -- it measures how much fragmentation can be observed after a certain amount of use. According to your logic we couldn't compare any properties of NTFS/ReiserFS/FAT32/HFS+ because they work differently.
How a programming language bends to someones will is beyond me sorry
You should try reading about LISP macros. Paul Graham has written mostly about macros; it's available here. To really get it, you require a bit of LISP knowledge, but you can get the general idea of the power of macros just by skimming the introductory parts of some of the later chapters. If you've got the time, I recommend reading through, it's very well written and really shows off what LISP can do for you.
2 and 5 (from your other post, obviously) are both valid criticisms. (5) less so since journaling is available these days; but if your storage is a RAID, then you need an UPS.
I agree that they're were not all that helpful in your situation, but if you do run a server with some form of backup, you are a fucking idiot.
No amount of metadata journaling (will short of an append-only file system) is going to save you if you (or a malfunctioning/cracked server app) does the equivalent of a
Even if it worked ideally, it means your server could be passing, say, child porn.
Yes, but it also means it could be passing, oh, I don't know... information about a planned organized revolt against an opressive government or inside company information from a whistleblower about e.g. pollution of ground water. Welcome to the double-edged sword of truly free speech.
If I ran a server and someone was engaged in such nefarious activity, they would be "censored" pronto, as in rm -rf *-
That's certainly your perogative (and you would probably be breaking laws if you didn't). Incidentally, I would certainly also do so.
-how in the world can not knowing what's going on (the Sgt. Schultz method?) be an improvement?
It's the difference between being a common carrier and not being one.
If I participate in FreeNet, I'm basically saying: "Here is some disk space and network bandwidth, use it for whatever (and I mean whatever) you want -- I neither care nor do I want to know what you use it for.". IOW, I'm donating resources for good or bad.
Not knowing (or being able to know) what is actually stored on your computer gives you (morally, if not legally) common carrier status.
I didn't mean to give the impression that I think Java is very slow (the "fast enough" comment might be interpreted that way). I don't. But I don't think it is generally as fast as C, either.
I know of one case where it definitely is faster than C, though: If you implement the Fibonacci function in a naive way, then Java will be quite a bit faster than C, but this is only because it implements its stack on the heap. If you do the same in C it again beats Java.
Compilers do not need them if properly designed, as with the many
modern languages I cited.
But C and C++ require this. Ever notice how in C and C++, you can't refer to an undeclared type, even if it is declared later in the file? You have to provide at least a forward definition. ("class Bob;") Likewise functions, data members, etc. This is most annoying in C++, with inline functions. You have to pay attention to ordering. In other languages, you do not.
This is unrelated to whether or not you require a separate interface file. The reason that the forward declaration exists is that you cannot declare circular types (such as linked list elements) without them. In all other cases, you can just sort the declarations topologically and write them out in that order.
Besides, what you're saying is true even of "properly designed languages" like ML. Just try:
type list_of_a =
Cons a list_of_a
| Nil;
type a =
int;
It doesn't compile, but it DOES work if you use:
type list_of_a =
Cons a list_of_a
| Nil
and type a =
int;
(note the and)
So you're basically talking about a syntactical problem in C/C++ which forces you to declare (textuall) things in a topological order.
Okay...that's great for those 1% of people who want the interface file to remain absolutely static. And I mean absolutely static. No new methods. No changes to the comments. No nothing. (In fact, I doubt there are even 1% of people who want this, once they give it some thought.)
For the remaining 99% of us, this is unwanted Bondage and Discipline.
Making up a statistic is never a good way to argue a point.
Besides, nobody said anything about forcing you to use separate interface/implementation. I just said to it could be a good thing to use it and have it be supported by the compiler.
In my preferred language, OCaml, you have the option of having a separately declared interface (a.mli file) or not having one. If you have one, the compiler will rigorously check that your code complies with the declared interface. If you don't have one, it will just generate the interface your code implements.
By the way, since you brought them up, declaring a proper interface is much more important in type-inferencing languages, since even tiny changes to code can cause completely different types to be inferred. For example, in OCaml:
let f x =
x + 5;
let g x =
x +. 5;
f and g have different signatures even though the difference is tiny. If you're interfacing to binary libraries it helps immensely to know that the library would not have compiled if such a type-altering change has occurred in the "hidden" code.
Maybe the people who want the interface to remain static can do so in a more intelligent way. Like comparing javap output on check-in and ensuring the old methods are there, with the same signatures as before.
You call that intelligent? Instead of just having the compiler do it? It already knows all about type aliases, what types are compatible, etc. etc. (i.e. all the stuff that makes checking such things using a postprocessor extremely error-prone).
Note, I said C. Not C++. There is a big difference since C++ is notoriously hard to write really efficient code in (well, unless you restrict yourself to the C "subset").
Slashdot Mirror
Correct, but entrapping someone is a surefire way to secure an acquittal.
This is entrapment if you would never have attempted to buy the drugs in the first place without the police officer offering them (i.e. they are actually indirectly causing you to commit the crime when you would not have committed said crime under normal circumstances). Whether or not this is the case is a judgement call on the part of the judge/jury, but in cases of clear entrapment (for instance a PO calling you out of the blue, offering drugs for sale) the case would immediately be thrown out of court.
own the Daleks? That explains it!
Emacs w/the "semantic" package has those, I believe. (Well, maybe not "immediate", but close enough
Have you considered that the fact that plugins actually need to do this AST manipulation, might actually be a shortcoming of the language?
Your argument only supports the notion that Java references and C/C++ pointers are not the same. That, however, is rather obvious since Java and C/C++ are not the same.
Whether or not pointer arithmetic is allowed is irrelevant.
...) -- which means that pointers are not special in this regard.
A pointer is a reference is a pointer. They both embody the notion of pointing to (or equivalently referencing) something. The fact that the C/C++ type system is broken and lets you do stupid things with pointers is irrelevant. C/C++ also lets you typecast any random struct to an int (note: not pointers to
Nonsense! You just need to find a suitable encoding.
(Yes, that was a joke. A lame one, but still a joke.)
but you're still blocking zombies on the >95% (a wild guesstimate) of hosts who don't run mail servers (and would thus not have any interest in being unblocked). Even if every single unblocked host were compromised, you would still be blocking a huge number of zombies.
(probably also lots of other stuff I've forgotten)
Fusion has none of these drawbacks.
Translation: It's only expensive on 90% of all deployed systems. (Yes, yes, I made the statistic up, but it's just to make a point).
These are both sort of combined configuration and build systems (which is the way it should be IMHO). Scons requires Python (>=1.5.2, IIRC), so it is as "only" as portable as Python itself (which is to say "very") while cmake doesn't require anything except a C++ compiler. The actual "language" in Scons is just regular python while cmake uses a hideous custom language.
one light year is the distance travelled by time in a year. :)
Time travels? Amazing!
(I know, I know... you meant to say "distance travelled by light in a year.")
When people here speak of a "database" they really mean a "database system".
Technically, you're correct, though. But I would content that the definition of "database" is so wide as to make it completely worthless to refer to a "database" and not "database system" in any technical context -- which is why people use "database" as shorthand for referring to a database system.
It's a perfectly valid test -- it measures how much fragmentation can be observed after a certain amount of use. According to your logic we couldn't compare any properties of NTFS/ReiserFS/FAT32/HFS+ because they work differently.
here (it's linked in the text you quoted from FFS).
Then some MTAs are broken and should be fixed.
That last bit is not allowed by the GPL. It does not allow further restrictions on the distribution of the software which is under the GPL.
Linky. There's no guarantee anyone will read it, though. Them's the breaks.
You should try reading about LISP macros. Paul Graham has written mostly about macros; it's available here. To really get it, you require a bit of LISP knowledge, but you can get the general idea of the power of macros just by skimming the introductory parts of some of the later chapters. If you've got the time, I recommend reading through, it's very well written and really shows off what LISP can do for you.
I agree that they're were not all that helpful in your situation, but if you do run a server with some form of backup, you are a fucking idiot.
No amount of metadata journaling (will short of an append-only file system) is going to save you if you (or a malfunctioning/cracked server app) does the equivalent of aorSo there.
Yes, but it also means it could be passing, oh, I don't know... information about a planned organized revolt against an opressive government or inside company information from a whistleblower about e.g. pollution of ground water. Welcome to the double-edged sword of truly free speech.
That's certainly your perogative (and you would probably be breaking laws if you didn't). Incidentally, I would certainly also do so.
It's the difference between being a common carrier and not being one.
If I participate in FreeNet, I'm basically saying: "Here is some disk space and network bandwidth, use it for whatever (and I mean whatever) you want -- I neither care nor do I want to know what you use it for.". IOW, I'm donating resources for good or bad.
Not knowing (or being able to know) what is actually stored on your computer gives you (morally, if not legally) common carrier status.
But nice try.
I just re-read my reply (the parent), and realize I came off as a bit rude. Apologies for that, no offense meant.
So, actually, one might say that the MS-DOS acronym stands for MicroSoft Dirty Operating System? Sounds about right.
I didn't mean to give the impression that I think Java is very slow (the "fast enough" comment might be interpreted that way). I don't. But I don't think it is generally as fast as C, either.
I know of one case where it definitely is faster than C, though: If you implement the Fibonacci function in a naive way, then Java will be quite a bit faster than C, but this is only because it implements its stack on the heap. If you do the same in C it again beats Java.
This is unrelated to whether or not you require a separate interface file. The reason that the forward declaration exists is that you cannot declare circular types (such as linked list elements) without them. In all other cases, you can just sort the declarations topologically and write them out in that order.
Besides, what you're saying is true even of "properly designed languages" like ML. Just try:It doesn't compile, but it DOES work if you use: (note the and)
So you're basically talking about a syntactical problem in C/C++ which forces you to declare (textuall) things in a topological order.
Making up a statistic is never a good way to argue a point.
Besides, nobody said anything about forcing you to use separate interface/implementation. I just said to it could be a good thing to use it and have it be supported by the compiler.
In my preferred language, OCaml, you have the option of having a separately declared interface (a
By the way, since you brought them up, declaring a proper interface is much more important in type-inferencing languages, since even tiny
changes to code can cause completely different types to be inferred. For example, in OCaml:f and g have different signatures even though the difference is tiny. If you're interfacing to binary libraries it helps immensely to know that the library would not have compiled if such a type-altering change has occurred in the "hidden" code.
You call that intelligent? Instead of just having the compiler do it? It already knows all about type aliases, what types are compatible,
etc. etc. (i.e. all the stuff that makes checking such things using a postprocessor extremely error-prone).
Note, I said C. Not C++. There is a big difference since C++ is notoriously hard to write really efficient code in (well, unless you restrict yourself to the C "subset").