Re: Are these all really true ?

>>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
else
index = $1 ", x"
foo[index] = ...


Of course a real example is a bit more complex, but I think that illustates
the point.


>>>* Memory is free, speed is what is worth optimizing.
>
>>OK.
>
>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: scott@infoadv.mn.org
Information Advantage, Inc. work: (612) 820-3846
Edina, MN home: (612) 488-5406
--

Return to the comp.compilers page.
Search the comp.compilers archives again.