You claim that you've identified an area where it wouldn't work. Now go to the XP site, and observe what project it was originally used in -- a huge, multi-technological one.
I don't think this one's a problem.
Your other objections are also pretty transparent -- they're all of the nature "That's not how we do things here! It's impossible!". Indeed, if management cops that attitude you can't do XP -- but it's an attitude problem, nothing more.
A foundational part of XP is the mutability of code: you write the code for what you know now, and be willing in the future to totally change it. One of the best technical books I've read recently discusses the how-tos of this: "Refactoring" (by the way, the link directs you to a price comparison site which I find REALLY useful).
I tried to use this method is my latest project, a test framework, and I was extremely pleased by the results; not only did the design morph as I discovered the requirements (so the final result was a design I was pleased with), but the final result snapped into place around the item being tested and no bugs have been discovered in it!
I can highly recommend at least that part of XP: refactoring and coding for today. I'm going to try some of the other parts in small bits at a time, but from what I see they look very useful.
I certainly wouldn't describe XP as being for someone who doesn't have time to design; I would describe it as something for someone who doesn't expect to get it right the first time, and who wants to get it right anyhow. I would also describe it as being for someone who wants to be useful to customers without hurting his own productivity -- see the Bill of rights on the Extreme Programming website. In short, XP is about never having to tell a customer that you can't make that change now -- and it's also about always being able to make changes when you need to.
Whether you ask for it or not? Say what? You're completely wrong. Perl doesn't require sysadmin knowledge, whether you want it or not.
Of course not. Read what I wrote. That's not even CLOSE to what I said. Okay, I'll repeat it:
I said that Perl gives you sysadmin tools whether you need them or not. No system programmer would ever use regexps to do his job; they're too general, too slow. System programmers need speed above all else, since they're writing things like device drivers and interrupt handlers. Yet Perl puts regexps out as part of the main syntax of the language. And then there's barewords.
And so on.
All these things are TRES cool for sysadmining, but no system programmer would use them for their job (although everyone has to do a bit of sysadminning eventually).
So as I said, I wouldn't expect a Unix system programmer to find Perl very recognizable, unless he learned it like any other programming language. Perl and Python would therefore be interchangable in such an environment.
I've heard that. I've never believed it. I know only one Unix system programmer, and he HATES Perl.
Perhaps that's true for system administrators, though. Before Perl, they had to use AWK, grep, ed, and many other awkward tools. Perl slaps all those together MUCH better than the Unix command line could.
Even there, though, there's no reason for a programmer to prefer Perl to Python (unless they only know Perl, of course). Their programming abilities are about equivalent, except that Perl throws a lot of sysadmin stuff your way whether you ask for it or not.
Back when Perl had has few users as Python, everyone was nice there, too.
I apologise for the comparative -- I didn't mean it. I was just saying that the Python community is helpful.
I'm rather frightened by the fact that my slip of the pen was correct. I'm sorry about that.
In both cases, popularity destroyed that community.
No offence meant, but look at the size of the Python community. It's by no means as huge as Perl's, but it still gets a lot of newbies. Somehow they all wind up contributing to the community.
Perhaps Perl's and C++'s problems are that they're not easy languages to learn. Perhaps the problem IS the sheer size of the crowd. We'll see. You do have to notice, though, that Perl and C++ are not seperate cases; they're both very complex languages with highly non-orthogonal syntax.
My apologies. That was VERY unclear, and is not what I meant to say.
I meant to say that the Python community is very nice. I've mingled very little with the Perl community, so I have no qualification for calling them meanies;-), and I did not mean to do so.
However, I have mingled with the Python community, and there are some great guys there.
Second, I'd like to ask why a good, pseudo-code, readable language *isn't* more popular nowadays.
It is -- Python is actually quite popular. It's nowhere near as popular as Perl, but its community is well past critical mass (so to speak), and is also much, much nicer.
The definition I'm familiar with is that an enterprise system is one in which a single failure will (in general) cost more than the system itself cost.
In other words, many Linux boxes are already enterprise servers (0.5 wink).
I'm serious, BTW, and I think that's a good definition. What it implies is that you'd better take plenty of time choosing your system, and price is literally not an issue.
I agree with you as far as the BSD license thing goes; I prefer it (and I am a programmer). I like its wide-open nature.
However,
I think that GPL is great for programmers, but I can't see how it can make great business sense
The GPL, IMO, sucks for programmers, because it explicitly limits their right to steal source (note: this is not a criticism of the GPL). The GPL, believe it or not, is actually best for marketers and businesses -- marketers who want to get 'into' the free software movement (good for them!) and businesses who want to get the debugging advantages of open source but who don't want to allow their competitors to use their source to build an exclusive competitive advantage.
What, you ask, about the programmers who like GPL? The answer is simple: we're also marketers. We want to position our product not so that it serves the largest number of needs, but rather so that it serves a long-term goal, the establishment of open software.
A lot of us, BTW, are seriously decieved about the purpose of the GPL -- some even say it's more free than the other licences. It's not, it's merely more practical than the other free licenses, since the other free licenses depend on the community to keep a product free, while the GPL gives the illusory impression that even if the community disappears the software will still remain free.
Foolishness.
-Billy
Re:Can we mod this up till it's over the silliness
on
Can Computers Pray?
·
· Score: 2
Agreed -- that belongs up there, +5 or so.
Religion is a way to cheat at sprituality knowing you'll never have any substance but everyone else will think you do.
OTOH, religion is the (practical) exercise of spirituality/faith. Religion without spirituality is meaningless; spirituality without religion is worthless.
I suspect you mean "organized religion", though. In which case, yes, it's one of the ways to do that. There are many others -- but none of them are bad in their own right. They're only bad when used to cheat.
I haven't seen any compelling size advantage to Forth code, which, by the way, does NOT normally use wordcodes, but uses thread pointers which these days are typically 32 bits.
I have. It's one of the things that just about every Forth programmer touts as the Great Thing about Forth. And yes, I know that most modern Forths use 32-bit cells; in fact, many modern Forths are switching to call threading rather than token threading, because it allows for inlined optimization. This is often an easy choice, because a call for many processors takes up 32 bits anyhow.
Just having the code be 16-bits wide neither allows you to have more primitives (which you can do with multi-byte sequences of bytecode),
At a serious cost in speed.
nor does it "not have as many illegal combinations of primitives". Certainly FORTH allows (even in 16-bit implementations) for a huge number of "illegal combinations".
You're ignoring what I said -- I said that it's possible to design an instruction set which does not have as many illegal combinations of primitives. I didn't say that Forth was it -- of course not. Forth was designed for totally different purposes -- security doesn't even show up on the list.
Furthermore, there is every reason to expect that wordcodes would be larger than bytecodes, since even the most common primitives are forced to use twice as many bits.
That's obvious. What's not obvious is that since there are many more wordcodes, the most common sequences of bytecodes can be encoded in a single, preoptimised, wordcode. This is also how a certain amount of increased security is possible.
If x-codes were fundamentally better for larger x, don't you think people would have noticed that by now?
Why do you think they haven't? I'm not sharing qabbalistic secrets here. Optimising wordcodes is a new science; using them is old.
For equivalent security to that provided by Java, wordcodes would still require a wordcode verifier. The verifier does a whole lot more than check for illegal codes. It has to analyze the code and make sure every possible path results in the same stack depth. Wordcodes don't help with this sort of problem.
Of course. You're absolutely right. All I claimed is that the analysis was less complex. I admit that not only did I not give numbers, though, I don't even HAVE any. To the best of my knowledge, nobody's ever written a security-critical system using wordcodes -- but then Java's the only bytecode-based system I know of.
My preference is to use neither -- I like abstract syntax trees.
Wordcodes are technically just an extension of bytecodes; instead of being 8 bits long, they're longer. A common length is 16 bits.
They're faster and smaller because there are so many more possible ones -- the VM can have many more primitives which are more tailored to the job at hand. They're more secure for the same reason; it's possible to design an instruction set which does not have as many illegal combinations of primitives.
You still need a security manager, of course, but the verifier can be much smaller and quicker.
Secure in what sense?
Secure in the sense that a verifier has to watch for much fewer conditions, and is thus simpler to build. Once you've built the verifier, of course, both systems have the same security.
An example of a wordcoded system is threaded Forth. I don't know whether anyone has made a portable executable format out of wordcodes.
As for java, the language is cool. The VM stuff is equaly cool, though less refined. It will, in time, prove to be one of the most significant computer things of all time.
I didn't used to think this, but I have to admit that the language IS cool. It does lack a lot, but oh well -- so does everything except Lisp.
The VM, on the other hand, is ridiculous. Why did they go and use bytecodes, the single most inefficient and insecure technology out there? Wordcodes would have been faster, smaller, and more secure; abstract syntax trees would have been faster and more secure (smaller in transit, too, but they take more memory to compile than the basic bytecode interpreter).
Yes, it'll have nearly perfect compatibility with MSWord -- WP 2000 is great on my (Windows) system. Microsoft keeps trying to change, but Wordperfect MUST be comatible of it's to survive.
Here in the US we have a _written_ promise of free speech. Our Constitution claims that everyone else has it as well, so you can't say that the UKers don't.
Anyhow, is anyone in the US interested in posting this encryption program on the web? I'm in the US, but I don't really want to spend a few years in jail for exporting munitions.
But we do have free speech, really. Just as long as you don't speak in a way that disturbs politics as usual.
Yes, that's a good solution. The problem is that the normal Palm IR is pretty weak. Read the user testimonials to see the range.
You either have to get an IR extender (fairly cheap and useful) or instead of buying a Palm, buy a Visor. User reports indicate that they have punch-through-the-walls power IR. I have no idea why they'd do that -- but that's WAY cool. Nobody's yet reported a maximum range for remote control (but there are very few people who have Visors yet); the people who have tried gave up after getting out of sight of their devices.
I can think of a use, though. Imagine an entire classroom set up as a distributed network -- during a test.
The *only* part you disliked was him flying off at the end? I'm suprised. The Matrix used comic-book cliche heavily, and usually if you dont' like one cliche you won't like any of them.
Personally, I *like* a well-played cliche -- but IMO it's never enough to hold up a movie on its own. It adds (or subtracts) nothing to my evaluation of the movie.
Matrix held up well because it had a strong plot with unique elements.
I agree that maintaining the qualities of the original is going to be very hard. For one thing, they're going to have to drop the whole "ignorant audience" assumption.
Just a laundry list of potential problems here, followed by my idea of the Right Way to do things. And why I suspect that they're doing something like this.
As others have commented, Neo is already a superman. He can discover his powers, but he's not going to get better.
Keanu can't act -- he has only one expression, confused befuddlement. The director of Matrix used that perfectly. It's not appropriate now that he's superman.
The Matrix's best feature was the Unknown. It's not there anymore. Don't pretend it is!
And now for the promised Better Idea:
Neo's a superman. So, potentially, are the other humans. Okay, fine. Most of the humans in the world are STILL at the back and call of huge AIs. If you anger them, they can eliminate VAST numbers of people without a qualm. In addition, the Matrix itself isn't evil; only the deception is evil. The obvious conclusion is that there is going to be war, followed by either total mutual destruction or a peace treaty which involves teaching everyone about the Matrix.
So, two seqels. One showing the war; the other one showing the negotiations leading to the peace. Neither one can REALLY use the sense of wonder and mystery that the original had, so unfortunately those cool cliches are going to have to go (cliches work well mainly when the overal structure of the movie is a mystery).
I would say that the draw of the middle movie should be conflict (of course). Lots of it. Strategy. Infighting (very little, but on both sides).
The draw of the final movie should be high strategy, politics, and so on. Think of Heinlein's "The Moon is a Harsh Mistress", with Neo playing the part of Mycroft/Mike/Adam.
In both movies Neo should play a bit part, because Keanu doesn't have the acting range to handle such things. the focus should be on humanity freeing itself, not on Superman freeing them (although, of course, he should do just that, in many exciting scenes).
I'm looking forward to these, though. They *could* really screw them up (just as Peter Jackson could screw up Tolkien's LOTR), but then... Maybe they already know that.
Not the same -- Debian _requires_ you to start up dselect. For a new user, dselect is certainly intimidating -- I'm experienced, and I always am hitting the wrong keys.
The advantage for this choice is simply tech support; everyone starts out with the same config. And the tech support and advertizing that this company is already doing is an advantage to all of Debian, doubly so since they use essentially the same software that we do.
That's their value-add -- service. It's the right thing for them to do.
Unlike Corel, they're not ever going to have problems falling behind Debian because they have so many changes.
But hey. I use the real thing:-), and call it by its correct name -- Debian. Good thing they don't keep the real name secret, even though they did choose a new name.
I asked Libranet what this distro was about, and they said that the main thing they changed was to take dselect out of the install and instead give apt-get a list of things to install.
IMO, this is WONDERFUL. These people are adding a lot of value to Debian in general by putting up a first-rate website with responsive service and nice general Linux propaganda.
Add to that the fact that they don't seem to want to create their own code fork, so they'll always be able to keep up with Debian (and vice versa).
I appreciate all that Corel's doing, but in a very real sense they _have_ to do it to make their proprietary system work. Libranet is in a sense much more in line with what Debian needs, because every minute of service they provide is a direct service to Debian itself, rather than some being a service to Debian and some to WordPerfect.
Of course, again, I like what Corel's doing. I just wanted to point out that these guys have their heads screwed on straight as well, and they're actually MORE useful to Debian.
There are reasons it is better to use the GPL for projects that aren't designed to be libraries.
I agree.
For example, suppose I develop a specialized mathematics program. If I release it under the LGPL, it is possible for Wolfram (for example) to rip out the interesting routines and make it into a library. They LGPL their changes to my program, then use that library in Mathematica without my consent or even mentioning that I wrote that code!
They can't do that, though -- your code is STILL under the LGPL, and because they've made changes to it they have to distribute their changed source. It's true that they've gotten the advantage of your library without their software being free, but at the same time they haven't done anything to hurt your library.
So nothing unexpected has happened -- and in fact, I see that as being VERY good. They will fix bugs in your library, and you'll be able to use the bugfixes. You have gained.
What I'm saying is that I've seen plenty of production code (you'll have to take my word), and I've never seen curly braces cause trouble (have to take my word on that, also).
I believe you. I'm just stating that I've been involved in much development, and I see it happen all the time. The only cure is to always use [short and] curlies.
I can picture it happening, though. My point was I think it's unlikely that python has never had the same problem (indeed, I'd be very suprised), and so the unique indention model doesn't really serve any good purpose.
The *purpose* of the indentation isn't to avoid that particular problem. It's twofold: first, to remove a nasty source of style debate; and second, to make code easier to read by making style cues match up with meaning.
It works very well at both.
Oh. You're saying there's software (tabnanny?) available to assist the programmer to make sure such errors do not occur? I guess it has come up, and I don't need to use my imagination.
Nope -- tabnanny was written unwillingly after the insistent demands of people who knew nothing about Python.
(ps. I hit enter before I was done, hence the post and a half. I blame slashdot. perl, rather:)
I could imagine an extra tab causing problems in production python code, just as easily as the curly brace (if you deny the possiblity, you are fooling yourself), so I guess we are even. And that makes your argument just as pointless.
Wait. His argument was that in extensive use he has seen no problems with Python's indentation. How can you rebut that, aside from offering contradictor experience? All you have is a theory that it might impact productivity (and you're wrong about the details of the theory -- the odds of an indentation change actually changing the _meaning_ of the code without being an error is VERY small, and even that possibility can be eliminated by using tabnanny).
He didn't tell you you can't have an opinion; he told you exactly why your opinion is wrong. Which it is. Although I admit he also put a silly title on his post, so I can understand why you'd be annoyed.
To be fair, I have never seen optional braces cause problems in production C or C++ code.
What do you mean by "To be fair?"
How much production C code have you seen? I've seen and written my share, and I have seen the optional braces cause problems in real code. To be sure, it wasn't production code, because we corrected the bug before we shipped it -- but that was just luck (and skill), not any feature of C.
I could imagine an extra tab causing problems in production python code,
As everyone knows, the intelligence of a group is equal to the minimum intelligence of its members divided by the number of members. This point has been proven often enough in software engineering.
Of course, teams are a little different -- that's the only reason we lasted even this long, we had a good team helping us.
If we want to ever do any good, we need a surgical chess team (c.f. Mythical Man Month). And when I say team I don't mean a bunch of people who just met, or met over the web!
Or perhaps this is just the beginning of the defeat of chess -- perhaps it'll be replaced by the One True Strategy Game, Go. Now THAT is a good game.;-)
There have been reports about these before; it seems Intel had released some of the chips without as many NDAs as before, and people had been benchmarking and overclocking them:-).
The higest speed they released was 766; this doesn't mean that the official release won't have higher speeds, of course. And someone overclocked one a little, nothing really impressive.
The Athlon 700 matched a P766 on a 820motherboard in most tests. Of course, the 820mobo is really nice, with 4xAGP and such -- but it's _completely_ unavailable. So expecting a P766 to match an A700 on available mobos is unrealistic.
And, of course, AMD supports 'overclockers' officially, so you can buy K7-900 systems with warrenty intact. I found another place which sells overclocked A750 for the cost of an A600 elsewhere with a lifetime warantee -- and no cooling aside from the ubiquitous fans (they take the cartrige apart and mount a heat sink directly on the chip).
Slashdot Mirror
You claim that you've identified an area where it wouldn't work. Now go to the XP site, and observe what project it was originally used in -- a huge, multi-technological one.
I don't think this one's a problem.
Your other objections are also pretty transparent -- they're all of the nature "That's not how we do things here! It's impossible!". Indeed, if management cops that attitude you can't do XP -- but it's an attitude problem, nothing more.
-Billy
A foundational part of XP is the mutability of code: you write the code for what you know now, and be willing in the future to totally change it. One of the best technical books I've read recently discusses the how-tos of this: "Refactoring" (by the way, the link directs you to a price comparison site which I find REALLY useful).
I tried to use this method is my latest project, a test framework, and I was extremely pleased by the results; not only did the design morph as I discovered the requirements (so the final result was a design I was pleased with), but the final result snapped into place around the item being tested and no bugs have been discovered in it!
I can highly recommend at least that part of XP: refactoring and coding for today. I'm going to try some of the other parts in small bits at a time, but from what I see they look very useful.
I certainly wouldn't describe XP as being for someone who doesn't have time to design; I would describe it as something for someone who doesn't expect to get it right the first time, and who wants to get it right anyhow. I would also describe it as being for someone who wants to be useful to customers without hurting his own productivity -- see the Bill of rights on the Extreme Programming website. In short, XP is about never having to tell a customer that you can't make that change now -- and it's also about always being able to make changes when you need to.
-Billy
Whether you ask for it or not? Say what? You're completely wrong. Perl doesn't require sysadmin knowledge, whether you want it or not.
Of course not. Read what I wrote. That's not even CLOSE to what I said. Okay, I'll repeat it:
I said that Perl gives you sysadmin tools whether you need them or not. No system programmer would ever use regexps to do his job; they're too general, too slow. System programmers need speed above all else, since they're writing things like device drivers and interrupt handlers. Yet Perl puts regexps out as part of the main syntax of the language. And then there's barewords.
And so on.
All these things are TRES cool for sysadmining, but no system programmer would use them for their job (although everyone has to do a bit of sysadminning eventually).
So as I said, I wouldn't expect a Unix system programmer to find Perl very recognizable, unless he learned it like any other programming language. Perl and Python would therefore be interchangable in such an environment.
-Billy
I've heard that. I've never believed it. I know only one Unix system programmer, and he HATES Perl.
Perhaps that's true for system administrators, though. Before Perl, they had to use AWK, grep, ed, and many other awkward tools. Perl slaps all those together MUCH better than the Unix command line could.
Even there, though, there's no reason for a programmer to prefer Perl to Python (unless they only know Perl, of course). Their programming abilities are about equivalent, except that Perl throws a lot of sysadmin stuff your way whether you ask for it or not.
-Billy
Back when Perl had has few users as Python, everyone was nice there, too.
I apologise for the comparative -- I didn't mean it. I was just saying that the Python community is helpful.
I'm rather frightened by the fact that my slip of the pen was correct. I'm sorry about that.
In both cases, popularity destroyed that community.
No offence meant, but look at the size of the Python community. It's by no means as huge as Perl's, but it still gets a lot of newbies. Somehow they all wind up contributing to the community.
Perhaps Perl's and C++'s problems are that they're not easy languages to learn. Perhaps the problem IS the sheer size of the crowd. We'll see. You do have to notice, though, that Perl and C++ are not seperate cases; they're both very complex languages with highly non-orthogonal syntax.
-Billy
and is also much, much nicer.
;-), and I did not mean to do so.
My apologies. That was VERY unclear, and is not what I meant to say.
I meant to say that the Python community is very nice. I've mingled very little with the Perl community, so I have no qualification for calling them meanies
However, I have mingled with the Python community, and there are some great guys there.
-Billy
Second, I'd like to ask why a good, pseudo-code, readable language *isn't* more popular nowadays.
It is -- Python is actually quite popular. It's nowhere near as popular as Perl, but its community is well past critical mass (so to speak), and is also much, much nicer.
-Billy
Grin.
The definition I'm familiar with is that an enterprise system is one in which a single failure will (in general) cost more than the system itself cost.
In other words, many Linux boxes are already enterprise servers (0.5 wink).
I'm serious, BTW, and I think that's a good definition. What it implies is that you'd better take plenty of time choosing your system, and price is literally not an issue.
-Billy
I agree with you as far as the BSD license thing goes; I prefer it (and I am a programmer). I like its wide-open nature.
However,
I think that GPL is great for programmers, but I can't see how it can make great business sense
The GPL, IMO, sucks for programmers, because it explicitly limits their right to steal source (note: this is not a criticism of the GPL). The GPL, believe it or not, is actually best for marketers and businesses -- marketers who want to get 'into' the free software movement (good for them!) and businesses who want to get the debugging advantages of open source but who don't want to allow their competitors to use their source to build an exclusive competitive advantage.
What, you ask, about the programmers who like GPL? The answer is simple: we're also marketers. We want to position our product not so that it serves the largest number of needs, but rather so that it serves a long-term goal, the establishment of open software.
A lot of us, BTW, are seriously decieved about the purpose of the GPL -- some even say it's more free than the other licences. It's not, it's merely more practical than the other free licenses, since the other free licenses depend on the community to keep a product free, while the GPL gives the illusory impression that even if the community disappears the software will still remain free.
Foolishness.
-Billy
Agreed -- that belongs up there, +5 or so.
Religion is a way to cheat at sprituality knowing you'll never have any substance but everyone else will think you do.
OTOH, religion is the (practical) exercise of spirituality/faith. Religion without spirituality is meaningless; spirituality without religion is worthless.
I suspect you mean "organized religion", though. In which case, yes, it's one of the ways to do that. There are many others -- but none of them are bad in their own right. They're only bad when used to cheat.
-Billy
I haven't seen any compelling size advantage to Forth code, which, by the way, does NOT normally use wordcodes, but uses thread pointers which these days are typically 32 bits.
I have. It's one of the things that just about every Forth programmer touts as the Great Thing about Forth. And yes, I know that most modern Forths use 32-bit cells; in fact, many modern Forths are switching to call threading rather than token threading, because it allows for inlined optimization. This is often an easy choice, because a call for many processors takes up 32 bits anyhow.
Just having the code be 16-bits wide neither allows you to have more primitives (which you can do with multi-byte sequences of bytecode),
At a serious cost in speed.
nor does it "not have as many illegal combinations of primitives". Certainly FORTH allows (even in 16-bit implementations) for a huge number of "illegal combinations".
You're ignoring what I said -- I said that it's possible to design an instruction set which does not have as many illegal combinations of primitives. I didn't say that Forth was it -- of course not. Forth was designed for totally different purposes -- security doesn't even show up on the list.
Furthermore, there is every reason to expect that wordcodes would be larger than bytecodes, since even the most common primitives are forced to use twice as many bits.
That's obvious. What's not obvious is that since there are many more wordcodes, the most common sequences of bytecodes can be encoded in a single, preoptimised, wordcode. This is also how a certain amount of increased security is possible.
If x-codes were fundamentally better for larger x, don't you think people would have noticed that by now?
Why do you think they haven't? I'm not sharing qabbalistic secrets here. Optimising wordcodes is a new science; using them is old.
For equivalent security to that provided by Java, wordcodes would still require a wordcode verifier. The verifier does a whole lot more than check for illegal codes. It has to analyze the code and make sure every possible path results in the same stack depth. Wordcodes don't help with this sort of problem.
Of course. You're absolutely right. All I claimed is that the analysis was less complex. I admit that not only did I not give numbers, though, I don't even HAVE any. To the best of my knowledge, nobody's ever written a security-critical system using wordcodes -- but then Java's the only bytecode-based system I know of.
My preference is to use neither -- I like abstract syntax trees.
-Billy
Wordcodes are technically just an extension of bytecodes; instead of being 8 bits long, they're longer. A common length is 16 bits.
They're faster and smaller because there are so many more possible ones -- the VM can have many more primitives which are more tailored to the job at hand. They're more secure for the same reason; it's possible to design an instruction set which does not have as many illegal combinations of primitives.
You still need a security manager, of course, but the verifier can be much smaller and quicker.
Secure in what sense?
Secure in the sense that a verifier has to watch for much fewer conditions, and is thus simpler to build. Once you've built the verifier, of course, both systems have the same security.
An example of a wordcoded system is threaded Forth. I don't know whether anyone has made a portable executable format out of wordcodes.
-Billy
As for java, the language is cool. The VM stuff is equaly cool, though less refined. It will, in time, prove to be one of the most significant computer things of all time.
I didn't used to think this, but I have to admit that the language IS cool. It does lack a lot, but oh well -- so does everything except Lisp.
The VM, on the other hand, is ridiculous. Why did they go and use bytecodes, the single most inefficient and insecure technology out there? Wordcodes would have been faster, smaller, and more secure; abstract syntax trees would have been faster and more secure (smaller in transit, too, but they take more memory to compile than the basic bytecode interpreter).
An example of AST technology is Juice and ANDF.
Yes, it'll have nearly perfect compatibility with MSWord -- WP 2000 is great on my (Windows) system. Microsoft keeps trying to change, but Wordperfect MUST be comatible of it's to survive.
Here in the US we have a _written_ promise of free speech. Our Constitution claims that everyone else has it as well, so you can't say that the UKers don't.
Anyhow, is anyone in the US interested in posting this encryption program on the web? I'm in the US, but I don't really want to spend a few years in jail for exporting munitions.
But we do have free speech, really. Just as long as you don't speak in a way that disturbs politics as usual.
-Billy (hmph)
Yes, that's a good solution. The problem is that the normal Palm IR is pretty weak. Read the user testimonials to see the range.
You either have to get an IR extender (fairly cheap and useful) or instead of buying a Palm, buy a Visor. User reports indicate that they have punch-through-the-walls power IR. I have no idea why they'd do that -- but that's WAY cool. Nobody's yet reported a maximum range for remote control (but there are very few people who have Visors yet); the people who have tried gave up after getting out of sight of their devices.
I can think of a use, though. Imagine an entire classroom set up as a distributed network -- during a test.
-Billy
The *only* part you disliked was him flying off at the end? I'm suprised. The Matrix used comic-book cliche heavily, and usually if you dont' like one cliche you won't like any of them.
Personally, I *like* a well-played cliche -- but IMO it's never enough to hold up a movie on its own. It adds (or subtracts) nothing to my evaluation of the movie.
Matrix held up well because it had a strong plot with unique elements.
I agree that maintaining the qualities of the original is going to be very hard. For one thing, they're going to have to drop the whole "ignorant audience" assumption.
All we can do is hope...
-Billy
And now for the promised Better Idea:
Neo's a superman. So, potentially, are the other humans. Okay, fine. Most of the humans in the world are STILL at the back and call of huge AIs. If you anger them, they can eliminate VAST numbers of people without a qualm. In addition, the Matrix itself isn't evil; only the deception is evil. The obvious conclusion is that there is going to be war, followed by either total mutual destruction or a peace treaty which involves teaching everyone about the Matrix.
So, two seqels. One showing the war; the other one showing the negotiations leading to the peace. Neither one can REALLY use the sense of wonder and mystery that the original had, so unfortunately those cool cliches are going to have to go (cliches work well mainly when the overal structure of the movie is a mystery).
I would say that the draw of the middle movie should be conflict (of course). Lots of it. Strategy. Infighting (very little, but on both sides).
The draw of the final movie should be high strategy, politics, and so on. Think of Heinlein's "The Moon is a Harsh Mistress", with Neo playing the part of Mycroft/Mike/Adam.
In both movies Neo should play a bit part, because Keanu doesn't have the acting range to handle such things. the focus should be on humanity freeing itself, not on Superman freeing them (although, of course, he should do just that, in many exciting scenes).
I'm looking forward to these, though. They *could* really screw them up (just as Peter Jackson could screw up Tolkien's LOTR), but then... Maybe they already know that.
-Billy
Not the same -- Debian _requires_ you to start up dselect. For a new user, dselect is certainly intimidating -- I'm experienced, and I always am hitting the wrong keys.
:-), and call it by its correct name -- Debian. Good thing they don't keep the real name secret, even though they did choose a new name.
The advantage for this choice is simply tech support; everyone starts out with the same config. And the tech support and advertizing that this company is already doing is an advantage to all of Debian, doubly so since they use essentially the same software that we do.
That's their value-add -- service. It's the right thing for them to do.
Unlike Corel, they're not ever going to have problems falling behind Debian because they have so many changes.
But hey. I use the real thing
-Billy
I asked Libranet what this distro was about, and they said that the main thing they changed was to take dselect out of the install and instead give apt-get a list of things to install.
IMO, this is WONDERFUL. These people are adding a lot of value to Debian in general by putting up a first-rate website with responsive service and nice general Linux propaganda.
Add to that the fact that they don't seem to want to create their own code fork, so they'll always be able to keep up with Debian (and vice versa).
I appreciate all that Corel's doing, but in a very real sense they _have_ to do it to make their proprietary system work. Libranet is in a sense much more in line with what Debian needs, because every minute of service they provide is a direct service to Debian itself, rather than some being a service to Debian and some to WordPerfect.
Of course, again, I like what Corel's doing. I just wanted to point out that these guys have their heads screwed on straight as well, and they're actually MORE useful to Debian.
-Billy
There are reasons it is better to use the GPL for projects that aren't designed to be libraries.
I agree.
For example, suppose I develop a specialized mathematics program. If I release it under the LGPL, it is possible for Wolfram (for example) to rip out the interesting routines and make it into a library. They LGPL their changes to my program, then use that library in Mathematica without my consent or even mentioning that I wrote that code!
They can't do that, though -- your code is STILL under the LGPL, and because they've made changes to it they have to distribute their changed source. It's true that they've gotten the advantage of your library without their software being free, but at the same time they haven't done anything to hurt your library.
So nothing unexpected has happened -- and in fact, I see that as being VERY good. They will fix bugs in your library, and you'll be able to use the bugfixes. You have gained.
-Billy
What I'm saying is that I've seen plenty of production code (you'll have to take my word), and I've never seen curly braces cause trouble (have to take my word on that, also).
:)
I believe you. I'm just stating that I've been involved in much development, and I see it happen all the time. The only cure is to always use [short and] curlies.
I can picture it happening, though. My point was I think it's unlikely that python has never had the same problem (indeed, I'd be very suprised), and so the unique indention model doesn't really serve any good purpose.
The *purpose* of the indentation isn't to avoid that particular problem. It's twofold: first, to remove a nasty source of style debate; and second, to make code easier to read by making style cues match up with meaning.
It works very well at both.
Oh. You're saying there's software (tabnanny?) available to assist the programmer to make sure such errors do not occur? I guess it has come up, and I don't need to use my imagination.
Nope -- tabnanny was written unwillingly after the insistent demands of people who knew nothing about Python.
(ps. I hit enter before I was done, hence the post and a half. I blame slashdot. perl, rather
*Grin*.
-Billy
Wait. His argument was that in extensive use he has seen no problems with Python's indentation. How can you rebut that, aside from offering contradictor experience? All you have is a theory that it might impact productivity (and you're wrong about the details of the theory -- the odds of an indentation change actually changing the _meaning_ of the code without being an error is VERY small, and even that possibility can be eliminated by using tabnanny).
He didn't tell you you can't have an opinion; he told you exactly why your opinion is wrong. Which it is. Although I admit he also put a silly title on his post, so I can understand why you'd be annoyed.
To be fair, I have never seen optional braces cause problems in production C or C++ code.
What do you mean by "To be fair?"
How much production C code have you seen? I've seen and written my share, and I have seen the optional braces cause problems in real code. To be sure, it wasn't production code, because we corrected the bug before we shipped it -- but that was just luck (and skill), not any feature of C.
I could imagine an extra tab causing problems in production python code,
Imagination doesn't carry the day.
-Billy
We usually are.
;-)
As everyone knows, the intelligence of a group is equal to the minimum intelligence of its members divided by the number of members. This point has been proven often enough in software engineering.
Of course, teams are a little different -- that's the only reason we lasted even this long, we had a good team helping us.
If we want to ever do any good, we need a surgical chess team (c.f. Mythical Man Month). And when I say team I don't mean a bunch of people who just met, or met over the web!
Or perhaps this is just the beginning of the defeat of chess -- perhaps it'll be replaced by the One True Strategy Game, Go. Now THAT is a good game.
-Billy
There have been reports about these before; it seems Intel had released some of the chips without as many NDAs as before, and people had been benchmarking and overclocking them :-).
The higest speed they released was 766; this doesn't mean that the official release won't have higher speeds, of course. And someone overclocked one a little, nothing really impressive.
The Athlon 700 matched a P766 on a 820motherboard in most tests. Of course, the 820mobo is really nice, with 4xAGP and such -- but it's _completely_ unavailable. So expecting a P766 to match an A700 on available mobos is unrealistic.
And, of course, AMD supports 'overclockers' officially, so you can buy K7-900 systems with warrenty intact. I found another place which sells overclocked A750 for the cost of an A600 elsewhere with a lifetime warantee -- and no cooling aside from the ubiquitous fans (they take the cartrige apart and mount a heat sink directly on the chip).
-Billy