From: lex@cc.gatech.edu   
      
   >> But why would the constraints be fixed?  Surely these probes go   
   >> through an initial design phase where it is sketched out how much   
   >> power will be generated and how much shielding will be around and how   
   >> much mass is expected and so on.  During that initial sketch, I see no   
   >> reason they could not consider copious CPU power as a design option.   
   >   
   > I don't understand why you don't get this. Constraints are fixed because   
   > you're launching a rocket. The initial constraints are fixed by the   
   > mission science objectives and the budget. Given those, probably the   
   > next step is picking a launcher, at which point your total payload mass   
   > is also fixed. You're contraints are in place very early in the game.   
      
   At some point, someone has to make the decisions about what resources   
   to allocate where.  Someone has to make a decision about how much risk   
   is acceptible for how much money.   
      
   Notice that this is really a design spectrum and you can move the   
   decisions in either direction.  I have been talking about spending   
   more on parts in order to decrease risk and complexity and development   
   time.  You can also go the other way.  You can have less RAM, for   
   example, or you can write your own specialized operating system.  The   
   high-level designers have to choose a spot in this spectrum.   
      
   I am suggesting that there may be a better sweet spot than is commonly   
   chosen.  And at any rate, the sweet spot moves as time goes on.  Good   
   rules of thumb from thirty years ago should be reevaluated as   
   computers get awesomely less expensive.   
      
      
      
      
   >> > Hire a team of GOOD programers, much cheaper.   
   >>   
   >> Yes, but that's an independent issue.   
   >   
   > No, it's not independent. Really good programmers can do wonders with   
   > hardware that wouldn't have impressed the early PC pioneers. Although   
   > some programmers do mass quite a bit, you don't have to launch them   
   > anywhere.   
      
   I do not see the connection.  You want good programmers no matter what   
   else you do.   
      
   As an aside, I thoroughly disagree that good programmers can save any   
   project.  If there's any one factor that makes software projects work   
   or fail, it is management practices, ie software engineering.  Poor   
   programmers will still make a working and robust program if they have   
   good management; super programmers will still make faulty programs or   
   fail outright if they have poor management.  The poor programmers will   
   take longer to do it, but at least their program will actually work   
   correctly.   
      
   But to get back to the point, keep in mind that the more programmers   
   you use, the lower your percentage of really good programmers will be.   
      
      
   >> Anyway, if you want to have   
   >> really good programmers, it helps to give them less to do.  The more   
   >> work that must be done, the more programmers you need to hire, and the   
   >> harder it will be to find programmers of any particular productivity.   
   >   
   > I'm sorry, but this is totally misguided. You never want to give good   
   > programmers (or any good workers) less to do, it reduces productivity   
   > and annoyes and/or bores them.   
      
   That is a possible issue, but not with the scale of changes I am   
   proposing.  Using automatic memory management will gid rid of small   
   percentage of the programming effort, perhaps on the order of 10%.   
      
   But even if you did manage to massively decrease the programming   
   effort, and you kept all the programmers on staff for some reason, I   
   am not sure they will truly get bored.  All you have to do is turn   
   them loose on verification.  If you avoid 10,000 lines of unnecessary   
   code, then thee programmers can instead write 10,000 lines of   
   simulators and test cases.  Alternatively, they could use the saved   
   time for checking, proof checkers, or inspections.  In fact, I suspect   
   many programmers would be *happier* this way.  Instead of writing 2000   
   lines of mediocre code, they could write 1000 lines of the most   
   pristine code in the known universe.   
      
      
      
   > A small and simple flight computer means   
   > a small team working close to the hardware.   
      
   Well, simple is good, and small teams are good.  That's what I'm   
   arguing for.  However, working closer to the hardware often works   
   against these issues.  That's the problem.   
      
      
   > No bloatware required.   
      
   Nothing is *required*.  Inferior designs can still succeed.   
      
      
   Incidentally, the word "bloatware" is being thrown around   
   inaccurately, I think.  It's not exactly a technical term :), but   
   where I see it used, it refers to software that has a lot of features,   
   not software that requires a lot of resources.  MS Word is bloatware,   
   but a simple rocket simulator is not, even though the simulator can   
   take 1000 times more CPU cycles than MS Word.   
      
      
   -Lex   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)