Re: A little first-hand about the Orbiter development

[Rick DeNatale]

On Fri, 27 Jun 2003 00:27:13 +0000, rk wrote:

> For any program of significant size, I would want at a least a
> rudimentary assembler so one can jump to symbolic addresses, have
> reasonable names for constants, registers, etc. Of course, this
> wouldn't affect the size or runtime of the program. I remember even in
> the '70s and early '80s some rather slow FORTRAN compilers. I don't
> know about the speed of the assemblers back in the '60s. I know there
> were some programmers from back there in the group (added .history) and
> perhaps they can chime in with their $0.02.

There was a time, which ended in the early 1970s when I was in college, in
which computer programming textbooks tended to be machine specific and
covered machine language, Fortran II, and assembly language in that order.

In the old days, computer programs tended to be carefully "desk checked"
before they ever saw the machine, computer time was more precious than
programmer time, so manually producing machine code was de rigeur.

I beleive that the machine which gave the impetus to using assembly
language rather than machine code was the IBM 605. This machine had
instructions which had a field which held the address of the next
instruction to be executed. This is because it fetched instructions for
execution directly from a rotating drum memory. The trick was to arrange
the instructions so that the next instruction was under the read head when
it was needed. This lead to SOAP or the Share Optimizing Assembly Program.
The optimization was the allocation of the 'right' address to each
instruction.

[James Oberg]

We were doing assembly language programming for the IBM 1620 in the summer
of 1963, and it was just magnetic core memory. As they say, that was when
ships were wood and men were iron -- and so was their memory.

"Rick DeNatale" > wrote in message
...
> On Fri, 27 Jun 2003 00:27:13 +0000, rk wrote:
>
> > For any program of significant size, I would want at a least a
> > rudimentary assembler so one can jump to symbolic addresses, have
> > reasonable names for constants, registers, etc. Of course, this
> > wouldn't affect the size or runtime of the program. I remember even in
> > the '70s and early '80s some rather slow FORTRAN compilers. I don't
> > know about the speed of the assemblers back in the '60s. I know there
> > were some programmers from back there in the group (added .history) and
> > perhaps they can chime in with their $0.02.
>
> There was a time, which ended in the early 1970s when I was in college, in
> which computer programming textbooks tended to be machine specific and
> covered machine language, Fortran II, and assembly language in that order.
>
> In the old days, computer programs tended to be carefully "desk checked"
> before they ever saw the machine, computer time was more precious than
> programmer time, so manually producing machine code was de rigeur.
>
> I beleive that the machine which gave the impetus to using assembly
> language rather than machine code was the IBM 605. This machine had
> instructions which had a field which held the address of the next
> instruction to be executed. This is because it fetched instructions for
> execution directly from a rotating drum memory. The trick was to arrange
> the instructions so that the next instruction was under the read head when
> it was needed. This lead to SOAP or the Share Optimizing Assembly Program.
> The optimization was the allocation of the 'right' address to each
> instruction.

[OM]

On Mon, 14 Jul 2003 03:23:02 GMT, "James Oberg"
> wrote:

>We were doing assembly language programming for the IBM 1620 in the summer
>of 1963, and it was just magnetic core memory. As they say, that was when
>ships were wood and men were iron -- and so was their memory.

"...And there I was, a prisoner of Captain Ned and his crew of the
Raging Queen. However, I was finally able to sneak off board while the
ship was docked at the International Space Station, the adventures
following my escape I shall relate forthwith in my next chapter, 'As
My Body Explosively Decompresses...'"

The Fake Pat Flannery (*)

(*) Try saying that three times real fast :-P


--
The STS-107 Columbia Loss FAQ can be found
at the following URLs:

Text-Only Version:
http://www.io.com/~o_m/columbia_loss_faq.html

Enhanced HTML Version:
http://www.io.com/~o_m/columbia_loss_faq_x.html

Corrections, comments, and additions should be
e-mailed to , as well as posted to
sci.space.history and sci.space.shuttle for
discussion.

[OM]

On Tue, 15 Jul 2003 18:38:50 -0600, "Jay Windley"
> wrote:

>
>LOL, yes I remember that. Our computing center back in the Olden Days had
>printouts on a rack behind the operator's window. The system would print
>your user ID in big block letters on the burst page, and it would be visible
>from the window. So you could walk up to the window and, before getting the
>operator's attention, gauge the success of your run. If there was an
>inch-thick pile of paper behind your burst page, you got results. If there
>was only a sheet or two behind the burst page, you knew you had some sort of
>error to decipher.

....Or, if while waiting for your job to print out, you saw a UID page
pop up with the account name of "LGSPOCK", you knew you were in for a
wait :-P


OM

--

"No ******* ever won a war by dying for | http://www.io.com/~o_m
his country. He won it by making the other | Sergeant-At-Arms
poor dumb ******* die for his country." | Human O-Ring Society

- General George S. Patton, Jr

[Kent Betts]

I had the pleasure of working on the Burroughs TC500, the first intelligent data
terminal. It contained a sealed aluminum disk about the size of an LP record
with a R/W head for each track and turning about 3000 or 6000 RPM. The rotating
disk was synchronized with the processor, and provided the comm software as well
as the microcode required for the processor to complete its instructions. The
TC500 was a big seller at about 50,000 units at around $50,000 each. A big
market for the things was with banks, a traditional Burroughs market. I figure
in the early 60s that one TC500 would be enought to handle the transactions of
your hometown bank or savings and loan. The wide carriage on the thing was
sized to accomodate ledger pages in use at the time. Burroughs kept them in the
field thru the late 80s on various lease contracts, long after they were
economically viable. Then again, dumb glass terminals in the late 80s were not
cheap, but jeez. I think DEC or Burroughs had a nice dot matrix terminal
available during this time. Made me appreciate the California school of
engineering design vs Pennsylvania.

> "Rick DeNatale"
> > I beleive that the machine which gave the impetus to using assembly
> > language rather than machine code was the IBM 605. This machine had
> > instructions which had a field which held the address of the next
> > instruction to be executed. This is because it fetched instructions for
> > execution directly from a rotating drum memory. The trick was to arrange
> > the instructions so that the next instruction was under the read head when
> > it was needed. This lead to SOAP or the Share Optimizing Assembly Program.
> > The optimization was the allocation of the 'right' address to each
> > instruction.
>
>

[Kevin Willoughby]

Jay Windley said:
> "rk" > wrote in message
> ...
> | I found out that some schools are no longer teaching
> | even assembly language and machine organization any more
> | for the Computer Science majors.
>
> Along those lines, compiled languages are on the way out in academia.
> JIT-compiled Java is becoming the de facto standard for core algorithm

uh, how isn't "JIT-compiled" not compiled?

While Java isn't the pedagogically best language, it is better than its
predecessors. How much time in how many University classes has been
wasted explaining the obscurities of C pointers or C++ multiple
inheritance?


> Unfortunately it doesn't occur to a lot of these
> professors that there are still computing applications that can't
> accommodate (and shouldn't) a 20-megabyte optimizing multi-pass JVM.

The SE (Java Standard Edition) can run in less than 20 Mbyte. The
mobile edition of Java can run in environments much smaller than you
might expect. Fun factoid: in 2003, worldwide, there will be more Java
platforms delivered to paying customers than Windows platforms. (Hint:
many new cell phones in the USA and most new cell phones in Europe will
run Java, but are too resource constrained to run Windows.)

OBspace: one of the recently launched Martian rovers is Java powered.


> The running joke is that when flight control software starts being written
> in Java we'll have to add an extra 1,000 feet of runway for getting the
> JVM-laden aircraft off the ground.

If the alternative is a Windows FCS that crashes one time in a
thousand...


> I'm running into more and more mechanical engineers who CAN'T DRAW!

I'm running into a lot of young C.S. graduates who can't do a back-of-
the-envelope calculation to save their lives. It isn't pretty.

Heck, I still use one of my slide rules every now and then.


> There
> is a definite correlation between design ability in the abstract sense, and
> the capability of expressing oneself graphically with nothing more than a
> stick and a flat spot of dirt. I've seen it myself.

Myself, I like blackboard and chalk.
--
Kevin Willoughby

We'd spend the remaining time trying to fix the engine.
-- Neil Armstrong

[Mike Speegle]

In news:Kevin Willoughby > typed:
> Jay Windley said:

> > I'm running into more and more mechanical engineers who CAN'T DRAW!
>
> I'm running into a lot of young C.S. graduates who can't do a back-of-
> the-envelope calculation to save their lives. It isn't pretty.

Even with calculators kids struggle. Last week at the movies I
bought something at the counter for $3.25. Gave the kid 3 ones and
while I'm fishing in my pocket for change he enters $3.00 tendered and
the display reads $.25 still due. I give him 3 dimes and he keys in
$3.30 tendered with $3.05 in change. ??? He actually counted out 3
ones but I saved his butt and just took the nickel shaking my head.
Sheesh. So even with electonic help some of these kids are seriously
polluting the gene pool. :-(
--
Mike
__________________________________________________ ______
"Colorado Ski Country, USA" Come often, Ski hard,
Spend *lots* of money, Then leave as quickly as you can.

[OM]

On Wed, 16 Jul 2003 01:02:41 -0400, Kevin Willoughby
> wrote:

>While Java isn't the pedagogically best language, it is better than its
>predecessors. How much time in how many University classes has been
>wasted explaining the obscurities of C pointers or C++ multiple
>inheritance?

....Oh, agreed. Encapsulation and inheritance were pushed along with
the biggest bull**** of them all, top-down design, and to this day
almost *nobody* uses any of it. It's simply too much of a headache to
code within the time limits demanded by profitability.

OM

--

"No ******* ever won a war by dying for | http://www.io.com/~o_m
his country. He won it by making the other | Sergeant-At-Arms
poor dumb ******* die for his country." | Human O-Ring Society

- General George S. Patton, Jr

[jeff findley]

Kevin Willoughby > writes:
> While Java isn't the pedagogically best language, it is better than its
> predecessors. How much time in how many University classes has been
> wasted explaining the obscurities of C pointers or C++ multiple
> inheritance?

That's because such understanding is necessary, depending on where you
get your job after college...

Java has its place, but it isn't at the heart of engineering
software. I ought to know, considering I work on CAE (finite element)
software. We've still got lots of Fortran, C, and some C++ in
performance critical code. Java doesn't cut it in the guts of code
that has to deal with one million plus finite elements (and their
nodes and etc).

To be fair, my current project is in Java, but it's largely user
interface that has no direct contact with any of the "guts" of the
code. This is where Java works well, at least where I work. Rapid
development of a user interface level code is well suited to a high
level language (or a GUI builder).

Jeff
--
Remove "no" and "spam" from email address to reply.
If it says "This is not spam!", it's surely a lie.

[Jay Windley]

"jeff findley" > wrote in message
...
|
| That's because such understanding is necessary, depending on where you
| get your job after college...

That's exactly my point. Why would I hire a BSCS if some guy who has read
"Java For Dummies" can do just as good a job and charge me less?

I remember once calling some programmer into my office to have him explain
why his project was ridiculously behind. He said he was working around a
bug in the JVM and it wasn't easy to do. "Why don't you just fix the JVM?"
I asked. (We had the source code to it.) He looked at me like I was crazy.
I was entirely serious. The guy was a CS grad, not just some wannabe. It
took only a day or so to fix the JVM. I just had a hard time dealing with
his attitude that "all that JVM stuff" was under the hood and he thought he
had no business violating the abstraction.

One of my most talented embedded-systems programmers in a former job was the
guy who had written IBM's JVM. This guy *knew* Java, but didn't try to
evangelize it. He used Java where it was appropriate, and C/C++ where
appropriate.

(ObSpace: This guy also worked on the AP-101 project, IBM's computer used
on the space shuttle.)

I understand there is a tremendous market right now for Java programmers. A
lot of stuff in the commerce end of things is being written in Java, and I
don't see anything wrong with that. The Java of today is not the Java of
six or seven years ago, and I don't think a lot of computer people realize
this. I see a lot of invalid criticism of Java based on arguments that have
been resolved.

| I ought to know, considering I work on CAE (finite element)
| software.

Heh heh, you're precisely the type of person my company sells computers to.
Boeing, Ford, and other big engineering types use our computers for funky
computational structural and fluid dynamics, heat transfer, and other
problems without closed forms that require fine-grained discretization. I
saw a presentation in Baltimore last year where someone had used one of our
competitor's computers to do a CSD analysis of an entire aircraft carrier at
an obscene level of detail.

ObSpace: In the same session there was a presentation of n-body gravitation
simulations for the Kuiper Belt, where n was in the thousands or tens of
thousands. (For some reason they didn't include Neptune, though.)

| Java doesn't cut it in the guts of code that has to deal with
| one million plus finite elements (and their nodes and etc).

Agreed, but even that gap is narrowing.

The exciting principle behind modern JITs is runtime profiling. They run
your byte code for a few iterations and gather runtime metrics, and then
they compile and aggressively optimize the portions that are responsible for
most of the running time.

The classic bad example is

for (i=0; i<SOME_HUGE_NUMBER; i++)
{
foo = 0;
}

A good JIT will optimize this loop away entirely regardless of what the
programmer specifies, while the GNU C/C++ compilers will generally leave it
there even if they move the invariant outside. So the Java version runs
instantly while the C version often spins through the loop even though it's
not doing anything useful in the body.

The key is recognizing the invariant. The best JITs have very good
optimizers and can optimize not only on the static structure of a program
but also on the runtime behavior. Many C compilers have good optimizers
too, but runtime optimization is limited to a separate step. The GNU
compilers are frequently used for benchmarks, but most people who need good
performance use commercial compilers that have optimizers tuned for the
specific architectures for which they generate code.

It's a bad example above because it simply tests one feature of
optimization, and so nobody really accepts it as a valid benchmark. But
this particular example illustrates the point. The key is recognizing the
invariant. An experienced programmer with a good theoretical understanding
will see that the code example above is bad. He knows why it's bad, and he
rewrites the code to eliminate the problem, which is a far better solution
because it will run efficiently even in the face of a poor optimizer (or
even the lack of one). A programmer whose butt is saved time after time at
runtime by a clever JIT may not be effective outside that sheltered
environment.

And that was my understanding of what this thread is about (or rather, what
it has become). It's less about Java versus C or FORTRAN and more about
correct understanding of underlying principles and basic concepts. Today's
grads are being insulated from concepts that are still important.

Memory management in Java is still a major hassle, and when I'm supplying
computers with 4 terabytes of RAM (yes, terabytes) because that's the size
of the datasets my customers need to have in memory, you don't want any of
that garbage collection stuff in the way. You've got to let the programmer
do his own memory management according to his own expertise and judgment.
Garbage collectors work very slowly and inefficiently on allocations of this
size. Some of these jobs run for days or weeks at a time, so a memory
management overhead adds up fast.

It may not matter in the long run if a program makes a copy of a ten-byte
chunk of data more times than it strictly needs to. But if a program is
trying to copy a 4,000,000 element matrix just because a certain abstraction
demands it, that may render the program entirely unrunnable. You go to
extreme lengths to *avoid* copying that matrix at all. Ever.

| To be fair, my current project is in Java, but it's largely user
| interface that has no direct contact with any of the "guts" of the
| code. This is where Java works well, at least where I work.

I thoroughly agree. User interaction is an application for which Java is
particularly suited and often gives you very big wins with portability.

--
|
The universe is not required to conform | Jay Windley
to the expectations of the ignorant. | webmaster @ clavius.org

[Bruce Palmer]

Mike Speegle wrote:
> Even with calculators kids struggle. Last week at the movies I
> bought something at the counter for $3.25. Gave the kid 3 ones and
> while I'm fishing in my pocket for change he enters $3.00 tendered and
> the display reads $.25 still due. I give him 3 dimes and he keys in
> $3.30 tendered with $3.05 in change. ??? He actually counted out 3
> ones but I saved his butt and just took the nickel shaking my head.
> Sheesh. So even with electonic help some of these kids are seriously
> polluting the gene pool. :-(

And to think baseball pitcher Mike Hampton left New York for the Rockies
because he liked the Colorado school system better :)

But seriously, here on Long Island if the cash registers didn't figure
out the change, 99% of the kids you run into couldn't do it themselves.

--
bp
Proud Member of the Human O-Ring Society Since 2003

[Sam Seiber]

Bruce Palmer wrote:
>
> And to think baseball pitcher Mike Hampton left New York for the Rockies
> because he liked the Colorado school system better :)

And I thought it was the $100 some odd million over 10 years that
was the reason. Silly me.

Sam

[Jay Windley]

Oh, goody, I get to eat my words. I was a little uncomfortable with my
grasp of the optimizing question so I asked a few of our compiler gurus. A
static and a dynamic optimizer should be equally adept at removing loop
invariants. There is nothing especially knowable at runtime that clarifies
the invariance of ambiguous code. The issue of runtime optimization is
strictly one of profiling -- looking at how code behaves when it runs and
optimizing it accordingly based on this information. This is not generally
available to static optimizers, but natively-compiled languages such as
C/C++ can use standalone optimizers to identify problematic code stretches.

The simplistic example I posted was, of course, an unambiguously invariant
loop body. Both Java and C will, if set up to optimize to the same degree,
remove that code and eliminate the loop entirely. It was based on a
comparison I read a while back which used a somewhat less straightforward
loop which the HotSpot JVM had optimized (correctly) into oblivion while the
C compiler (gcc) had not. As I said, it doesn't appear that this happens
very often and the benchmarking people don't seem interested in it.

--
|
The universe is not required to conform | Jay Windley
to the expectations of the ignorant. | webmaster @ clavius.org

[Mike Speegle]

In news:Sam Seiber > typed:
> Bruce Palmer wrote:
> >
> > And to think baseball pitcher Mike Hampton left New York for the
> > Rockies because he liked the Colorado school system better :)
>
> And I thought it was the $100 some odd million over 10 years that
> was the reason. Silly me.

...and then his ego got the best of him when he couldn't figure out
that pitching is different at a mile high of thin air. What a maroon,
and good riddance.
--
Mike
__________________________________________________ ______
"Colorado Ski Country, USA" Come often, Ski hard,
Spend *lots* of money, Then leave as quickly as you can.

[Kevin Willoughby]

Jay Windley said:
> The issue of runtime optimization is
> strictly one of profiling -- looking at how code behaves when it runs and
> optimizing it accordingly based on this information.

Not really. A dynamic optimizer has an advantage over a static
optimizer. Static optimizers are often thwarted by not knowing all the
code that is running. Things like the possibility of aliasing (non-
obvious ways of having multiple ways of referring to the same variable)
force static optimizers to be conservative. There is at least one JVM
(currently, iirc, owned by BEA) that can over-optimize the code because
it knows what other code is also loaded into the JVM. Should the
program load some new code, the JVM can deoptimize the code as needed
to prevent problems.

A large dose of engineering good taste is needed to be sure you don't
loose more than you gain in dynamic optimization.


> This is not generally
> available to static optimizers, but natively-compiled languages such as
> C/C++ can use standalone optimizers to identify problematic code stretches.

This really isn't a language thing. Traditionally, C/C++ has been
statically optimized, but there is nothing that would prohibit a
HotSpot-like system that detected performance-sensitive code and
optimized it. With most C/C++ systems, this would be a machine-code to
machine-code optimizer, with the advantage of being usable with any
language that compiles to machine code.


> The simplistic example I posted was, of course, an unambiguously invariant
> loop body. Both Java and C will, if set up to optimize to the same degree,
> remove that code and eliminate the loop entirely. It was based on a
> comparison I read a while back which used a somewhat less straightforward
> loop which the HotSpot JVM had optimized (correctly) into oblivion while the
> C compiler (gcc) had not. As I said, it doesn't appear that this happens
> very often and the benchmarking people don't seem interested in it.

Actually, the benchmarking people were interested in it because the
compiler writers optimized their products for best benchmark numbers,
resulting, as you say, in optimizing away entire loops. (Tuning to the
benchmark was not just a software thing. I know of a machine that
included an arc-hyperbolic-cosecant instruction, but didn't include an
arc-hyperbolic-secant function. Guess which trig functions appeared in
the popular benchmarks.) The benchmark owners eventually mandated that
the benchmarks be run with all optimizers turned off.
--
Kevin Willoughby

We'd spend the remaining time trying to fix the engine.
-- Neil Armstrong

[Kevin Willoughby]

I could go on and on over this topic. Given the forum, let me just say
we essentially agree on all of this stuff.

Jay Windley said:
> Right now Java costs me time. My Java programmers have to wait until a JVM
> becomes operational on platforms I build. That has to wait until the C/C++
> environment is ready, at which point my C/C++ guys are off and running.

I'm not surprised. One of the dirty secrets of Java is that most of the
JVMs are coded in C. Can't start a new JVM until the C compiler is
working well. So the JVM guys can't start working until the time when
your C/C++ guys can also start working.


> ObSpace: I am, however, interested in Java being used on the new Mars
> probes. Is it written up anywhere in more detail?

Not as much detail as I suspect you'd like. If you are a member of the
Java Developers Community (or willing to register for the JDC), go to
http://servlet.java.sun.com/javaone/sf2003/home/index.jsp
and enter MARS into the search box.


> | Myself, I like blackboard and chalk.
>
> Just TRY to find an honest-to-goodness chalkboard anymore. I hate
> whiteboards; not enough resistance to the stroke.

Also, getting chalk dust off my pants is trivial, getting those damn
marker inks off my pants is tough.
--
Kevin Willoughby

We'd spend the remaining time trying to fix the engine.
-- Neil Armstrong

[Jay Windley]

(Replies consolidated to reduce off-topicness)

"Kevin Willoughby" > wrote in message
...
|
| A large dose of engineering good taste is needed to be sure
| you don't loose more than you gain in dynamic optimization.

Yes, thank you. I was going to allude to this eventually. Static or
dynamic, an optimizer will always have the disadvantage of not knowing the
problem you're trying to solve. It can do lint-picking things like strength
reduction or factoring out invariants, or consolidating similar code as you
brought up. But the greatest increases in efficiency that I've seen -- and
I mean they're *big* wins -- have always been from skilled programmers
figuring out better ways to do things at the bird's-eye level with knowledge
of what each modular chunk of code is supposed to accomplish.

Funny how it always comes back to having skilled people whose understanding
is focused on the problem rather than on the tool. I run into this all the
time. People think in terms of what's available to them and what they can
do with it, not in terms of what you need to solve the problem.

| ... With most C/C++ systems, this would be a machine-code
| to machine-code optimizer, with the advantage of being usable
| with any language that compiles to machine code.

Most compilers you buy will optimize both at the abstract code level and at
the machine code level. These are the compilers sold by the CPU
manufacturers. In the cases I've tested they produce much better code than
freebies like GNU's compiler. Remember, my customers write code that has to
run for several days on terascale systems. A 10% speedup is not
insignificant.

| Actually, the benchmarking people were interested in it because
| the compiler writers optimized their products for best benchmark
| numbers, resulting, as you say, in optimizing away entire loops.

Well, I don't put a lot of stock in benchmarks, especially those done by
manufacturers of either hardware or compilers/runtimes. I always find it
interesting in the Java versus C debate that the C people's benchmarks come
out faster for C while the Java people's benchmarks come out faster for
Java. Again, the spectre of the skilled programmer raises its head.

The only benchmark I pay attention to is LINPACK because it's a standard in
the supercomputing industry. And pretty much anything goes. I've got a guy
whose only job is to hand-optimize math libraries for these beasts. He can
sometimes squeeze 20% speedups out of that code, which pushes our benchmarks
along nicely. And we use compilers provided by the CPU manufacturers with
all the recommended optimizations enabled.

But what I meant was that the loop in question wasn't interesting because it
was, in fact, so trivial. The failure of one compiler to optimize it to the
bit bucket isn't that big a deal in the grand scheme of things. I certainly
don't mean to say that factorization of loop invariants is not interesting,
nor that elimination of dead loops is not interesting.

"Kevin Willoughby" > wrote in message
...
| I could go on and on over this topic. Given the forum, let me
| just say we essentially agree on all of this stuff.

Yeah, I think we're wearing out our welcome. I don't mind Java being
pitched for things that it's never been used for before. I do mind Java
being pitched for everything.

| I'm not surprised. One of the dirty secrets of Java is that
| most of the JVMs are coded in C.

I never considered it that much of a secret. I worked with Sun's original
JVM that was *very poorly* coded in C. I *really* hated that code and so
did everyone else that touched it. I think that was one of the big reasons
Java didn't have immediate appeal.

| Not as much detail as I suspect you'd like. If you are a member of the
| Java Developers Community (or willing to register for the JDC), go to
| http://servlet.java.sun.com/javaone/sf2003/home/index.jsp
| and enter MARS into the search box.

LOL, I'll get one of our Java guys to do it. Thanks. I've worked alongside
several projects to embed Java, none of which came to fruition. I'd like to
see a success story.

| Also, getting chalk dust off my pants is trivial, getting those damn
| marker inks off my pants is tough.

Here's a tip (pun intended). Make this a tight "basic block" in your
whiteboard presentations:

1. Remove cap
2. Draw on whiteboard
3. Replace cap

Not only will it keep your clothes cleaner, the pens will last longer.
Nothing irritates me more than an enfeebled whiteboard marker, except for
people who stand there for five minutes talking while the cap is off the
pen. They *dry out*, people!

--
|
The universe is not required to conform | Jay Windley
to the expectations of the ignorant. | webmaster @ clavius.org

[LooseChanj]

On or about Thu, 17 Jul 2003 22:44:39 -0400, Kevin Willoughby
> made the sensational claim that:
> On of my pet peeves: people who mash the marker's point into the
> whiteboard so that is has the consistency of overcooked spaghetti. Ya
> just can't do a drawing with a blunt, mushy marker.

*sniff sniff* Wazzat you say?
--
This is a siggy | To E-mail, do note | This space is for rent
It's properly formatted | who you mean to reply-to | Inquire within if you
No person, none, care | and it will reach me | Would like your ad here

[Jay Windley]

"rk" > wrote in message
...
|
| What did he do on the AP-101?

Writing assemblers and compilers for it. I don't know if he did any direct
support work for the shuttle. He was working for IBM at the time, but I
don't know who else might have been using the -101 while he was there.

--
|
The universe is not required to conform | Jay Windley
to the expectations of the ignorant. | webmaster @ clavius.org

[Jay Windley]

"Kevin Willoughby" > wrote in message
...
|
| Yah, but the hand that holds the cap will get brightly colored
| splotches.

Better the hand than the pants. Or the white shirt.

| On of my pet peeves: people who mash the marker's point into the
| whiteboard so that is has the consistency of overcooked spaghetti.

Agreed. But around here they tend to dry out before succumbing to
tenderization. The other nice thing about chalk is that you can use the
same rotation technique as for pencil to assure consistent line weight.

I like CAD. I'm commited to CAD. I've evangelized CAD. I've built CAD.
But I still like the feel of pencil on vellum.

--
|
The universe is not required to conform | Jay Windley
to the expectations of the ignorant. | webmaster @ clavius.org

[jeff findley]

"Jay Windley" > writes:
> And that was my understanding of what this thread is about (or rather, what
> it has become). It's less about Java versus C or FORTRAN and more about
> correct understanding of underlying principles and basic concepts. Today's
> grads are being insulated from concepts that are still important.

Agreed. I'm sure we all have a story we can tell about paying for
something we bought with cash, something unexpected happens, and all
of a sudden the cashier simply can't make change for you because of "a
problem with the register". The real problem is that the person
running the cash register has no clue how to make change on their own.
We're turning out grads (at all levels) that are entirely dependent on
computers to do this sort of work for them.

Jeff
--
Remove "no" and "spam" from email address to reply.
If it says "This is not spam!", it's surely a lie.

[OM]

On Fri, 18 Jul 2003 10:46:55 -0600, "Jay Windley"
> wrote:

>Agreed. But around here they tend to dry out before succumbing to
>tenderization.

....And the reason for that is universally obvious: The damn things are
the most fun legal inhalants since Testor's changed the Red Tube
formula in '71.

OM

--

"No ******* ever won a war by dying for | http://www.io.com/~o_m
his country. He won it by making the other | Sergeant-At-Arms
poor dumb ******* die for his country." | Human O-Ring Society

- General George S. Patton, Jr

[OM]

On 18 Jul 2003 13:09:28 -0400, jeff findley
> wrote:

>Agreed. I'm sure we all have a story we can tell about paying for
>something we bought with cash, something unexpected happens, and all
>of a sudden the cashier simply can't make change for you because of "a
>problem with the register". The real problem is that the person
>running the cash register has no clue how to make change on their own.

....In defense here, there's usually one of three reasons here,
sometimes a combination of them are in effect:

1) Their employers have expressly forbidden them to perform manual
transactions. This is to eliminate a great opportunity for employ
theft.

2) Most registers rely on barcodes for pricing and inventory tracking.
If the item is out the door and hasn't been scanned, it screws with
inventory management, and the beancounters get an opportunity to
masturbate their egos.

3) In most cases, the cash register software won't allow the cash
drawer to be manually opened if links to the server are down without a
special ID and password, and most basic flunkies they hire at minwage
to man these are *never* given that kind of access.

....Now, I'm not saying these people aren't the lower end of the
intelligence level, but sometimes it's really beyond their control
and/or fault.


OM

--

"No ******* ever won a war by dying for | http://www.io.com/~o_m
his country. He won it by making the other | Sergeant-At-Arms
poor dumb ******* die for his country." | Human O-Ring Society

- General George S. Patton, Jr

[Mary Shafer]

On Fri, 18 Jul 2003 10:46:55 -0600, "Jay Windley"
> wrote:

> I like CAD. I'm commited to CAD. I've evangelized CAD. I've built CAD.
> But I still like the feel of pencil on vellum.

Or the look of India ink in a ruling pen going onto creamy drafting
paper.

Mary

--
Mary Shafer Retired aerospace research engineer

"A MiG at your six is better than no MiG at all."
Anonymous US fighter pilot

[OM]

On Fri, 18 Jul 2003 23:28:59 -0700, Mary Shafer
> wrote:

>On Fri, 18 Jul 2003 10:46:55 -0600, "Jay Windley"
> wrote:
>
>> I like CAD. I'm commited to CAD. I've evangelized CAD. I've built CAD.
>> But I still like the feel of pencil on vellum.
>
>Or the look of India ink in a ruling pen going onto creamy drafting
>paper.

....Or the fun of letting the ink dry on vellum to make sure you don't
smear it before proceeding with the next line?


OM

--

"No ******* ever won a war by dying for | http://www.io.com/~o_m
his country. He won it by making the other | Sergeant-At-Arms
poor dumb ******* die for his country." | Human O-Ring Society

- General George S. Patton, Jr

[Herb Schaltegger]

In article >,
Mary Shafer > wrote:

> On Fri, 18 Jul 2003 10:46:55 -0600, "Jay Windley"
> > wrote:
>
> > I like CAD. I'm commited to CAD. I've evangelized CAD. I've built CAD.
> > But I still like the feel of pencil on vellum.
>
> Or the look of India ink in a ruling pen going onto creamy drafting
> paper.
>
> Mary

When I was a freshman engineering undergrad (1986 - 1987) we were
required to take two quarters of Engineering Graphics, which at that
time still meant basic drafting. The classes were a bit of a rarity in
that they were four hour classes and actually met four mornings a week.
Day after day we'd all sit around drafting tables and learn to letter
properly; how to properly dimension drawings; how to derive perspectives
and elevations, etc.

By the time I'd graduated and gone to work on Space Station Freedom,
Boeing had almost entirely eliminated manual drafting. Due to an MSFC
requirement (to help a local business, of course!) we were using
Intergraph Unix-based workstations running their I/EMS software (on
machines with a then-generous 16 megabytes of RAM - about a year later
Intergraph was in the midst of upgrading the machines to an astounding
48 megs each! One of the most interesting things about the Intergraph
system was that even then they were capable of being clustered to
perform detailed 3D renderings using spare machine cycles - very common
in redering farms now but amazing new technology to us junior engineers.
Some of the models were detailed enough that one master machine and the
spare cycles of two or three dozen others took two weeks or more to
render. This was Boeing's first "paper-free" design - everything from
the pressure vessel to the fluid lines were modeled in 3D and the
drawings generated from the models.

Interestingly, a couple years after the start of the SSF contract when
the company started the Triple-7 program, they chose CATIA instead of
I/EMS . . . ;-)

--
Herb Schaltegger, Esq.
Chief Counsel, Human O-Ring Society
"I was promised flying cars! Where are the flying cars?!"
~ Avery Brooks

[OM]

On Sat, 19 Jul 2003 08:19:47 -0500, Herb Schaltegger
> wrote:

>Interestingly, a couple years after the start of the SSF contract when
>the company started the Triple-7 program, they chose CATIA instead of
>I/EMS . . . ;-)

....Probably because CATIA had evolved quite a bit from its 308x/434x
days when I played around with it and CAEDS in my college days. Before
I left Texas U, I was part of a small group working on adapting Franz
Joseph's TOS Enterprise blueprints to a 3D walkthru to show visiting
"dignitaries", complete with a nekkid green Orion female in Kirk's
quarters. We'd gotten the outer hull modeled, laid out the flat decks,
turbolift shafts, and the base details for the hangar deck. We were in
the middle of Kirk's quarters and the Bridge when the project got put
on hold so everyone could work on the 4381 installation. Halfway
through that, I'd been given a job offer at another department that
paid *twice* what my meager student salary paid, and with tuition
jumping for no real reason, I was forced to take that job. The "E"
project died shortly after that, as the 4381 install took longer than
expected, and one of the directors wanted a ****ing yacht instead, and
done in something new called GRAPHIGS.

Last I heard, one of the old timers still had the CATIA files on 9",
and that's probably where they'll stay, too...


OM

--

"No ******* ever won a war by dying for | http://www.io.com/~o_m
his country. He won it by making the other | Sergeant-At-Arms
poor dumb ******* die for his country." | Human O-Ring Society

- General George S. Patton, Jr

[Bruce Hedley]

Bruce Palmer > wrote in message >...
> Mike Speegle wrote:
> > Even with calculators kids struggle. Last week at the movies I
> > bought something at the counter for $3.25. Gave the kid 3 ones and
> > while I'm fishing in my pocket for change he enters $3.00 tendered and
> > the display reads $.25 still due. I give him 3 dimes and he keys in
> > $3.30 tendered with $3.05 in change. ??? He actually counted out 3
> > ones but I saved his butt and just took the nickel shaking my head.
> > Sheesh. So even with electonic help some of these kids are seriously
> > polluting the gene pool. :-(
>
> And to think baseball pitcher Mike Hampton left New York for the Rockies
> because he liked the Colorado school system better :)
>
> But seriously, here on Long Island if the cash registers didn't figure
> out the change, 99% of the kids you run into couldn't do it themselves.

I can recall, not terribly long ago although it seems like it, a
summer student we had (4th yr Mech Eng, OK, I _was_ having an affair
with her but I wasn't her supervisor) who came to me with a problem
and I hand-estimated a square root (casting out 9's method, usually
gives you a decent value) and I had to explain to her what it was:
the implication being that without calculators (didn't have mine at
work that day) she was lost. So, then, what ARE they teaching
engineers, or high school students for that matter, in maths class
these days ?

BTW, it all ended amicably and I attended her wedding in France a few
years later.

Cheers all,

[Bruce Hedley]

jeff findley > wrote in message >...
> Kevin Willoughby > writes:
> > While Java isn't the pedagogically best language, it is better than its
> > predecessors. How much time in how many University classes has been
> > wasted explaining the obscurities of C pointers or C++ multiple
> > inheritance?
>
> That's because such understanding is necessary, depending on where you
> get your job after college...
>
> Java has its place, but it isn't at the heart of engineering
> software. I ought to know, considering I work on CAE (finite element)
> software. We've still got lots of Fortran, C, and some C++ in
> performance critical code. Java doesn't cut it in the guts of code
> that has to deal with one million plus finite elements (and their
> nodes and etc).
>
> To be fair, my current project is in Java, but it's largely user
> interface that has no direct contact with any of the "guts" of the
> code. This is where Java works well, at least where I work. Rapid
> development of a user interface level code is well suited to a high
> level language (or a GUI builder).
>
> Jeff

Absolutely agree.

I'm part of a development group holding a large-ish (350K lines)
Fortran
code for doing CFD modelling on CANDU reactors, and, quite frankly,
were we
to have written it in Java, we wouldn't be able to do our job in
anything like
a reasonable time frame. Tests on solving large equations of the form
Ax = b
where the rank of A is ~10,000 show that F77 is still way more
efficient
computationally than Java -- can't say about JVM since we haven't done
that one (yet). That's for real*8 values, BTW.

We're intending to recode (and rethink the code) in F95 or F2000 if a
vendor comes out with a product in the next 18 months or so, which
should widen the gap with Java, most likely.

Visit us at: www.cathena.aecl.ca

Cheers all,

[David Higgins]

Jay Windley wrote:
> The first CAD I tried was on
> Techtronix storage tube -- those things where you draw on a big tablet with
> a pen and it shows up as a fuzzy green line on a big picture tube. The only
> way you can erase anything is to erase everything and draw it all over
> again.

You forgot to mention the blinding flash when the storage
tube was erased. Made worse by the dimness of the lines,
which caused everyone to darken the room.

[Scott Hedrick]

I once worked for 7-11. After an inspection, I had a chance to look at the
inspection sheet. Every area was graded in several criteria, each of which
were graded 1-5. Some things had as few as three criteria, while others had
a dozen. I understand why it might be necessary to do long division if you
have several 2s, 3s and 5s to average, but I have yet to understand why it
took long division to two decimal places to figure out the average of 3 4s
was, in fact, 4.

My father considered building his own convenience store. A woman asked me to
consider her for a job. I asked her to tell me how much change was due on
three 45 cent cans of tuna paid for with a 5 (no tax on food here), and to
do it in her head. She gave me a nasty look and said that not everyone was a
genius. I asked her how she expected to handle money when the register
wasn't working.

--
If you have had problems with Illinois Student Assistance Commission (ISAC),
please contact shredder at bellsouth dot net. There may be a class-action
lawsuit
in the works.

[OM]

On Sun, 3 Aug 2003 20:40:41 -0400, "Scott Hedrick"
> wrote:

>My father considered building his own convenience store. A woman asked me to
>consider her for a job. I asked her to tell me how much change was due on
>three 45 cent cans of tuna paid for with a 5 (no tax on food here), and to
>do it in her head. She gave me a nasty look and said that not everyone was a
>genius. I asked her how she expected to handle money when the register
>wasn't working.

....I sincerely hope she'd had her tubes tied so she couldn't
contaminate the gene pool. Pray tell, was her last name Maxson by
chance?


OM

--

"No ******* ever won a war by dying for | http://www.io.com/~o_m
his country. He won it by making the other | Sergeant-At-Arms
poor dumb ******* die for his country." | Human O-Ring Society

- General George S. Patton, Jr

[Alan Jones]

On Sun, 3 Aug 2003 20:43:09 -0400, "Scott Hedrick"
> wrote:

>I miss F77. Wish I had a compiler for Win98. I got nearly 100 in that class
>even after skipping the final at the instructor's request (and getting a
>zero on it, counting for 10% of my grade). Years of Trash-80 BASIC came in
>handy. I think I still have 4x6 cards with my favorite subroutines on them.

I go back at laest as far as Watt IV Fortran. I tried to get the
university to allow me to just take the advanced course. As it was, I
often lost points for using Fortran that they had not taught yet.