But I don't agree that it's a side trip; instead, it's a step on the journey. Right now we keep everything directly on the machines; next we keep the reliable copies on the network and the working copies on the machine; finally the working copies become temporary.
Of course you want offsite backups -- but you _also_ want onsite backups. The two serve different purposes.
You also need to consider that this software can _also_ provide offsite backup services far more efficiently: it knows, for example, to only make one copy of each shared file.
Sorry, Mojonation uses pretty strong encryption. You'd have a hard time of it; you'd do better to walk over to the person's computer....and why shouldn't it work for a group of open-source developers? Or for the entire Internet?
Actually, using the idle portion is natural with asynchronous logic. It's hard, but natural.
One way of doing it is to have each portion of the chip 'request' more data once the data it contains is accepted by another part. So as soon as instruction decoding is done, the instruction decoder is ready for the next instruction from the loader (even though the instruction hasn't executed).
The reason it's hard is the same reason that upgrading the Linux kernel to support multiple processors is hard -- you have to add more and more 'locks' so that data doesn't break in while you're trying to work. It's easier with hardware because nothing can break in without a line being cut for it, of course.
The alternative is to do the same thing the Linux kernel used to do -- run only one instruction at a time, and wait until it's completely done before trying another one. That's safe, and very fast (data locks slow things down even when they're ready for data), but doesn't use the full capabilities of the hardware you have, and denys the ability to add still more hardware.
Now, the interesting thing comes along when you continue the comparison. BitKeeper author Larry McVoy has long been saying that fine-grained kernel locking is a bad strategy, because it makes things slower on each processor and increases the complexity of the code _immensely_. Instead he recommends what you might call microclusters: one kernel running on each processor (or small group of processors), pretending to be a seperate machine, and communicating with the other processors as though over a very high-bandwidth network. This way you can have as many processors in a single machine as you want without making the kernel any more complex.
Now, consider: how does this relate to microchips? The answer's pretty obvious: make the chips simpler, but put more of them on the die, and give them an internal network. Sure enough, both Sun and Chuck Moore are taking this path -- and preliminary results indicate that it works VERY well indeed.
-Billy
Re:Heard about this stuff in class
on
Clockless Computing
·
· Score: 5, Insightful
It's amusing to read the claim that an asychronous chip couldn't take advantage of pipelining. You see, the thing is that pipelining exists ONLY to control two of the disadvantages of clocked processors.
First, it allows different instructions to complete in different amounts of time. An asynchronous chip wouldn't have that disadvantage.
Second, it allows 'idle' portions of the chip to be used by other instructions whose time hasn't come. Asynchronous chips are vulnerable to that as well, but they can be much less vulnerable than even the most pipelined architecture, because dataflow can completely guide the chip: you can hammer in more data as soon as the previous data's been slurped in.
So far from not taking advantage of pipelining, asynchonous chips naturally have one of the advantages of pipelining, and can be built to have the only other.
-Billy
Re:One problem with asynchronous logic
on
Clockless Computing
·
· Score: 3, Insightful
That's not true either. It can take fewer transistors even at a small scale, and it often takes fewer transistors at a large scale, since propagating the clock pulse across a chip requires a surprising amount of circuitry.
Consider that the Pentium 4 added entire pipeline stages for the sole purpose of getting data from one side of the chip to the other in step with the clock.
Consider that the x25, a largely asynchronous chip, has about as many gates as a 386 yet contains 25 parallel processors.
The main problem isn't impossibility or complexity; the problem is that asynchronous design isn't yet understood. We have a LOT of research to do. Once we've done it, engineers will consider asynchrony to be a simple, solved problem.
Believe me, I'd love to. But Tom Bombadil isn't explainable; that's why he wasn't in the movie. JRRT's invention of Tom was either brilliant in its creation of a truly multidimensional character which the book only hinted at, or it was just crazy:-).
You really, really have to read the book -- and it really helps to think about it, too, to see how little Tom fits into the bigger picture of the world.
In the long run, Tom with all his mysterious power and limitations is critical to the meaning of the book. Not everything is explained; Tom is one of the things that aren't.
So I'm sorry, I can't. There may be enlightenment to be had, but it has to be gained the hard way.
Nonsense. Lots of things in microwaves can get above 100C; the only reason the oil in your experiment didn't is that it's nonpolar, and thus unaffected by the waves.
Pizza oil contains some suspended polar molecules, so it gets heated; that's why plastic containers used to heat pizza develops nicks. The HOT oil melts the plastic.
Check out this page for more info, and goo dlinks to even more.
I've heard this before (the claim that microwaves heat the O-H bond in water), but that doesn't make it true. If the O-H bond were the only source of heat, then why can MWs heat things up beyond 100C?
The simple fact that this person is melting metals proves that there's some other mechanism at work, and further, it's almost certain that this other mechanism is more powerful than the hypothetical water resonance.
Here is a page which discusses many "myths" about microwaves, including this one. It also contains some _facinating_ experiments, lots of fun. My favorite is microwaving a light bulb (not listed on that page, but a surprising color light show you can look up elsewhere -- caution, don't try it without the safety precautions).
-Billy
Re:This review makes too great a logical leap
on
Minority Report
·
· Score: 2
I agree; the movie's point is FAR broader than our simple current situation, and applies to much of justice. The review's reduction is almost absurd, as if we could solve the proposed problems by ending the war on terror or by eliminating key escrow.
But only/almost/ absurd, not completely absurd. Just because he's driving the point into the ground doesn't mean he lacks a point:-).
I have no clue why the post is marked funny -- perhaps the moderator found my comment about 'suability' to be amusing enough to grant the rest of the post exalted status. I do think that's amusing, although I wouldn't have modded a post that way for that reason.
If a metamoderator disagrees with the moderator, I'm going to lose a point of karma (I'm already at 50). No big deal, but THAT's what's funny -- I said something amusing incedentally while posting my opinion, someone agreed that it was funny, and for that I'm going to get my karma reduced.
Odd.
Like I said, though, that only happens to people who are at +50, and we are in no danger:-).
I suspect you're totally missing his point (I may be wrong). He's saying that unified usability is more important than configurability; you're saying that configurability can't be made simple.
You may be right; my experience agrees with you. But that doesn't address his claim, that configurability should take a backseat to unified usability.
Is he right? I'd say that he is. Yes, I want all our stuff to remain configurable; however, more and more that configurability should focus to a point. When I change the way the help system works, ALL the help facilities should change (except the ones I ask to not change, of course -- and those shouldn't just be the ones the author happened to use the wrong help viewer on).
A Windows user doesn't have to configure, and doesn't have a huge amount of choice; but the choices he does have apply pretty consistently throughout the system. Well, at least that's the goal;-). We can do better; we can become consistent while remaining configurable.
-Billy (who keeps mistyping 'usability' as 'suability')
I disagree. Typing 'slashdot' in my browser bar is how I get here once I know the URL; until I know it, Google is _far_ more reliable, and utterly certain to not dump me onto a squatter site.
Of course, I knew slashdot's URL before I ever used Google, but the point is still valid -- there are many other sites to be found that way.
Google isn't the all-in-all, of course; but Teoma doesn't come close. I like using alltheweb when Google isn't enough.
P21 was used in a settop box for Internet access, RIP (too many settop boxes, too little demand). It's not exclusively for that, but I'm not aware of any other use.
The shBOOM is now being marketed as a Java accelerator (it's called the PSC1000, by Patriot); another variant of it is rad-hardened and used in orbit.
The 25x (sorry, I mispelled it originally), described at http://www.colorforth.com/25x.html, is a new development from the guy who designed both the above chips, and isn't funded.
I found a list of similar chips at http://www.ultratechnology.com/chips.htm. Interesting stuff.
how is that? does it have multiple stacks? how can it execute more than one instruction at a time, if only the top element on the stack can be addressed?
Great question! There's a little bit of a false assumption in there; I believe you're assuming that only superscalar chips can be fast. Not true; superscalar has a LOT of advantages, but a lot of disadvantages as well. The worst disadvantage is complexity; the superscalar chips eat a LOT more energy.
The fastest stack chips don't execute multiple instructions at the same time. (They do have multiple stacks, but that's a different issue.)
The trick is that although they can't execute 5 instructions at the same time, they can and do execute 5 instructions in the time it takes other processors to execute one, for two reasons: first, their cycle length is that much shorter; second, their instruction encodings are that much shorter.
The cycle length is shorter because the top two registers of the stack are gated directly to all the chip's functional units. As soon as the stack stabilizes from the last instruction, the functional units begin computing correct results for the next instruction. By the time the next instruction's decoded, all it has to do is MUX the correct result onto the stack, and possibly pop the stack.
The encoding is shorter because there are no operands: instructions always apply to the top of the stack (well, except the LITERAL instruction). This means that (for the fastest chip) 4 instructions fit into one machine word -- so one can fairly consistently get 4 instructions per RAM cycle.
The chip speed is so much faster than the 18-bit 4ns cache chip being used as RAM for this that the multiprocessor version of this chip, the X25, uses one of its processors to drive each of its logic pins, thereby making its logical interface essentially software-driven. 250MHz isn't impressive (that's the effective speed of the cache RAM, if my calculations are correct), but having enough spare MHz to implement the access protocol in software IS impressive. Doing all this at 500 mW @ 1.8 V (this assumes all 25 computers running at full bore, which isn't needed; at minimum draw, 100mAh battery life is 1 year, with 1 computer running throttled (I'm quoting from the specs, I haven't bothered to do the conversions needed to compare wattage directly).
But I don't want to get caught in the trap of claiming stack chips are faster than superscalar chips. Not true -- but you have to use a LOT of power and a LOT of transistors to beat a stack chip.
Partially true. For example, Forth's VM avoids all that, and is VERY fast -- as a bonus, its VM is extremely easy to produce native code for (native code compilers are entirely compatible with others).
Others have discussed why GC isn't as bad as you say; I agree with them, although they're a little extreme (it's NOT true that you always need GC).
I'm working on a VM which can handle both GC'ed and non-GC'ed stuff at the same time, for a substantial speed advantage. Unfortunately, my VM has a language tiedown; I'm not sure how to add the type support I need to most languages.
[Specifically for Java:] VM is stack-based, and stack-based designs were tried couple of decades ago, and eventually were obsoleted by register-based CPUs. Memory-to-memory just isn't efficient way to do it, even with caches.
That's not true -- stack-based chips were dropped for other reasons. The modern stack-based chips are very fast indeed -- consider the X25, shBOOM, or P21.
But I think you're confusing "stack based" with "memory to memory". Not all stacks are implemented in memory; an on-chip stack is very fast, and allows the CPU to operate at almost the full ALU clock, since there's no register access delay.
Your other reasons are, of course, sufficient and correct.
From experience, we know that testing is essential for maintainable code, but the practice which REALLY catches defects is peer review, not testing.
Two effective ways, both tried and true:
1. Take your code to your coworkers (at most two at a time) and have them go over it with a checklist of common defects and goals. Then explain the code (while they still have the checklist, so they can make additions), then have them explain the problems they found. Look up "formal reviews" for more info.
2. Pair program at all times. Follow the basic XP guidelines for this: be sure to rotate teams. This is usually harder to arrange than #1 (it takes more management support), and it doesn't provide recorded numbers for analysis, but it squashes a similar number of bugs, and has other benefits (for example, knowledge about every chunk of code is present with at least two people on the team, rather than just one).
And, as I noted when I first entered this thread, such an approach guarantees only correctness, not necessarily maintainability.
Yet all your arguments show that it'll produce maintainability, not correctness. Think about it -- correctness isn't shown or implied by the existance of tests.
But code that's been involved in five independent refactoring exercises in the last month may or may not still be easily refactorable in time for the sixth.
On the contrary -- code that's been though five independent refactorings will almost certainly be ready for a sixth, because the team has been reworking it so much and has already proven that it can be independently refactored.
Actually, in real use, by the time you've done 5 independent refactorings you've got a library-quality chunk of code, because you've proven that the same basic idea is useful in in as many as six independent contexts.
Doing refactoring will cause programmers to try to write refactorable code, because it's in their best interests. Sure, just like all programmers think through the problem before they start writing, and spend the time testing thoroughly afterwards, because the time more than pays for itself in the long run. No wait, sorry, most of them don't. What makes you think they'll be any less lazy under an XP approach?
Let me add a word: because it's in their immediate best interests. If they know they're in maintenance mode, and they're doing their work in a maintenance style, they'll do work to make maintenance simpler. It's simple, short-term self-interest.
And that's the genius of XP: it takes the useful practices of design, testing, requirement analysis, reuse, and many other things, and changes them from long-term useful to immediately useful by moving them around.
Requirement analysis, for example, is moved from a big lump at the beginning of the project to small sums all throughout the project, assisted with the delivery of "evolutionary prototypes" (to use a non-eXtreme term). This way the people who know the requirements best (the customer who's paying for them) can see the fruits of their specifications so far.
Testing is moved from a big lump at the end to a colloidal dispersion throughout. In the process it changes character: from a roadblock between you and the customer, to a roadmap showing your intended route to get to where the customer claims to want you to be.
Design is moved from a huge up-front activity with no natural feedback, and is transmuted into a constantly ongoing process with many forms of immediate feedback, ranging from ease of testing (a testable design is not always a good one, but an untestable design is always bad, and because writing unit tests is how you express detailed design in XP, your design is certain to be testable right out of the gate) to fulfillment of acceptance tests to frequency and massiveness of refactorings.
All the known good practices are in XP, and they're all provided with a natural, immediate feedback; the is completely unlike the traditional approach you describe, in that the traditional approach fits the good practices in only with words on paper. The only thing keeping the programmers doing the good practices is their own determination; the only way you can tell whether they're doing them well is by looking at the schedule overruns after the fact.
So, yes, the so-called "Killer Bees" (any bee can kill you if you are allergic to them, but it's highly unlikely otherwise) are pollinating the coffee.
Just a comment: "killer bees" aren't named so for the strength of their sting, but the frequency. Common bees sting relatively rarely; killer bees will go all-out to defend their hives, and will go into a stinging frenzy at some odd provocations.
Allergic or not, if you get 300 stings you're dead. But then odds are VERY high that you are allergic, even if you aren't aware of it. Most people are, but the allergy is dormant.
I've done test-first. I'll never go back, no matter what other practices I'm using. It's just SO much easier to use my tests as my ally rather than my enemy!
Tests are easy to write, and writing them helps clarify the requirements and design. Once they're written, the actual code often just falls out as obvious; even when it doesn't and I have to work for it, the tests are still a win because they tell me, automatically, when I'm finished coding: as soon as the tests all pass I'm done.
I don't use xUnit, though, because I'm using C and C++. xUnit is available for them, but it's really an inappropriate model for static languages. I wrote my own testassert package, and my friend wrote a little Python script to build a test "main()" file by scanning a bunch of files containing tests. Together they serve me very well (in fact, they're published on Sourceforge under the name of CUT, with a new version due any time).
For anything more than short bits of code it's almost impossible to prove anything useful, and certainly impossible to communicate your proof in a way useful to someone who has to maintain your code.
As Knuth himself said, "Be careful about using the following code -- I've only proven that it works, I haven't tested it."
In all the focus on passing unit tests (which are written first) and constantly refactoring, they have deliberately lessened the focus on a clean, maintainable design...
Continuous refactoring is a type of maintenance. How can you claim that an emphasis on refactoring could reduce maintainability? Doing refactoring will cause programmers to try to write refactorable code, because it's in their best interests. Refactorable code is EXACTLY maintainable code.
Unit tests are not a part of maintainence, but they are a helpful part of maintainability. With unit tests you not only have a safety net to catch you when you make an out-of-spec change to a unit; you also have a readable spec to show you what normal, expected use for the component is. If you want to reuse a component, you first look at its unit tests to see that its author expected your type of use, and if not you add unit tests which DO typify your expected use.
An emphasis on refactoring, dual authorship, and reuse is DIRECT encouragement to write maintainable code, as well as constantly increase maintainability.
In fact, XP is often typified as continuous maintenance; most critics and proponents agree that XP projects are in maintenance mode almost from day one. Your accusations otherwise are so out of the blue it's hard to fathom where they came from.
Now, suppose six months down the line, I have a codebase that passes all the tests, but in making a simple change to meet a new requirement I can cause it to fail 500 tests and need six man-months of rewrite time before it passes them all again. Do I really have a good codebase?
That's not the right question; the answer would be useless. The right question is, do you really have a simple change? Consider that the codebase in an ordinary XP project has gone through MANY simple changes, and hasn't ever been failing its tests for that long before. Your change shouldn't be anything special.
The XP thing to do is to back out of the "simple" change and redesign it in parts which will result in new functionality being added every week, and the code passing all its unit tests every day.
If you don't do this the XP way, then how WILL you do it? No other way is as amenable to requirements being added after the fact.
It's also possible, of course, that the codebase is totally inappropriate for your new requirement. Not every requirement can be added to every software product.
No, it has no validity. If it did, the employee could get the money without ANY company.
The company itself provides value to the worker, not merely the other way around. The two exist in synergy, as long as someone values the company's product more than anyone values the company's raw inputs.
Slashdot Mirror
Good point! I didn't think of it that way.
But I don't agree that it's a side trip; instead, it's a step on the journey. Right now we keep everything directly on the machines; next we keep the reliable copies on the network and the working copies on the machine; finally the working copies become temporary.
It's a brilliant short step.
-Billy
Of course you want offsite backups -- but you _also_ want onsite backups. The two serve different purposes.
You also need to consider that this software can _also_ provide offsite backup services far more efficiently: it knows, for example, to only make one copy of each shared file.
-Billy
Sorry, Mojonation uses pretty strong encryption. You'd have a hard time of it; you'd do better to walk over to the person's computer. ...and why shouldn't it work for a group of open-source developers? Or for the entire Internet?
-Billy
Actually, using the idle portion is natural with asynchronous logic. It's hard, but natural.
One way of doing it is to have each portion of the chip 'request' more data once the data it contains is accepted by another part. So as soon as instruction decoding is done, the instruction decoder is ready for the next instruction from the loader (even though the instruction hasn't executed).
The reason it's hard is the same reason that upgrading the Linux kernel to support multiple processors is hard -- you have to add more and more 'locks' so that data doesn't break in while you're trying to work. It's easier with hardware because nothing can break in without a line being cut for it, of course.
The alternative is to do the same thing the Linux kernel used to do -- run only one instruction at a time, and wait until it's completely done before trying another one. That's safe, and very fast (data locks slow things down even when they're ready for data), but doesn't use the full capabilities of the hardware you have, and denys the ability to add still more hardware.
Now, the interesting thing comes along when you continue the comparison. BitKeeper author Larry McVoy has long been saying that fine-grained kernel locking is a bad strategy, because it makes things slower on each processor and increases the complexity of the code _immensely_. Instead he recommends what you might call microclusters: one kernel running on each processor (or small group of processors), pretending to be a seperate machine, and communicating with the other processors as though over a very high-bandwidth network. This way you can have as many processors in a single machine as you want without making the kernel any more complex.
Now, consider: how does this relate to microchips? The answer's pretty obvious: make the chips simpler, but put more of them on the die, and give them an internal network. Sure enough, both Sun and Chuck Moore are taking this path -- and preliminary results indicate that it works VERY well indeed.
-Billy
It's amusing to read the claim that an asychronous chip couldn't take advantage of pipelining. You see, the thing is that pipelining exists ONLY to control two of the disadvantages of clocked processors.
First, it allows different instructions to complete in different amounts of time. An asynchronous chip wouldn't have that disadvantage.
Second, it allows 'idle' portions of the chip to be used by other instructions whose time hasn't come. Asynchronous chips are vulnerable to that as well, but they can be much less vulnerable than even the most pipelined architecture, because dataflow can completely guide the chip: you can hammer in more data as soon as the previous data's been slurped in.
So far from not taking advantage of pipelining, asynchonous chips naturally have one of the advantages of pipelining, and can be built to have the only other.
-Billy
That's not true either. It can take fewer transistors even at a small scale, and it often takes fewer transistors at a large scale, since propagating the clock pulse across a chip requires a surprising amount of circuitry.
Consider that the Pentium 4 added entire pipeline stages for the sole purpose of getting data from one side of the chip to the other in step with the clock.
Consider that the x25, a largely asynchronous chip, has about as many gates as a 386 yet contains 25 parallel processors.
The main problem isn't impossibility or complexity; the problem is that asynchronous design isn't yet understood. We have a LOT of research to do. Once we've done it, engineers will consider asynchrony to be a simple, solved problem.
-Billy
Believe me, I'd love to. But Tom Bombadil isn't explainable; that's why he wasn't in the movie. JRRT's invention of Tom was either brilliant in its creation of a truly multidimensional character which the book only hinted at, or it was just crazy :-).
You really, really have to read the book -- and it really helps to think about it, too, to see how little Tom fits into the bigger picture of the world.
In the long run, Tom with all his mysterious power and limitations is critical to the meaning of the book. Not everything is explained; Tom is one of the things that aren't.
So I'm sorry, I can't. There may be enlightenment to be had, but it has to be gained the hard way.
-Billy
Nonsense. Lots of things in microwaves can get above 100C; the only reason the oil in your experiment didn't is that it's nonpolar, and thus unaffected by the waves.
Pizza oil contains some suspended polar molecules, so it gets heated; that's why plastic containers used to heat pizza develops nicks. The HOT oil melts the plastic.
Check out this page for more info, and goo dlinks to even more.
-Billy
I've heard this before (the claim that microwaves heat the O-H bond in water), but that doesn't make it true. If the O-H bond were the only source of heat, then why can MWs heat things up beyond 100C?
The simple fact that this person is melting metals proves that there's some other mechanism at work, and further, it's almost certain that this other mechanism is more powerful than the hypothetical water resonance.
Here is a page which discusses many "myths" about microwaves, including this one. It also contains some _facinating_ experiments, lots of fun. My favorite is microwaving a light bulb (not listed on that page, but a surprising color light show you can look up elsewhere -- caution, don't try it without the safety precautions).
-Billy
I agree; the movie's point is FAR broader than our simple current situation, and applies to much of justice. The review's reduction is almost absurd, as if we could solve the proposed problems by ending the war on terror or by eliminating key escrow.
/almost/ absurd, not completely absurd. Just because he's driving the point into the ground doesn't mean he lacks a point :-).
But only
-Billy
I have no clue why the post is marked funny -- perhaps the moderator found my comment about 'suability' to be amusing enough to grant the rest of the post exalted status. I do think that's amusing, although I wouldn't have modded a post that way for that reason.
:-).
If a metamoderator disagrees with the moderator, I'm going to lose a point of karma (I'm already at 50). No big deal, but THAT's what's funny -- I said something amusing incedentally while posting my opinion, someone agreed that it was funny, and for that I'm going to get my karma reduced.
Odd.
Like I said, though, that only happens to people who are at +50, and we are in no danger
-Billy
I suspect you're totally missing his point (I may be wrong). He's saying that unified usability is more important than configurability; you're saying that configurability can't be made simple.
;-). We can do better; we can become consistent while remaining configurable.
You may be right; my experience agrees with you. But that doesn't address his claim, that configurability should take a backseat to unified usability.
Is he right? I'd say that he is. Yes, I want all our stuff to remain configurable; however, more and more that configurability should focus to a point. When I change the way the help system works, ALL the help facilities should change (except the ones I ask to not change, of course -- and those shouldn't just be the ones the author happened to use the wrong help viewer on).
A Windows user doesn't have to configure, and doesn't have a huge amount of choice; but the choices he does have apply pretty consistently throughout the system. Well, at least that's the goal
-Billy (who keeps mistyping 'usability' as 'suability')
I disagree. Typing 'slashdot' in my browser bar is how I get here once I know the URL; until I know it, Google is _far_ more reliable, and utterly certain to not dump me onto a squatter site.
Of course, I knew slashdot's URL before I ever used Google, but the point is still valid -- there are many other sites to be found that way.
Google isn't the all-in-all, of course; but Teoma doesn't come close. I like using alltheweb when Google isn't enough.
-Billy
You're quite used to typing, aren't you. I can see that you're so used to it that you now think it's natural.
It's not. Not in the least. It's not only unnatural and difficult, it's dangerous.
-Billy
P21 was used in a settop box for Internet access, RIP (too many settop boxes, too little demand). It's not exclusively for that, but I'm not aware of any other use.
The shBOOM is now being marketed as a Java accelerator (it's called the PSC1000, by Patriot); another variant of it is rad-hardened and used in orbit.
The 25x (sorry, I mispelled it originally), described at http://www.colorforth.com/25x.html, is a new development from the guy who designed both the above chips, and isn't funded.
I found a list of similar chips at http://www.ultratechnology.com/chips.htm. Interesting stuff.
-Billy
how is that? does it have multiple stacks? how can it execute more than one instruction at a time, if only the top element on the stack can be addressed?
Great question! There's a little bit of a false assumption in there; I believe you're assuming that only superscalar chips can be fast. Not true; superscalar has a LOT of advantages, but a lot of disadvantages as well. The worst disadvantage is complexity; the superscalar chips eat a LOT more energy.
The fastest stack chips don't execute multiple instructions at the same time. (They do have multiple stacks, but that's a different issue.)
The trick is that although they can't execute 5 instructions at the same time, they can and do execute 5 instructions in the time it takes other processors to execute one, for two reasons: first, their cycle length is that much shorter; second, their instruction encodings are that much shorter.
The cycle length is shorter because the top two registers of the stack are gated directly to all the chip's functional units. As soon as the stack stabilizes from the last instruction, the functional units begin computing correct results for the next instruction. By the time the next instruction's decoded, all it has to do is MUX the correct result onto the stack, and possibly pop the stack.
The encoding is shorter because there are no operands: instructions always apply to the top of the stack (well, except the LITERAL instruction). This means that (for the fastest chip) 4 instructions fit into one machine word -- so one can fairly consistently get 4 instructions per RAM cycle.
The chip speed is so much faster than the 18-bit 4ns cache chip being used as RAM for this that the multiprocessor version of this chip, the X25, uses one of its processors to drive each of its logic pins, thereby making its logical interface essentially software-driven. 250MHz isn't impressive (that's the effective speed of the cache RAM, if my calculations are correct), but having enough spare MHz to implement the access protocol in software IS impressive. Doing all this at 500 mW @ 1.8 V (this assumes all 25 computers running at full bore, which isn't needed; at minimum draw, 100mAh battery life is 1 year, with 1 computer running throttled (I'm quoting from the specs, I haven't bothered to do the conversions needed to compare wattage directly).
But I don't want to get caught in the trap of claiming stack chips are faster than superscalar chips. Not true -- but you have to use a LOT of power and a LOT of transistors to beat a stack chip.
-Billy
Partially true. For example, Forth's VM avoids all that, and is VERY fast -- as a bonus, its VM is extremely easy to produce native code for (native code compilers are entirely compatible with others).
Others have discussed why GC isn't as bad as you say; I agree with them, although they're a little extreme (it's NOT true that you always need GC).
I'm working on a VM which can handle both GC'ed and non-GC'ed stuff at the same time, for a substantial speed advantage. Unfortunately, my VM has a language tiedown; I'm not sure how to add the type support I need to most languages.
-Billy
[Specifically for Java:] VM is stack-based, and stack-based designs were tried couple of decades ago, and eventually were obsoleted by register-based CPUs. Memory-to-memory just isn't efficient way to do it, even with caches.
That's not true -- stack-based chips were dropped for other reasons. The modern stack-based chips are very fast indeed -- consider the X25, shBOOM, or P21.
But I think you're confusing "stack based" with "memory to memory". Not all stacks are implemented in memory; an on-chip stack is very fast, and allows the CPU to operate at almost the full ALU clock, since there's no register access delay.
Your other reasons are, of course, sufficient and correct.
-Billy
From experience, we know that testing is essential for maintainable code, but the practice which REALLY catches defects is peer review, not testing.
Two effective ways, both tried and true:
1. Take your code to your coworkers (at most two at a time) and have them go over it with a checklist of common defects and goals. Then explain the code (while they still have the checklist, so they can make additions), then have them explain the problems they found. Look up "formal reviews" for more info.
2. Pair program at all times. Follow the basic XP guidelines for this: be sure to rotate teams. This is usually harder to arrange than #1 (it takes more management support), and it doesn't provide recorded numbers for analysis, but it squashes a similar number of bugs, and has other benefits (for example, knowledge about every chunk of code is present with at least two people on the team, rather than just one).
-Billy
And, as I noted when I first entered this thread, such an approach guarantees only correctness, not necessarily maintainability.
Yet all your arguments show that it'll produce maintainability, not correctness. Think about it -- correctness isn't shown or implied by the existance of tests.
But code that's been involved in five independent refactoring exercises in the last month may or may not still be easily refactorable in time for the sixth.
On the contrary -- code that's been though five independent refactorings will almost certainly be ready for a sixth, because the team has been reworking it so much and has already proven that it can be independently refactored.
Actually, in real use, by the time you've done 5 independent refactorings you've got a library-quality chunk of code, because you've proven that the same basic idea is useful in in as many as six independent contexts.
Doing refactoring will cause programmers to try to write refactorable code, because it's in their best interests.
Sure, just like all programmers think through the problem before they start writing, and spend the time testing thoroughly afterwards, because the time more than pays for itself in the long run. No wait, sorry, most of them don't. What makes you think they'll be any less lazy under an XP approach?
Let me add a word: because it's in their immediate best interests. If they know they're in maintenance mode, and they're doing their work in a maintenance style, they'll do work to make maintenance simpler. It's simple, short-term self-interest.
And that's the genius of XP: it takes the useful practices of design, testing, requirement analysis, reuse, and many other things, and changes them from long-term useful to immediately useful by moving them around.
Requirement analysis, for example, is moved from a big lump at the beginning of the project to small sums all throughout the project, assisted with the delivery of "evolutionary prototypes" (to use a non-eXtreme term). This way the people who know the requirements best (the customer who's paying for them) can see the fruits of their specifications so far.
Testing is moved from a big lump at the end to a colloidal dispersion throughout. In the process it changes character: from a roadblock between you and the customer, to a roadmap showing your intended route to get to where the customer claims to want you to be.
Design is moved from a huge up-front activity with no natural feedback, and is transmuted into a constantly ongoing process with many forms of immediate feedback, ranging from ease of testing (a testable design is not always a good one, but an untestable design is always bad, and because writing unit tests is how you express detailed design in XP, your design is certain to be testable right out of the gate) to fulfillment of acceptance tests to frequency and massiveness of refactorings.
All the known good practices are in XP, and they're all provided with a natural, immediate feedback; the is completely unlike the traditional approach you describe, in that the traditional approach fits the good practices in only with words on paper. The only thing keeping the programmers doing the good practices is their own determination; the only way you can tell whether they're doing them well is by looking at the schedule overruns after the fact.
-Billy
So, yes, the so-called "Killer Bees" (any bee can kill you if you are allergic to them, but it's highly unlikely otherwise) are pollinating the coffee.
Just a comment: "killer bees" aren't named so for the strength of their sting, but the frequency. Common bees sting relatively rarely; killer bees will go all-out to defend their hives, and will go into a stinging frenzy at some odd provocations.
Allergic or not, if you get 300 stings you're dead. But then odds are VERY high that you are allergic, even if you aren't aware of it. Most people are, but the allergy is dormant.
-Billy
I've done test-first. I'll never go back, no matter what other practices I'm using. It's just SO much easier to use my tests as my ally rather than my enemy!
Tests are easy to write, and writing them helps clarify the requirements and design. Once they're written, the actual code often just falls out as obvious; even when it doesn't and I have to work for it, the tests are still a win because they tell me, automatically, when I'm finished coding: as soon as the tests all pass I'm done.
I don't use xUnit, though, because I'm using C and C++. xUnit is available for them, but it's really an inappropriate model for static languages. I wrote my own testassert package, and my friend wrote a little Python script to build a test "main()" file by scanning a bunch of files containing tests. Together they serve me very well (in fact, they're published on Sourceforge under the name of CUT, with a new version due any time).
-Billy
For anything more than short bits of code it's almost impossible to prove anything useful, and certainly impossible to communicate your proof in a way useful to someone who has to maintain your code.
As Knuth himself said, "Be careful about using the following code -- I've only proven that it works, I haven't tested it."
-Billy
I'm puzzled by your claim here.
In all the focus on passing unit tests (which are written first) and constantly refactoring, they have deliberately lessened the focus on a clean, maintainable design...
Continuous refactoring is a type of maintenance. How can you claim that an emphasis on refactoring could reduce maintainability? Doing refactoring will cause programmers to try to write refactorable code, because it's in their best interests. Refactorable code is EXACTLY maintainable code.
Unit tests are not a part of maintainence, but they are a helpful part of maintainability. With unit tests you not only have a safety net to catch you when you make an out-of-spec change to a unit; you also have a readable spec to show you what normal, expected use for the component is. If you want to reuse a component, you first look at its unit tests to see that its author expected your type of use, and if not you add unit tests which DO typify your expected use.
An emphasis on refactoring, dual authorship, and reuse is DIRECT encouragement to write maintainable code, as well as constantly increase maintainability.
In fact, XP is often typified as continuous maintenance; most critics and proponents agree that XP projects are in maintenance mode almost from day one. Your accusations otherwise are so out of the blue it's hard to fathom where they came from.
Now, suppose six months down the line, I have a codebase that passes all the tests, but in making a simple change to meet a new requirement I can cause it to fail 500 tests and need six man-months of rewrite time before it passes them all again. Do I really have a good codebase?
That's not the right question; the answer would be useless. The right question is, do you really have a simple change? Consider that the codebase in an ordinary XP project has gone through MANY simple changes, and hasn't ever been failing its tests for that long before. Your change shouldn't be anything special.
The XP thing to do is to back out of the "simple" change and redesign it in parts which will result in new functionality being added every week, and the code passing all its unit tests every day.
If you don't do this the XP way, then how WILL you do it? No other way is as amenable to requirements being added after the fact.
It's also possible, of course, that the codebase is totally inappropriate for your new requirement. Not every requirement can be added to every software product.
No, it has no validity. If it did, the employee could get the money without ANY company.
The company itself provides value to the worker, not merely the other way around. The two exist in synergy, as long as someone values the company's product more than anyone values the company's raw inputs.