"Faster" in what sense? Tight programs in compiled languages can provide faster execution, sometimes by an order of magnitude. And if that's your measure, a hand-coded tight program in assembler can be two or three times faster than an equivalent program in a compiled language.
On the other hand,
grep '^foo*bar[a-zA-Z]' *.text
can be written in 30 seconds, where the equivalent C code would take all afternoon. A C program that evaluates just that one finite state machine will run at least an order of magnitude faster than grep will... but since most of the time will be spent opening and closing the files and doing read(2), the speed of the program itself won't make much difference. So while the program may be faster in some sense, it will cost ten times as much without doing anything more or shortening the wall-clock time to run.
To a first approximation, the time it takes to write a program is proportional to the number of lines of code in the solution, whether you're writing assembler or perl. The cost of a program is directly proportional to how long it takes to write it. So if you're going to opt for a compiled language over a "scripting" language, you should be sure that the additional cost is justified by the gains that come from performance.
Maybe you do "gotta say" that, but you'd be wrong. As we discussed above, if the key length is less than the message length there will be some difference between pure noise and your signal.
Re:Enviorment, not Genes for personality...
on
The Taste of Pain
·
· Score: 1
Because genes are more complicated and more thoroughly mixed than that. You might as well ask if being able to spell "environment" is purely genetically determined.
No one is suggesting that personality is completely genetically determined, any more than anyone is suggesting that anyone is suggesting that ability to spell is completely determined by environment -- and thus any cat can learn to spell.
Absolutely -- in fact It Is A Theorem that "perfect compression" would result in something that looked absolutely "white", because a "perfectly compressed" signal would have no redundancy. (Easily proven by contradiction: if there were any redundancy, the signal could be compressed further by eliminating it.)
Similarly, an encrypted signal should appear to have very little redundancy, because the closer to "white" it looks, the less statistical information there is to attack.
Your point about the code table is also good. We tend to forget as computer geeks that there is another kind of encryption besides a cipher, which is a good old fashioned code. That is, the construction of an ARBITRARY table of correspondences between some random code group and some desired message. This would be like...
...
28451 Run for your life, they found us! 28452 My cat really likes our new down comforter. 28453 When in the course of human events, it becomes necessary for one people... ...
(It used to be in Europe that you could tune across the shortwave and find a voice reading five-digit code groups out in German for just hours. I don't know that I ever heard authoritatively what that was, but it's odds-on that it was traffic from the East German stazi or from the Soviets to "moles".)
Obviously, a real code has the possibility of very great compression... but at the cost of not being able to to transmit any message. Real code books solve this by having codes for letters and digits, like...
...
38451 Alpha 38452 Bravo 38453 Charlie ...
... which makes it possible to laboriously spell out any message, but means that an unplanned message is very definitely NOT compressed. It is also a theorem that there exists a shortest compressed version of any message (the exact length depends on some assumptions, but the assumptions account at most for a constant factor.)
If you were to, say, Huffman-compress a message and could transmit the code table separately (and securely) the result would be pretty hard to read directly. (That still wouldn't make a good code, because it would be too easy to use statistical information about letter distribution in English to work backwards.)
Um, huh? Can you reference this for the rest of us? I'm admittedly a little behind the curve on this stuff, but if its true that MOST ciphertext is that "white" it would let me get at another problem I'm interested in.
... on the other hand, it sounds kind of unlikely for information-theoretic reasons, unless there are some additional constraints on key size and message lengths before the key is changed.
(1) there is always the possibility that you simply won't. In fact, a properly used one time pad cipher is indistinguishable from noise. It's also a major pain in the ass to use, because you must somehow transmit as many bits of key as you want to send bits of message, and your one-time pad is only as good as your method of transmitting the key.
(2) If there is some kind of message in the signal and a cipher is involved other than a one-time pad or something isomorphic to one, then there will be some degree of redundancy in it. This is a theorem of information theory. Statistical measures will eventually reveal that the redundancy exists.
(3) At that point, there are lots of approaches. A good readable and interesting introduction to these, along with the history of such things, is David Kahn's The Codebreakers. Bruce Schneier's Applied Cryptography is a good, more technical introduction for the computer geek. I've also heard good things for Handbook of Applied Cryptography as well, but I don't actually know the book.
But as someone notes above, it's an inherently hard problem to simply identify the cipher, and modern ciphers like RSA are, as far as we know, computationally intractable because the only known attack requires factoring a very large prime number.
(4) You give up and hire a pretty young woman to talk the marine guards into letting you at the code room. (Details of this approach are left as an exercise for the interested reader.) Sometimes the old fashioned ways are best.
No, you're confused, or we're having a terminology problem. The distinction between infix and prefix is seen most easily in the way things associate, and a add: b associates (as all SmallTalk does) purely to the left:((a add:) b). It looks a little confusing because the 'add:' is in some sense not the 'message', it's the message selector.
Or you could think about it purely in terms of the grammar. My mind goes blank on the exact terminology for SmallTalk (it seems they named a couple of things oddly) but basically, the grammar comes out to be simply left to right, which is the same as prefix, which is the same as Polish, etc.
One of the rather brilliant things about McKay's (et al) original insight with OO was that by treating the things that look like operators as message selectors on the left-hand object, you get something that parses purely left-right -- ie, prefix -- but still reads infix. (Or almost -- like APL in the Old Days, you can occasionally get into trouble by forgetting there's really no precedence.)
(PS. Sorry for the delayed response -- was away for a while.)
Hey, you can make up a better excuse than that. For example, I'd assumed you'd worked it backwards from 800 ms -- without subjecting myself to long division, it's of the right order of magnitude. Um, er -- yeah, 430 millisec one way, 860 millisec round trip time... see, that must be what you did. Right?;-)
Mild quibble: a geosycnhronous satellite is only about 18,000 miles "up" -- geosynchronous orbit is 22,300 miles from the center of the Earth, and one Earth radius is about 4,000 miles. But I've observed the ping time to be 770 +/- 35 msec in a configuration that I was trying to work with. (There's a lot of other delay in there in things like the signal processing of the very low level signal.) Thus the basic point is correct, even if the arithmetic is wrong.
Okay, that's fair -- but it wasn't clear from the context. But (at least with modern hardware) Java is no worse than most things. (Check was a Windows executable actually needs once it links all the dll's.)
If physical memory limits are an issue, you shouldn't be using J2SE; everything from the GC model to the way that it loads everything in the universe and six other libraries is unsuited for it. Use J2ME and establish the profile you really want.
In fact, it's worse than that because the common mythology is that you shouldn't consider any non-functional requirements until you're finished with the code -- as expressed in the common idea that you should defer optimizing for performance until the very last step in development.
Everyone with more than about 20 minutes of experience knows this isn't the way it's really done -- if it were, then every web system would be built first as one big honkin' monolithic program, and refined from there. Instead, we make lots of decisions (like use J2EE or not, distribute the servers or not, use an in-memory DBMS or MySQL, and so on) very early, in order to get somewhere close (we hope) to a system that does what we need.
We call this "architecture" and in general we don't teach it in school. This is in part because it's not very well understood as a discipline, IMAO because research in architecture has concentrated on representations rather than methods. (This is not to say that it's bad, don't mistake my point. People like Dave Garlan, Mary Shaw, and Paul Clements are doing good useful work; it's just not directed to figuring out what architects do rather than what their work products should be.) Len Bass has started doing something along these lines, and I have a paper in preparation. (You can read some good stuff about architecture here.)
The problem isn't that people program to "black boxes" though: in fact, you have to manage designs with abstraction at any time, and in an embedded system you invariably end up working with black boxes as well. For example, do you do an FFT in a DSP chip, do you implement it in a general-purpose processor?... not to mention really weird things, like using an FFT in a DSP to implement a matrix multiply for graphics. (Sounds weird, works good.) The problem is that people are being trained to think that they can choose any kind of black box and expect non-functional issues to be handled by Someone Else.
In all my years using java I have *never* needed dynamic classloading in my apps.
This suggests you've effectively been writing C in Java, rather that writing Java.
Most every realistic application in Java either uses dynamic class loading directly using Class.forName(), or does it under the covers in a bean container, J2EE, or the like. Or should.
I used to get called out to customer sites to help with Java memory problems fairly often (and believe me, nobody hires a $375/hr Sun consultant for a one week minimum engagement unless they're desperate) and I never once saw a memory-leak problem that wasn't due to a programming error.
You're right, it CAN be made to work. It ain't easy. It's a little easier now with ANSI C and "pedantic" on in GCC, but a lot of us still remember idioms like the old BSD trick of depending on address 0 containing 0. And you tell me what the value of i will be when the below terminates (assuming it does terminate) without knowing what the underlying hardware architecture is.
You're mising something (which is admittedly not a technical point, and also admittedly is something I know about because I saw it in person) --
The point of the memo wasn't to complain that they want to use java but the JRE sucks, it's that they don't want to use java because they'd rather stick with C. It's a continual problem within Sun, which the Solaris JRE issues only serve to inflame.
Get a look at J2ME (the "micro edition"). The J2SE model for the JVM classloads a load of stuff, eg all of java.lang.*, before it interprets the first word of your program. The JVM instruction set could be implemented minimally in a really tiny program, say with threaded-interpretation.
(There's an idea: writing a JVM in Forth.)
Anyway, the Micro-Edition lets you have a lot more control over just what is loaded through "profiles", and can be reduced to a much smaller footprint.
It's very common within Sun as a way to express "we use our own products." I always used to rephrase it "we eat our own cooking" because I thought it wasn't a very pleasing image to suggest we had our customers eating dog food.
Slashdot Mirror
No kidding this is the conclusion they just came to on Fox News.
John ALan Paulos was right.
He was pretty sensible for an abused lifetime virgin in the 17th century.
On the other hand,
can be written in 30 seconds, where the equivalent C code would take all afternoon. A C program that evaluates just that one finite state machine will run at least an order of magnitude faster than grep will
To a first approximation, the time it takes to write a program is proportional to the number of lines of code in the solution, whether you're writing assembler or perl. The cost of a program is directly proportional to how long it takes to write it. So if you're going to opt for a compiled language over a "scripting" language, you should be sure that the additional cost is justified by the gains that come from performance.
In an awful lot of cases, it just isn't.
Maybe you do "gotta say" that, but you'd be wrong. As we discussed above, if the key length is less than the message length there will be some difference between pure noise and your signal.
Because genes are more complicated and more thoroughly mixed than that. You might as well ask if being able to spell "environment" is purely genetically determined.
No one is suggesting that personality is completely genetically determined, any more than anyone is suggesting that anyone is suggesting that ability to spell is completely determined by environment -- and thus any cat can learn to spell.
Similarly, an encrypted signal should appear to have very little redundancy, because the closer to "white" it looks, the less statistical information there is to attack.
Your point about the code table is also good. We tend to forget as computer geeks that there is another kind of encryption besides a cipher, which is a good old fashioned code. That is, the construction of an ARBITRARY table of correspondences between some random code group and some desired message. This would be like
(It used to be in Europe that you could tune across the shortwave and find a voice reading five-digit code groups out in German for just hours. I don't know that I ever heard authoritatively what that was, but it's odds-on that it was traffic from the East German stazi or from the Soviets to "moles".)
Obviously, a real code has the possibility of very great compression
If you were to, say, Huffman-compress a message and could transmit the code table separately (and securely) the result would be pretty hard to read directly. (That still wouldn't make a good code, because it would be too easy to use statistical information about letter distribution in English to work backwards.)
Yeah, what he said. It was a long day.
No need -- that explanation makes perfect sense. "...it's impossible for information theoretic reasons" is what I meant, but I was trying to be nice.
Here's a partial answer:
(1) there is always the possibility that you simply won't. In fact, a properly used one time pad cipher is indistinguishable from noise. It's also a major pain in the ass to use, because you must somehow transmit as many bits of key as you want to send bits of message, and your one-time pad is only as good as your method of transmitting the key.
(2) If there is some kind of message in the signal and a cipher is involved other than a one-time pad or something isomorphic to one, then there will be some degree of redundancy in it. This is a theorem of information theory. Statistical measures will eventually reveal that the redundancy exists.
(3) At that point, there are lots of approaches. A good readable and interesting introduction to these, along with the history of such things, is David Kahn's The Codebreakers. Bruce Schneier's Applied Cryptography is a good, more technical introduction for the computer geek. I've also heard good things for Handbook of Applied Cryptography as well, but I don't actually know the book.
But as someone notes above, it's an inherently hard problem to simply identify the cipher, and modern ciphers like RSA are, as far as we know, computationally intractable because the only known attack requires factoring a very large prime number.
(4) You give up and hire a pretty young woman to talk the marine guards into letting you at the code room. (Details of this approach are left as an exercise for the interested reader.) Sometimes the old fashioned ways are best.
No, you're confused, or we're having a terminology problem. The distinction between infix and prefix is seen most easily in the way things associate, and a add: b associates (as all SmallTalk does) purely to the left:((a add:) b). It looks a little confusing because the 'add:' is in some sense not the 'message', it's the message selector.
Or you could think about it purely in terms of the grammar. My mind goes blank on the exact terminology for SmallTalk (it seems they named a couple of things oddly) but basically, the grammar comes out to be simply left to right, which is the same as prefix, which is the same as Polish, etc.
One of the rather brilliant things about McKay's (et al) original insight with OO was that by treating the things that look like operators as message selectors on the left-hand object, you get something that parses purely left-right -- ie, prefix -- but still reads infix. (Or almost -- like APL in the Old Days, you can occasionally get into trouble by forgetting there's really no precedence.)
(PS. Sorry for the delayed response -- was away for a while.)
Hey, you can make up a better excuse than that. For example, I'd assumed you'd worked it backwards from 800 ms -- without subjecting myself to long division, it's of the right order of magnitude. Um, er -- yeah, 430 millisec one way, 860 millisec round trip time ... see, that must be what you did. Right? ;-)
Mild quibble: a geosycnhronous satellite is only about 18,000 miles "up" -- geosynchronous orbit is 22,300 miles from the center of the Earth, and one Earth radius is about 4,000 miles. But I've observed the ping time to be 770 +/- 35 msec in a configuration that I was trying to work with. (There's a lot of other delay in there in things like the signal processing of the very low level signal.) Thus the basic point is correct, even if the arithmetic is wrong.
anObject -- the target eats up the next argument
getsMessage: -- is the message
-- which then eats the next two atoms
withArgument
andAnother
-- getsMessage is full
. -- means we're done.
Compare that to a LISP version, say(Of course you end up needing to have sort sort of selector on the CAR of the second argument -- don't bother, CLOOPS is easier.)
To be fair, though, it's true that there is some infix syntactic sugar in SmallTalk: for example
a + b
is an alias of
a add: b
Okay, that's fair -- but it wasn't clear from the context. But (at least with modern hardware) Java is no worse than most things. (Check was a Windows executable actually needs once it links all the dll's.)
If physical memory limits are an issue, you shouldn't be using J2SE; everything from the GC model to the way that it loads everything in the universe and six other libraries is unsuited for it. Use J2ME and establish the profile you really want.
The short answer is "yes and no". Of course.
... not to mention really weird things, like using an FFT in a DSP to implement a matrix multiply for graphics. (Sounds weird, works good.) The problem is that people are being trained to think that they can choose any kind of black box and expect non-functional issues to be handled by Someone Else.
In fact, it's worse than that because the common mythology is that you shouldn't consider any non-functional requirements until you're finished with the code -- as expressed in the common idea that you should defer optimizing for performance until the very last step in development.
Everyone with more than about 20 minutes of experience knows this isn't the way it's really done -- if it were, then every web system would be built first as one big honkin' monolithic program, and refined from there. Instead, we make lots of decisions (like use J2EE or not, distribute the servers or not, use an in-memory DBMS or MySQL, and so on) very early, in order to get somewhere close (we hope) to a system that does what we need.
We call this "architecture" and in general we don't teach it in school. This is in part because it's not very well understood as a discipline, IMAO because research in architecture has concentrated on representations rather than methods. (This is not to say that it's bad, don't mistake my point. People like Dave Garlan, Mary Shaw, and Paul Clements are doing good useful work; it's just not directed to figuring out what architects do rather than what their work products should be.) Len Bass has started doing something along these lines, and I have a paper in preparation. (You can read some good stuff about architecture here.)
The problem isn't that people program to "black boxes" though: in fact, you have to manage designs with abstraction at any time, and in an embedded system you invariably end up working with black boxes as well. For example, do you do an FFT in a DSP chip, do you implement it in a general-purpose processor?
In all my years using java I have *never* needed dynamic classloading in my apps.
This suggests you've effectively been writing C in Java, rather that writing Java.
Most every realistic application in Java either uses dynamic class loading directly using Class.forName(), or does it under the covers in a bean container, J2EE, or the like. Or should.
However, you're hardly alone in this.
Clearly you've never actually seen what real fascism is like.
I used to get called out to customer sites to help with Java memory problems fairly often (and believe me, nobody hires a $375/hr Sun consultant for a one week minimum engagement unless they're desperate) and I never once saw a memory-leak problem that wasn't due to a programming error.
You're right, it CAN be made to work. It ain't easy. It's a little easier now with ANSI C and "pedantic" on in GCC, but a lot of us still remember idioms like the old BSD trick of depending on address 0 containing 0. And you tell me what the value of i will be when the below terminates (assuming it does terminate) without knowing what the underlying hardware architecture is.
Exactly. Scott's trying to kick MS's ass, not his own.
You're mising something (which is admittedly not a technical point, and also admittedly is something I know about because I saw it in person) --
The point of the memo wasn't to complain that they want to use java but the JRE sucks, it's that they don't want to use java because they'd rather stick with C. It's a continual problem within Sun, which the Solaris JRE issues only serve to inflame.
Get a look at J2ME (the "micro edition"). The J2SE model for the JVM classloads a load of stuff, eg all of java.lang.*, before it interprets the first word of your program. The JVM instruction set could be implemented minimally in a really tiny program, say with threaded-interpretation.
(There's an idea: writing a JVM in Forth.)
Anyway, the Micro-Edition lets you have a lot more control over just what is loaded through "profiles", and can be reduced to a much smaller footprint.
It's very common within Sun as a way to express "we use our own products." I always used to rephrase it "we eat our own cooking" because I thought it wasn't a very pleasing image to suggest we had our customers eating dog food.
Yes, to both. I'm sure that memo was from developers to their first or second level manager, or to a project manager.