type safety in LISP
marcel haesok
...."Delegates ensure that the callback method is type-safe (in keeping with
one of the most important goals of the DOTNET Framework)............"
which seems to suggest that "type-safety" is a big issue in real programming
world.
Lisp, on the other hand, from the readings I've done here, seems noted for
its
"dynamism" of type. IE, "type-versatility" of some sort.......
Is LISP type-safe?
Tim Daly, Jr.
> I was reading C# book by Jeffery Richter. Quote:
*snip*
> Is LISP type-safe?
(declare (optimize (safety 3) (speed 0)))
Yes.
(declare (optimize (safety 0) (speed 3)))
No.
Lisp is by smart people, for smart people. Is C#?
-Tim
Chris Gehlker
haesok" <novu...@attbi.com> wrote:
> I was reading C# book by Jeffery Richter. Quote:
> ...."Delegates ensure that the callback method is type-safe (in keeping with
> one of the most important goals of the DOTNET Framework)............"
>
> which seems to suggest that "type-safety" is a big issue in real programming
> world.
It's a big issue in the sense that it's very controversial. There are many
very smart people who think it sucks. Other very smart people think it's
essential. See <http://perl.plover.com/yak/typing/notes.html> for a gentle
introduction to the controversy that doesn't take a side.
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----
marcel haesok
"Chris Gehlker" <geh...@fastq.com> wrote in message
news:BA1715B7.242D3%geh...@fastq.com...
Thanks for the link and quote from the link:
"So given my conclusion, that static typing, as implemented by languages
like C and Pascal, is a failure, what can we do about it? One strategy is to
simply give up and forget about static typing. This strategy has been very
successful. Languages that do this include APL, the perennially popular
Lisp, the Unix scanning language AWK, and of course Perl."
Incidentally, I was surprised by the phrase "the PERENNIALLY popular Lisp".
So its seems that LISP is not the 'ELITE LANGUAGE' that many here
newsgroupers seem to believe, but a very POPULAR language.
Although I doubt if LISP is exactly a bigmac hamburger.
Chris Gehlker
haesok" <novu...@attbi.com> wrote:
> Incidentally, I was surprised by the phrase "the PERENNIALLY popular Lisp".
>
> So its seems that LISP is not the 'ELITE LANGUAGE' that many here
> newsgroupers seem to believe, but a very POPULAR language.
>
> Although I doubt if LISP is exactly a bigmac hamburger.
I think he was using "popular" in the sense of "well know and highly
regarded." There are some who think that Lisp is like a Humvee, just the
thing you need if you are heading off into uncharted and possibly dangerous
territory with no support. But maybe not the best choice for going down to
the corner market. You might be stylin' but you are also wasting gas.
Could be that's just the folks I hang around with. They think Lisp is great
but they might still say "You used Lisp for that?" if they thought some
lighter weight language was more appropriate to the problem.
Erik Naggum
| I was reading C# book by Jeffery Richter. Quote: "Delegates ensure that
| the callback method is type-safe (in keeping with one of the most
| important goals of the DOTNET Framework)"
This is a peculiar case of post hoc, ergo propter hoc argumentation.
It is not type-safe /because/ of the delegates. The delegates have been
designed this way because the language implements type-safety that way.
| which seems to suggest that "type-safety" is a big issue in real
| programming world.
It is. But just like the most dangerous man in the world has decided to
scare almost 300 million people out of their wits in the name of national
security and safety, stripping them of freedoms and rights at a pace that
rivals the enemy back when another president defined the four freedoms in
response to not dissimilar threats 60 years earlier, the concept of "type-
safety" can also be thought of in terms of the freedoms you give up, or in
terms of the differences in implementation. Where one president promises
his people freedom of speech and freedom from fear in response to threats
(very much like Lisp offers freedom of expression when solving the problem
of type safety in response to dangerous program errors), another clamps
down on the freedom of expression and severely limits what the population
may say and offers them fear in response to threats (very much like C++ is
extremely restricting and has its users live in perennial fear of abuse of
the necessary type-casting operators).
It should be obvious from the above that it is not the threat itself that
defines the response, but the "personality" of the language (president).
The idiot will cave in to the fear and cannot see other solutions than to
abridge the freedoms of those he obviously believes he provides "safety"
in so doing. The intelligent will transcend the fear and determine the
most pacifying strategy, the one showing the most strength and power and
understanding of the threat involved, and then take advantage of it.
| Lisp, on the other hand, from the readings I've done here, seems noted
| for its "dynamism" of type. IE, "type-versatility" of some sort.......
It is in fact your understanding of "type safety" that is so limited that
you are not even aware of it. Please consider a brief study of logic so
you avoid committing so many annoying fallacies.
Some languages are "statically typed", which means that the /compiler/ is
the last element of the entire production line from programmer to system
execution of the binary that knows the type of anything -- the execution
environment deals only with bits that have no type at all. (Recall that
a bit is a bit is a bit (not unlike a rose), but what it means depends on
what the observer wants it to mean.) If you want type safety in a system
where the compiler is the last to know, you must ensure that the compiler
does indeed know, which is an incredibly complex task. Some languages
are therefore "dynamically typed", which means that the type information
/does not evaporate/ during processing. Think of compilation as cooking.
Dynamic typing means the steak is juicy and still a little red, like red
meat is supposed to be. Static typing means you burnt it to a crisp.
Dynamic typing means that the /object/ carries the type information.
Static typing means that storage container carries it and the object
inside it has lost its type information.
Some people, when they look at dynamically typed languages from the
statically typed language vantage point, seem to believe that since the
storage containers are no longer marked and the compiler cannot ensure
that only the appropriate kinds of objects are put into them, all hell
must break loose. This despite the glaring fact that "object-oriented"
programming in these languages introduce some measure of run-time type
information. I have a hard time actually imagining what went wrong with
people who think this way. It is so short-sighted, so devoid of any
thinking skills, so utterly /absent/ of intelligence, that one can only
marvel at the ability of the human species to produce this kind of people
and yet not destroy itself.
Just because you do not know does not mean that you can draw any form of
useful conclusions about that which you do not know. I wonder why this
is not drilled into the heads of people in kindergarten. In a dynamically
typed language, the storage containers are much more generic than the
storage containers in the statically typed languages. You do not have to
re-introduce the type information to the compiler when you pick an item
out of a collection in a properly designed language! The object already
carries type information around with it. Storage containers in Lisp can
hold objects of any type. The notion that a container for type T1 can
hold an object of type T2 is pretty fundamental to the "object-oriented"
crowd, yet when it comes to actually implementing it fully, they acquire
an amazing array of delusions about efficiency which they either ignored
or did not even consider when they were talking their heads off about the
amazing power of object-orientation, possibly because their understanding
of "object-orientation" is based in "encapsulation" and "inheritance" and
/not/ based on type-specific discrimination, which is far more important.
For some readers, there is evidently a /qualitative/ difference between
addition of numbers of various types and sending "messages" to objects of
various genealogy from a common ancestor. It appears to me that the only
cause for this rather amazing improvidence is the misguided notion that
it cannot be a "class" (or type) unless it stores some data in a container.
Thus an /integer/ cannot be a class, functions are not defined on /numbers/
because the "number" is not a structure that contains a virtual function
pointer table. Instead of thinking about types and functions on types,
the inverse notion that the type owns the function cannot but cause the
most heinous malabstraction.
| Is LISP type-safe?
Suppose I argue that the core purpose of the family is to ensure that the
offspring can grow up in safety and comfort and that the core purpose of
society is to enable families to provide such measures to their offspring,
which is a brief summary of the Republican position. Suppose I wish to
/implement/ this by extending the embrace of the familty to the entire
popularion and therefore secure the state-supplied safety and comfort
through state ownership of all means of production, which is a brief
summary of the Communist position. Are Republicans Communists?
If the only way you can imagine type safety is through state control and
loss of freedom, then you will have to conclude that the implementation
thereof does not matter, and since all political schools of thought have
been concerned with the physical and extended safety of the population
(sometimes through exclusivity as to what constitutes the "population"),
there can be no difference between them. If, however, you aim for a much
more abstract understanding of "safety" and grasp that it can be taken
care of at a different level than controlling all people (or objects), by
letting individual people (objects) remain free to be what they want, the
world suddenly looks very different. In a world where people believe that
only control over other people can produce safety, you get a suspicious
lot who are far from safe, but instead fear those they cannot control (as
happened in other countries that tried GWB's censorship and surveillance
methods). In a world where people trust that those who violate contracts
(both social and legal) can be punished and damages repaid, the need for
individual suspicion and fear has no place. Just as the right to bear
arms was a necessity at a time when the police could scarcely care less
(even if they had had the resources) and the gun control crowds primarily
wanted to disarm the lower classes for fear of armed uprising, institution
of a /working/ police force that the population actually trusts to protect
them obviates the need for personal armories, a programming language that
provides /no/ safety infrastructure, body (core) dumps in response to any
violation, and a direct threat to anyone who carelessly trusts a stranger,
/should/ have been obsoleted by a language that offers an infrastructure
that maintains security and trustworthiness.
Static typing in programming languages is closely akin to the need to bear
arms and the purported need to do all this anal compile-time checking is
precisely to keep the lower classes in check, the uneducated hoodlums who
program for food and wipe your windshield for cash and whose code more
likely than not will do something you would rather it refrain from.
Dynamic typing in programming languages means you can trust even code that
you would not in the static typing world, because it is so much harder to
lie successfully. In the static typing world, you need someone else (the
compiler) to tell you that the code you talk to is OK before you can trust
the /data/ it gives you, and some of the most insidious backstabbers you
can think of imagine some draconian measure like "Palladium" because they
are unable to escape the confines of their mental models, which produced
the virus vehicles they think they can halt by running them off the road,
and it all goes downhill from there.
The moral of this story that I want you to take with you is that there are
more /times/ to get type safety than compile-time. It is in fact a /lot/
easier to get true type safety if you do /not/ do it at compile-time, but
people who are massively inept at programming think that if they can catch
some bugs at compile-time, that somehow makes all the remaining bugs less
important and hard to catch. This is in fact wrong. Empirically, people
who believe their compilers will catch bugs for them because it enforces a
ridiculously irrelevant aspect of the task of programming, produce /more/
bugs than people who do their testing right and do not believe in a class
society for bugs (such that they can ignore or repress some bugs).
--
Erik Naggum, Oslo, Norway
Act from reason, and failure makes you rethink and study harder.
Act from faith, and failure makes you blame someone and push harder.
Pascal Costanza
> The moral of this story that I want you to take with you is that there are
> more /times/ to get type safety than compile-time. It is in fact a /lot/
> easier to get true type safety if you do /not/ do it at compile-time, but
> people who are massively inept at programming think that if they can catch
> some bugs at compile-time, that somehow makes all the remaining bugs less
> important and hard to catch. This is in fact wrong.
However, there are counter examples. Here is a quote by Guy Steele,
about his experience with Haskell which he used for a particular task:
"In the end, I have to say that the type checking was more help than
hindrance, especially in the construction of the continuations building
block. I had the same experience with Haskell that I had twenty years
ago with ECL [...] (which was, in effect, also a strongly-typed dialect
of Lisp): almost always, once I made the type checker happy, the program
was correct." (in "Building Interpreters by Composing Monads", POPL'94)
> Empirically, people
> who believe their compilers will catch bugs for them because it enforces a
> ridiculously irrelevant aspect of the task of programming, produce /more/
> bugs than people who do their testing right and do not believe in a class
> society for bugs (such that they can ignore or repress some bugs).
That's very interesting - can you point to a study that supports this
assessment?
Pascal
--
Given any rule, however ‘fundamental’ or ‘necessary’ for science, there
are always circumstances when it is advisable not only to ignore the
rule, but to adopt its opposite. - Paul Feyerabend
Pascal Costanza
> On 12/6/02 8:54 PM, in article VheI9.261624$QZ.39282@sccrnsc02, "marcel
> haesok" <novu...@attbi.com> wrote:
>
>
>>I was reading C# book by Jeffery Richter. Quote:
>>...."Delegates ensure that the callback method is type-safe (in keeping with
>>one of the most important goals of the DOTNET Framework)............"
>>
>>which seems to suggest that "type-safety" is a big issue in real programming
>>world.
>
>
> It's a big issue in the sense that it's very controversial. There are many
> very smart people who think it sucks. Other very smart people think it's
> essential. See <http://perl.plover.com/yak/typing/notes.html> for a gentle
> introduction to the controversy that doesn't take a side.
Another good source of information, especially on the terminology, is
the paper "Type Systems" by Luca Cardelli. (to be found at
http://www.luca.demon.co.uk/Bibliography.html, for example
http://research.microsoft.com/Users/luca/Papers/TypeSystems.pdf)
Raymond Wiker
> Erik Naggum wrote:
>
> > Empirically, people
> > who believe their compilers will catch bugs for them because it enforces a
> > ridiculously irrelevant aspect of the task of programming, produce /more/
> > bugs than people who do their testing right and do not believe in a class
> > society for bugs (such that they can ignore or repress some bugs).
>
> That's very interesting - can you point to a study that supports this
> assessment?
I'd say that there is quite a large number of programmers who
think that, if the code is acceptable to the compiler, it must be all
right. Part of their work pattern is to make random or semi-random
changes to the code in order to make the compiler happy.
--
Raymond Wiker Mail: Raymon...@fast.no
Senior Software Engineer Web: http://www.fast.no/
Fast Search & Transfer ASA Phone: +47 23 01 11 60
P.O. Box 1677 Vika Fax: +47 35 54 87 99
NO-0120 Oslo, NORWAY Mob: +47 48 01 11 60
Try FAST Search: http://alltheweb.com/
Thomas Stegen
> However, there are counter examples. Here is a quote by Guy Steele,
> about his experience with Haskell which he used for a particular task:
>
> "In the end, I have to say that the type checking was more help than
> hindrance, especially in the construction of the continuations
> building block. I had the same experience with Haskell that I had
> twenty years ago with ECL [...] (which was, in effect, also a
> strongly-typed dialect of Lisp): almost always, once I made the type
> checker happy, the program was correct." (in "Building Interpreters by
> Composing Monads", POPL'94)
Haskell is dynamically typed, is it not? Which basically means that
the above is not a counter example...
>> Empirically, people who believe their compilers will catch bugs
>> for them because it enforces a ridiculously irrelevant aspect of
>> the task of programming, produce /more/ bugs than people who do
>> their testing right and do not believe in a class society for
>> bugs (such that they can ignore or repress some bugs).
>
> That's very interesting - can you point to a study that supports this
> assessment?
>
I think that is is pretty obvious that people who do not do their
testing right produces more bugs than people who do their testing
right. But I do not think that there is any automatic correlation
between using a language/compiler which enforces "a ridicolously
irrelevant aspect [..] of programming" and not doing testing right.
There might be some correlatation between trusting the compiler
to do this well and not doing proper testing though. But this is a
people problem more than it is a language or compiler problem.
That the language leads them to believe this is of course part of
the problem, but unthinking brains should take their part of the
blame as well. And I am not so sure that these people will benefit
from using Common Lisp.
--
Thomas.
Pascal Costanza
> Pascal Costanza wrote:
> > However, there are counter examples. Here is a quote by Guy Steele,
> > about his experience with Haskell which he used for a particular task:
> >
> > "In the end, I have to say that the type checking was more help than
> > hindrance, especially in the construction of the continuations
> > building block. I had the same experience with Haskell that I had
> > twenty years ago with ECL [...] (which was, in effect, also a
> > strongly-typed dialect of Lisp): almost always, once I made the type
> > checker happy, the program was correct." (in "Building Interpreters by
> > Composing Monads", POPL'94)
>
> Haskell is dynamically typed, is it not? Which basically means that
> the above is not a counter example...
>
No, it's statically typed.
Pascal
P.S.: Thanks for the other comments - nothing to add.
Thomas Stegen
>
> No, it's statically typed.
Ok, but how does the polymorphism work then?
--
Thomas.
Pascal Costanza
I don't know exactly what you mean with this question. Haskell uses type
inference to determine static type soundness, so if the same function
can be used in different circumstances this is usually possible. You
don't need to declare the types of variables, etc. Information about
Haskell can be found at http://www.haskell.org
Does this help?
Pascal
Bruce Hoult
Thomas Stegen <tst...@cis.strath.ac.uk> wrote:
As with other HM languages (SML/NJ, CAML), a type can be polymorphic
(i.e. a union type), in which case anywhere it is used it must be either
passed to another place expecting the same polymorphic type, or else
must be broken down into *all* the possibilities using a
case/switch-like construct.
If you can't prove to the compiler that your case statement covers *all*
the possibilities then you have to add a default branch that does
something appropriate. Such as throw an exception.
Static typing people tell me that this is somehow different from the
compiler automatically inserting the exact same runtime check and
exception in dynamically-typed languages such as Dylan or Lisp or
Smalltalk.
-- Bruce
Thomas Stegen
> Thomas Stegen wrote:
>
>
> I don't know exactly what you mean with this question.
It was an idiotic question. Thanks anyway.
--
Thomas.
Simon András
Erik Naggum
| However, there are counter examples.
A counter-example is an example of something quite different than
what has been claimed, intending to refute the claims. However, I
made no claims about Haskell, nor any claims to universality that
can be shot down with a simple counter-example. I do know enough
about logic to avoid that kind of stupid traps, and so should you.
You have shown an /additional/ piece of information, namely that
static typing can be done better than the languages that were under
discussion in this case. Someone who reads about C# and asks some
questions about type-safety is unlikely to have the prerequisites to
understand what Haskell is, as well as being completely unable to
enter a context where it makes sense to talk about that language.
Pascal Costanza
> * Pascal Costanza
> | However, there are counter examples.
>
> A counter-example is an example of something quite different than
> what has been claimed, intending to refute the claims. However, I
> made no claims about Haskell, nor any claims to universality that
> can be shot down with a simple counter-example. I do know enough
> about logic to avoid that kind of stupid traps, and so should you.
I have quoted the following statement of yours.
[...]
> people who are massively inept at programming think that if they can
> catch some bugs at compile-time, that somehow makes all the remaining
> bugs less important and hard to catch. This is in fact wrong.
Then I have quoted the following statement by Guy Steele: "[...] almost
always, once I made the type checker happy, the program was correct."
These two statements contradict each other. There are only few kinds of
differences that are stronger than contradiction. The situation Guy
Steele describes _is_ a counter example.
> Someone who reads about C# and asks some
> questions about type-safety is unlikely to have the prerequisites to
> understand what Haskell is, as well as being completely unable to
> enter a context where it makes sense to talk about that language.
I don't think so.
Erik Naggum
| [Type safety is] a big issue in the sense that it's very controversial.
Really? There is no controversy over type safety that I know of.
There is great controversy over how to implement it, however. This
is not unlike the political scene, where /nobody/ argues that each
individual should be left entirely alone to fend for himself. The
many different ways political groups argue for the implementation
of safety measures and carefully balancing them against freedoms
and human rights should not be interpreted to mean that those who
do not agree with any particular measures to implement safety and
social and national security are fighting against safety and social
and national security. You would have to be astonishingly ignorant
of history, human nature, and politics to believe that core human
needs are controversial because their means of implementation is.
So, too, with type safety in programming languages. /Nobody/ wants
programming languages that only ship bits around. /Everybody/ is
in full agreement with everybody else that even though processors
ship machine words around in general-purpose registers and memory
cells that can hold any machine word, it is considered imprudent to
design programming languages that do not retain type information in
some form and ensure that a machine word that represents a value of
one type is not confused with another. Controversial this is not.
| There are many very smart people who think it sucks.
Can you name one person who thinks type safety sucks who is not
also a complete moron with zero understanding of what it means?
If /you/ confuse type safety with explicit, static typing, that is
your problem and you should upgrade yourself forthwith. Please do
not repeat your conflated misunderstanding.
Erik Naggum
| These two statements contradict each other.
Wrong. /Think/, now. How can I flatly reject your claims, which
you only repeat with that stubborn "I'm right, so there" attitude?
Could it be that you bring to your reading of what other people
write so much baggage that what other people write is immaterial
for your conclusions?
| I don't think so.
You have never thought long enough to realize the value of context,
so why should you start now?
Think, even though it hurts. You may actually learn something new,
and it may tear down several of your personal beliefs. One of the
most obvious ones is that you appear to believe that knowledge of
the truth does not need to be acquired through mental effort, but
that it is sufficient for something to just "be true". Another is
that you appear to believe that when you read something, only you
have the proper understanding of what it means and that the author
in particular has lost the right to tell you that it looks like you
have misunderstood. Both have in common that you appear to believe
that your interpretation of something is "the truth", infallibly.
To be blunt, I find this aspect of your behavior extremely annoying.
Pascal Costanza
> * Pascal Costanza
> | These two statements contradict each other.
>
> Wrong.
If this is the wrong conclusion, then the other alternative is that you
deliberately used the term "statically typed languages" to refer only to
the set of languages that are based on explicit typing. [1] However, the
correct usage of that term also covers languages based on implicit
typing (or type inference). If your intention was to exclude the latter
kind of languages you should have made that explicit. I have considered
the quote by Guy Steele to be a counter example under the assumption
that you have used the term "statically typed language" correctly. (In
this case it would be a counter example!)
I consider it a fundamental mistake to use a general term for a proper
subset without saying so. I didn't expect you to be more liberal in that
regard.
Pascal
[1] This would also explain your statement about me having "shown an
/additional/ piece of information".
Nils Goesche
> Erik Naggum wrote:
> > * Pascal Costanza
> > | These two statements contradict each other.
> > Wrong.
Now I am getting curious myself: The statements you explicitly
quoted were:
# people who are massively inept at programming think that if
# they can catch some bugs at compile-time, that somehow makes
# all the remaining bugs less important and hard to catch. This
# is in fact wrong. (Erik)
# almost always, once I made the type checker happy, the program
# was correct. (Guy Steele)
These two statements do indeed /not/ contradict each other. Why
do you think they do?
> I consider it a fundamental mistake to use a general term for a
> proper subset without saying so.
I am not sure why that would apply here, but you shouldn't. The
only field where this is actually feasible is mathematics. In
all other fields the exceptions have to be inferred from the
particular context because the real world is simply so complex
(and not clearly defined ;-) that it isn't possible to explicitly
mention all special cases all the time. You couldn't even say
something like ``Americans speak English.´´ or ``It is cold.´´ or
``Margaret Thatcher was cool.´´ without tons of further
qualifications. (There might be other people named ``Margaret
Thatcher´´ apart from the one I mean, for instance.)
Regards,
--
Nils Gösche
Ask not for whom the <CONTROL-G> tolls.
PGP key ID #xD26EF2A0
Chris Gehlker
Goesche" <n...@cartan.de> wrote:
> Pascal Costanza <cost...@web.de> writes:
>
>> Erik Naggum wrote:
>>> * Pascal Costanza
>>> | These two statements contradict each other.
>>> Wrong.
>
> Now I am getting curious myself: The statements you explicitly
> quoted were:
>
> # people who are massively inept at programming think that if
> # they can catch some bugs at compile-time, that somehow makes
> # all the remaining bugs less important and hard to catch. This
> # is in fact wrong. (Erik)
>
> # almost always, once I made the type checker happy, the program
> # was correct. (Guy Steele)
>
> These two statements do indeed /not/ contradict each other. Why
> do you think they do?
They certainly appear contradictory to me. I'm willing to make the following
assumptions from context:
"people who are massively inept .." means "only people who are massively
inept"
Pascal does not believe Guy Steele was massively inept at programming
The bugs in a set of bugs which is "almost always" empty are both less
important and easier to catch than the bugs in a set which contains "some
bugs."
Patrick W
> Erik Naggum wrote:
> > * Pascal Costanza
> > | These two statements contradict each other.
> > Wrong.
>
> If this is the wrong conclusion, then the other alternative is that
> you deliberately used the term "statically typed languages" to refer
> only to the set of languages that are based on explicit typing.
Another alternative: the mob's belief in the "safety" of static typing
has nothing to do with a master programmer's experience of same
(regardless of whether you're talking about explicit typing or static
typing in general). Is it conceivable to you in general terms that a
bunch of idiots can believe in the benefits of something, and a
talented person can *experience* the benefits of the same thing, and
yet the idiots still be mistaken in their beliefs?
I see no contradiction here. Guy Steele's good experiences with
Haskell do not provide a "counter example" to the notion that many
"massively inept programmers" believe that static eliminates the most
import bugs, and are wrong to believe it.
Tom Lord
Our ability to form quite sane abstractions that thwart even the
fanciest static type checkers exceeds the ability of static type
checker generators to keep up.
Well, duh ... that's just an instance of the "All we have to do is
solve the halting problem" bug.
And the value of putting on binders? Well, sure... I don't mind
driving across various bridges. That doesn't mean bridge designers
have the final say on mechanical engineering.
This debate goes in Wired's "tired" column.
Erik Naggum
| If this is the wrong conclusion, then the other alternative is that
| you deliberately used the term "statically typed languages" to refer
| only to the set of languages that are based on explicit typing. [1]
That is what people who believe books about C# believe.
| However, the correct usage of that term also covers languages based
| on implicit typing (or type inference).
Yes, Pascal, there is only one correct usage, and it is yours.
Instead of being such a fucking annoying dipshit all the time, how
about suggesting the terminology that you /would/ be happy with so
we can get past this goddamn pestering of yours? I shall endeavor
to use the terminology your anal-retentive highness suggests simply
because I hate your senseless abruptions and interruptions of what
was, or at least could have been, a discussion of something other
than your pathetic needs for the "correct" terminology.
| If your intention was to exclude the latter kind of languages you
| should have made that explicit.
So sue me. You seem to forget that there might be disagreement on
the things you pronounce your One True Judgment on. Please learn
that I do not agree with you that "static typing" /usefully/ covers
your pet functional languages. So many things become impossible to
discuss when you just /have/ to share your opinions on this matter.
I also fail to see how I can make you happy. No matter what people
say about "statically typed languages", there is always room for
some weirdo languages and its religious followers to scream "but
/my/ language is different!". The whole /point/ is that your pet
languages are different from the entire rest of the family it tries
very hard to be a member of, but is not.
| I consider it a fundamental mistake to use a general term for a
| proper subset without saying so.
I consider it a fundamental mistake to leap out of context with a
different specific meaning of a general concept than the one that
is actually in use. You annoy me about as much as the morons who
can never grasp that "hacker" /also/ means a malicious idiot, but
have to quip "the correct usage is cracker" solely to annoy people.
If you have such a massive problem coping with the usage that other
people accept, could you at the very least try to behave in public
so you do not derail other people's discussions all the time?
| I didn't expect you to be more liberal in that regard.
There we have it. Your expectations. I appreciate that you are
/finally/ beginning to become aware of their contribution.
| [1] This would also explain your statement about me having "shown
| an /additional/ piece of information".
Amazing! You are able to connect the dots. Congratulations!
Have I made it clear yet that you piss me off? Why do you have to
continue? Are social graces not part of your touchy-feely methods?
That you, of all people, value anal-retentive "correctness" over
the ability of other people to discuss something different from
your pet peeves is actually pretty sickening since you also attack
those who correct others. You /disgust/ me, Pascal Costanza.
Thomas Stegen
> "people who are massively inept .." means "only people who are massively
> inept"
>
> Pascal does not believe Guy Steele was massively inept at programming
This assumption makes the two statements irrelevant to each other since
they do not spply to the same people (or the same context if you
prefer). There are the inept people to which the first statement applies
and there is the Guy Steele people to which the second statement
applies. Neither statement applies meaningfully to both.
Saying that people are massively inept because they believe strongly
in certain types of static typing is putting the cart in front of the horse.
--
Thomas.
Pascal Costanza
> Pascal Costanza <cost...@web.de> writes:
>
>
>>Erik Naggum wrote:
>>
>>>* Pascal Costanza
>>>| These two statements contradict each other.
>>> Wrong.
>>
>
> Now I am getting curious myself: The statements you explicitly
> quoted were:
>
> # people who are massively inept at programming think that if
> # they can catch some bugs at compile-time, that somehow makes
> # all the remaining bugs less important and hard to catch. This
> # is in fact wrong. (Erik)
>
> # almost always, once I made the type checker happy, the program
> # was correct. (Guy Steele)
>
> These two statements do indeed /not/ contradict each other. Why
> do you think they do?
Erik was talking about statically typed languages and Guy Steele uses
Haskell in his paper, which is a statically typed language. Especially,
Guy Steele talks about an experience with Haskell where the type checker
helped to develop correct code. This contradicts Erik's assessment that
compile-time checks don't guarantee the absence of bugs. Of course, this
only holds under the assumption that Erik used "statically typed
languages" as the general term that it is.
>
>
>>I consider it a fundamental mistake to use a general term for a
>>proper subset without saying so.
>
>
> I am not sure why that would apply here, but you shouldn't. The
> only field where this is actually feasible is mathematics. In
> all other fields the exceptions have to be inferred from the
> particular context because the real world is simply so complex
> (and not clearly defined ;-) that it isn't possible to explicitly
> mention all special cases all the time. You couldn't even say
> something like ``Americans speak English.´´ or ``It is cold.´´ or
> ``Margaret Thatcher was cool.´´ without tons of further
> qualifications. (There might be other people named ``Margaret
> Thatcher´´ apart from the one I mean, for instance.)
We are talking about programming languages here. "Statically typed"
means "type checking carried out statically", i.e. at compile-time.
Languages based on implicit typing check their types statically. We are
dealing with well-defined terms that don't depend on context.
Pascal
--
Pascal Costanza University of Bonn
mailto:cost...@web.de Institute of Computer Science III
http://www.pascalcostanza.de Römerstr. 164, D-53117 Bonn (Germany)
Pascal Costanza
This wasn't the issue at hand. Here is Erik's quote again:
[...]
> people who are massively inept at programming think that if they can
> catch some bugs at compile-time, that somehow makes all the remaining
> bugs less important and hard to catch. This is in fact wrong.
I was referring to the very last sentence. ("This is in fact wrong.") I
don't think Erik wanted to deny the fact that some people believe in the
usefulness of compile-time checks, but he wanted to deny the usefulness
of compile-time checks as such.
Pascal Costanza
> * Pascal Costanza
> | If this is the wrong conclusion, then the other alternative is that
> | you deliberately used the term "statically typed languages" to refer
> | only to the set of languages that are based on explicit typing. [1]
>
> That is what people who believe books about C# believe.
This doesn't make it right.
> | However, the correct usage of that term also covers languages based
> | on implicit typing (or type inference).
>
> Yes, Pascal, there is only one correct usage, and it is yours.
No, it's not mine. I have already pointed to a paper that sorts out the
terminology in a consistent way. Here is the link again:
http://research.microsoft.com/Users/luca/Papers/TypeSystems.pdf
Some people actually benefit from reading.
> Instead of being such a fucking annoying dipshit all the time, how
> about suggesting the terminology that you /would/ be happy with so
> we can get past this goddamn pestering of yours?
I have already done that in another message of the current thread.
(asu86p$fc2$2...@newsreader2.netcologne.de). I have repeated the link to
the paper above. I am looking forward to an alternative suggestion of yours.
> | If your intention was to exclude the latter kind of languages you
> | should have made that explicit.
>
> So sue me. You seem to forget that there might be disagreement on
> the things you pronounce your One True Judgment on. Please learn
> that I do not agree with you that "static typing" /usefully/ covers
> your pet functional languages.
Haskell is not my pet language. "Static typing" means "type checking
carried out statically", i.e. at compile-time. Haskell checks types at
compile-time. There's no ambiguity involved here.
> | I consider it a fundamental mistake to use a general term for a
> | proper subset without saying so.
>
> I consider it a fundamental mistake to leap out of context with a
> different specific meaning of a general concept than the one that
> is actually in use.
"Statically typed language, restricted to the set of languages that are
based on explicit typing" is a specific case of a general concept, not
the other way around.
BTW, I am still interested in the foundation (papers, links, etc.) that
you base the following claim of yours on.
> Empirically, people who believe their compilers will catch bugs
> for them because it enforces a ridiculously irrelevant aspect
> of the task of programming, produce /more/ bugs than people who
> do their testing right and do not believe in a class society for
> bugs (such that they can ignore or repress some bugs).
...or have you also chosen to take on a liberal meaning of the term
"empirical"?
Simon András
> On 12/8/02 8:09 PM, in article 878yyzs...@darkstar.cartan, "Nils
> Goesche" <n...@cartan.de> wrote:
>
> > Pascal Costanza <cost...@web.de> writes:
> >
> >> Erik Naggum wrote:
> >>> * Pascal Costanza
> >>> | These two statements contradict each other.
> >>> Wrong.
> >
> > Now I am getting curious myself: The statements you explicitly
> > quoted were:
> >
> > # people who are massively inept at programming think that if
> > # they can catch some bugs at compile-time, that somehow makes
> > # all the remaining bugs less important and hard to catch. This
> > # is in fact wrong. (Erik)
> >
> > # almost always, once I made the type checker happy, the program
> > # was correct. (Guy Steele)
> >
> > These two statements do indeed /not/ contradict each other. Why
> > do you think they do?
>
> They certainly appear contradictory to me. I'm willing to make the following
> assumptions from context:
>
> "people who are massively inept .." means "only people who are massively
> inept"
>
> Pascal does not believe Guy Steele was massively inept at programming
Erik's statement is about a certain belief of `people who are
massively inept at programming' on static typing, while GLS's about
his own experiences with static typing (not with people's beliefs on
static typing). So I also can't see how they could contradict each
other.
BTW, the following recent message in the Types Forum may be
interesting to readers of this thread:
http://www.cis.upenn.edu/~bcpierce/types/archives/current/msg01180.html
A short excerpt:
[Bluntly put, it took Larry Wall (a SYSTEMS ADMINSTRATOR) to convince
the world of the value of CommonLisp. Think about it. Think hard
about it. 'cos it is true, and a really disappointing statement about
the entire programming-language community.]
Andras
Erik Naggum
| This doesn't make it right.
What is wrong with you?
| Some people actually benefit from reading.
You are not one of them. Please cut the unwarranted arrogance.
| I am looking forward to an alternative suggestion of yours.
What is wrong with you? Please cut the unwarranted arrogance.
| BTW, I am still interested in the foundation (papers, links, etc.)
| that you base the following claim of yours on.
What the hell makes you think that I will do anything to satisfy
you apart from causing you to shut the fuck up? You malfunction
when you do not get things exactly the way you want them, and you
are perfectly happy to derail discussions so you can point out what
is "right", as if anyone needs to hear this from you. You need to
learn to deal with disagreement and rejection, Pascal, and you
/really/ learn to deal with the fact that people do not accept what
you think is the only right thing, and be satisfied to explain your
views a limited number of times and let other people discuss things
even though they do not use every term /exactly/ right by your
standards. If you make it your life's mission to correct everyone
who misuses a term for which you have the right meaning, you are no
better than any other deranged fanatic who cannot change his mind
and refuse to change the subject (to use Churchill's definition of
a fanatic).
| ...or have you also chosen to take on a liberal meaning of the term
| "empirical"?
What is wrong with you? Please cut the unwarranted arrogance.
Why do you have to be such a snotty asshole when you are faced with
rejection of your pet peeves? You seem so utterly unable to deal
with rejection that there is no telling what /would/ cater to the
underlying psychological needs you obviously have.
You turn into an extremely annoying, combative little neurotic when
you are told that you annoy people, instead of trying to get the
point and stick to the topic at hand. Where is that friendly style
of yours when it could be put to the test? It works only when you
feel superior to other people, does it not? And when you do not,
indeed /are/ inferior, you turn into a hostile dipshit instead of
doing as you preach. Be /nice/ when it counts, or shut the fuck
about your holier-than-thou attitude about "style". You are worse
than most people when it comes to turning hostile, but you do not
realize that, do you? Other people of your ilk have staged /wars/
on newsgroups when their sensibilities have been offended, like the
mad muslems who rioted in Nigeria and killed hundreds of people
because some journalist said something these deranged lunatics were
unable to cope with rationally. You remind me of such people.
There is something seriously broken in you, Pascal Costanza.
Unless you start to behave courteously and nicely even when your
arguments are rejected, I have to conclude that you function only
under very specific conditions and turn into a lunatic when those
conditions are not met, just like religious fanatics. Long ago, I
concluded that the only reason you want all this "niceness" is that
you cannot handle real objections to your misguided notions and
therefore turn hostile in the face of failure. Many "nice" people
are nice only because they are downright evil when they do not
strictly control themselves. I think you are one of those, and you
do not exactly help to refute this conclusion.
Now, be specific, and tell me exactly what would make you happy and
would make you shut up /forever/ about this neurotic non-issue of
yours. What do you want to call statically typed languages except
those with type inference that you need to bring up to destroy a
line of argument? You answer this now, once, and I will call them
"statically typed languages (or foo according to Pascal Costanza)",
for the value you provide of "foo". You can choose anything you
want, as everyone will know who to ask what it means. I want you
to shut up about this so bad that I am willing to accept absolutely
anything you call it, but I will also make sure that the terminology
points back to you, because I do not want to be associated with the
bogus psychological needs you have that you refuse to keep personal.
I also think you should go repair yourself, and above all, /think/,
even though it obviously hurts so much you much prefer to act on
your emotions. Once you start to /think/ even in when it hurts,
you will take on a very different appearance, one that I will most
likely accept and treat with respect. Emotionally disturbed people
with an axe to grind and a fanatic outlook on what is "right" do
not, in general, encourage me to treat them nicely. I cannot fathom
why you do not grasp this and adjust your behavior to something
that at least could have /some/ hope of achieving what you want.
You see (or, of course you do not), when you insist that something
is /right/ when it is also out of place, people will object to it
regardless of the truth of your claim, and the more you insist, the
/more/ they will object simply because you are out of place and do
not grasp that it is not about how "right" you think you are.
So, let us have the "Pascal Costanza terminology" for the statically
typed languages that enables discussion of relevant aspects of them,
so that we will never, ever, hear any complaints from you again!
Erik Naggum
| This contradicts Erik's assessment that compile-time checks don't
| guarantee the absence of bugs.
Accept and take responsibility for your own contribution, will you?
Erik Naggum
| I don't think Erik wanted to deny the fact that some people believe
| in the usefulness of compile-time checks, but he wanted to deny the
| usefulness of compile-time checks as such.
Nobody is interested in what you think I want to do or not. Keep
such misguided speculations to yourself and QUIT ANNOYING PEOPLE.
Pascal Costanza
> * Pascal Costanza
> | I am looking forward to an alternative suggestion of yours.
>
> What is wrong with you? Please cut the unwarranted arrogance.
Why do you make things more complicated than they are? When you want to
restrict the term "statically typed language" to those that are based on
explicit typing, what term do you want to use to describe the fact that
languages based on type inference are also statically checked? Just
propose a terminology that's suitable for your needs but remains
consistent. I am still looking forward to such a terminology because it
would be a real contribution to the field.
It's actually extremely simple: When you have a consistent terminology,
just name it. If you don't name it, what should one assume? If you are
not willing to admit that you don't have a consistent terminoloy, then
at least just shut up.
> | BTW, I am still interested in the foundation (papers, links, etc.)
> | that you base the following claim of yours on.
>
> What the hell makes you think that I will do anything to satisfy
> you apart from causing you to shut the fuck up?
Again, you make things more complicated as they are. In case you have a
sound basis for your claim, just point to it. If you don't point to
anything, what should one assume? Is it too hard for you to say that you
don't have the material I am interested in? If that's the case, then
again at least just shut up.
> Unless you start to behave courteously and nicely even when your
> arguments are rejected, I have to conclude that you function only
> under very specific conditions and turn into a lunatic when those
> conditions are not met, just like religious fanatics.
I haven't seen any real refutation of my arguments yet. You have made a
mistake. Why don't you just admit it?
> Now, be specific, and tell me exactly what would make you happy and
> would make you shut up /forever/ about this neurotic non-issue of
> yours. What do you want to call statically typed languages except
> those with type inference that you need to bring up to destroy a
> line of argument?
This is getting boring. Just read
http://research.microsoft.com/Users/luca/Papers/TypeSystems.pdf -
everything's sorted out in that paper.
> So, let us have the "Pascal Costanza terminology" for the statically
> typed languages that enables discussion of relevant aspects of them,
> so that we will never, ever, hear any complaints from you again!
There's no "Pascal Costanza terminology" with regard to type systems.
This is ridiculous.
Chris Gehlker
Stegen" <tst...@cis.strath.ac.uk> wrote:
I think we are saying the same thing here.
Erik Naggum
| Why do you make things more complicated than they are?
I do not. I have asked you to state unequivocally what you would
be happy that I called the languages I want to talk about so that
we can rid the world of the abomination that is your incessant
abuse of this forum with your personal problems.
You refuse to answer.
This must mean that you want this forum to be about your personal
problems and your incessant whining about them and that you by far
prefer not to be happy, but to complain, complain, complain. This
is consistent with the demand you make on others, but evidently not
on yourself, to be nice -- or else!
| It's actually extremely simple: When you have a consistent
| terminology, just name it. If you don't name it, what should one
| assume? If you are not willing to admit that you don't have a
| consistent terminoloy, then at least just shut up.
Then why do /you/ not simply answer the question?
I am so tired of people who cannot accept responsibility for their
own actions and emotions. You demand something of me, when /you/
come out of nowhere with your moronic complaints, and when asked
what would make /you/ happy so we could be relieved of your moronic
complaints, you do such a cowardly act as demanding of those /you/
have arrested for what /you/ think is misuse to come up with what
you obviously cannot deliver yourself. The intellectual dishonesty
you display defy words.
| I haven't seen any real refutation of my arguments yet. You have
| made a mistake. Why don't you just admit it?
What!? The /gall/! You really /do/ suffer from serious delusions
of being the only one to have the right answer in this world.
Your mistake here is to believe there is a contradiction. What has
kept you from admitting that? I know -- puerile notions of pride,
notions of "honor" that belong in cultures known to stone people
who abuse the name of their prophet.
| This is getting boring. Just read
| http://research.microsoft.com/Users/luca/Papers/TypeSystems.pdf -
| everything's sorted out in that paper.
That explains what somebody else would want to call it. I ask
/you/ what /you/ would call it, because /you/ storm in here and
make your stupid complaints and derail discussions when your petty
personal concerns are disturbed. And you won't quit, either!
| There's no "Pascal Costanza terminology" with regard to type
| systems. This is ridiculous.
I want to know what would make /you/ happy and quit complaining.
This is not complicated. You refuse to answer, however. That
speaks volumes about your /real/ intentions in this forum: To stir
up trouble when people do not do precisely what you want. I have
suspected as much when you started a war over /other/ people not
being nice while you obviously could run the whole gamut from bad
to downright evil.
/You/ have complained. /You/ get to explain what /you/ want other
people to do. Explicitly, no complications. Just present us with
the term Pascal Costanza wants everybody else to use for statically
typed programming languages that makes it possible to talk about
them without having Pascal Costanza complaining incessantly about
misuse of terminology and dragging in irrelevant complications and
moronic "contradictions" that are figments of your imagination.
Is it /possible/ to talk about deficiencies of languages like C++,
Java, and C# without having moronic complaints from Pascal Costanza?
So far, it does not look like it. If it is not possible, I shall
have to append a disclaimer to every message I post that readers be
advised to ignore the rants that inevitably will result from your
mental hangup with terminology and your refusal to be explicit
about what you want others to use instead.
So, to repeat the very simple request: What would it /take/ for you
to refrain from mentioning Haskell when deficiencies of statically
typed programming languages are discussed? Name it!
Patrick W
> Here is Erik's quote again:
>
> [...]
> > people who are massively inept at programming think that if they can
> > catch some bugs at compile-time, that somehow makes all the remaining
> > bugs less important and hard to catch. This is in fact wrong.
>
> I was referring to the very last sentence. ("This is in fact wrong.")
> I don't think Erik wanted to deny the fact that some people believe in
> the usefulness of compile-time checks, but he wanted to deny the
> usefulness of compile-time checks as such.
Not the way I see it. He was not arguing against the usefulness of
compile-time type checking, but against the common belief that it
protects against the _most important_ programming errors. You seem to
have overlooked this and focussed on the difference between implicit
and explicit static typing instead (which is a bit of a red herring,
in context).
I think Erik is quite right anyway, regardless of whether we're
talking about implicit or explicit static typing, and regardless of
whether Guy Steele's Haskell programs worked correctly once he'd
satisfied the type checker. Type errors account for only a small
fraction of potential problems. Explicit typing arguably creates more
problems than it solves. (Certainly does for me!). Implicit static
typing is less obtrusive, to be sure, but I don't see how this is
inconsistent with Erik's remarks.
Pascal Costanza
> Pascal Costanza <cost...@web.de> writes:
>
>
>>Here is Erik's quote again:
>>
>>[...]
>> > people who are massively inept at programming think that if they can
>> > catch some bugs at compile-time, that somehow makes all the remaining
>> > bugs less important and hard to catch. This is in fact wrong.
>>
>>I was referring to the very last sentence. ("This is in fact wrong.")
>>I don't think Erik wanted to deny the fact that some people believe in
>>the usefulness of compile-time checks, but he wanted to deny the
>>usefulness of compile-time checks as such.
>
>
> Not the way I see it. He was not arguing against the usefulness of
> compile-time type checking, but against the common belief that it
> protects against the _most important_ programming errors. You seem to
> have overlooked this and focussed on the difference between implicit
> and explicit static typing instead (which is a bit of a red herring,
> in context).
In Guy Steele's example, the type checker helped to make the code
correct, which implies that the code was free of both important and
non-important bugs. Under the assumption that static type checking
generally does not ensure correctness, it is still a counter example.
I have no focus whatsoever on the difference between implicit and
explicit typing. I have just given the counter-example under the
assumption that Erik meant what he said. The term "static typing" is a
well-defined term that happens to include both implicit and explicit
approaches.
> I think Erik is quite right anyway, regardless of whether we're
> talking about implicit or explicit static typing, and regardless of
> whether Guy Steele's Haskell programs worked correctly once he'd
> satisfied the type checker. Type errors account for only a small
> fraction of potential problems.
In Guy Steele's example, the type checker obviously accounted for _all_
potential problems. This is what makes this quote so interesting.
> Explicit typing arguably creates more
> problems than it solves. (Certainly does for me!). Implicit static
> typing is less obtrusive, to be sure, but I don't see how this is
> inconsistent with Erik's remarks.
I didn't intend to disprove Erik's reasoning, I just wanted to point to
an interesting counter-example. Actually I also think that static type
checking does not help in most cases, why would I use Common Lisp otherwise.
Do we have a real issue here?
Chris Gehlker
András" <asi...@math.bme.hu> wrote:
> Erik's statement is about a certain belief of `people who are
> massively inept at programming' on static typing, while GLS's about
> his own experiences with static typing (not with people's beliefs on
> static typing). So I also can't see how they could contradict each
> other.
I won't even try to be cute. Erik made the observation that the kind of
static typing provided in C# is not useful. I doubt that anyone here would
quarrel with that. But, with what I take to be typical hyperbole, he phrased
this as "All people who believe in the usefulness of static typing are
ignorant/deluded/incompetent.
Pascal called him on this by pointing out that some competent/knowledgeable
people believe in *some forms* of static typing.
Erik responded that that in the context of C#, his meaning was clear.
Pascal's response was essentially "you said what you said and it's simply
not true."
AFAICT that's really all that's going on in this thread.
Pascal Costanza
> * Pascal Costanza
> | Why do you make things more complicated than they are?
>
> I do not. I have asked you to state unequivocally what you would
> be happy that I called the languages I want to talk about so that
> we can rid the world of the abomination that is your incessant
> abuse of this forum with your personal problems.
>
> You refuse to answer.
You can read, can't you?
> | This is getting boring. Just read
> | http://research.microsoft.com/Users/luca/Papers/TypeSystems.pdf -
> | everything's sorted out in that paper.
>
> That explains what somebody else would want to call it. I ask
> /you/ what /you/ would call it, because /you/ storm in here and
> make your stupid complaints and derail discussions when your petty
> personal concerns are disturbed. And you won't quit, either!
I haven't felt any kind of disturbance at all. I just wanted to point to
an interesting counter-example under the implicit assumption that you
made correct use of the terminology. Obviously, my mistake was to
believe that you are capable of doing so, or at least correct your
mistakes when they are pointed out.
It doesn't matter what concrete terminology I would personally prefer,
because we are not talking about personal opinions or tastes, etc. Just
use the correct and accepted terminology.
> Is it /possible/ to talk about deficiencies of languages like C++,
> Java, and C# without having moronic complaints from Pascal Costanza?
> So far, it does not look like it.
Of course this is possible. Just use the correct and accepted terminology.
Oh, I am sorry, I have forgotten that you are obviously incapable of
reading. So I will help you out on this: According to the paper I have
repeatedly pointed to, the languages you mention are statically and
explicitly typed languages. Java is strongly typed, whereas C++ and C#
also allow weak typing in some cases.
Pascal Costanza
> On 12/9/02 5:31 AM, in article vcdn0nf...@tarski.math.bme.hu, "Simon
> András" <asi...@math.bme.hu> wrote:
>
>
>>Erik's statement is about a certain belief of `people who are
>>massively inept at programming' on static typing, while GLS's about
>>his own experiences with static typing (not with people's beliefs on
>>static typing). So I also can't see how they could contradict each
>>other.
>
>
> I won't even try to be cute. Erik made the observation that the kind of
> static typing provided in C# is not useful. I doubt that anyone here would
> quarrel with that. But, with what I take to be typical hyperbole, he phrased
> this as "All people who believe in the usefulness of static typing are
> ignorant/deluded/incompetent.
>
> Pascal called him on this by pointing out that some competent/knowledgeable
> people believe in *some forms* of static typing.
>
> Erik responded that that in the context of C#, his meaning was clear.
>
> Pascal's response was essentially "you said what you said and it's simply
> not true."
>
> AFAICT that's really all that's going on in this thread.
Exactly!
Thanks for this summary.
Patrick W
> I also think that static type checking does not help in most cases,
> why would I use Common Lisp otherwise.
>
> Do we have a real issue here?
No, I don't think so. We've learned that static type checking solves
all problems for all programs whose only problems are type errors.
We've also learned that this is an excellent counter-example of
nobody's argument that static type checking is useless and is valued
only by cretins. So let's quit while we're ahead. <g>
Erik Naggum
| Obviously, my mistake was to believe that you are capable of doing
| so, or at least correct your mistakes when they are pointed out.
Several other people here have now commented on your mistake, but I
see nothing from you that could give me an indication of capability
to correct mistakes, nor of actually understanding what you are
asked to do, but you project this paucity of abilities onto others.
Why do you so arrogantly assume that other people are just as
deficient as yourself? Why do you treat other people as if they are
what you fear most that you might be yourself?
You hurl a number of really insane accusations at me about things
you have no possible /means/ to know, further supporting an argument
of mine that you do not understand that acquiring knowledge is work
and requries directed, conscious effort. When you make such claims,
I /know/ that you lack some /very/ fundamental argumentative and
intellectual skills. I look at you and