Essentially, he is saying that if you assume that the good guys are really the bad guys, and vice-versa, the whole series makes more sense. It's not particularly insightful. Just another way of saying that the movies don't make sense.
On Feb 9, 1992, somebody named Jim (polari!mojo@sumax.seattleu.edu) posted to alt.brother-jed:
Now, what I'd really like to see is Brother Jed (or Jim, or someone
similar) meeting Kibo. Kibo, are you reading this? (I'll bet he is. He
probably greps all of Usenet for his name.) That'd be worth a trip out
to Boston to see.
Yes! Yes!
Kibo vs Brother Jed , 8 Rounds!
World Title Bout... for what prize?
Somebody, think of a prize!
Kibo jumps in, crossposts to a.r.k and alt.slack, and awards the Triple Grep Award and the Good Bozosity Seal of Allowedness to Merlyn LeRoy (merlyn@digibd.com).
So was the grepping inspired by the above post? Or did it start earlier?
Good point. And after reading some of the Generic Java stuff somebody up there pointed out, particularly Guy Steele's 1998 OOPSLA keynote, I realize I shouldn't be so harsh.
A Big Language That Everybody Can Use For Everything could maybe have these FP datatypes:
IEEE 754 single precision
IEEE 754 double precision
IEEE 754 "double-extended"-compliant type
IEEE 754 quadruple precision
greatest available hardware-supported precision
The D language could perhaps support only the last type initially. Then the language could be "grown" (in Steele's sense) to support the others. So not a tragedy.
And less tragic still if he'd put overloaded operators back in (see Steele on Java's BigNums).
D's philosophy about floating-point arithmetic is dangerous:
On many computers, greater precision operations do not take any longer than lesser precision operations,
so it makes numerical sense to use the greatest precision available for internal temporaries. The philosophy
is not to dumb down the language to the lowest common hardware denominator, but to enable the
exploitation of the best capabilities of target hardware.
For floating point operations and expression intermediate values, a greater precision can be used than the
type of the expression. Only the minimum precision is set by the types of the operands, not the maximum.
This reflects a terrible misunderstanding of floating-point arithmetic. Decades ago, scientific programmers realized that getting a computer to "just give me the best FP answer you can come up with, I'm sure it's good enough" caused headaches. That's why we have IEEE FP standards that define EXACTLY what the results should be, to the bit.
If you get different answers on different computers due to different roundoff errors, your software becomes unreliable. It's true!
People get confused by Intel's 80-bit FP arithmetic. Yes, the FPU expends some effort in rounding the 80-bit result back to 64 bits, but the result is not more accurate than a 64-bit FPU. In fact the answers will be exactly the same--this is mandated by the standard.
Anyone using floating-point arithmetic for anything serious needs to know exactly what the arithmetic model is. If Walter pursues this philosophy with his new language, he will make it unusable for numerical applications.
Walter needs to read:
David Goldberg, "What Every Computer Scientist Needs To Know About Floating Point Arithmetic," ACM Computing Surveys, vol. 23, pp. 5-48, 1991.
I could not find a copy online, but here is an interview with William Kahan, the Turing award winner who co-developed the IEEE 754 floating-point standard.
Language designers should notice that Kahan implicates of Java and Fortran at the end of the article.
Re:Because Ruby Rocks! :-)
on
Why not Ruby?
·
· Score: 1
Again the performance issue rears its ugly head, and also the issue of assignments etc. having side
effects. Sure, it can be "cool" to overload access/modification, e.g. to enforce range/consistency limits
or to create "magic" variables such as r/theta when what you're really storing is x/y. However, the cost
and potential for abuse aren't worth it. You can already get almost the same effect with explicit
accessor functions, or with a keyword attached to declarations.
The most important use for accessors is to improve performance! Often you're asking a class for a piece of data, and the class has the option of recomputing the data each time the accessor is called (easy to code) or caching the result as an instance variable (harder to code, but can run faster). If you always have an accessor, you can write it the easy way and postpone the caching optimization until after you've got the whole thing running under a profiler.
You are right, of course, that calling accessors that simply read and write an instance variable is less efficient that directly reading and writing. But using direct access for efficiency is often a premature optimization.
You say there is a potential for abuse of accessors... what is it?
I am a C++ fan. I often defend C++ from the accusations of fans of other languages. But I have to say that if I'm going to give up some efficiency, universal accessor functions would be a good thing to get in return.
In Ruby, Everything Is An Object, and typing is dynamic, so you're not going to be able to write code that's as fast as C++ anyway. The accessors are cheap in comparison!
When I was in grad school, I released some code on our research project's web page. I was told to assign copyright to the code to the university. If I recall correctly, there was an accompanying license saying that anyone could use the code for anything as long as the copyright notice is preserved.
I note that one of my colleagues, whose grad-school software is more widely used, has kept the copyright to himself and licensed his code unter LGPL. (The project is GLUI, a portable UI toolkit for OpenGL programs. Google keyword: GLUI. Hi Paul.)
Confronted with this same problem, I wrote a program to synchronize sets of mailboxes. It's a little like rsync, but it considers the messages individually, instead of treating them as files. It will propagate deletions as well as new messages, and it treats the two mail stores symmetrically. It is based on the UW IMAP c-client code, so it can handle many formats; you can then choose your format based on your MUA's preference or performance considerations. I've used it to duplicate my mail on several machines at once. You can also keep your mail in multiple formats on the same machine. http://mailsync.sourceforge.net
Slashdot Mirror
Essentially, he is saying that if you assume that the good guys are really the bad guys, and vice-versa, the whole series makes more sense. It's not particularly insightful. Just another way of saying that the movies don't make sense.
Yes, but I'm going to name my band Hyperbolic Tonicity Mustard.
...until grep returns a match, I suppose.
I tried to uncover early examples of the legendary grep+crosspost tactic. Here is the thread containing the earliest example I could find.
On Feb 9, 1992, somebody named Jim (polari!mojo@sumax.seattleu.edu) posted to alt.brother-jed:
Kibo jumps in, crossposts to a.r.k and alt.slack, and awards the Triple Grep Award and the Good Bozosity Seal of Allowedness to Merlyn LeRoy (merlyn@digibd.com).
So was the grepping inspired by the above post? Or did it start earlier?
A Big Language That Everybody Can Use For Everything could maybe have these FP datatypes:
- IEEE 754 single precision
- IEEE 754 double precision
- IEEE 754 "double-extended"-compliant type
- IEEE 754 quadruple precision
- greatest available hardware-supported precision
The D language could perhaps support only the last type initially. Then the language could be "grown" (in Steele's sense) to support the others. So not a tragedy.And less tragic still if he'd put overloaded operators back in (see Steele on Java's BigNums).
If you get different answers on different computers due to different roundoff errors, your software becomes unreliable. It's true!
People get confused by Intel's 80-bit FP arithmetic. Yes, the FPU expends some effort in rounding the 80-bit result back to 64 bits, but the result is not more accurate than a 64-bit FPU. In fact the answers will be exactly the same--this is mandated by the standard.
Anyone using floating-point arithmetic for anything serious needs to know exactly what the arithmetic model is. If Walter pursues this philosophy with his new language, he will make it unusable for numerical applications.
Walter needs to read:
David Goldberg, "What Every Computer Scientist Needs To Know About Floating Point Arithmetic," ACM Computing Surveys, vol. 23, pp. 5-48, 1991.
I could not find a copy online, but here is an interview with William Kahan, the Turing award winner who co-developed the IEEE 754 floating-point standard. Language designers should notice that Kahan implicates of Java and Fortran at the end of the article.
You are right, of course, that calling accessors that simply read and write an instance variable is less efficient that directly reading and writing. But using direct access for efficiency is often a premature optimization.
You say there is a potential for abuse of accessors... what is it?
I am a C++ fan. I often defend C++ from the accusations of fans of other languages. But I have to say that if I'm going to give up some efficiency, universal accessor functions would be a good thing to get in return.
In Ruby, Everything Is An Object, and typing is dynamic, so you're not going to be able to write code that's as fast as C++ anyway. The accessors are cheap in comparison!
I note that one of my colleagues, whose grad-school software is more widely used, has kept the copyright to himself and licensed his code unter LGPL. (The project is GLUI, a portable UI toolkit for OpenGL programs. Google keyword: GLUI. Hi Paul.)
Unfortunately, I don't think it can do hidden lines. Also, it costs money. However, it is easy to use.
Confronted with this same problem, I wrote a program to synchronize sets of mailboxes. It's a little like rsync, but it considers the messages individually, instead of treating them as files. It will propagate deletions as well as new messages, and it treats the two mail stores symmetrically. It is based on the UW IMAP c-client code, so it can handle many formats; you can then choose your format based on your MUA's preference or performance considerations. I've used it to duplicate my mail on several machines at once. You can also keep your mail in multiple formats on the same machine. http://mailsync.sourceforge.net