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 see a person who does not,
even when it would save him, /think/ and /reflect/ and get a grip on
himself. It is truly disturbing to watch. And over such an ickle
thing as terminology and imaginary contradictions. Lamentable!
One of the skills you lack is to limit your statements to what you
/can/ know, and, in the words of Aristotle, to say about that which
is that it is and about that which is not that it is not; he talked
about /honesty/ and /intgrity/. Since this discussion is concerned
with whether what you think is correct is indeed so, I look for
clues in what other things you write that you obviously appear to
think is correct, but you know what? I find that you make a number
of utterly /unfounded/ claims, wild conjectures based on that
hateful thing in emotionally disturbed people that demonizes their
opponent so they do not have to treat them like human beings. You
/make up/ things to accuse me of. This does not happen to people
who retain their composure and are in control of themselves. It is
a very strong symptom of complete mental breakdown. Why do you
share this with the world. And when all that has been required of
you is to tell me exactly, unequivocally, what would make you happy.
You continue to tell the whole world how unhappy you are, but you do
not make a single attempt to rectify the situation. Pathological!
This whole unwillingness to curtail your fantasizing about me goes
directly to your credibility and your /ability/ to distinguish what
you believe from what is out there in reality. I have suspected
that to you, there /is/ no such distinction, that you literally live
in your own world where everything you say makes sense, but look at
yourself, man! You make sweeping claims about other people in a way
that strictly speaking is /insane/ -- what you say /cannot possibly/
all be true at the same time. That tether between your mind and
reality has overextended itself.
| 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.
Again, it appears that you are not even aware that in order to use
"correct and accepted terminology" you need to know precisely what
you are talking /about/. There is no point in knowing what the
"correct and accepted terminology" is unless you also know what it
means. The point of asking /you/ what would make /you/ happy and
quit complaining and hurling accusations at people (is this your
idea of being nice and friendly, by the way?) is to know whether
/you/ have any idea whatsoever about what other people are talking
about? But clearly, you do not. You assume that some disembodied
"correct and accepted terminology" is sufficient, but do you know to
what it applies? I fear you do not even ask yourself that question.
| You can read, can't you?
I marvel at your idiocy, Pascal, but more than that, I am deeply
worried about your sanity. Because, you see, after this moronic
rhetorical question, which suggests that if you were any slower, you
would be thinking backwards, mere moments later, you write this:
| Oh, I am sorry, I have forgotten that you are obviously incapable
| of reading.
Pascal, I have long suspected you to be a deficient, malfunctioning
human being, but when you go and say such things, I know that the
fragile connection between reality and whatever is inside that poor
excuse for a cranium of yours is no more. /Psychosis/ has set in,
wherein you actually believe what is not so to be the truth, and
sadly but typical of psychotics, you insist with a strenght rivaling
religious fanatics that only what you think is right, even though it
is frequently self-contradictory and betray a mind that is no longer
accepting any input from the external world.
Rest assured that I can read, Pascal, also between the lines. When
I look at your "output", I feel the remnants of pity that a flood of
disgust cannot quite wash away. You betray your innermost fears to
me in ways at which your future self will recoil in horror, and you
display your want of coping strategies in ways that so far removed
from an adult discussion that somebody, /anybody/ with compassion
for you, would have yanked you out of that mental state you are in,
/made/ you snap out of it since you cannot do that on your own.
This was about /programming languages/, Pascal! You act as if your
entire psychological makeup is under attack, that your identity as a
person is in danger, that you will cease to /exist/ if you have to
admit that (1) your contradiction was a figment of your imagination
and (2) your personal problem with "correct" terminology tells the
whole world that you /malfunction/ when an error occurs. Smart and
healthy people exhibit a graceful degradation of performance under
pressure as well as self-awareness of same, but you lose /all/ your
marbles at once.
Do you think you could try to get back to what your objections were?
Do you think you could at least /try/ to keep somewhat on track? I
do not want to hear any more of your insane ranting and raving about
whether I can read or what you have "forgotten" of what you have
clearly invented entirely on your own. I want you to be /nice/ to
me, like you have argued that people should be towards one another,
and apologize for all the insane accusations you have hurled my way,
and /demonstrate/ the superiority of your kinder, gentler way. Use
that warm language of yours, show cognizance and care for how I feel
and display your excellent command of the way you suggest that I and
others deal with people on this newsgroup. As you are hurt and
frustrated, there is no better time than now to /perform/ according
to your own standards. Show us the Pascal Costanza that you want us
to remember, your flair for compassionate communication. Show us
the grandeur of a person who can, in the face of negative emotions
and suspicions that he is a staggering fool, put his money where his
mouth is. Show us the Pascal Costanza that takes it upon himself to
lambast those who unfairly criticizes yet is far and away above that
reprehensible act himself. Show us Pascal Costanza as he wants to
be seen! I await your performance with baited breath. Imagine, not
a harsh word, not one accusation, not a single rabid rant.
We who are about to read, salute you!
By the way, I do have a really heartfelt suggestion to you: Do try
to be nice to people. Not because I think you should primarily be
nice, but because I think you should avoid trying to insult people
at all cost: You absolutely stink at it, and I loathe incompetence.
Patrick W
> 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.
See a slight difference in meaning here?
"Al Qa'ida members follow Islam."
"All who follow Islam are Al Qa'ida members"
Now compare Erik's original statement with your paraphrase.
Pretty cute, considering you weren't even trying, eh?
Pascal Costanza
> Do you think you could try to get back to what your objections were?
I didn't have any strong objections to your original argument. [1] I
just wanted to point to an interesting example that either adds to, or
disagrees with your original argument, depending on which interpretation
of the terminology you used one agrees to. For reasons I have already
explicated in detail, I have chosen a wording according to the second
interpretation. It's strange that you hopped onto this very superficial
aspect of my example in the first place.
As a sidenote, it's really amazing what amount of nonsense you read into
my statements.
Pascal
[1] Perhaps that's the essential problem of our "conversation" that you
regard my statements as objections.
Erik Naggum
| I have just given the counter-example under the assumption that
| Erik meant what he said.
You continue to amaze me (which suggests that I should downgrade my
expectations, I guess) in not understanding the difference between
what people write and what you interpret it to mean, which suggests
an absence of understanding, indeed /appreciation/, of interpretive
processes. How is this possible? How can anyone fail to grasp
that they have had to perform some /mental work/ to arrive at the
meaning of what they have read and that this work /necessarily/
embodies the influences of their own context, conceptual framework,
and prior participations in the great dialog that is civilization?
I fear that the conclusion is that no such work has occurred.
| In Guy Steele's example, the type checker obviously accounted for
| _all_ potential problems. This is what makes this quote so
| interesting.
I am fairly confident that that is /not/ what he meant, as it would
be a fairly retarded interpretation of what he wrote, and although
people vary greatly in their performance although they usually have
sufficient self-awareness not to publish sheer idiocy (with some
glaringly obvious exceptions), I do not wish to insult Guy Steele's
intelligence by assuming he meant such a thing.
| I didn't intend to disprove Erik's reasoning, I just wanted to
| point to an interesting counter-example.
Amazing. And you objected to calling it additional information.
| Actually I also think that static type checking does not help in
| most cases, why would I use Common Lisp otherwise.
Because you do not practice what you preach? Oh, sorry, there was
no question mark. Smart move.
Nils Goesche
> Erik Naggum wrote:
> > 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.
As the repeated discussions on cll about this sufficiently show, it is
not so clear what the ``correct and accepted´´ terminology actually
is. Citing /one/ paper is /not/ enough to prove that the terminology
it uses is generally accepted. Just as /one/ statement by Steele
doesn't prove anything about the general effect of static typing on
programming.
> According to the paper I have repeatedly pointed to, the languages
> you mention are statically and explicitly typed languages.
Actually, I don't see why the situation would be any different with
languages like Haskell or ML that derive types from context through
type inference: You /still/ provide complete information about types
in your source code. It is just made implicit to save some key
strokes. This is not a fundamental difference.
> Java is strongly typed, whereas C++ and C# also allow weak typing in
> some cases.
It is a bit sad that the /interesting/ point Erik was going to make
got drowned in yet another boring and pointless discussion about
terminology. If it is not clear what Erik meant why not ask him
instead of trying to enforce a certain terminology unto the whole
world which is not going to happen any time soon, anyway?
The important point here has nothing whatsoever to do with
terminology. The point is that static typing generates an illusion of
safety that isn't there. This applies to all kinds of statically
typed languages, sometimes in different ways.
In languages that also provide weak typing like C++ this is only
easier to trigger: Just cast, or use an invalid pointer, and undefined
behavior will come all over you. As there is no runtime type
information, there cannot be any mechanism that would protect you from
this. In Java, watch out for runtime type errors on array access, and
null pointer exceptions. Languages like Haskell or ML are designed in
a way that they can claim that they won't have any type errors at run
time; of course, this is only really correct if you kindly adopt their
definition of runtime type error. Earlier I gave an example:
http://groups.google.com/groups?selm=lkvg5bx...@pc022.bln.elmeg.de
This is not a runtime type error according to the ML crowd but it
certainly is in my world!
Then there is a whole lot of things we can do in Common Lisp to
correct all kinds of errors, including type errors, /at run time/.
This is because we have the type information available at run time and
the static typers don't. People should read Erik's posting
http://groups.google.com/groups?selm=32482911...@naggum.no
in this context. That not every single one of this points applies to
every single statically typed language ever invented changes nothing
about the general validity of the argument. Neither does the fact
that every beginner in such languages, when he finally got some hello
world program to run after three hours of fighting the type checker,
thinks ``Wow, without this cool type checker I would have had 30 bugs
in my hello world program!´´, constitute any prove that you /really/
write safer non-hello-world programs in statically typed languages.
In fact, I think the opposite is true, for a whole lot of different
reasons.
Regards,
--
Nils Gösche
"Don't ask for whom the <CTRL-G> tolls."
PGP key ID 0x0655CFA0
Erik Naggum
| 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.
That was not even what I wrote. I think what I actually wrote would
be far better example of how I phrased things than any paraphrase.
Some people seem to believe that absent an explicit quantifier, they
have the right to assume the universal quantifier and so believe it
is fruitful to produce what they believe are counter-examples, which
has the curiously anti-intellectual effect of making what was not
adorned with the universal quantifier appear as though it were,
effectively rendering further discussion impossible. Those who are
of the strange mental bent that sees universal quantifiers wherever
they see disagreement and who actually believe that counter-examples
have a place in discussions should be force-fed a course on logic
and have their posting privileges revoked pending passing an exam.
Erik Naggum
| It's strange that you hopped onto this very superficial aspect of
| my example in the first place.
Feeling better from shirking responsibility is so deeply ingrained
into your personality that you are not even aware of it, right?
| As a sidenote, it's really amazing what amount of nonsense you read
| into my statements.
Pot. Kettle. Pascal.
This planet would be better off if people like you would at least
consider the possibility that you are not perfect and flawless and
that everything that goes wrong is somebody else's fault.
Chris Gehlker
<patri...@yahoo.com.au> wrote:
Now *that's cute*.
Here is some red meat:
Some programmers are competent/knowledgeable/non-delusional despite the fact
that they believe the kind of static type checking provided by C# is useful.
Marc Spitzer
This *only* applies iff you can prove that Guy Steele is a member
of the set of "people who are massively inept at programming". Are
you making this claim? And can you prove it?
From what little I know about Guy Steele he appears to be a very
competent programmer and very smart in general. Now what I believe he
was talking about in that quote is that Haskell helped him find typos,
physical and logical, and not bugs. Also keep in mind that many of
the typos may not have been typos in a dynamically typed language.
typos == spelling errors or simple logic errors that come from keeping
all the details just right. Like (+ a b) where a == 4 and b == "6" in
common lisp.
bugs == The code works correctly( does what you told it to) but does
not do what you want.
From what I have read your argument boils down to I have 2 disjoint
sets and fact/rule applies to one of them so it applies to both of
them. Here is a simple example of why this is wrong:
set A is even numbers
set B is odd numbers
I can prove that for all numbers in set A a mod 2 == 0, so all numbers
in the union of sets a and b must have this property.
marc
marcel haesok
secondly because it seems easier than C or C++ or Java.
(If learning C, LISP, SMALLTALK ----the three pillars as someone put it
here---- is too difficult, I can start with C#, LISP, SMALLTALK......)
2. I do agree that LISP is much greater language and I have the feeling that
it's going to be my 'native' tongue soon.
3. 'learning a great deal from reading this newsgroup.
Pascal Costanza
any content? Don't you have something more substantial to offer? Like,
for example, a consistent foundation for your terminology or, for
example, the empirical data backing some of the claims you have made?
Or are you just full of hot air?
Thomas Stegen
> I think we are saying the same thing here.
>
You say they contradict eachother, I say they do not. How can we
be saying the same thing?
--
Thomas.
Pascal Costanza
> Pascal Costanza <cost...@web.de> writes:
>
>
>>Erik Naggum wrote:
>
>
>>> 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.
>
>
> As the repeated discussions on cll about this sufficiently show, it is
> not so clear what the ``correct and accepted´´ terminology actually
> is. Citing /one/ paper is /not/ enough to prove that the terminology
> it uses is generally accepted.
However, this would be very easy to deal with - Erik could just suggest
a different terminology. The advantage of that paper's terminology is
that it removes the traps that people usually run into when talking
about these issues. That's a real contribution. If Erik is capable of
introducing a different terminology that is still consistent, why
doesn't he just do that? This would also be a real contribution - but I
have my doubts that he can come up with an alternative terminology any
time soon.
In the meantime, I will stick to the one provided in that paper.
> Just as /one/ statement by Steele
> doesn't prove anything about the general effect of static typing on
> programming.
Right. As I said, it's just an example. Albeit an interesting one. (And
this was the only point I wanted to make.) So what?
>>According to the paper I have repeatedly pointed to, the languages
>>you mention are statically and explicitly typed languages.
>
>
> Actually, I don't see why the situation would be any different with
> languages like Haskell or ML that derive types from context through
> type inference: You /still/ provide complete information about types
> in your source code. It is just made implicit to save some key
> strokes. This is not a fundamental difference.
However, you can make the same piece of code work in different contexts,
and the type checker might infer different types depending on the
context. AFAIK, this is not possible with explicit typing. (But don't
ask me about the details, other people can explain these things better
than me.)
>>Java is strongly typed, whereas C++ and C# also allow weak typing in
>>some cases.
>
>
> It is a bit sad that the /interesting/ point Erik was going to make
> got drowned in yet another boring and pointless discussion about
> terminology. If it is not clear what Erik meant why not ask him
> instead of trying to enforce a certain terminology unto the whole
> world which is not going to happen any time soon, anyway?
Erik's points were rather trivial to me. And I am not trying to enforce
anything.
> The important point here has nothing whatsoever to do with
> terminology. The point is that static typing generates an illusion of
> safety that isn't there. This applies to all kinds of statically
> typed languages, sometimes in different ways.
I agree, and I think you have provided interesting examples.
Kenny Tilton
> 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:
> >>> | 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?
>
bzzzt! Sorry, as Erik noted, Pascal's interesting find, the Steele
quote, is fodder for the discussion but not a counter-example to
Erik's observation.
Erik set up a bit of a straw man (hard to counter-example), a coder
who thinks "if they can catch some bugs at compile-time, that somehow
makes all the remaining bugs less important and hard to catch".
Steele's observation says something very favorable about the type
checker, but does not say anything as preposterous as did the straw
man.
Now if only Pascal had not said "counter-example" we would not have
this frightfully dull thread (which I cannot resist joining!), but he
did and Erik caught him on it. Now if only Pascal had responded,
right, "counterexample" was the wrong word, how about a nice type of
safe characterization like "food for thought", again we'd be back to
discussing something important like my great Cells project. But
nooooo....! You decide to summarize and really cock things up by
misquoting Erik:
Chris wrote"
'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.'
Is the missing second quote a C++-ism for a string containing a
misquote? I like it! Anyway, I saw Erik's temperate response to this
misquote, and all I can say is that you are lucky to be alive.
Dude, mediators should not muddy the water by /adding/ to the number
of he-saids-she-saids to be resolved.
Peace y'all. kenny
Pascal Costanza
> bzzzt! Sorry, as Erik noted, Pascal's interesting find, the Steele
> quote, is fodder for the discussion but not a counter-example to
> Erik's observation.
Hmmm...
> Erik set up a bit of a straw man (hard to counter-example), a coder
> who thinks "if they can catch some bugs at compile-time, that somehow
> makes all the remaining bugs less important and hard to catch".
> Steele's observation says something very favorable about the type
> checker, but does not say anything as preposterous as did the straw
> man.
I still think you could rephrase Steele's quote as follows: "As soon as
no bugs occurred at compile-time, that somehow made the code free of any
remaining bugs."
> Now if only Pascal had not said "counter-example" we would not have
> this frightfully dull thread (which I cannot resist joining!), but he
> did and Erik caught him on it. Now if only Pascal had responded,
> right, "counterexample" was the wrong word, how about a nice type of
> safe characterization like "food for thought", [...]
Should I have said "exceptional case"?
Chris Gehlker
Stegen" <tst...@cis.strath.ac.uk> wrote:
It seemed from your previous post that you were saying "I disagree with your
assumption and therefore with your conclusion." I was merely responding to
the effect that "If you disagree with my assumption, of course you will
reach a different conclusion."
To make this explicit, I interpreted Erik as saying "People find static
typing useful iff they are incompetent."
Thomas F. Burdick
> Kenny Tilton wrote:
>
> > Erik set up a bit of a straw man (hard to counter-example), a coder
> > who thinks "if they can catch some bugs at compile-time, that somehow
> > makes all the remaining bugs less important and hard to catch".
Actually, I've seen this a lot. You'd *hope* that this hypothetical
fool of a programmer was a straw-man argument, but I've seen far too
many people who think that making semi-random changes (ie, they change
things without knowing *why*) to make the compiler shut up (or even
just change errors to warnings) -- once you've done that, the program
should pretty much work. These people exist, there's quite a lot of
them, and they're surprised every time their code breaks.
> I still think you could rephrase Steele's quote as follows: "As soon as
> no bugs occurred at compile-time, that somehow made the code free of any
> remaining bugs."
What?!?! Try rereading the quote without having already decided what
he's saying.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Pascal Costanza
>>I still think you could rephrase Steele's quote as follows: "As soon as
>>no bugs occurred at compile-time, that somehow made the code free of any
>>remaining bugs."
>
>
> What?!?! Try rereading the quote without having already decided what
> he's saying.
Now I am really puzzled. Steele's quote, with my understanding of the
quote added:
"...almost always, once I made the type checker happy [no bugs at
compile-time], the program was correct [no bugs at all, including
"reamining" bugs]."
Do I really misunderstand the quote? If so, could you perhaps provide
some help to correct my understanding?
Thanks,
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
Kenny Tilton
Pascal Costanza wrote:
> Kenny Tilton wrote:
>
>> bzzzt! Sorry, as Erik noted, Pascal's interesting find, the Steele
>> quote, is fodder for the discussion but not a counter-example to
>> Erik's observation.
>
>
> Hmmm...
>
>> Erik set up a bit of a straw man (hard to counter-example), a coder
>> who thinks "if they can catch some bugs at compile-time, that somehow
>> makes all the remaining bugs less important and hard to catch".
>> Steele's observation says something very favorable about the type
>> checker, but does not say anything as preposterous as did the straw
>> man.
>
>
> I still think you could rephrase Steele's quote as follows: "As soon as
> no bugs occurred at compile-time, that somehow made the code free of any
> remaining bugs."
(1) Steele also said "almost always". :)
(2) Steele did not proceed from that observation to the conclusions
Erik's straw man (Straw, for short) seems to have drawn from
type-checking re remaining bugs.
(3) Hell, Steele is talking about the type-checker almost always
eliminating all bugs in /his/ code (important that!). Straw's delusion
stems finding "some bugs at compile-time". Apples and oranges!
(4) Steele was talking about Steele's experience. Steele is a helluva
coder. It may well be that "almost always" the only mistakes he makes
are the kind of braindead gaffes a typechecker can find. He might also
only have been talking about small programs, which are easier to get
right. (Cells make big programs easy to get right. <g>)
Given all that...
> Should I have said "exceptional case"?
Only if you still consider it a counterexample. :)
I think you honestly and in good faith read something into Erik's words
which was not there, and to which Steele /was/ a counterexample. By
staring harder and harder at Steele and how you might tweak
"counterexample", you have innocently fallen into a false minimum in
your search of the solution space to this tedious argument.
--
kenny tilton
clinisys, inc
---------------------------------------------------------------
""Well, I've wrestled with reality for thirty-five years, Doctor,
and I'm happy to state I finally won out over it.""
Elwood P. Dowd
Kenny Tilton
Thomas F. Burdick wrote:
> Pascal Costanza <cost...@web.de> writes:
>
>
>>Kenny Tilton wrote:
>>
>>
>>>Erik set up a bit of a straw man (hard to counter-example), a coder
>>>who thinks "if they can catch some bugs at compile-time, that somehow
>>>makes all the remaining bugs less important and hard to catch".
>>
>
> Actually, I've seen this a lot.
<heh-heh. I have been waiting for this! You are right, and it reminds me
of the two DC-10s brought down by baggage handlers who forced shut (or
so they thought) the baggage compartment doors. The second guy had to
put his knee on the handle because they had tried to prevent false
closings by arranging things so the handle would not get into the
"closed" position if the door was not fully seated. when the alignment
pins did not find their matching holes, he put his knee on the handle
and got it down into place anyway. another 200 dead.
Well, straw man or no, Steele would never allow his words to be taken as
justifying Straw's attitude. (Fondly remembering Woody Allen pulling the
real Marshal McCluhan (sp?) from off-screen in the movie Annie Hall to
contradict the guy in front of Allen in a movie line, who was spouting
nonsense about what McCluhan had said.)
Edi Weitz
> (Fondly remembering Woody Allen pulling the real Marshal McCluhan
> (sp?) from off-screen in the movie Annie Hall to contradict the guy
> in front of Allen in a movie line, who was spouting nonsense about
> what McCluhan had said.)
Yeah, one of my favorite scenes in movie history... :)
(Now, was /that/ off-topic or what?)
Cheers,
Edi.
PS: Marshall McLuhan.
Kaz Kylheku
> 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)............"
When static language idiots spew about ``type safety'' what they are
really talking about is static typing; having everything declared in
the program text so that a computer science sophomore can write an
optimizing compiler.
> which seems to suggest that "type-safety" is a big issue in real programming
> world.
What in a goddamned text on C# can possibly pertain to any issue in
the 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?
Lisp is type safe, except over regions of the program which are
declared unsafe by the programmer. The programmer is in control; if
the programmer wishes to have no safety, the language must bend to her
wishes. In Lisp, it's possible to declare the type of everything, and
to specify how important speed, safety and size are over a specific
portion of the program text.
Type safety in Lisp, like in other languages, means that a memory cell
is never misinterpreted according to the wrong representation.
A Lisp program can have a type error at the high level, but this is a
``soft'' phenomenon that doesn't cause the machine to blindly
misinterpret an object. Rather, the system notices that the object's
type does not match the operationThis situation turns into an error
condition that can be caught with a handler. This error checking
depends on the interpreter or generated code correctly interpreting
the type field of the object and finding it to have the wrong value.
Some run-time parameter can have the wrong value in any language;
naive programmers think, therefore, that the solution is to banish
run-time parameters and have as much pre-computed static information
as possible, which pushes complexity into the representation of the
program itself.
If some function written in C# requires a parameter that is an odd
integer, and you pass an even one, that is a type error. The set of
odd integers constitute a de-facto type. Unless you can declare an odd
integer type, and have the compiler statically check everything, you
have to implement a run-time check for oddness.
Also consider the problem of a null reference. In Lisp, there is no
such thing as a null reference to some type; rather, there is a
special value NIL which has its own type. So what is a *value* problem
(null reference) in some languages can be treated as a *type* problem
in Lisp (wrong type passed, object of type NULL). So you see there
isn't a clear cut difference between type errors and other kinds of
errors, and there is even overlap.
Run time typing is advantageous; since we have NIL as its own type,
type NULL, we can specialize methods to catch null references and
provide useful default behaviors. Practitioners of idiotic languages
rediscovered this idea and called it the ``null object design
pattern''.
Another advantage is that if a Lisp compiler statically infers that
some variable is a reference to some type type other than NULL, it can
eliminate the run-time type checking. A Java or C# compiler, even
though knows that some variable has some specific class type, still
has to generate code to perform null reference checks. So a sane,
dynamic type system can actually help the compiler produce better
code.
Tim Bradshaw
> 1. I am doing C# firstly to earn my living doing window programming, and
> secondly because it seems easier than C or C++ or Java.
I think people thinking about learning C# to make a living should look
at the stats. Here in the UK (mostly, some jobs are abroad) the
leading job search engine (I think), jobserve.com gives, for all jobs
both contract and permanent:
C# or .net 436 hits
Java 1215 hits
C or C++ 1667
OK, maybe C#/.net are ramping up, and this seems to be borne out.
jobstats.co.uk has C# going up from 0.2% in May 2001 to about 1% now,
during which period Java has gone from abut 12 to 9%. So maybe C# is
the future, after all.
--tim (yes, I know: meaningless statistics)
sv0f
>Kenny Tilton <kti...@nyc.rr.com> writes:
>
>> (Fondly remembering Woody Allen pulling the real Marshal McCluhan
>> (sp?) from off-screen in the movie Annie Hall to contradict the guy
>> in front of Allen in a movie line, who was spouting nonsense about
>> what McCluhan had said.)
>
>Yeah, one of my favorite scenes in movie history... :)
From: http://www.geocities.com/Hollywood/Boulevard/1498/anniehall.html
===
They stood in line in front of a loud, pompous pseudo-intellectual
professor who rambled at length about Marshall McLuhan; when Alvy
couldn't listen to another word, he produced McLuhan himself from
the theater lobby and brought him over to discredit the professor:
"I heard what you were saying. You know nothing of my work . . .
How you ever got to teach a course in anything is totally amazing."
Alvy then addresses the camera: "Boy, if life were only like this."
===
Not a perfect summary, but...
Pascal Costanza
>
>
> Pascal Costanza wrote:
>
>> Kenny Tilton wrote:
>>
>>> bzzzt! Sorry, as Erik noted, Pascal's interesting find, the Steele
>>> quote, is fodder for the discussion but not a counter-example to
>>> Erik's observation.
>>
>>
>>
>> Hmmm...
>>
>>> Erik set up a bit of a straw man (hard to counter-example), a coder
>>> who thinks "if they can catch some bugs at compile-time, that somehow
>>> makes all the remaining bugs less important and hard to catch".
>>> Steele's observation says something very favorable about the type
>>> checker, but does not say anything as preposterous as did the straw
>>> man.
>>
>>
>>
>> I still think you could rephrase Steele's quote as follows: "As soon
>> as no bugs occurred at compile-time, that somehow made the code free
>> of any remaining bugs."
>
>
> (1) Steele also said "almost always". :)
:) Agreed.
> (2) Steele did not proceed from that observation to the conclusions
> Erik's straw man (Straw, for short) seems to have drawn from
> type-checking re remaining bugs.
OK.
> (3) Hell, Steele is talking about the type-checker almost always
> eliminating all bugs in /his/ code (important that!). Straw's delusion
> stems finding "some bugs at compile-time". Apples and oranges!
Not agreed - but I admit that this is nitpicking.
> (4) Steele was talking about Steele's experience. Steele is a helluva
> coder. It may well be that "almost always" the only mistakes he makes
> are the kind of braindead gaffes a typechecker can find. He might also
> only have been talking about small programs, which are easier to get
> right.
OK.
> (Cells make big programs easy to get right. <g>)
This was the advertisment section, right? :)
> Given all that...
>
>> Should I have said "exceptional case"?
>
>
> Only if you still consider it a counterexample. :)
:)
> I think you honestly and in good faith read something into Erik's words
> which was not there, and to which Steele /was/ a counterexample. By
> staring harder and harder at Steele and how you might tweak
> "counterexample", you have innocently fallen into a false minimum in
> your search of the solution space to this tedious argument.
OK, I give up...
Simon András
> 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.
Maybe he did, but certainly not in the part quoted by Pascal. There he
didn't mention C# at all, and he said something about "people who are
massively inept at programming", not about "all people who believe
in the usefulness of static typing". So I stand by what I wrote.
But at least we probably agree that this subthread has nothing to do
with the usefulness of static typing :-)
Andras
Erik Naggum
| Why don't you just stop posting messages that are essentially free of
| any content? Don't you have something more substantial to offer?
"You"? You do not quote anyone, so does that mean you talk to the
mirror that is your computer display?
| Or are you just full of hot air?
I asked for proof of his kinder, gentler method of dealing with
people when he dislikes what they do. I see that he has accepted
my invitation to show us the Pascal Costanza that he really wants
us to remember. The kinder, gentler Pascal Costanza method of
compassionate communication boils down to "or are you just full of
hot air?" -- /that/ is what Pascal wants us to remember about him.
I, for one, have never believed the self-serving crap he has posted
about being nicer to people. He cannot do it himself when it would
save his ass, hence it is nothing but bullshit. Anyone can be nice
when not under any sort of pressure, internal or external. He now
demonstrates what happens to someone who is inexperienced at
dealing with his uncontrolled negative emotions and particularly to
someone who checks his emotions first and only /maybe/ thinks if he
feels like it. It is /not/ a pretty sight. The worst part is that
he is doing even more self-serving recovery to feel better by
pretending none of this is his own fault. This is what broken
people look like, shirking responsibility for their own behavior
and going "look what you made me do!" when they clearly started the
whole thing themselves. Coming out on top and feeling good is all
that matters to these emotionally broken people.
You have behaved like a retarded, uncontrollably emotional child,
Pascal Costanza, and it looks like you will learn nothing from it
because you can blame someone else for how bad you feel about it.
You /should/ feel bad, however, and you /should/ think about it,
because you could have avoided the insane accusations, the moronic
"can you read" questions and commentary that only highlights how
uncontrollably enraged you were. You have been an idiot, Pascal,
and nothing on this planet can erase that from anyone's memory.
What matters now is whether you are able to accept responsibility
for your own behavior or whether you still have to blame someone.
Please realize, even if you are mentally unprepared to accept the
full ramifications of it, that I am /extremely/ annoyed with your
incessant need to blame /me/ for /your/ malfunction and misbehavior.
If I am right about you, you have /never/ accepted responsibility
for your own emotions in your whole entire life. My guess is that
somebody has always been there to make you "feel better" and tell
you that the people who "hurt" you (i.e., pretending they /caused/
you to feel hurt, further avoiding responsibility for your emotions)
were wrong and bad but /you/ were a good kid, no matter what you
did to anyone. That never was true, was it? It was you who hurt
people, was it not? Because you were never made responsible for
your reactions to what you only /perceived/ to be wrong-doing (and
we already know that you lack the ability to distinguish between
your impression of something and that something, effectively not
knowing how to distinguish an observation from a conclusion), you
got the misguided notion that as long as /you/ thought something
was wrong, /you/ had the right to attack people with no checks and
balances and contrary opinions accepted, right? Parents who teach
their children that they can retaliate and are never responsible for
their own actions because they were only retaliating produce people
who are /fantastically/ evil. The institutions of due process and
rule of of law was instituted to keep such people from acting on
their revengeful emotions, but some people never undestand what
this is all about because they actually believe that their emotional
response is all they need to determine who is good and who is bad.
The simple-minded attitude you have towards everything, that there
is one correct answer and it is the one you have, betrays a history
of mistakes that somebody else covered up for you. No one is more
certain than the person who has never had to pay for his mistakes,
and the worst of that lot are those who could get away with blaming
and making someone else pay for their mistakes. You may infer that
those who have been on the receiving end of blame or who have been
forced to pay for the mistakes of others have a very low tolerance
for new people who try the same -- and consider people like Pascal
Costanza, who have the /gall/ to pretend to be champions of "nice"
when they are in fact only unable to accept responsibility of their
own malfunction and misbehavior, to be the worst of the worst, as
they are the kind of people who go through life feeling good about
themselves solely because they were able to blame someone who does
not /matter/ to them, combining irresponsibility with dehumanizing
the victims of their blamethrowing.
A person who preaches "nice" and acts the way Pascal Costanza does,
even when repeatedly urged to act the way he has demands of others
and has very strongly argued is the right way to deal with people,
is not just a despicable hypocrite, he has a double standard: There
are those people that Pascal Costanza will be nice towards, and the
people he will be downright evil towards -- the worthy and the not
worthy -- the human and the not quite human, the undeserving of
human empathy from the great benefactor, Pascal Costanza. To see
this behavior from a German is /frightening/. To see this behavior
from a person who has spent so much time and effort arguing against
the way he himself chooses to act when he needs to blame someone
for his own evil is actually enormously, engulfingly /fascinating/.
It is actually possible for a person like Pascal Costanza to live a
life of ignorant bliss where he rises to defend ways he himself
does /not/ employ when it could have saved him and to attack the
ways he himself chooses when he feels revengeful, hateful, and
destructive towards another human being. When the champion of
"nice" resorts to this kind of behavior, which he himself has spent
countless hours attacking, vilifying, the only result that one can
predict with some degree of certainty is that this person /must/
blame someone else for his own evil behavior. It is not possible
for Pascal Costanza to stand up and accept that he has indeed been
behaving the same way as, and even worse than, what he has been so
strongly against. And over what? "Correct terminology"! The mind
boggles.
I can hardly /express/ the disgust I feel towards Pascal Costanza.
The magnitude of the hypocrisy of this unthinking, evil bastard
whose only goal is to feel good about himself defies description by
normal means. I may request the literary services of J.K.Rowling
to describe the monstrosity of the badly broken mind that is Pascal
Costanza and his willingness and deeply rooted personal need to
blame someone for his own evil so he can escape the consequences,
scot free, once more, and so he can go on to argue that /others/
should be "nice" without feeling the pain of his conscience telling
him that he, of all people, should shut the hell up about telling
/anybody/ to be "nice". But I believe it is impossible for someone
like Pascal Costanza to have a conscience. It is not possible for
a person to do what he has done in this thread and not be /aware/
that he has denounced his own behavior extremely strongly in the
past. In the single most pronounced failure of his own method of
dealing with other people, Pascal Costanza has shown us just how
/irrelevant/ the "be nice" is. If Pascal Costanza cannot keep his
own standards of conduct, at the very least nobody /else/ should
feel guilty for not managing to do what he has told them to do.
I bet, however, that he will come back with more blame-throwing,
yet more evasive measures to dodge responsibility for what he has
done, he will yet again blame me for his malfunction, like those of
his ilk are wont to do when they realize what they have done and
need, desperately, for someone to tell them that they are good kids
and somebody else "made them do it". Helplessness at the scale we
have witnessed in Pascal Costanza's behavior is simply not credible,
however. The reason he acted the way he did was that he believed
that he could blame someone else all along, that he would not be
remembered for what he had done if he could blame someone for it.
Sadly, there are people who accept this line because they hope they
will benefit from it themselves some day. I hope I have put an end
to the chances Pascal Costanza has to blame someone for what does
for the rest of his miserable existence on this newsgroup and maybe
even elsewhere as search engines match his name to this article.
And to think he staged this war over something as fundamentally
stupid as his severely misguided notion of correct and accepted
terminology and his idiotic insistence on a contradiction. Sheesh!
And, now, we get to watch the dipshit try to save face. Stay tuned!
Mark Jason Dominus
Bruce Hoult <br...@hoult.org> wrote:
>In article <3df36c7c$1...@nntphost.cis.strath.ac.uk>,
> Thomas Stegen <tst...@cis.strath.ac.uk> wrote:
>
>> Pascal Costanza wrote:
>> >
>> > No, it's statically typed.
>>
>> Ok, but how does the polymorphism work then?
>
>As with other HM languages (SML/NJ, CAML), a type can be polymorphic
>(i.e. a union type),
In HM languages, union types are not what is usually referred to by
'polymorphic types'.
A union type is a union of two essentially different types, which must
then be tagged somehow so that the run-time system knows which of the
base types is actually stored.
A polymorphic type is not a union type. A function with a polymorphic
type is one that can be compiled to machine code in such a way that it
does not care what the underlying type is. A trivial example is the
identity function. Identical machine code implements the identity
function on integers, reals, strings, lists, functions, and every
other sort of data.
A less trivial example is the 'car' function, which in ML is called
'hd'. 'hd' operates on any list at all, regardless of the type of
data stored in the list. In SML, it has the type
'a list -> 'a
indicating that the argument is a list (whose elements have type 'a,
where 'a is a free variable) and that the return value is a single
datum, also of type 'a. In contrast, a function to take a list of
integers and return the sum of the integers would have type
int list -> int
The 'hd' function can operate on any list whatsoever, and its return
type depends on the type of the list it is given. However, the return
type is not totally unconstrained; each time the 'hd' function is used
in the source code, if the type of its argument can be deduced, so can
the type of its return value, and the return type can then be used in
further type checking to make sure it was used properly. Or vice
versa: If the return value type can be deduced, then that implies a
constraint on the argument, which can be checked to make sure that t
he argument came from the right place.
A function like 'hd' is polymorphic because the same machine code can
be generated to operate on any list, regardless of the type of the
data stored in the list. No case analysis is necessary.
>in which case anywhere it is used it must be either passed to another
>place expecting the same polymorphic type,
It need only be passed to another place that expects a *compatible*
polymorphic type. For example, the first argument of the 'map'
function is required to be another function, of type 'a -> 'b. 'hd'
is a legal argument even though it doesn't have type 'a -> 'b because
its type is 'a list -> 'a, which is a special case of 'a -> 'b.
Passing an argument in this way then constrains the type of the
argument, which may in turn constrain the way it is used or the type
of the function that produced it. The argument of 'hd' is not
completely constrained, but it is not completely unconstrained,
either.
The constraints propagate backward and forward through the program,
and if any of the constraints are inconsistent with one another, the
compiler raises an error.
> or else must be broken
>down into *all* the possibilities using a case/switch-like construct.
You appear to be discussing union types, not polymorphic types. Of
course union types need to be broken down by cases, because the
compiler can't generate the same code for ints as for floats.
>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.
Typically, languages like SML/NJ will add the default exception branch
automatically, but will also raise a compile-time nonfatal warning to
inform you that the run-time exception is possible.
>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.
I don't know what these people told you. But you seem to have
confused this with polymorphic typing; it is not really related to
that, or to the HM type system.
I hope this helps to clear up your misunderstanding of polymorphic types.
Erik Naggum
| If Erik is capable of introducing a different terminology that is
| still consistent, why doesn't he just do that?
Do you think you could try to figure out just how many logical
fallacies you committed in this disgusting excuse for an argument?
My guess is that you are unable to think logically because you do
not feel that logic can help you. You could not think your way out
of a wet paper bag, could you? All emotion, no thought. *puke*
| Erik's points were rather trivial to me.
There is no evidence that you have actually understood any points.
Chris Gehlker
f06747e2.0212...@posting.google.com, "Kenny Tilton"
<kti...@nyc.rr.com> wrote:
> Chris Gehlker <geh...@fastq.com> wrote in message
> news:<BA1972CA.24373%geh...@fastq.com>...
>> 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.
>
> bzzzt! Sorry, as Erik noted, Pascal's interesting find, the Steele
> quote, is fodder for the discussion but not a counter-example to
> Erik's observation.
That depends on how you read Erik's original statement. I submit that
reading it 'people believe in static typing iff they are massively
incompetent' is not much of a stretch. I agree that you could read it 'there
are some people who are both incompetent and believe in static typing'.
Given the whole post, that seems an unlikely reading.
> Erik set up a bit of a straw man (hard to counter-example), a coder
> who thinks "if they can catch some bugs at compile-time, that somehow
> makes all the remaining bugs less important and hard to catch".
> Steele's observation says something very favorable about the type
> checker, but does not say anything as preposterous as did the straw
> man.
The statement, taken literally, doesn't need a counter example because it is
false on its face. Clearly if a program has 100 bugs, and 10 are caught at
compile time, then the remaining 90 are easier to catch. But I don't think
Erik meant it that way. I think he meant something like 'You are going to
catch all the trivial bugs that the static checker catches anyway as part of
the testing needed to catch the more serious bugs. And static type checking
isn't free.'
> Now if only Pascal had not said "counter-example" we would not have
> this frightfully dull thread (which I cannot resist joining!), but he
> did and Erik caught him on it. Now if only Pascal had responded,
> right, "counterexample" was the wrong word, how about a nice type of
> safe characterization like "food for thought", again we'd be back to
> discussing something important like my great Cells project.
Yes it is a great project. Just stop the polls. Your first intuition is
right. Go with it.
> But
> nooooo....! You decide to summarize and really cock things up by
> misquoting Erik:
I didn't. I was quoting fictional characters named Eric and Pascal in my
little historical fiction summarizing the thread. There was no possibility
that anyone could mistake these for real quotes of actual people even in
plain text. One Usenet, where there is an entirely different quoting style
for real quotes of actual people, there is another safeguard.
>
> Peace y'all. kenny
Piers Cawley
> Thomas F. Burdick wrote:
>
>>> I still think you could rephrase Steele's quote as follows: "As
>>> soon as no bugs occurred at compile-time, that somehow made the
>>> code free of any remaining bugs."
>> What?!?! Try rereading the quote without having already decided what
>> he's saying.
>
> Now I am really puzzled. Steele's quote, with my understanding of the
> quote added:
>
> "...almost always, once I made the type checker happy [no bugs at
> compile-time], the program was correct [no bugs at all, including
> "reamining" bugs]."
>
> Do I really misunderstand the quote? If so, could you perhaps provide
> some help to correct my understanding?
You do seem to be ignoring the 'almost always' qualifier.
--
Piers
"It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
-- Jane Austen?
Kenny Tilton
> Kenny Tilton wrote:
> > (Cells make big programs easy to get right. <g>)
>
> This was the advertisment section, right? :)
Mr. Subliminal <cells> strikes again. :)
--
kenny tilton
clinisys, inc
---------------------------------------------------------------
""Well, I've wrestled with reality for thirty-five years, Doctor,
and I'm happy to state I finally won out over it.""
Cellswood P. Dowd
Patrick W
> Here is some red meat:
>
> Some programmers are competent/knowledgeable/non-delusional despite
> the fact that they believe the kind of static type checking provided
> by C# is useful.
And now for the vegetables: this was never in dispute.
Frank A. Adrian
> In the meantime, I will stick to the one provided in that paper.
And herein lies the problem. You believe it is up to *us* to do the
research and read these stupid papers (I read the first one you referenced
- it's pretty crappy and not worth the time and about as unbiased as a
loaded die) so that we have the privilege of understanding *you*, rather
than you, yourself, taking the responsibility to define the terms that are
not necessarily commonly held (except by your say so) so that you are not
misunderstood.
And you wonder why people call you arrogant.
faa
Ray Blaak
> This contradicts Erik's assessment that compile-time checks don't guarantee
> the absence of bugs.
But compile-time checks don't guarantee the absence of bugs. They just make
you deal with different kinds of bugs.
There is always something that is not fully known until runtime.
On the other hand, many important classes of bugs can indeed be detected and
thus prevented at compile time. Indeed there are whole classes of tests one
does not need to write since it is verified by the language itself.
But there are trade offs: you have to take the trouble to specify things
precisely enough that the compiler has enough information to determine if you
have violated your intended abstractions.
Sometimes this is more trouble than it is worth. Sometimes the adherence to
one's specifications results in a loss of flexibility. Sometimes people do not
want to be bothered by an official "compilation" phase.
> We are talking about programming languages here. "Statically typed"
> means "type checking carried out statically", i.e. at compile-time.
"Real" (as in real useful) statically typed languages always have some aspect
of dynamism to them. Indeed the static/dynamic typing divide is really a
continuum rather than a rift.
Different languages take up different positions on this line.
Dylan is an example of a language where the user gets to choose just where on
the continuum they want to live.
--
Cheers, The Rhythm is around me,
The Rhythm has control.
Ray Blaak The Rhythm is inside me,
bl...@telus.net The Rhythm has my soul.
Ray Blaak
> In Java, watch out for runtime type errors on array access, and null pointer
> exceptions. Languages like Haskell or ML are designed in a way that they
> can claim that they won't have any type errors at run time; of course, this
> is only really correct if you kindly adopt their definition of runtime type
> error.
Do people really believe that static-typing means "no runtime errors"? Or do
they believe that static-typing freaks believe that? This would explain a lot
why this issue keeps on popping up, with such strong opinions on both sides.
Have you ever encountered a language in which runtime errors are impossible?
The reference manuals for the standard static languages always have a section
on the kinds of errors that can happen at runtime.
The real question is: what kind of automated error checking do you want from
your langauge system, and what work are you willing to do to let that error
checking be achieved? One's answers here guide their choice of language.
Pascal Costanza
> Pascal Costanza <cost...@web.de> writes:
>
>>This contradicts Erik's assessment that compile-time checks don't guarantee
>>the absence of bugs.
>
>
> But compile-time checks don't guarantee the absence of bugs. They just make
> you deal with different kinds of bugs.
>
> There is always something that is not fully known until runtime.
>
So perhaps Guy Steele somehow intuitively avoids the bugs that are not
caught by compile-time checks, and maybe for this reason Haskell's type
checker helped him just because it dealt with the kind of bugs he needed
help with. Sounds plausible. Less experienced programmers are likely to
have a different outcome.
>>We are talking about programming languages here. "Statically typed"
>>means "type checking carried out statically", i.e. at compile-time.
>
>
> "Real" (as in real useful) statically typed languages always have some aspect
> of dynamism to them. Indeed the static/dynamic typing divide is really a
> continuum rather than a rift.
Yes, that's right. I don't think that there is _any_ language out there
that does not rely on dynamic typing to a certain degree. The declared
goal of the static typing community is to cover as many cases as
possible, but there will always be something left to dynamic typing.
> Different languages take up different positions on this line.
>
> Dylan is an example of a language where the user gets to choose just where on
> the continuum they want to live.
This is indeed interesting. Is this similar to what, for example,
Objective-C does? Could you point to a source that describes this aspect
of Dylan?
There are also other interesting approaches that try to bridge the gap
between static and dynamic typing. Soft typing is very interesting
(http://c2.com/cgi/wiki?SoftTyping); in the AOSD community there are
also approaches that allow you to define your own type checking, like
parts of AspectJ or, for example,
http://www.joint.org/use2002/sub/#kimmensIntensionalViews
Pascal Costanza
> Pascal Costanza wrote:
>
>
>>In the meantime, I will stick to the one provided in that paper.
>
>
> And herein lies the problem. You believe it is up to *us* to do the
> research and read these stupid papers (I read the first one you referenced
> - it's pretty crappy and not worth the time and about as unbiased as a
> loaded die)
Do you mean the Cardelli paper? If you think its contents are crappy,
then just come up with a better alternative.
> so that we have the privilege of understanding *you*, rather
> than you, yourself, taking the responsibility to define the terms that are
> not necessarily commonly held (except by your say so) so that you are not
> misunderstood.
I did that. "Statically typed" means "statically checked" means "checked
at compile-time". "Explicit typed" means "types are given explicitly";
"implicitly typed" means "types are implicit" means "types must be
inferred", hence "type inference". It's not too difficult.
> And you wonder why people call you arrogant.
I don't know what arrogance has to do with it. Just come up with an
alternative suggestion, and we can discuss the advantages and disadvantages.
Alain Picard
> Actually, I've seen this a lot. You'd *hope* that this hypothetical
> fool of a programmer was a straw-man argument, but I've seen far too
> many people who think that making semi-random changes (ie, they change
> things without knowing *why*) to make the compiler shut up (or even
> just change errors to warnings) -- once you've done that, the program
> should pretty much work. These people exist, there's quite a lot of
> them, and they're surprised every time their code breaks.
Actually, this reminds me of a mate who used to
say: "If it compiles, it runs... FAST!!!"
I _think_ he was tongue in cheek, but it became
a favorite of mine. :-)
Nils Goesche
> Nils Goesche <car...@cartan.de> writes:
> > In Java, watch out for runtime type errors on array access, and
> > null pointer exceptions. Languages like Haskell or ML are
> > designed in a way that they can claim that they won't have any
> > type errors at run time; of course, this is only really correct if
> > you kindly adopt their definition of runtime type error.
>
> Do people really believe that static-typing means "no runtime
> errors"? Or do they believe that static-typing freaks believe that?
I've met enough people who indeed do believe that. And in some sense,
it is even true that you won't have any runtime type errors in ML or
Haskell.
> This would explain a lot why this issue keeps on popping up, with
> such strong opinions on both sides.
The reason it is popping up again and again is that there are a lot of
people who believe that you need static typing to write working
software. These people keep telling things like ``but without static
typing you'll get runtime type errors like when you do (+ 2 "3")´´.
This might be an idiotic statement -- but they won't magically go
away just because we know it is nonsense. Read comp.lang.functional
for a while to see what I mean.
> Have you ever encountered a language in which runtime errors are
> impossible?
>
> The reference manuals for the standard static languages always have
> a section on the kinds of errors that can happen at runtime.
True. But they also seem to be very proud when they tell you they
won't have any runtime _type_ errors in ML...
> The real question is: what kind of automated error checking do you
> want from your langauge system, and what work are you willing to do
> to let that error checking be achieved? One's answers here guide
> their choice of language.
No, this is already static typing propaganda: ``Why, everybody chooses
the language that suits his needs -- you don't care if your programs
have lots of errors at runtime, so you choose a dynamically typed
language, and /I/ want to write bug-free software and hence choose a
statically typed language; ok, that means I'll have to do some more
work before the program runs...´´.
What kind of ``automated error checking´´ you want? Who in his right
mind would /not/ accept any kind of ``automated error checking´´ he
can get? I always fix every warning my Lisp compiler spits out, for
instance. That is /not/ the question.
All arguments trying to show that static typing leads to safer
software are flawed, because they are attempts to somehow circumvent
Nils' Fundamental Theorem #2:
# You cannot, under whatever circumstances, improve the security of a
# system by removing type information from your data.
This is obviously true, almost trivial in fact. Because of this, all
attempts to show why static typing improves security are futile right
from start. This doesn't stop people, however, to try anyway; just as
there are lots of people who continue trying to build a perpetuum
mobile or trisect an angle. Often the machines and proofs such people
come up with are very elaborate and intelligent, and it is hard to see
where they're flawed -- but we already know they're flawed because
they contradict Theorem #2.
More honest and knowledgable static typers know that the /real/ goal
of static typing is not security but something different: Efficiency.
The whole purpose of their ``compile time checks´´ is to find places
where the compiler can /omit/ security checks to gain efficiency.
Restrictions are added to the language so this is made easier for the
compiler, like forcing all integers to be fixnums, and having every
list carry elements of the same type. As the programming task, what
the program is supposed to do, is still the same, this only makes
programming more tedious and complex /for more efficiency/, not for
more security. If you make a certain conceptual error, by forcing
your concepts into your restricted language's type system you only
shift the bug from the type level to another level of abstraction.
You can tell your marketing people that the bug wasn't a type error,
however.
So, the extra ``work you are willing to do´´ when using a statically
typed language is micro-optimization of everything (even the helpme
message), the work you do in Lisp when the program works: If it is too
slow, you profile and add some declarations where necessary (but not
to everything as you would in a statically typed language).
Regards,
--
Nils Gösche
"Don't ask for whom the <CTRL-G> tolls."
PGP key ID 0x0655CFA0
Kenny Tilton
Pascal Costanza wrote:
> Ray Blaak wrote:
>
>> Pascal Costanza <cost...@web.de> writes:
>>
>>> This contradicts Erik's assessment that compile-time checks don't
>>> guarantee
>>> the absence of bugs.
>>
>>
>>
>> But compile-time checks don't guarantee the absence of bugs. They just
>> make
>> you deal with different kinds of bugs.
>>
> > There is always something that is not fully known until runtime.
> >
>
> So perhaps Guy Steele somehow intuitively avoids the bugs that are not
> caught by compile-time checks, and maybe for this reason Haskell's type
> checker helped him just because it dealt with the kind of bugs he needed
> help with. Sounds plausible. Less experienced programmers are likely to
> have a different outcome.
When I ported Cells <g> to Java, I came away with the same feeling as
Steele, tho I put it in a less favorable light: "If I can get the
friggin' compiler to accept my code, it's probably right." This was not
a compliment.
All that happened was that braindead, sloppy stuff I dashed off often
got caught at compile time instead of runtime. Most programmers
presented with either kind of error just try to make the error go away.
I usually rewrite the whole thing from scratch when anything breaks,
because I notice behind the immediate error some deeper conceptual error
of mine.
I'm not a very good programmer, but (1) I know when I have written crap
and (2) I take the trouble to rewrite it. So during the Java port (of
Cells), every time I got a compile-time error I did a lot of reworking
of the code that would have gotten done anyway after runtime errors. And
by time the damn thing compiled and linked clean, it was right. (But
when I say that, and I would wager Steele as well, we are being
melodramatic, striving for a sound bite.) Anyway...
The mysterious "for some reason" is simply that any good programmer,
when spanked by compiler or backtrace, takes it as a possible Message
From God(tm) to make the deepest fix possible, howver much refactoring
that requires. Type checkers just move a lot of that process from
runtimme to compile-time. And since they do not rely on code or path
coverage by the test suite, they may even offer something over runtime
type safety.
So my take on this is that when Steele got a compiler error he started
thinking. Straw's problem is that when he got a clean compile he stopped
thinking.
--
kenny tilton
clinisys, inc
---------------------------------------------------------------
""Well, I've wrestled with reality for thirty-five years, Doctor,
and I'm happy to state I finally won out over it.""
Elwood P. Dowd
Kellom{ki Pertti
> Have you ever encountered a language in which runtime errors are impossible?
AFAIK, the logic of the PVS theorem prover <http://pvs.csl.sri.com> is
such a language. There is a mapping from a subset of the higher order
logic to (you guessed it) Common Lisp so you can run your
definitions. They have used it for simulation of microprocessors in
order to have just one description of a processor for simulation and
for verification.
> The real question is: what kind of automated error checking do you want from
> your langauge system, and what work are you willing to do to let that error
> checking be achieved? One's answers here guide their choice of language.
Exactly. The type system of PVS is very expressive (an arbitrary
predicate can denote a type) with the expense that type checking is
undecidable. The machine does what it can, and asks for human
assistance when it fails. For example, the following definitions
foo(n : nat) : nat = n + 1
bar(x : int) : real = if x >= 0 then 1 / foo(x) else x endif
result in a proof obligation
bar_TCC1: OBLIGATION FORALL (x: int): x >= 0 IMPLIES foo(x) /= 0;
to ensure that division by zero does not occur. Hence, if you map the
definitions to CL and run them, there is no possibility of a run-time
error if you have done your type checking.
I should probably hasten to add that the PVS folks market their system
as a specification language rather than a programming language. Still,
my hunch is that the next big advances in programming languages will come
from sophisticated type systems like PVS's.
--
Pertti Kellom\"aki, Tampere Univ. of Technology, Software Systems Lab
Chris Gehlker
<bl...@telus.net> wrote:
> Do people really believe that static-typing means "no runtime errors"? Or do
> they believe that static-typing freaks believe that? This would explain a lot
> why this issue keeps on popping up, with such strong opinions on both sides.
I started to to study Haskell but set it aside in favor of Lisp. I can
assure you that the Haskell crowd believes that their very strong typing
makes runtime errors *very* unlikely. As Nils has said, in part this relies
on using a definition of "run time" which seems stretched to prove their
point.
<opinion> I think they make a fetish of catching errors at compile time. It
is as if they believe that the only alternative is reading core dumps. They
seem not to understand that dynamic typing can work very well. They also
seem to not consider it an 'error' if the program runs but produces
incorrect output because of some fundamental logic flaw. It's easy enough in
Haskell to produce a 'correct' program that will tell you 0 degrees
Fahrenheit is 100 degrees Centigrade.</opinion>
Pascal Costanza
> When I ported Cells <g> to Java, I came away with the same feeling as
> Steele, tho I put it in a less favorable light: "If I can get the
> friggin' compiler to accept my code, it's probably right." This was not
> a compliment.
:) OK, I get your point.
On an unrelated sidenote: Yesterday I have taken a look at your Cells
project, and it seems to be extremely cool stuff. I would love to have
more time to actually try this...
Pascal
P.S.: Do you pay for surreptitious adertising? ;)
--
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)
Paolo Amoroso
> I think people thinking about learning C# to make a living should look
> at the stats. Here in the UK (mostly, some jobs are abroad) the
Concerning job security and Microsoft technologies, does any of you still
remember the name of the content creation and delivery technology--it was
around 1995--that should have replaced the Web? I seem to remember that its
code name sounded like "blackhawk" or something similar, and that it was
related to MSN.
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://www.paoloamoroso.it/ency/README
Joe Marshall
> Do people really believe that static-typing means "no runtime
> errors"?
Static typing aficionados believe that there will be ``no runtime
*TYPE* errors''. However, there can certainly be ``union
discrimination exceptions'' at runtime as well as other sorts of
programming errors.
> Have you ever encountered a language in which runtime errors are impossible?
Sure, but they are `toy' languages.
> The reference manuals for the standard static languages always have a section
> on the kinds of errors that can happen at runtime.
But they aren't ``type'' errors (for certain definitions of ``type'').
> The real question is: what kind of automated error checking do you want from
> your langauge system, and what work are you willing to do to let that error
> checking be achieved? One's answers here guide their choice of language.
And what do you want to do if the automatic process can't statically
decide?
My personal preference is that the automatic error checking should do
as much as it possibly can as early as it possibly can, with the
constraints that I'm not at all willing to decorate my program with
hints for the type checking and that if the type checker cannot prove
that my program *will unconditionally* generate an error, it should
assume that I know what I'm doing.
Pascal Costanza
> My personal preference is that the automatic error checking should do
> as much as it possibly can as early as it possibly can, with the
> constraints that I'm not at all willing to decorate my program with
> hints for the type checking and that if the type checker cannot prove
> that my program *will unconditionally* generate an error, it should
> assume that I know what I'm doing.
Do such systems exist?
Pascal
Dan Schmidt
| So perhaps Guy Steele somehow intuitively avoids the bugs that are
| not caught by compile-time checks, and maybe for this reason
| Haskell's type checker helped him just because it dealt with the
| kind of bugs he needed help with. Sounds plausible. Less experienced
| programmers are likely to have a different outcome.
It also depends on the kind of program you are writing.
If you're doing lots of numeric computation then most of your variables
are going to be floats or whatever, so type-checking doesn't really buy
you anything.
If your problem space is such that you have lots of distinct types, so
that a lot of subproblems really are mostly of the form "given values
of types A and B, produce the corresponding value of type C", then
Haskell-style type checking does help to catch a lot of mistaken code
at compile time.
Dan
Wade Humeniuk
"Ray Blaak" <bl...@telus.net> wrote in message news:uel8qp...@telus.net...
>
> Do people really believe that static-typing means "no runtime errors"? Or do
> they believe that static-typing freaks believe that? This would explain a lot
> why this issue keeps on popping up, with such strong opinions on both sides.
>
That is "no runtime type errors". Anyone (and I mean in the universal sense)
that has actually written larger programs knows that type errors are one of the
most basic and simplest errors possible. By far the largest type of error is
the program not doing what it should do. I would call these
programmer errors (loose thinking). Perhaps people think by having a
consistent definition of the data (types) that they think they have all
the design and programming issues out of the way. Part of brain
thinks that by understanding the form of the data and how it is passed
around, that it understands the whole problem. It may, but still the
program has to be written with reality in mind. This is inherently
limited by what a computer and language can actually do.
> Have you ever encountered a language in which runtime errors are impossible?
>
> The reference manuals for the standard static languages always have a section
> on the kinds of errors that can happen at runtime.
>
> The real question is: what kind of automated error checking do you want from
> your langauge system, and what work are you willing to do to let that error
> checking be achieved? One's answers here guide their choice of language.
Lisp has a runtime typing system because it is a dynamic language where
code, structures, classes can change "on the fly". Having static type
checks in the compiler has no meaning in CL and is dangerous in all
but the most tested and stable code. (declare (optimize (safety 0)))
If you want a dynamic language, this decison is pretty well made for you.
Wade
manuel...@cetp.ipsl.fr
> The reason it is popping up again and again is that there are a lot of
> people who believe that you need static typing to write working
> software. These people keep telling things like ``but without static
> typing you'll get runtime type errors like when you do (+ 2 "3")创.
> This might be an idiotic statement -- but they won't magically go
> away just because we know it is nonsense.
>
I think I don't get it. As I understand it, this kind of claim is
nonsense because whatever language you use, when you do (+ 2 "3"), you
will get :
(or 'a-compile-time-error ;; Typically OCaml
'a-runtime-error ;; Typically Lisp
'no-error-but-real-bug) ;; C and char*
Is this why it is nonsense : because error have to be somewhere whatever
place it will be ?
> Read comp.lang.functional for a while to see what I mean.
>
I think I should do this, first. Can you think of a particular thread or
just few keyword to search Google Groups ?
--
_Manuel Giraud_
Ray Blaak
> Ray Blaak wrote:
> > Dylan is an example of a language where the user gets to choose just where
> > on the continuum they want to live.
>
> This is indeed interesting. Is this similar to what, for example,
> Objective-C does? Could you point to a source that describes this aspect
> of Dylan?
Any decent Dylan tutorial will do. There is a "Dylan Programming" page at:
http://www.geocities.com/dylan_programmer/index.html
See also "Getting Started with Dylan" at: http://www.tpk.net/~ekidd/dylan/
Basically, type specifications for variables, parameters and method return
values are optional. When known, the compiler will check statically. If not
known at compile time, the check is deferred till runtime.
So, if you wish to be anal you can. If you wish maximum flexibility, say
during prototyping, you can do that too.
ObLisp: The main thing that makes Dylan shitty is the syntax :-).
Erik Naggum
| Do you mean the Cardelli paper? If you think its contents are
| crappy, then just come up with a better alternative.
You appear not to learn from experience or input from the external
world, so let me just say this for any remaining audience:
If one thinks something somebody does is utter crap in one's
judgment, there is /no/ obligation do better, and neither /can/
there be. An age-old principle is that the burden of proof is on
he who asserts the positive. In practice, this means that the
person who argues /for/ something gets to do the dirty work. It is
a serious logical fallacy for the person who argues /for/ something
to demand that those who argue /against/ it do the dirty work of
achieving his goals, not to mention highly immoral and /sleazy/.
This goes directly to how some people fail to handle rejection, and
it is one of those things that defines a person's personality: When
other people do not value what you have done, /you/ should take it
back to the drawing board if /you/ need their approval; you should
/not/ demand that those who do not approve of it fix it for you, or
you should work harder to convince people of the value /you/ think
it has, not demand that other people do something else that /you/
value.
It is /indecent/ to make the kind of demands that Pascal Costanza
keeps making when people reject his ideas or opinions. First, it
portrays a serious lack of self-sufficiency in that it appears to
be a /demand/ for approval. This is consistent with the demand
that others be "nice" and take care of their emotional well-being.
Second, it appears to be an admission of /defeat/, that what people
reject is the absolute best he could ever come up with, and even
when people reject it, they are obligated to help achieve the goals
-- meaning that unless you want to spend time helping, you should
not offer any suggestions or comments whatsoever. This is, sadly,
also consistent with the demand that others be "nice" because it
may be "hurtful" to someone to face rejection of their /goals/ as
well as their half-assed attempts to achieve it. It is consistent
with the lack of self-sufficiency, too, as the defeat indicates not
a lack of effort, but of /insufficiency/ in achieving one's goals.
An argument from misery like this is a well-known fallacy dating
back thousands of years, but it does not get more valid with time.
It may not be in particularly good taste to reject something without
due cause, but it is just too stupid to take it seriously. Attempts
to belittle any rejection, well-founded or not, with a demand on the
rejector to come up with something better is not just in bad taste,
not just stupid, but the kind of thing that manipulative people need
to resort to when they are shit out of luck, and know it.
| I don't know what arrogance has to do with it. Just come up with an
| alternative suggestion, and we can discuss the advantages and
| disadvantages.
It is /quite/ arrogant to demand that people do as you please, and
it tends to piss people off to have some dishonest dipshit who does
not even know enough about proper argumentation to stay away from
serious fallacies make such demands.
According to the principle of burden of proof and ordinary decency,
it is Pascal Costanza who gets to listen to the criticisms and come
up with something better. After all, /he/ is the one who has made
a stink about "correct and accepted terminology", not anybody else,
so /he/ gets to support his case, not anybody else.
No wonder he wants people to be nice -- to /him/. It is pathetic!
Joe Marshall
> Joe Marshall wrote:
>
> > My personal preference is that the automatic error checking should do
> > as much as it possibly can as early as it possibly can, with the
> > constraints that I'm not at all willing to decorate my program with
> > hints for the type checking and that if the type checker cannot prove
> > that my program *will unconditionally* generate an error, it should
> > assume that I know what I'm doing.
>
> Do such systems exist?
Well, sure. Common Lisp, for example. I don't have to put in a
single type declaration, and if the compiler can't prove my program
*will unconditionally* generate an error, it goes ahead and compiles
my program.
The problem here is that I suspect that your average common lisp
compiler could go a lot further with regard to checking as much as it
possibly can as early as it possibly can.
Ray Blaak
> More honest and knowledgable static typers know that the /real/ goal
> of static typing is not security but something different: Efficiency.
I don't buy this, at least not in general. That is, efficiency is a common
enough goal, to be true, but the reams of literature on static typing
definitely show an obsession with correctness, safety, etc.
Now, they might be complete morons and be absolutely mistaken, but they
certainly think security is a goal.
I would assert that the opposite is true: security is the primary goal,
efficiency is a nice side effect, an optimization.
> If you make a certain conceptual error, by forcing your concepts into your
> restricted language's type system you only shift the bug from the type level
> to another level of abstraction.
If you have to "force" your concepts into the type system, then you are using
the wrong language. You define your own types, they describe *your*
abstractions. The compiler verifies the consistency of your usage of your own
design.
"Fighting the compiler" usually means "haven't thought things out properly yet".
Now, to be fair, it is entirely possible that for a particular problem you do
indeed need the flexibility of complete dynamism, or that in general your
preferences for programming tend to a more iterative, evolutionary
approach. Fine.
But to dismiss security entirely is foolish. You yourself pay attention to the
statically analyzed warnings from your Lisp environment. They are beneficial,
no?
Static typing can be thought of the language environment giving even more
warnings. The trade off is that the more "up front analysis" desired, the more
information the programmer has to give to the compiler. In can be worth the
trouble, or it might not.
Joe Marshall
> I think I don't get it. As I understand it, this kind of claim is
> nonsense because whatever language you use, when you do (+ 2 "3"), you
> will get :
> (or 'a-compile-time-error ;; Typically OCaml
> 'a-runtime-error ;; Typically Lisp
> 'no-error-but-real-bug) ;; C and char*
or some well specified, but unintended result like "23" or 5 (for
those systems that think that `if all else fails, its a string')
Nils Goesche
> Nils Goesche <car...@cartan.de> writes:
> > The reason it is popping up again and again is that there are a
> > lot of people who believe that you need static typing to write
> > working software. These people keep telling things like ``but
> > without static typing you'll get runtime type errors like when you
> > do (+ 2 "3")´´. This might be an idiotic statement -- but they
> > won't magically go away just because we know it is nonsense.
> I think I don't get it. As I understand it, this kind of claim is
> nonsense because whatever language you use, when you do (+ 2 "3"),
> you will get :
> (or 'a-compile-time-error ;; Typically OCaml
> 'a-runtime-error ;; Typically Lisp
> 'no-error-but-real-bug) ;; C and char*
>
> Is this why it is nonsense : because error have to be somewhere
> whatever place it will be ?
No; it is nonsense on a higher level :-) Ask how such an error might
occur: Will anybody ever type (+ 2 "3")? Clearly not, or only to
consciously signal a TYPE-ERROR condition. So, these values have to
come from somewhere else, for instance: (reduce #'+ some-list). But
then, how would a string ever get into SOME-LIST? Doesn't SOME-LIST
have some purpose? Who constructed it and how? Wasn't the function
that constructed it tested before? Still, how would a string creep in
there? This is just something that doesn't happen in practice.
Static typers would restrict lists now to contain only elements of the
same type and sure, then it would be impossible to put a string in an
integer list. However, if SOME-LIST is really supposed to be an
integer list, it is also very unlikely that you will ever put anything
else in there in the first place. Bugs like this just don't happen.
What sounds somewhat more likely is that SOME-LIST is in fact supposed
to be a list that can indeed sometimes contain strings besides
integers. Maybe it contains a list of tokens from user input. When
would we call (reduce #'+ ...) on it? Only when we are convinced that
in some particular situation there isn't possibly anything else but
integers in there. However, if we are wrong here, we will make the
same mistake in a statically typed language, because then the list
will be defined to hold elements of a union type -- basically the same
situation. The error exception will be raised explicitly and is
hopefully caught, but in safe Common Lisp code we will catch and
handle errors just as well (and we have restarts...). We have this
error automatically signalled, however, and don't have to define a
gazillion union types to get even started. So, our programs will be
shorter and simpler -- and hence probably contain even less bugs.
The kind of bug compilers of statically typed languages protect us
from is a kind of bug that hardly ever occurs in practice. When you
are learning a new statically typed language, you have a different
impression because at the beginning you hardly get any program
compiled because of the type checker... However, if you analyze the
``errors´´ the type checker actually finds, you'll see that most if
not all of them are only errors in your understanding of the weird
syntax and type system those languages typically have. Another
indication for this is that when you become more proficient in such a
language, this effect goes away -- the type checker won't find many
bugs anymore... and most of the ones it finds will still be mostly
caused by the shitload of restrictions and complications that were
introduced into the language to make the type checker work at all.
(``How did I call this f*cking constructor again? Oh no, that one
belongs to another union type...´´)
And a more theoretical explanation would be: Lisp is a dynamic object
oriented language. (2 "3" 4) is a list containing objects. If I call
REDUCE with #'+ on it, I am successively invoking methods on objects.
If I want the same functionality in a statically typed language, I'll
have to define a union type resembling the kind of objects I want to
deal with, and then functions that will dispatch on the particular
type of object so they'll operate exactly like my methods. These
functions will have to throw some exceptions on unexpected
combinations, just like #'+ does when you invoke it on non-numbers.
Same situation modulo Greenspun's 10th rule: The ML code doing what I
just described will be /much/ more complicated and verbose than the
corresponding Lisp code it is modelling. And most likely it will even
be much slower as ML isn't optimized for this way of programming.
This might seem like a trivial argument, as you'd never actually do
this in ML but start narrowing the union types right away (what I call
doing micro-optimization), but that doesn't make the argument
invalid.
> > Read comp.lang.functional for a while to see what I mean.
>
> I think I should do this, first. Can you think of a particular
> thread or just few keyword to search Google Groups ?
No, sorry. After all this I really don't feel like reading that stuff
right now ;-|
Kellom{ki Pertti
> All arguments trying to show that static typing leads to safer
> software are flawed, because they are attempts to somehow circumvent
> Nils' Fundamental Theorem #2:
>
> # You cannot, under whatever circumstances, improve the security of a
> # system by removing type information from your data.
>
> This is obviously true, almost trivial in fact. Because of this, all
> attempts to show why static typing improves security are futile right
> from start. This doesn't stop people, however, to try anyway; just as
> there are lots of people who continue trying to build a perpetuum
> mobile or trisect an angle. Often the machines and proofs such people
> come up with are very elaborate and intelligent, and it is hard to see
> where they're flawed -- but we already know they're flawed because
> they contradict Theorem #2.
>
> More honest and knowledgable static typers know that the /real/ goal
> of static typing is not security but something different: Efficiency.
> where the compiler can /omit/ security checks to gain efficiency.
If this is your view of static typing, no wonder you hold it in such
low esteem. An argument that comes up every once in a while in c.l.l
is that lispers are in fact very much aware of the types in their
programs, but the types are not expressible in the impoverished type
systems of mainstream languages. While true, this says nothing about
static typing per se, it only says something of the type systems of
mainstream languages.
There are already type systems out there that can express things like
"values in this list are in an ascending order" and "every reference
to a variable in this syntax tree has a corresponding definition of
the same variable". These things can be statically checked as well,
see my earlier post in this thread about the type system of the PVS
theorem prover <http://pvs.csl.sri.com>. Granted, they do not exist
for programming languages yet and maybe never will, but steps in the
direction are already there.
> Restrictions are added to the language so this is made easier for the
> compiler, like forcing all integers to be fixnums, and having every
> list carry elements of the same type.
You have been fooled by the dynamic typing propaganda. It is perfectly
possible to have heterogeneous collection types in a statically typed
language (see e.g. existential types in Mercury,
<http://www.cs.mu.oz.au/research/mercury/information/doc-latest/reference_manual_11.html>).
Fixnums I don't know about, but overflowing integers to bignums should
be no more difficult for an implementation of a statically typed
language than for an implementation of Lisp.
> So, the extra ``work you are willing to do创 when using a statically
> typed language is micro-optimization of everything (even the helpme
> message), the work you do in Lisp when the program works: If it is too
> slow, you profile and add some declarations where necessary (but not
> to everything as you would in a statically typed language).
In case this comes as a surprise to you,
f x = x + 1
is a perfectly good function definition in Haskell, and produces the
expected result:
Hugs session for:
/opt/local/lang/hugs98/share/hugs/lib/Prelude.hs
/tmp/hugs5819weH
Main> f 3
4
See mom, no declarations!
If you want to pick on statically typed languages, at least forget the
1970's vintage and tackle the more modern languages.