One more time, for the majority of people who don't understand:
Strong typing is when your language will only allow appropriate operations to be performed on values of the appropriate type.
Weak typing is the opposite, where a language will implicitly convert between (possibly incompatible) types or will simply allow any operation to occur.
Static typing is when a language enforces its typesystem (whether it be strong or weak) at compile time.
Dynamic typing is the opposite, when a language enforces its typesystem at runtime.
Python is strongly, dynamically typed. If you try to perform an integer operation on a string, it will check this at runtime and raise an exception. It will not perform the operation.
Perl is weakly, dynamically typed. If you try to perform an integer operation on a string, it will implicitly convert that string to an integer (using 0 in the case of strings that aren't a valid representation of an integer). It does this at runtime.
Haskell is strongly, statically typed. If the compiler cannot prove that all your operations are performed on values of the appropriate type, it will not compile your program.
C is weakly, statically typed. It will implicitly convert beteween incompatible values (pointers and ints, for instance) but it will determine which implicit conversions will occur at compile time (as well as reject some other conversions or type errors).
Python is not in any way statically typed. Perhaps only moderators who actually know Python should get mod points on articles such as these (yes, I know that'd be impossible, but it'd ridiculous that the parent post got modded up to 5, interesting when it's blatantly and obviously wrong).
Because QT (which KDE is based on) isn't Free on Windows. Duh.
Of course, I'm a bit known for tilting at windmills
(If you didn't read his link, you can skip over this now).
You can't treat "investment" like it's some magical way to multiply money. You don't take two million dollars, stick it in a cage for 10 years, and suddenly, like rabbits, it's multiplied to a "rolling cashflow" that can reduce taxes. Money always has to come from somewhere, and in your case, the money you're "investing" would simply be paying back a small portion of the taxes you had to raise to get that money.
I'm not even a Java programmer and I can see your problem. You lack a quality testing methodology. If all you're doing are hand tests to assure yourself that your code is correct, I pity your customers, whether you program in C++ or Java or Python.
Type safety alone (especially the faux "safety" you get in C++) is not an adequate replacement for a comprehensive testing methodology.
So when you run a test 5 times, and you get 5 results, the hardware is broken. When you run the same test 5 times, and it gets to the exact same point before sig11ing, you have a software flaw.
This isn't true. If you're running a program that uses a deterministic memory allocation algorithm (a compiler, for instance) and have a segment of bad memory, then you easily could crash at the exact same point (when a pointer in that segment is dereferenced, for instance).
I know. It's happened to me. I've even had such slightly bad memory that I could compile nearly everything I needed, but one project consistently failed. I took out a bad memory chip (actually it was simply mismatched PC100/PC133) and everything worked fine.
Go look at the GNU Win CD or The Open CD and count the Qt/KDE apps. Or let me save you the time and do it for you. Zero.
That's because QT/KDE hasn't been ported to Windows yet. There's nothing stopping someone from taking the Free GPL'ed QT (and KDE) and porting it to Windows. It just hasn't been done yet.
The pisser with the Qt license is that a project must decide before writing the first line of code which license they plan to release under and you can't change your mind later.
Are you insane? The copyright holder on a piece of code can decide at any time what license he wishes to use in his code. If he develops against the Free QT, he has to release his source code under a GPL-compatible license. If he later decides to go commercial, then he can relicense all later code (the code he originally released under the GPL will remain GPL for all time) and write against the Professional/Enterprise QT and release it under whatever license he wants.
You can't dual license either.
You can do whatever you want as long as it's GPL-compatible.
And if you opt for free you can never port to an unfree system.
You can't take your code that you released under the GPL back, no. But that's the case with any code you release under the GPL. You can later choose to go proprietary and close your source, though. All you have to do is purchase a Professional/Enterprise QT license.
The KDE camp still refuse to admit they made an unholy alliance with the devil and will forever be damned for it.
If by "forever be damned for it" you mean "must link with GPLed software," then sure, you're right. Although I wouldn't exactly call that an "unholy alliance with the Devil."
Repeat after me: Free QT is the GPL. There are no further restrictions on your code and there can be no further restrictions on your code. All the same restrictions that normally apply to linking against GPLed code apply here.
Since the first movie will be "The Lion, The Witch and The Wardrobe" (which is the second book)
No, The Lion, the Witch, and the Wardrobe is the first book. C. S. Lewis himself wrote it and defined it as such. Don't play into the publishers' tricks by believing it is anything but the first book. They have no right to reorder the series, chronologically or otherwise.
While OpenBSD has not shared in the commercial success of Linux, it does have one area of technical superiority: its security review process has yet to permit a remote root compromise in a standard install.
You know, when I install a computer, I consider the "install" to be the files installed on my hard drive. "/bin/ls" is part of the "install." "/sbin/ifconfig" is part of the "install." "/usr/libexec/ftpd" is part of the "install."
Apparently, however, the OpenBSD developers disagree. Something has to actually be running to be part of the "install." Thus, by their definition, none of those programs are part of the "install."
Good thing, too. Because/usr/libexec/ftpd has sure as hell had a remotely-exploitable root hole.
You may not like virii, but if enough people use it, it is a word.
No, if enough people use it, it just lowers the average intelligence of English speakers.
I don't give one rat's ass about your linguistic mumbo-jumbo. Some people are just retarded, and the ones who continually use the word "virii" because they think they're cool happen to be among them.
We can claim we're the good guys and we won't use it. But we can look at Nagasaki and Hiroshima.
Nagasaki and Hiroshima saved millions of lives by ending the war without an invasion of Japan. Had we not dropped those bombs, we would have been forced to do the same thing on the island of Japan that we did in Europe, and that would've cost millions of lives on both sides of the war.
The point is that networks oftentimes scroll breaking news across the bottom of the screen during other shows. Fox is concerned that viewers will mistake the parody scroll for a real scroll.
It sounds perfectly justified to me. In this case, the news was ridiculous and unbelievable, but in the future, that may not be the case, and it only takes one issue like to lose the trust of millions of viewers.
Brute-force decoding of these schemes is not recommended for the faint of heart, but I wonder: how can they tell that a 2 ^ 512 possibility range is as secure as a 2 ^ 15360 probabilities scheme?
It's because the problem being solved is completely different.
The key here (ha!) is that when you see a 512 bit symmetrical cipher, you've got to brute-force a 512 bit key, which means you'll try 2**511 keys on average before cracking the ciphertext. But when you see a 512 bit RSA key, that means you have just have to factor a 512 bit composite number into its two prime factors before cracking the ciphertext. That's hard, but not nearly as hard as exhaustively testing the keys in a 512 bit keyspace.
Now ask yourself - why would they NEED to enlarge them, if not to screw with compression, in the same way the RIAA has done with sound recordings?
Because movie compression is lossy, and the dots were too small to discern the actual code before. They're enlarging the dots so they can still read the code when the movie has been lossily compressed.
In the end, an experienced C programmer can get the same job done with the same quality in C as an experienced Java program can in Java, and that ought to be good enough for anybody.
This simply isn't the case.
Studies have shown (if you're interested, the relevant studies are referenced in "Code Complete" by Steve McConnell) that programmers are capable of writing approximately the same number of lines of code per unit of time in whatever language they program in. Whether it's C, Java, or Sparc Assembler, they'll write pretty much the same number of lines of code in day.
The catch, however, is the expressivity of the languages used. A thousand lines of C will certainly "do more" than the same number of lines of Sparc assembler. Likewise (though arguably not on the same scale), a thousand lines of Java will certainly "do more" than the same number of lines of C. So disregarding errors for the moment, programmers are more productive in a higher level language like Java than they are in C or Sparc assembler.
Now, as far as errors go: it's true that experienced programmers (in whatever language) will make fewer mistakes than less experienced programmers. But they're still human, and even if you're Donald Knuth himself, you're still going to make mistakes. The fact is that mistakes in C are far more costly than mistakes in Java. You can have off-by-one errors in both languages. In Java, however, your program will raise an out of bounds exception and, at worst, halt. In C, such a mistake could easily lead to a buffer overflow security flaw that can be exploited for elevated privilege. The same error in C and in Java is far more costly in C than in Java.
With even higher level languages, entire classes of mistakes cannot even exist, but I don't have time to go into the advantages of such languages like SML or Haskell.
Programmers no matter how experienced, are going to make mistakes. What matters is how costly those mistakes are. And they cost a whole lot more in C than in Java.
The new HP's... aren't even made by HP. (They're rebranded.)
Absolutely untrue. They're made by the same calculator division that worked on calculators before HP spun off Agilent. It's just that Agilent got the calculator division.
Python 2.3 had its development accelerated, but it most definitely was not released early. Had we not chosen to accelerate development, we would have released it just a week later.
That's why you haven't noticed any serious problems with the 2.3 release. It wasn't rushed.
District Judges aren't really political creatures. Once they're appointed, they're there for life, and their ONLY politicking is jockying for a seat on the Apellate Circuit or the Supreme Court.
And that means they suddenly become disinterested in money why?
Jeremy
Re:Works by maintaining/increasing telomere length
on
The Oldest Mouse Contest
·
· Score: 2, Informative
There's a gene called telomerase that synthesizes these telomeres at the ends of chromosones.
Telomerase is an enzyme, not a gene. And it prevents the shortening of the telomeres; it doesn't actually lengthen them after they've been shortened.
Slashdot Mirror
One more time, for the majority of people who don't understand:
Strong typing is when your language will only allow appropriate operations to be performed on values of the appropriate type.
Weak typing is the opposite, where a language will implicitly convert between (possibly incompatible) types or will simply allow any operation to occur.
Static typing is when a language enforces its typesystem (whether it be strong or weak) at compile time.
Dynamic typing is the opposite, when a language enforces its typesystem at runtime.
Python is strongly, dynamically typed. If you try to perform an integer operation on a string, it will check this at runtime and raise an exception. It will not perform the operation.
Perl is weakly, dynamically typed. If you try to perform an integer operation on a string, it will implicitly convert that string to an integer (using 0 in the case of strings that aren't a valid representation of an integer). It does this at runtime.
Haskell is strongly, statically typed. If the compiler cannot prove that all your operations are performed on values of the appropriate type, it will not compile your program.
C is weakly, statically typed. It will implicitly convert beteween incompatible values (pointers and ints, for instance) but it will determine which implicit conversions will occur at compile time (as well as reject some other conversions or type errors).
Python is not in any way statically typed. Perhaps only moderators who actually know Python should get mod points on articles such as these (yes, I know that'd be impossible, but it'd ridiculous that the parent post got modded up to 5, interesting when it's blatantly and obviously wrong).
Jeremy
Why Open Source for Linux Only?
Because QT (which KDE is based on) isn't Free on Windows. Duh.
Of course, I'm a bit known for tilting at windmills
(If you didn't read his link, you can skip over this now).
You can't treat "investment" like it's some magical way to multiply money. You don't take two million dollars, stick it in a cage for 10 years, and suddenly, like rabbits, it's multiplied to a "rolling cashflow" that can reduce taxes. Money always has to come from somewhere, and in your case, the money you're "investing" would simply be paying back a small portion of the taxes you had to raise to get that money.
Jeremy
I'm not even a Java programmer and I can see your problem. You lack a quality testing methodology. If all you're doing are hand tests to assure yourself that your code is correct, I pity your customers, whether you program in C++ or Java or Python.
Type safety alone (especially the faux "safety" you get in C++) is not an adequate replacement for a comprehensive testing methodology.
Jeremy
Becuase golly gee whiz, they sure can't break the window or anything...
So when you run a test 5 times, and you get 5 results, the hardware is broken. When you run the same test 5 times, and it gets to the exact same point before sig11ing, you have a software flaw.
This isn't true. If you're running a program that uses a deterministic memory allocation algorithm (a compiler, for instance) and have a segment of bad memory, then you easily could crash at the exact same point (when a pointer in that segment is dereferenced, for instance).
I know. It's happened to me. I've even had such slightly bad memory that I could compile nearly everything I needed, but one project consistently failed. I took out a bad memory chip (actually it was simply mismatched PC100/PC133) and everything worked fine.
Jeremy
Go look at the GNU Win CD or The Open CD and count the Qt/KDE apps. Or let me save you the time and do it for you. Zero.
That's because QT/KDE hasn't been ported to Windows yet. There's nothing stopping someone from taking the Free GPL'ed QT (and KDE) and porting it to Windows. It just hasn't been done yet.
The pisser with the Qt license is that a project must decide before writing the first line of code which license they plan to release under and you can't change your mind later.
Are you insane? The copyright holder on a piece of code can decide at any time what license he wishes to use in his code. If he develops against the Free QT, he has to release his source code under a GPL-compatible license. If he later decides to go commercial, then he can relicense all later code (the code he originally released under the GPL will remain GPL for all time) and write against the Professional/Enterprise QT and release it under whatever license he wants.
You can't dual license either.
You can do whatever you want as long as it's GPL-compatible.
And if you opt for free you can never port to an unfree system.
You can't take your code that you released under the GPL back, no. But that's the case with any code you release under the GPL. You can later choose to go proprietary and close your source, though. All you have to do is purchase a Professional/Enterprise QT license.
The KDE camp still refuse to admit they made an unholy alliance with the devil and will forever be damned for it.
If by "forever be damned for it" you mean "must link with GPLed software," then sure, you're right. Although I wouldn't exactly call that an "unholy alliance with the Devil."
Repeat after me: Free QT is the GPL. There are no further restrictions on your code and there can be no further restrictions on your code. All the same restrictions that normally apply to linking against GPLed code apply here.
Jeremy
Since the first movie will be "The Lion, The Witch and The Wardrobe" (which is the second book)
No, The Lion, the Witch, and the Wardrobe is the first book. C. S. Lewis himself wrote it and defined it as such. Don't play into the publishers' tricks by believing it is anything but the first book. They have no right to reorder the series, chronologically or otherwise.
Jeremy
Um, given that this review is on UNIX Network Programming, I don't know if it quite qualifies as "other must have books by richard stevens" :)
While OpenBSD has not shared in the commercial success of Linux, it does have one area of technical superiority: its security review process has yet to permit a remote root compromise in a standard install.
/usr/libexec/ftpd has sure as hell had a remotely-exploitable root hole.
You know, when I install a computer, I consider the "install" to be the files installed on my hard drive. "/bin/ls" is part of the "install." "/sbin/ifconfig" is part of the "install." "/usr/libexec/ftpd" is part of the "install."
Apparently, however, the OpenBSD developers disagree. Something has to actually be running to be part of the "install." Thus, by their definition, none of those programs are part of the "install."
Good thing, too. Because
Jeremy
Redhat, +1, Already doing it. -1, not failing to install if the packages don't verify.
Which is exactly the state in Debian, too.
Jeremy
You may not like virii, but if enough people use it, it is a word.
No, if enough people use it, it just lowers the average intelligence of English speakers.
I don't give one rat's ass about your linguistic mumbo-jumbo. Some people are just retarded, and the ones who continually use the word "virii" because they think they're cool happen to be among them.
Jeremy
We can claim we're the good guys and we won't use it. But we can look at Nagasaki and Hiroshima.
Nagasaki and Hiroshima saved millions of lives by ending the war without an invasion of Japan. Had we not dropped those bombs, we would have been forced to do the same thing on the island of Japan that we did in Europe, and that would've cost millions of lives on both sides of the war.
Jeremy
The only corruption here is the horrible corruption of the English language that somehow lead to CmdrTaco thinking "to savage" meant "to ravage."
Jeremy
The point is that networks oftentimes scroll breaking news across the bottom of the screen during other shows. Fox is concerned that viewers will mistake the parody scroll for a real scroll.
It sounds perfectly justified to me. In this case, the news was ridiculous and unbelievable, but in the future, that may not be the case, and it only takes one issue like to lose the trust of millions of viewers.
Jeremy
How many cereal box toys do you know that could break into fewer than a dozen pieces flying at Mach 5?
The RSA cryptosystem for instance is thoroughly explained on RSA's web-site, but you would still need a lisence to use the algorithm in a program
No. That patent expired in (iirc) October 2001.
Jeremy
Brute-force decoding of these schemes is not recommended for the faint of heart, but I wonder: how can they tell that a 2 ^ 512 possibility range is as secure as a 2 ^ 15360 probabilities scheme?
It's because the problem being solved is completely different.
The key here (ha!) is that when you see a 512 bit symmetrical cipher, you've got to brute-force a 512 bit key, which means you'll try 2**511 keys on average before cracking the ciphertext. But when you see a 512 bit RSA key, that means you have just have to factor a 512 bit composite number into its two prime factors before cracking the ciphertext. That's hard, but not nearly as hard as exhaustively testing the keys in a 512 bit keyspace.
Jeremy
Now ask yourself - why would they NEED to enlarge them, if not to screw with compression, in the same way the RIAA has done with sound recordings?
Because movie compression is lossy, and the dots were too small to discern the actual code before. They're enlarging the dots so they can still read the code when the movie has been lossily compressed.
Jeremy
This simply isn't the case.
Studies have shown (if you're interested, the relevant studies are referenced in "Code Complete" by Steve McConnell) that programmers are capable of writing approximately the same number of lines of code per unit of time in whatever language they program in. Whether it's C, Java, or Sparc Assembler, they'll write pretty much the same number of lines of code in day.
The catch, however, is the expressivity of the languages used. A thousand lines of C will certainly "do more" than the same number of lines of Sparc assembler. Likewise (though arguably not on the same scale), a thousand lines of Java will certainly "do more" than the same number of lines of C. So disregarding errors for the moment, programmers are more productive in a higher level language like Java than they are in C or Sparc assembler.
Now, as far as errors go: it's true that experienced programmers (in whatever language) will make fewer mistakes than less experienced programmers. But they're still human, and even if you're Donald Knuth himself, you're still going to make mistakes. The fact is that mistakes in C are far more costly than mistakes in Java. You can have off-by-one errors in both languages. In Java, however, your program will raise an out of bounds exception and, at worst, halt. In C, such a mistake could easily lead to a buffer overflow security flaw that can be exploited for elevated privilege. The same error in C and in Java is far more costly in C than in Java.
With even higher level languages, entire classes of mistakes cannot even exist, but I don't have time to go into the advantages of such languages like SML or Haskell.
Programmers no matter how experienced, are going to make mistakes. What matters is how costly those mistakes are. And they cost a whole lot more in C than in Java.
Jeremy
(P.S.: I'm a Python and SML fan, myself.)
Comparing it to the discovery of penicillin is like saying Tolkien discovered the lord of the rings.
Tolkien himself would say that he was merely a discoverer of Middle-earth. Perhaps there's a comparison here...
Jeremy
Absolutely untrue. They're made by the same calculator division that worked on calculators before HP spun off Agilent. It's just that Agilent got the calculator division.
The division was rebranded, not the calculator.
Jeremy
Python 2.3 had its development accelerated, but it most definitely was not released early. Had we not chosen to accelerate development, we would have released it just a week later.
That's why you haven't noticed any serious problems with the 2.3 release. It wasn't rushed.
Jeremy
District Judges aren't really political creatures. Once they're appointed, they're there for life, and their ONLY politicking is jockying for a seat on the Apellate Circuit or the Supreme Court.
And that means they suddenly become disinterested in money why?
Jeremy
Telomerase is an enzyme, not a gene. And it prevents the shortening of the telomeres; it doesn't actually lengthen them after they've been shortened.
Jeremy
For someone who invented the language, you sure have a funny way of spelling, "We Brits invented the language"
Jeremy