Re: "safer" Euphoria
David Cuny writes:
> [Catching bugs vs. Saving Data]
As people may have figured out by now, I am
in favor of automatically catching bugs as soon
as possible, rather than quietly ignoring them and
hoping that the program will somehow continue and
do the right thing.
As I've said before, RDS has implemented Euphoria
in such a way that the cost of subscript checking
and uninitialized variable checking are both almost zero.
An optimization that I added a few days ago has reduced
the cost of uninitialized variable checking even further.
If both of these checks could be turned off by the programmer,
the speed increase would only be on the order of 1 or 2%.
I therefore reject the notion that these checks are so
expensive that we need a way to turn them off in shippable
code.
The other argument is that stopping the program will
cause data loss. This is sometimes true. It is also sometimes
true that *not* stopping the program will cause data loss.
I'd rather lose data in a situation where I know that the
program has failed, than have my data *quietly* corrupted during
a run that appeared to be normal. I'd rather lose my editing
session, than have the editor *quietly* insert an incorrect
character into my source program. (x = x + 1 becomes x = x + 2).
I'd rather have my C compiler crash, than continue to quietly
produce slightly incorrect machine code.
> However, Maguire notes that the debug statements are
> ONLY for in-house testing, placed in #ifdef...#endif and
> assert macros.
On a compiler project I worked on several years ago, I deliberately
*left in* lots of redundant debug checks and assertions in
#ifdef code. The compiler ran 5% slower and was shipped to the customers.
This approach paid off in a big way. Users couldn't
care less about the extra 5%, but they were able to report
*meaningful* bugs back to me, which I could easily fix. Otherwise
it could have wasted days of their time and days of my time to track down
the resulting bugs in the machine code. (I also had some
extra, very expensive, checks that I only turned on for in-house
debugging).
(The debug version of Euphoria at RDS has tons of checks. The
released version has almost none, since speed is very
important.)
There are many ways of protecting a users data. For instance
an editor could save the buffer to a temp file every once in a while.
When I worked on a database management system a few years
ago, there was a carefully worked out algorithm for committing
and rolling-back records (with logs of transactions).
The software, or the machine, could crash at any point and
you wouldn't corrupt your database.
Still, I am interested in investigating a global exception
handling mechanism of some kind.
> 90% less bugs = 90% less registrations
> -----------------------------------------
> I suspect this would be the biggest reason for Robert not to have
> automatic range checks.
As a shareware author who has developed a relatively-unknown
language and interpreter, I am *really* glad that Euphoria
does a lot of run-time checking, but *not* for the reason you
suggest.
Suppose there were no run-time checks. Someone downloads
Euphoria, writes a simple program that he believes to be correct,
runs it, and *crash* - his whole system goes down in flames.
Is he going to believe that his program was at fault? Or is he
going to blame the $#%$#%!!! shareware program he just
downloaded?
Regards,
Rob Craig
Rapid Deployment Software
http://members.aol.com/FilesEu/
|
Not Categorized, Please Help
|
|
