|[17 earlier articles]|
|Re: Are these all really true ? J.Biddiscombe@rl.ac.uk (The Lord of Darkness) (1995-09-27)|
|Re: Are these all really true ? firstname.lastname@example.org (1995-09-28)|
|Re: Are these all really true ? email@example.com (1995-09-28)|
|Re: Are these all really true ? firstname.lastname@example.org (Rodney Bates) (1995-10-03)|
|Re: Are these all really true ? email@example.com (Jeremy Carroll) (1995-09-29)|
|Re: Are these all really true ? firstname.lastname@example.org (Stefan Monnier) (1995-10-02)|
|Re: Are these all really true ? email@example.com (Scott Nicol) (1995-10-02)|
|Re: Are these all really true ? firstname.lastname@example.org (1995-10-02)|
|Re: Are these all really true ? email@example.com (1995-10-03)|
|Re: Are these all really true ? firstname.lastname@example.org (1995-10-16)|
|Re: Are these all really true ? email@example.com (1995-10-04)|
|Re: Are these all really true ? firstname.lastname@example.org (1995-10-11)|
|Re: Are these all really true ? email@example.com (1995-10-12)|
|From:||Scott Nicol <firstname.lastname@example.org>|
|Date:||Mon, 2 Oct 1995 14:11:28 GMT|
>>Better in what sense? There are fewer hidden side-effects, but
>>side-effects aren't always a bad thing. It really depends on what
>>the language is designed to do. For example, awk would be unusable
>>if it were strongly typed.
>Oddly enough, I have a paper design for a "Typed AWK" [...]
>the Typed AWK paper design is a strongly typed _language_ but programs
>never explicitly indicate types; it's all done by type inference.
I guess I disagree with you on this one. There are many times when
I like to use an awk variable as both a number and a string, ie:
if (NF == 5)
index = $1 + 3
index = $1 ", x"
foo[index] = ...
Of course a real example is a bit more complex, but I think that illustates
>>>* Memory is free, speed is what is worth optimizing.
>Academic work in databases is based very much on the idea that memory
>is not free, that figuring out what to bring into memory when and how
>long to keep it is hard but has huge payoffs.
Oddly enough :-), I work for a company that writes software for
multi-dimensional database analysis. One of our customers has a
database of over a terabyte, and the machine feeding off it has 2GB
of RAM. Its really neat to do a "ps" and see a core image size of
2xxxM. There is a limit to how much memory you can use, but memory
is certainly much cheaper than it used to be. With memory at anywhere
from $40 to $100 per meg (depending on type), 2GB of core is $80k - $200K.
If you have a terabyte of data, chances are pretty good that you have
a few hundred thousand bucks to throw around for more memory.
>>>* Formal specifications yield correct programs.
>>You can't prove correctness for anything other than the smallest
>>program. If specifications yield correct programs, there would
>>be no need for regression tests.
>Nobody said anyting about proving correctness.
>_Informal_ specifications sure as heck don't yield correct programs.
There is no such thing as correct programs, for any but the smallest
program. Informal specifications can yield programs that are as
robust as programs from formal specifications. Having worked in a
number of companies (some very large, some very small), I can tell
you that specifications never keep up with the code. I prefer the
sparse approach to specifications - a page or two will do.
Scott Nicol email: email@example.com
Information Advantage, Inc. work: (612) 820-3846
Edina, MN home: (612) 488-5406
Return to the
Search the comp.compilers archives again.