An Appeal to Moderators... not a question
on
Ask Larry Niven
·
· Score: 4, Insightful
Moderators: These interviews are probably the neatest thing Slashdot does. Please only moderate up actually interesting questions that can't be answered with a quick Google search, a read through his (excellent) work, a few moments thought, or a handful of words ("Yes, I do like to write.").
I particularly recall the Dave Barry interview where it seemed like half the questions were pathetic attempts to toss him a straight line, rather then really interesting questions.
I think these are the most "importent" moderations you can do on Slashdot, as they are the only ones that have any real effect on the world. Please consider them carefully.
Again, this is not a question so should this happen to get modded highly please do not forward;-)
Programming right now is an activity that requires huge amounts of context to produce good output. Just being distrubed can cost big. Splitting the context in half will cost, it will not benefit.
Programming is an extreme problem, though. Some things, like "getting from here to there" requires much less context. You routinely set out on journeys with incrediblely incomplete amounts of knowlege regarding the conditions of your path. Sometimes you end up taking alternate routes because of obstructions. Compared to the amount of context maintained while programming, you set off to your destinations almost blind.
Only some problems can be "swarmed", mostly where there's some form of reinforcement that can be used. "Getting from here to there" is a great, obvious example of that, with the phermone trails reinforcement. On the other hand, the whole point of programming and its great attaction to me is the desire to never do the same thing twice, almost the exact opposite kind of problem. ("The number one sin of programming is code duplication." - me.)
This is slashdot, not your personal research desk. Do your own research. Yeah, it's a little more complicated then I mentioned; it's a rule of thumb, but a good one.
Funny you should say this, because as I'm reading your post, I see nothing but lots of anecdotal evidence.
No shit. You didn't read it real carefully, did you? You read into it what you expected, and completely missed the point.
What do you want me to do, post my program, tell you how long it took me to write, and then write it in Java for your personal pleasure? You obviously have no experience in both environments. I do. If you want something better then anecdotal, go get it yourself. If you're not willing, then frankly, shut up, you're not in a position to comment on the relative merits of things you haven't tried. If you refuse, good, one more programmer who can't seriously compete with me in value.
I'd challenge anybody to come up with a problem that could be solved within a few hours in Perl or Python that couldn't be solved within 2 or 3 times that length of time (longer, but not "weeks") by a competent C or Java programmer.
You issue a challenge where you will never accept the answers, because you can always argue that a C++ programmer could theoretically beat that time. And you'd be right, because the well-documented LOC difference for significant programs between, say, Java and Python is on the order of 5 to 10. In theory, if both programmers program perfectly correctly, the Java programmer will only take 5 to 10 times as long, because that's how much more typing they need to do. Thus, you'll never be satisfied with the answers, because you can always counter-argue, and in the absense of experience you can always counter with another anecdote, or accusations of incompetence in the programmers use of C++ or Java.
However, I'm not going to argue on your terms. Instead, I simply say this: In the experience of people who have used both, Python or correctly-used Perl (which, BTW, tends to look pretty Pythonic if you want it to be maintainable) does indeed give advantages on the order of 10 at the minimum, usually more. I find the advantages multiple exponentially as the product gets larger; to lay my cards out on the table, I believe that most conventional applications, even ones sized in the multi-megabytes, should be written in "scripting" languages*.
I'll briefly justify this by waving my hands in the direction of the well-known facts surrounding how many lines of code one programmer can produce and maintain, and point out that the effects are exponential as each module requires fewer lines, but it's handwaving and any Slashdot comment, which can't be book sized, must consist mostly of hand-waving. So instead I offer this challenge: Based on people's experiences (LOTS of people's experiences; just search on groups.google.com through comp.lang.python, for instance), and based on this LOC justification, try Python for a good six months, on something serious. Do your own research.
Worst case scenario, you learn another language which might expose you to a few idioms you didn't know before. Best case scenario, your effective productivity multiplies, which will easily pay back the time you put into it. I can't prove this for you, you can only learn yourself.
*: And I'm putting my money (well, "time", but time is money) where my mouth is. I have a large application I'm building, all in Python, and while it's not done, I've only spent my spare time on it and the parts that are done are ahead of all the competition I've looked at so far, almost all of which are done either in conventional languages, or someone who is still writing Python as if it were a conventional language. This also includes, in terms of capabilities, my knowlege of the commercial competition, certainly written in C/C++. There are some parts where it would be a full time job to replace a single component in C++ for a whole (person-)month because of the time-sink that strong typing can be in certain situations. (See "Design Patterns" for examples; many of those patterns are ways around type prisons.) Again, in theory somebody could type it in directly, correctly, in one or two days with no mistakes, but we all know it doesn't work that way. C++ requires a lot of debugging. If I were trying to write it in C or C++... well, frankly I would have given up, as I'd never finish it this decade on my own, no matter how 'leet I am at C++. I like C++ for what it is... but it's so... clumsy.
Re:Reminds me of a physics article
on
Game Theory at 190mph
·
· Score: 4, Insightful
No, I think the article has a good point. It's challenging to come up with another popular sport where cooperation with the opponents is necessary to win. (Emphasis "popular"; yes, I too can reel off video games and odd-ball sports where that's true too, but they don't preempt Futurama to death on Fox.)
Using as a guide what the networks, including ESPN will run (even late at night): Basketball, baseball, soccer, football, tennis, golf, hockey, billiards, chess, various "slam-dunk" style contests, strongman/American Gladiator-type competitions, convention human/bicycle/boat racing, every Olympic event I can think of (though one or two may fit the bill, it's hard to remember them all), the list goes on. None of these things involve cooperation with oppenents. About the only thing I've ever seen on ESPN that might fit the bill is some wierd moves in Poker that might be based on unspoken alliances, but I'm just speculating and that's not as obvious as it is in NASCAR.
In fact I'm not a NASCAR fan but this does give me a new respect for the sport.... interestingly, based on this article I now mentally classify NASCAR as next to Poker, requiring psychological manuevering, "social capital", and some luck (in the form of good pit crews, along with traditional luck) to win. I guess only a game theorist could stick car racing and poker "closer together" then car racing and bike racing and consider it perfectly logical...
the books won't suddenly turn into dust just because there's a new version out.
Fortunately, DRM systems will close this gaping hole in the future. Thank God for Palladium and friends!
(and because there are morons, yes, morons who read Slashdot, "</sarcasm>". If you didn't realize that this message was sarcastic until you read this paragraph, I'm talking about you.)
It may seem obvious, but if you can run the program under Linux in Wine, you can export the display anywhere you want it to go. Don't recommend it for games, but I did it once for a "real application" over my LAN once, just to try it, and it works fine.
Of course Wine doesn't run everything, but my experience is that if it does run something, it runs it stably. Try both wine and winex (the latter even if you aren't trying to run a game, I've had mixed experiences with both), and if it runs the app(s) you're looking to share, you're "done".
I know it's not perfect and I know it's not quite what you're looking for, but sometimes you have to take what you can get.
When you have less data then a smallish key (and that message has no more then 28 * 8 = 244 bits, probably much less), the data can (most likely) decrypt to anything at all with the proper key. If that's all you really have, then you need to pursue non-code-breaking methods of finding out what that is.
And of course what to do next depends on the characteristics of that more data. A lot of cyptoanalysis assumes you have knowlege of the encryption method; this is because it's "easy" to obtain by reading code, but "easy" is a relative term. It's easier then just guessing, but still hard. Without knowlege of an algorithm, you need to luck out and hope they used one with a distinct signiture. If they didn't, you're probably basically out of luck on a single person's resources, because all of the "good" algorithms should be effectively indistinguishable from noise after encryption.
Ditto on the other three replies as of this writing pointing out that the construction industry is far from paradigmatic, but also:
Do you think that GM people stand around and talk about Extreme Engineering for their engineers who design high tech engines?
Actually, while I'm sure it wouldn't be called "Extreme Engineering" I would not be surprised that they take a bit more experimental approach to engine design, now that it's all in a computer that can reasonably accurately simulate the effects of various design choices.
Times have changed in the automotive industry. The "waterfall"(-analog) model in the "old days" was forced on them, with an engine design and a few prototypes at best before shipping. Now an engineer can change one component and find out what happens. I suspect they don't use the "waterfall" either anymore, in favor of something a bit more "agile".
You don't run unit tests at run time! You run them before you ship.
Sure, if you like you can give the user the option to run them, but it's not like you just write the tests, never run them, and ship them. (It's certainly a great diagnostic to allow the user's to run them.)
The point is not to see errors at "compile time"; that's just defining the win for static typing on an irrelevant point. The point is to see the errors before the system is put into production. Unit testing will catch the type errors and a whole hell of a lot more.
Sorry, but that's spoken like someone parroting the party line, not someone with experience in both.
Strong typing allows mechanical type checking via compilers and incremental type checkers during the development process.
OK, but A: it only allows type checking and B: it enforces type checking.
A: Type consistency is not a guarentee of correctness. It's not even close to a guarentee of correctness. It's not even more then loosely related to guarentee of correctness. Type 'errors' are only one class of error, and they are detectable in both paradigms, just at different times. Don't skip the focus on "unit-test based testing"; the point of unit-based testing is that it tests for any kind of error you can program a test case for, including type errors, wrong-output for input, environment interaction, and all the other kinds of non-type errors that happen in real life. Unit-test based programming says why pay so much for such a weak guarentee of correctness when you can spend that time writing unit tests and test for useful properties?
Note that XP calls for unit testing in all languages, not just dynamic ones. You need to be writing them anyhow; why not lean on them and keep your program flexible and tested correct, rather then "proven type correct"?
B: It enforces type consistency. How many times have you wanted to jump out of the type cage? When programming in a dynamically (not really 'weakly') typed language, it encourages an "interface based" style. If you implement an object that has all the necessary methods, and it'll work right, why shouldn't you be able to use it just because it's not the right "type"? Many, many things in Python present a file-like interface, or a string-like interface, or a sequence-like interface, without having to inherit from the official implementations which may be very wrong for their purposes. And many other parts of the language do that too.
And guess what? Even in large programs, the world does not come to an end. See unit-testing, although even without that it's still usually OK.
Because the interface style pervades the whole language, you get to easily write programs that can handle certain types of "type" violations without blowing themselves to smithereens like you might expect if you've never tried it before.
On the other hand, since it is not possible to mechanically check weak typed code, weak typing places much more load on the programmer to make sure the types are correct than a strongly typed system.
Two more things:
One, my experience and the experience of a lot of others says the opposite. You spend an unbelievable amount of time jumping through compiler hoops in a static typed language, and sometimes the smallest change cascades down your entire static hierarchy. You spend a lot of time worrying about things that really aren't importent in the grand scheme of things. Half the time if you're trying to write with any sort of flexible pattern like Iterator or something you end up with a superclass called "Iterable" or "Object" (sound familiar?) or some equivalent, which isn't that far from dynamic typing anyhow.
The other thing is again, "mechanically checking" code isn't possible for anything but type-correctness. No other goodness properties can be checked that way; in fact Rice's theorem proves no non-trivial property of programs can be proven mechanically. (This implies type correctness is not an interesting property;-) )
If type safety could give me something above and beyond type safety, I might be interested. But all it does is "prevent" a class of problems that don't exactly plague most coders anyhow. It's an incredibly steep price to pay for something that doesn't do much for you.
I've experienced both sides of this. Sure, in theory type checking is great, but in practice, the dangers of type errors are incredibly exaggerated. It's just not a problem. It's too late to convince me with theory that has completely failed to play out the way the the type-safety advocates said it would.
The last two books, which are basically one large book split into two pieces, "Heretics of Dune" and "Chapterhouse: Dune" are the best books in the series, which you didn't even mention. It takes place thousands of years after God Emperor and kicks ass in much the same style (though not in the same ways) as the original Dune. After the claustrophobia of the fourth book, the universe in the fifth and sixth book is too large for even any of the characters to understand.
If you're going to sit through God Emperor, at least get the payoff of reading the last two.
Are there (m)any embedded applications that A: are so starved for speed that running in the cache could make a difference and B: fit in 640Kb, including data?
Honest question; it's a nifty idea. Thinking inside the (CPU) box.
Oh come on... haven't you figured out by now that all new chips start expensive, and in a year are the bottom of the barrel, bargain basement, can't buy anything slower deals? And that all top-of-the-line chips are a marginal improvement for way too much money?
Do you know what bottom-of-the-barrel is right now? It's like an Athlon 1800+ depending on where you shop. (Gee, I was just in there last week and they were still selling 1.2GHz Durons...) Do you know how much an Athlon 1800+ cost when it came out? Do you really think this price is permenent?
What's the alternative? Never introduct a chip until it's cheap? Doesn't work that way, for a whole lotta reasons.
Why would they bring those up, and then within a sentence or two, mention Python. From what I understand, Python is mainly used for server side scripting. I doubt anyone uses Python for serializing anonymous inner-classes!
No, Python is used for everything that a general-purpose language is used for, except anything best done in C is stuffed into C extensions. The exceptions are of course the standard exceptions for C, which basically owns systems programming. (The need for fast, tight code in Python is done by embedding C; see the Numeric extension which provides many very fast number operations comparable to anything else, because the operations are in C.)
In general, Python has no need for anonymous inner-classes; anonymous inner-classes are a worthless hack in Java to provide things that should be provided through any number of other good mechanisms, and even then they only partially and frustratingly succeed. Don't take my word for it, take jwz's word for it (do a find for "mind-blowing worthlessness of inner classes", for instance, though it comes up several times as he mentions the lack of several better solutions).
Inner classes, as implemented in Java, are an atrocious idea and I know of no other language, including specifically Python, that doesn't have at least one inherently superior mechanism for doing that stuff, and most have multiple. (Even Perl has closures!) Thus, they have no need for what Java means by 'anonymous inner classes'. (Inner classes can exist in Python, but they have so many more capabilities that it's not even close to comparable, and I only need them when I'm dynamically generating classes anyhow.)
On the one hand, I'd say have a look at some of these other languages and use them enough to understand the idiomatic uses of the capabilities in those languages. On the other hand, I don't suggest it, as you may find it very difficult to program in Java again after you are done. Java is not a language designed to empower the developer.
That, and I don't believe we even have any existing technology to simply capture a collection of mixed radio signals and somehow (digitally or analog) store them...
Sounds like what radio telescopes do, and what SETI@Home analyses.
That said, the bandwidth is obscene (as you mentioned), the TiVo hasn't got the processor power to handle that much data (even the lowest scale cable subscription). I didn't do the calculations but I'm pretty confident that even if the TiVo did have the processor power, the hard drive would not be able to write more then five or ten channel's data at a time. And even if it could, the amount of data would overwhelm even a hacked TiVo with a hypothetical terabyte of hard drive space. (I don't think they've been hacked that high but I could be wrong.)
Guestimate such a drive at a thousand hours (1 Hr. = 1GB or so; it's not perfect but who cares?) and call the cable subscription about 70 channels at the least (that's what I get here w/ Basic Only), and you're looking at a whole 14 hours of storage. (Coincidentally that's how much my 1st-gen TiVo stores of just one channel...;-) ) Real drives are of course smaller and many people have more then 70 channels.
You could certainly build a machine capable of doing this but I'm guestimating you're getting into the tens of thousands of dollars to aquire the processor power and the massive RAID-like array needed to compress the stream to a decent size, not to mention the price of the memory bus that can move that much data around. Again, radio telescopes do this stuff so I know it must exist somewhere... but if it's rare enough, the fees associated with the fact that it's a custom solution every time could start pushing you into the hundreds of thousands or millions+ to build a box that just eats the cable signals and stores some decent amount.
(You can shuffle some of the cost by changing the specs of the system, such as needing less processor power if you don't compress, but then you need to spend more on the drive array to up the throughput. If you're on a DirecTV service, all the data is already compressed but you're still going to spend a lot of money on that drive array.)
In conclusion, do not hold your breath expecting to see this in consumer electronics anytime soon.
Surely at some point the provisions restricting judicial oversight become a slam dunk case for overturning due to fact the Constitution laid out the judicial system? Frankly, I thought the first Patriot act went overboard with that. Congress can't just tell the Court system to go stuff it.
I also don't understand why... well, I do, but for rhetorical purposes let's say I don't... the need for security necessitates less oversight by the court system. Once you've got the guy in custody, what's he going to do to the country while rotting away in jail waiting for judicial review? Is Congress seriously concerned that the judge is going to just let a criminal go? They're not in that business, assuming the government has enough evidence to back up their case. Oh, hey, think maybe the government wants the right to make wild accusations?
Sometimes, for laws like this, I wish you could bring a case before the Supreme Court for judicial review without an actual complainent. I understand the reasoning for not allowing this and generally agree with it, but in cases like this it's sad you have to wait for someone to be screwed over, and willing to spend years of their life fighting back, before the law might be overturned.
Oh, and it's not contradictory: The point of the essay is software will never be 100% intuitive... but that doesn't let people off the hook today for gratuitously making stuff harder to use and thinking their somehow justified.
Ease of use and power are inversely proportional. If you increase ease of use you decrease power.
No. Under optimal circumstances, ease of use and power are inversely proportional.
If you've already made a given piece of software the optimal (or close to optimal) UI, then yes, adding another capability implies another preference, or another menu option, or icon, or something, that by its very existance will complicate the interface. It can also complicate things if it interacts with other features.
However, for the vast majority of programs, this is a completely, utterly useless bit of information, because they aren't even close to optimal UI. (Or optimal power for that matter.) Thus, the "inverseness" doesn't hold in practice for most software. Pick a random program from, say, debian (just to pick from a pool of programs), and the odds are that it can be made more usable and more funcational, generally by removing or further suppressing odd or unused preferences and making common use profiles easier to set up and use, even with the additional features.
I tell people every day to build their own computers, and they have this fear they will mess it up, or that its difficult. In fact it is no more difficult that putting together a set of legos. Square peg and square hole. If people stop fearing computers and begin to believe they are simple, then people will have an easier time learning them.
Mmmmmmm... it's gotten better that way but there's still too good a chance you'll buy a Via motherboard and a Soundblaster Live!, to cite one example I have personal experience of of incompatible hardware. If you're lucky everything pretty much just works nowadays, especially with Windows XP, but if they get in trouble they will have no where to turn. (In fact just establishing that Via and Live!'s don't get along took a lot of my time, and I'm reasonably good with these things.)
The method of teaching computers sucks. People learn processes, click this, click that, then click this.
Well, up to this point, I've been defending the users, but I'm going to defend the trainers a bit. Having been on the training side a little, I can attest that the users have no interest in learning concepts, on average.
Probably because, as the article says, they've been burned too often by obscenely complicated, inconsistent, poorly-thought-out (if at all) "concepts" behind their software. It is not fair to ask the users to understand their systems as well as I do, yet software expects that all the time. No wonder people are burned out.
Damn. I was really hoping to see a post from CleverNickName saying "Personally, I'd vote for 9." on the grounds that it would, of course, be the most fun to tape... >;-)
Patience. "Lord Bitman", a 15-year old's internet moniker if I ever heard one, will probably look back on this conversation and cringe himself one day, if he remembers it.
If you haven't seen the advances then you haven't been looking. The recent sudden jump to hundreds of gigabytes on the cheap, for instance, is AFAIK the result of this IBM research. Yes, that article talks about 16.8 GB drives but that was just the first one available under that technology; I believe it is used in all high-capacity drives now.
There is no real marketing benefit to describing the real tech behind such devices, only assigning them buzzwords and hyping them up, so you only see stupid buzzwords.
The computer industry is actually very good about getting major advances in the hands of consumers on a time scale measured in months after the practical advances are made.
Slashdot Mirror
Moderators: These interviews are probably the neatest thing Slashdot does. Please only moderate up actually interesting questions that can't be answered with a quick Google search, a read through his (excellent) work, a few moments thought, or a handful of words ("Yes, I do like to write.").
;-)
I particularly recall the Dave Barry interview where it seemed like half the questions were pathetic attempts to toss him a straight line, rather then really interesting questions.
I think these are the most "importent" moderations you can do on Slashdot, as they are the only ones that have any real effect on the world. Please consider them carefully.
Again, this is not a question so should this happen to get modded highly please do not forward
Hopefully this 3000+ year old prior art will prevent somebody from taking out a stupid patent!
Context, context, context.
Programming right now is an activity that requires huge amounts of context to produce good output. Just being distrubed can cost big. Splitting the context in half will cost, it will not benefit.
Programming is an extreme problem, though. Some things, like "getting from here to there" requires much less context. You routinely set out on journeys with incrediblely incomplete amounts of knowlege regarding the conditions of your path. Sometimes you end up taking alternate routes because of obstructions. Compared to the amount of context maintained while programming, you set off to your destinations almost blind.
Only some problems can be "swarmed", mostly where there's some form of reinforcement that can be used. "Getting from here to there" is a great, obvious example of that, with the phermone trails reinforcement. On the other hand, the whole point of programming and its great attaction to me is the desire to never do the same thing twice, almost the exact opposite kind of problem. ("The number one sin of programming is code duplication." - me.)
I stand corrected. ;-)
This is slashdot, not your personal research desk. Do your own research. Yeah, it's a little more complicated then I mentioned; it's a rule of thumb, but a good one.
Funny you should say this, because as I'm reading your post, I see nothing but lots of anecdotal evidence.
No shit. You didn't read it real carefully, did you? You read into it what you expected, and completely missed the point.
What do you want me to do, post my program, tell you how long it took me to write, and then write it in Java for your personal pleasure? You obviously have no experience in both environments. I do. If you want something better then anecdotal, go get it yourself. If you're not willing, then frankly, shut up, you're not in a position to comment on the relative merits of things you haven't tried. If you refuse, good, one more programmer who can't seriously compete with me in value.
I'd challenge anybody to come up with a problem that could be solved within a few hours in Perl or Python that couldn't be solved within 2 or 3 times that length of time (longer, but not "weeks") by a competent C or Java programmer.
You issue a challenge where you will never accept the answers, because you can always argue that a C++ programmer could theoretically beat that time. And you'd be right, because the well-documented LOC difference for significant programs between, say, Java and Python is on the order of 5 to 10. In theory, if both programmers program perfectly correctly, the Java programmer will only take 5 to 10 times as long, because that's how much more typing they need to do. Thus, you'll never be satisfied with the answers, because you can always counter-argue, and in the absense of experience you can always counter with another anecdote, or accusations of incompetence in the programmers use of C++ or Java.
However, I'm not going to argue on your terms. Instead, I simply say this: In the experience of people who have used both, Python or correctly-used Perl (which, BTW, tends to look pretty Pythonic if you want it to be maintainable) does indeed give advantages on the order of 10 at the minimum, usually more. I find the advantages multiple exponentially as the product gets larger; to lay my cards out on the table, I believe that most conventional applications, even ones sized in the multi-megabytes, should be written in "scripting" languages*.
I'll briefly justify this by waving my hands in the direction of the well-known facts surrounding how many lines of code one programmer can produce and maintain, and point out that the effects are exponential as each module requires fewer lines, but it's handwaving and any Slashdot comment, which can't be book sized, must consist mostly of hand-waving. So instead I offer this challenge: Based on people's experiences (LOTS of people's experiences; just search on groups.google.com through comp.lang.python, for instance), and based on this LOC justification, try Python for a good six months, on something serious. Do your own research.
Worst case scenario, you learn another language which might expose you to a few idioms you didn't know before. Best case scenario, your effective productivity multiplies, which will easily pay back the time you put into it. I can't prove this for you, you can only learn yourself.
*: And I'm putting my money (well, "time", but time is money) where my mouth is. I have a large application I'm building, all in Python, and while it's not done, I've only spent my spare time on it and the parts that are done are ahead of all the competition I've looked at so far, almost all of which are done either in conventional languages, or someone who is still writing Python as if it were a conventional language. This also includes, in terms of capabilities, my knowlege of the commercial competition, certainly written in C/C++. There are some parts where it would be a full time job to replace a single component in C++ for a whole (person-)month because of the time-sink that strong typing can be in certain situations. (See "Design Patterns" for examples; many of those patterns are ways around type prisons.) Again, in theory somebody could type it in directly, correctly, in one or two days with no mistakes, but we all know it doesn't work that way. C++ requires a lot of debugging. If I were trying to write it in C or C++... well, frankly I would have given up, as I'd never finish it this decade on my own, no matter how 'leet I am at C++. I like C++ for what it is... but it's so... clumsy.
No, I think the article has a good point. It's challenging to come up with another popular sport where cooperation with the opponents is necessary to win. (Emphasis "popular"; yes, I too can reel off video games and odd-ball sports where that's true too, but they don't preempt Futurama to death on Fox.)
Using as a guide what the networks, including ESPN will run (even late at night): Basketball, baseball, soccer, football, tennis, golf, hockey, billiards, chess, various "slam-dunk" style contests, strongman/American Gladiator-type competitions, convention human/bicycle/boat racing, every Olympic event I can think of (though one or two may fit the bill, it's hard to remember them all), the list goes on. None of these things involve cooperation with oppenents. About the only thing I've ever seen on ESPN that might fit the bill is some wierd moves in Poker that might be based on unspoken alliances, but I'm just speculating and that's not as obvious as it is in NASCAR.
In fact I'm not a NASCAR fan but this does give me a new respect for the sport.... interestingly, based on this article I now mentally classify NASCAR as next to Poker, requiring psychological manuevering, "social capital", and some luck (in the form of good pit crews, along with traditional luck) to win. I guess only a game theorist could stick car racing and poker "closer together" then car racing and bike racing and consider it perfectly logical...
the books won't suddenly turn into dust just because there's a new version out.
Fortunately, DRM systems will close this gaping hole in the future. Thank God for Palladium and friends!
(and because there are morons, yes, morons who read Slashdot, "</sarcasm>". If you didn't realize that this message was sarcastic until you read this paragraph, I'm talking about you.)
It may seem obvious, but if you can run the program under Linux in Wine, you can export the display anywhere you want it to go. Don't recommend it for games, but I did it once for a "real application" over my LAN once, just to try it, and it works fine.
Of course Wine doesn't run everything, but my experience is that if it does run something, it runs it stably. Try both wine and winex (the latter even if you aren't trying to run a game, I've had mixed experiences with both), and if it runs the app(s) you're looking to share, you're "done".
I know it's not perfect and I know it's not quite what you're looking for, but sometimes you have to take what you can get.
Step One: "Aquire more samples."
When you have less data then a smallish key (and that message has no more then 28 * 8 = 244 bits, probably much less), the data can (most likely) decrypt to anything at all with the proper key. If that's all you really have, then you need to pursue non-code-breaking methods of finding out what that is.
And of course what to do next depends on the characteristics of that more data. A lot of cyptoanalysis assumes you have knowlege of the encryption method; this is because it's "easy" to obtain by reading code, but "easy" is a relative term. It's easier then just guessing, but still hard. Without knowlege of an algorithm, you need to luck out and hope they used one with a distinct signiture. If they didn't, you're probably basically out of luck on a single person's resources, because all of the "good" algorithms should be effectively indistinguishable from noise after encryption.
Ditto on the other three replies as of this writing pointing out that the construction industry is far from paradigmatic, but also:
Do you think that GM people stand around and talk about Extreme Engineering for their engineers who design high tech engines?
Actually, while I'm sure it wouldn't be called "Extreme Engineering" I would not be surprised that they take a bit more experimental approach to engine design, now that it's all in a computer that can reasonably accurately simulate the effects of various design choices.
Times have changed in the automotive industry. The "waterfall"(-analog) model in the "old days" was forced on them, with an engine design and a few prototypes at best before shipping. Now an engineer can change one component and find out what happens. I suspect they don't use the "waterfall" either anymore, in favor of something a bit more "agile".
And type checking does how...?
You don't run unit tests at run time! You run them before you ship.
Sure, if you like you can give the user the option to run them, but it's not like you just write the tests, never run them, and ship them. (It's certainly a great diagnostic to allow the user's to run them.)
The point is not to see errors at "compile time"; that's just defining the win for static typing on an irrelevant point. The point is to see the errors before the system is put into production. Unit testing will catch the type errors and a whole hell of a lot more.
Sorry, but that's spoken like someone parroting the party line, not someone with experience in both.
;-) )
Strong typing allows mechanical type checking via compilers and incremental type checkers during the development process.
OK, but A: it only allows type checking and B: it enforces type checking.
A: Type consistency is not a guarentee of correctness. It's not even close to a guarentee of correctness. It's not even more then loosely related to guarentee of correctness. Type 'errors' are only one class of error, and they are detectable in both paradigms, just at different times. Don't skip the focus on "unit-test based testing"; the point of unit-based testing is that it tests for any kind of error you can program a test case for, including type errors, wrong-output for input, environment interaction, and all the other kinds of non-type errors that happen in real life. Unit-test based programming says why pay so much for such a weak guarentee of correctness when you can spend that time writing unit tests and test for useful properties?
Note that XP calls for unit testing in all languages, not just dynamic ones. You need to be writing them anyhow; why not lean on them and keep your program flexible and tested correct, rather then "proven type correct"?
B: It enforces type consistency. How many times have you wanted to jump out of the type cage? When programming in a dynamically (not really 'weakly') typed language, it encourages an "interface based" style. If you implement an object that has all the necessary methods, and it'll work right, why shouldn't you be able to use it just because it's not the right "type"? Many, many things in Python present a file-like interface, or a string-like interface, or a sequence-like interface, without having to inherit from the official implementations which may be very wrong for their purposes. And many other parts of the language do that too.
And guess what? Even in large programs, the world does not come to an end. See unit-testing, although even without that it's still usually OK.
Because the interface style pervades the whole language, you get to easily write programs that can handle certain types of "type" violations without blowing themselves to smithereens like you might expect if you've never tried it before.
On the other hand, since it is not possible to mechanically check weak typed code, weak typing places much more load on the programmer to make sure the types are correct than a strongly typed system.
Two more things:
One, my experience and the experience of a lot of others says the opposite. You spend an unbelievable amount of time jumping through compiler hoops in a static typed language, and sometimes the smallest change cascades down your entire static hierarchy. You spend a lot of time worrying about things that really aren't importent in the grand scheme of things. Half the time if you're trying to write with any sort of flexible pattern like Iterator or something you end up with a superclass called "Iterable" or "Object" (sound familiar?) or some equivalent, which isn't that far from dynamic typing anyhow.
The other thing is again, "mechanically checking" code isn't possible for anything but type-correctness. No other goodness properties can be checked that way; in fact Rice's theorem proves no non-trivial property of programs can be proven mechanically. (This implies type correctness is not an interesting property
If type safety could give me something above and beyond type safety, I might be interested. But all it does is "prevent" a class of problems that don't exactly plague most coders anyhow. It's an incredibly steep price to pay for something that doesn't do much for you.
I've experienced both sides of this. Sure, in theory type checking is great, but in practice, the dangers of type errors are incredibly exaggerated. It's just not a problem. It's too late to convince me with theory that has completely failed to play out the way the the type-safety advocates said it would.
The last two books, which are basically one large book split into two pieces, "Heretics of Dune" and "Chapterhouse: Dune" are the best books in the series, which you didn't even mention. It takes place thousands of years after God Emperor and kicks ass in much the same style (though not in the same ways) as the original Dune. After the claustrophobia of the fourth book, the universe in the fifth and sixth book is too large for even any of the characters to understand.
If you're going to sit through God Emperor, at least get the payoff of reading the last two.
Are there (m)any embedded applications that A: are so starved for speed that running in the cache could make a difference and B: fit in 640Kb, including data?
Honest question; it's a nifty idea. Thinking inside the (CPU) box.
Oh come on... haven't you figured out by now that all new chips start expensive, and in a year are the bottom of the barrel, bargain basement, can't buy anything slower deals? And that all top-of-the-line chips are a marginal improvement for way too much money?
Do you know what bottom-of-the-barrel is right now? It's like an Athlon 1800+ depending on where you shop. (Gee, I was just in there last week and they were still selling 1.2GHz Durons...) Do you know how much an Athlon 1800+ cost when it came out? Do you really think this price is permenent?
What's the alternative? Never introduct a chip until it's cheap? Doesn't work that way, for a whole lotta reasons.
Why would they bring those up, and then within a sentence or two, mention Python. From what I understand, Python is mainly used for server side scripting. I doubt anyone uses Python for serializing anonymous inner-classes!
No, Python is used for everything that a general-purpose language is used for, except anything best done in C is stuffed into C extensions. The exceptions are of course the standard exceptions for C, which basically owns systems programming. (The need for fast, tight code in Python is done by embedding C; see the Numeric extension which provides many very fast number operations comparable to anything else, because the operations are in C.)
In general, Python has no need for anonymous inner-classes; anonymous inner-classes are a worthless hack in Java to provide things that should be provided through any number of other good mechanisms, and even then they only partially and frustratingly succeed. Don't take my word for it, take jwz's word for it (do a find for "mind-blowing worthlessness of inner classes", for instance, though it comes up several times as he mentions the lack of several better solutions).
Inner classes, as implemented in Java, are an atrocious idea and I know of no other language, including specifically Python, that doesn't have at least one inherently superior mechanism for doing that stuff, and most have multiple. (Even Perl has closures!) Thus, they have no need for what Java means by 'anonymous inner classes'. (Inner classes can exist in Python, but they have so many more capabilities that it's not even close to comparable, and I only need them when I'm dynamically generating classes anyhow.)
On the one hand, I'd say have a look at some of these other languages and use them enough to understand the idiomatic uses of the capabilities in those languages. On the other hand, I don't suggest it, as you may find it very difficult to program in Java again after you are done. Java is not a language designed to empower the developer.
That, and I don't believe we even have any existing technology to simply capture a collection of mixed radio signals and somehow (digitally or analog) store them...
;-) ) Real drives are of course smaller and many people have more then 70 channels.
Sounds like what radio telescopes do, and what SETI@Home analyses.
That said, the bandwidth is obscene (as you mentioned), the TiVo hasn't got the processor power to handle that much data (even the lowest scale cable subscription). I didn't do the calculations but I'm pretty confident that even if the TiVo did have the processor power, the hard drive would not be able to write more then five or ten channel's data at a time. And even if it could, the amount of data would overwhelm even a hacked TiVo with a hypothetical terabyte of hard drive space. (I don't think they've been hacked that high but I could be wrong.)
Guestimate such a drive at a thousand hours (1 Hr. = 1GB or so; it's not perfect but who cares?) and call the cable subscription about 70 channels at the least (that's what I get here w/ Basic Only), and you're looking at a whole 14 hours of storage. (Coincidentally that's how much my 1st-gen TiVo stores of just one channel...
You could certainly build a machine capable of doing this but I'm guestimating you're getting into the tens of thousands of dollars to aquire the processor power and the massive RAID-like array needed to compress the stream to a decent size, not to mention the price of the memory bus that can move that much data around. Again, radio telescopes do this stuff so I know it must exist somewhere... but if it's rare enough, the fees associated with the fact that it's a custom solution every time could start pushing you into the hundreds of thousands or millions+ to build a box that just eats the cable signals and stores some decent amount.
(You can shuffle some of the cost by changing the specs of the system, such as needing less processor power if you don't compress, but then you need to spend more on the drive array to up the throughput. If you're on a DirecTV service, all the data is already compressed but you're still going to spend a lot of money on that drive array.)
In conclusion, do not hold your breath expecting to see this in consumer electronics anytime soon.
Surely at some point the provisions restricting judicial oversight become a slam dunk case for overturning due to fact the Constitution laid out the judicial system? Frankly, I thought the first Patriot act went overboard with that. Congress can't just tell the Court system to go stuff it.
I also don't understand why... well, I do, but for rhetorical purposes let's say I don't... the need for security necessitates less oversight by the court system. Once you've got the guy in custody, what's he going to do to the country while rotting away in jail waiting for judicial review? Is Congress seriously concerned that the judge is going to just let a criminal go? They're not in that business, assuming the government has enough evidence to back up their case. Oh, hey, think maybe the government wants the right to make wild accusations?
Sometimes, for laws like this, I wish you could bring a case before the Supreme Court for judicial review without an actual complainent. I understand the reasoning for not allowing this and generally agree with it, but in cases like this it's sad you have to wait for someone to be screwed over, and willing to spend years of their life fighting back, before the law might be overturned.
Oh, and I meant to link to my essay Why Software Will Never Stop Sucking, which incidentally shreds the tool metaphor.
Oh, and it's not contradictory: The point of the essay is software will never be 100% intuitive... but that doesn't let people off the hook today for gratuitously making stuff harder to use and thinking their somehow justified.
Ease of use and power are inversely proportional. If you increase ease of use you decrease power.
No. Under optimal circumstances, ease of use and power are inversely proportional.
If you've already made a given piece of software the optimal (or close to optimal) UI, then yes, adding another capability implies another preference, or another menu option, or icon, or something, that by its very existance will complicate the interface. It can also complicate things if it interacts with other features.
However, for the vast majority of programs, this is a completely, utterly useless bit of information, because they aren't even close to optimal UI. (Or optimal power for that matter.) Thus, the "inverseness" doesn't hold in practice for most software. Pick a random program from, say, debian (just to pick from a pool of programs), and the odds are that it can be made more usable and more funcational, generally by removing or further suppressing odd or unused preferences and making common use profiles easier to set up and use, even with the additional features.
I tell people every day to build their own computers, and they have this fear they will mess it up, or that its difficult. In fact it is no more difficult that putting together a set of legos. Square peg and square hole. If people stop fearing computers and begin to believe they are simple, then people will have an easier time learning them.
Mmmmmmm... it's gotten better that way but there's still too good a chance you'll buy a Via motherboard and a Soundblaster Live!, to cite one example I have personal experience of of incompatible hardware. If you're lucky everything pretty much just works nowadays, especially with Windows XP, but if they get in trouble they will have no where to turn. (In fact just establishing that Via and Live!'s don't get along took a lot of my time, and I'm reasonably good with these things.)
The method of teaching computers sucks. People learn processes, click this, click that, then click this.
Well, up to this point, I've been defending the users, but I'm going to defend the trainers a bit. Having been on the training side a little, I can attest that the users have no interest in learning concepts, on average.
Probably because, as the article says, they've been burned too often by obscenely complicated, inconsistent, poorly-thought-out (if at all) "concepts" behind their software. It is not fair to ask the users to understand their systems as well as I do, yet software expects that all the time. No wonder people are burned out.
Ooops, there I go defending the users again.
Damn. I was really hoping to see a post from CleverNickName saying "Personally, I'd vote for 9." on the grounds that it would, of course, be the most fun to tape... >;-)
Patience. "Lord Bitman", a 15-year old's internet moniker if I ever heard one, will probably look back on this conversation and cringe himself one day, if he remembers it.
If you haven't seen the advances then you haven't been looking. The recent sudden jump to hundreds of gigabytes on the cheap, for instance, is AFAIK the result of this IBM research. Yes, that article talks about 16.8 GB drives but that was just the first one available under that technology; I believe it is used in all high-capacity drives now.
There is no real marketing benefit to describing the real tech behind such devices, only assigning them buzzwords and hyping them up, so you only see stupid buzzwords.
The computer industry is actually very good about getting major advances in the hands of consumers on a time scale measured in months after the practical advances are made.