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.
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?
"marcel haesok" <·········@attbi.com> writes:
> 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
On 12/6/02 8:54 PM, in article ·····················@sccrnsc02, "marcel
haesok" <·········@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! =-----
"Chris Gehlker" <·······@fastq.com> wrote in message
···························@fastq.com...
> On 12/6/02 8:54 PM, in article ·····················@sccrnsc02, "marcel
> haesok" <·········@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! =-----
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.
On 12/7/02 11:21 AM, in article ······················@sccrnsc01, "marcel
haesok" <·········@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.
-----= 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! =-----
Chris Gehlker wrote:
> On 12/6/02 8:54 PM, in article ·····················@sccrnsc02, "marcel
> haesok" <·········@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)
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
* Chris Gehlker
| [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, 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.
* "marcel haesok" <·········@attbi.com>
| 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.
Erik Naggum wrote:
> 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 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...
>> 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.
Thomas Stegen wrote:
> 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.
--
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
Thomas Stegen wrote:
> Pascal Costanza wrote:
>
>>
>> No, it's statically typed.
>
>
> Ok, but how does the polymorphism work then?
>
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
--
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 wrote:
> Thomas Stegen wrote:
>
>
> I don't know exactly what you mean with this question.
It was an idiotic question. Thanks anyway.
--
Thomas.
Thomas Stegen <·······@cis.strath.ac.uk> writes:
> Pascal Costanza wrote:
> >
> > No, it's statically typed.
>
> Ok, but how does the polymorphism work then?
>
With polymorphic types, I guess.
Andras
In article <··········@nntphost.cis.strath.ac.uk>,
Thomas Stegen <·······@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 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
From: Mark Jason Dominus
Subject: Re: type safety in LISP
Date:
Message-ID: <at378t$onk$1@plover.com>
In article <···························@copper.ipg.tsnz.net>,
Bruce Hoult <·····@hoult.org> wrote:
>In article <··········@nntphost.cis.strath.ac.uk>,
> Thomas Stegen <·······@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.
Pascal Costanza <········@web.de> writes:
> 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: ·············@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/
Raymond Wiker <·············@fast.no> writes:
> Pascal Costanza <········@web.de> writes:
>
> > 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.
Yes, who has not seen a freshly diplomed 'programmer' be surprized
because his C program that compiled without error crashed?
--
__Pascal_Bourguignon__ http://www.informatimago.com/
----------------------------------------------------------------------
There is a fault in reality. do not adjust your minds. -- Salman Rushdie
Pascal Bourguignon wrote:
> Raymond Wiker <·············@fast.no> writes:
>
>
>>Pascal Costanza <········@web.de> writes:
>>
>>
>>>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.
>
>
> Yes, who has not seen a freshly diplomed 'programmer' be surprized
> because his C program that compiled without error crashed?
These are two different statements. Some comments:
- If a program is compiled correctly, and a small amount of test cases
are correctly executed, its programmer can falsely believe that the
program is correct. If a program is compiled correctly, and any test run
crashes immediately, that's a very different case.
- Novices are likely to be surprised by any programming language, for
various sorts of reasons.
- The fact that we all have seen novices making beginner's mistakes
doesn't tell us anything about statistical probabilities.
Pascal
--
Pascal Costanza University of Bonn
···············@web.de Institute of Computer Science III
http://www.pascalcostanza.de R�merstr. 164, D-53117 Bonn (Germany)
* 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.
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.
--
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.
Erik Naggum wrote:
> * 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.
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
| 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.
--
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.
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. [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".
--
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 <········@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?
> 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
On 12/8/02 8:09 PM, in article ··············@darkstar.cartan, "Nils
Goesche" <···@cartan.de> wrote:
> Pascal Costanza <········@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."
-----= 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! =-----
Chris Gehlker wrote:
> "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.
On 12/9/02 2:39 AM, in article ··········@nntphost.cis.strath.ac.uk, "Thomas
Stegen" <·······@cis.strath.ac.uk> wrote:
> Chris Gehlker wrote:
>
>> "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.
I think we are saying the same thing here.
-----= 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! =-----
Chris Gehlker wrote:
> 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.
On 12/9/02 9:56 AM, in article ········@nntphost.cis.strath.ac.uk, "Thomas
Stegen" <·······@cis.strath.ac.uk> wrote:
> Chris Gehlker wrote:
>
>> 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?
>
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."
-----= 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! =-----
Chris Gehlker <·······@fastq.com> wrote in message news:<······················@fastq.com>...
> On 12/8/02 8:09 PM, in article ··············@darkstar.cartan, "Nils
> Goesche" <···@cartan.de> wrote:
>
> > Pascal Costanza <········@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.
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
On 12/9/02 11:24 AM, in article
···························@posting.google.com, "Kenny Tilton"
<·······@nyc.rr.com> wrote:
> Chris Gehlker <·······@fastq.com> wrote in message
> news:<······················@fastq.com>...
>> On 12/8/02 8:09 PM, in article ··············@darkstar.cartan, "Nils
>> Goesche" <···@cartan.de> wrote:
>>
>>> Pascal Costanza <········@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
-----= 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! =-----
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."
> 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"?
Pascal
--
Pascal Costanza University of Bonn
···············@web.de Institute of Computer Science III
http://www.pascalcostanza.de R�merstr. 164, D-53117 Bonn (Germany)
Pascal Costanza <········@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. 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! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Thomas F. Burdick wrote:
> Pascal Costanza <········@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.)
--
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 <·······@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... :)
(Now, was /that/ off-topic or what?)
Cheers,
Edi.
PS: Marshall McLuhan.
In article <··············@bird.agharta.de>, Edi Weitz <···@agharta.de> wrote:
>Kenny Tilton <·······@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...
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?
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
Pascal Costanza <········@web.de> writes:
> 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?
Pascal Costanza <········@web.de> writes:
> 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]."
Okay.
> Do I really misunderstand the quote? If so, could you perhaps provide
> some help to correct my understanding?
"Once I made the type-checker happy, the program was [almost always]
correct," is not the same as, "that somehow made the code free of any
remaining bugs."
If we assume that bugs can be divided into overlapping categories, and
that each bug falls into at least one -- static type-checking will
catch a certain set of categories of bugs. Certain types of
information lossage, and certain types of infinite loops are the most
prominent. It seems painfully obvious that the type-checker has no
deep knowledge of the program, and thus cannot find a single bug which
requires anything more than a superficial understanding of the
program. A good type-checker does intensive analysis of what
information it has, but that information is necessarily limited and
superficial. Thus, it will be able to find bugs only in the least
important, and easiest to analyse layer of the program's logic.
I'm guessing that Steele focuses his intellectual energy on the more
important layers of the program, and--being someone noted for his
ability in this field--does a good job of getting those parts right.
Using a system with a static type-checker frees him from the need to
consider the logic that an automated type-checker can analyze. Thus,
the quote demonstrates how he divides labor between himself and the
machine. It does not imply that the machine was able to perform any
but the most banal tasks on his behalf, just that it was able to
perform those tasks.
A mediocre programmer who does not completely understand his or her
task, given a thorough analysis of the superficial logic of the
program, will often only push the bugs into deeper logical layers that
the type-checker cannot analyze, instead of fixing those bugs.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
This actually makes a lot of sense - thanks for that!
Pascal
Thomas F. Burdick wrote:
> Pascal Costanza <········@web.de> writes:
>
>
>>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]."
>
>
> Okay.
>
>
>>Do I really misunderstand the quote? If so, could you perhaps provide
>>some help to correct my understanding?
>
>
> "Once I made the type-checker happy, the program was [almost always]
> correct," is not the same as, "that somehow made the code free of any
> remaining bugs."
>
> If we assume that bugs can be divided into overlapping categories, and
> that each bug falls into at least one -- static type-checking will
> catch a certain set of categories of bugs. Certain types of
> information lossage, and certain types of infinite loops are the most
> prominent. It seems painfully obvious that the type-checker has no
> deep knowledge of the program, and thus cannot find a single bug which
> requires anything more than a superficial understanding of the
> program. A good type-checker does intensive analysis of what
> information it has, but that information is necessarily limited and
> superficial. Thus, it will be able to find bugs only in the least
> important, and easiest to analyse layer of the program's logic.
>
> I'm guessing that Steele focuses his intellectual energy on the more
> important layers of the program, and--being someone noted for his
> ability in this field--does a good job of getting those parts right.
> Using a system with a static type-checker frees him from the need to
> consider the logic that an automated type-checker can analyze. Thus,
> the quote demonstrates how he divides labor between himself and the
> machine. It does not imply that the machine was able to perform any
> but the most banal tasks on his behalf, just that it was able to
> perform those tasks.
>
> A mediocre programmer who does not completely understand his or her
> task, given a thorough analysis of the superficial logic of the
> program, will often only push the bugs into deeper logical layers that
> the type-checker cannot analyze, instead of fixing those bugs.
>
--
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
···@conquest.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> 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. :-)
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 wrote:
>
>
> 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...
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 wrote:
> 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
Kenny Tilton <·······@nyc.rr.com> writes:
> Pascal Costanza wrote:
> > Kenny Tilton wrote:
>
> > > (Cells make big programs easy to get right. <g>)
> >
> > This was the advertisment section, right? :)
>
> Mr. Subliminal <cells> strikes again. :)
No offense, but that was about as subliminal as the Clamatto ad by my
house that has a gigantic picture of a frosty mug filled with ceviche
and clamatto. "Prep�rate uno." Effective though (I kinda feel like
ceviche, and playing with a constraints system).
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Kenny Tilton <·······@nyc.rr.com> writes:
> Pascal Costanza wrote:
> > Kenny Tilton wrote:
>
> > > (Cells make big programs easy to get right. <g>)
> > This was the advertisment section, right? :)
>
> Mr. Subliminal <cells> strikes again. :)
Speaking of which, could you post an URL to Cells? I think I've been
especially stupid and somehow missed the link.
Thanks,
Greg Menke
Greg Menke wrote:
> Speaking of which, could you post an URL to Cells?
Twist my arm <g>: http://www.tilton-technology.com/
"Cellophane" was very briefly the name for the GUI project, so follow
that link to see screenshots. Follow the Cells link to find some rough,
incomplete, out-of-date doc which does at least explain how the little
suckers work and why I like them.
Re Cello, finally got outline fonts to work. Jeez, OpenGL is a ball-buster.
Thank god for the NeHe tutorials. But 3D (and being able to program
it from Lisp) is a blast.
I still want to see if RMaux of OpenRM fame will serve instead of GLUT,
but more and more I think the second step after getting the GUI working
universally will be to reinvent GLUT. We'll see.
--
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
Chris Gehlker <·······@fastq.com> writes:
> On 12/8/02 8:09 PM, in article ··············@darkstar.cartan, "Nils
> Goesche" <···@cartan.de> wrote:
>
> > Pascal Costanza <········@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
On 12/9/02 5:31 AM, in article ···············@tarski.math.bme.hu, "Simon
Andr�s" <······@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.
-----= 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! =-----
Chris Gehlker wrote:
> On 12/9/02 5:31 AM, in article ···············@tarski.math.bme.hu, "Simon
> Andr�s" <······@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.
Pascal
--
Pascal Costanza University of Bonn
···············@web.de Institute of Computer Science III
http://www.pascalcostanza.de R�merstr. 164, D-53117 Bonn (Germany)
* Chris Gehlker
| 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, 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.
Chris Gehlker <·······@fastq.com> writes:
> On 12/9/02 5:31 AM, in article ···············@tarski.math.bme.hu, "Simon
> Andr�s" <······@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
Chris Gehlker <·······@fastq.com> writes:
> 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?
On 12/9/02 9:22 AM, in article ··············@key.localdomain, "Patrick W"
<···········@yahoo.com.au> wrote:
> Chris Gehlker <·······@fastq.com> writes:
>
>> 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?
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.
-----= 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! =-----
Chris Gehlker <·······@fastq.com> writes:
> 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.
From: Pascal Costanza
Subject: Re: type safety in LISP
Date:
Message-ID: <3DF47645.10206@web.de>
Nils Goesche wrote:
> Pascal Costanza <········@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
···············@web.de Institute of Computer Science III
http://www.pascalcostanza.de R�merstr. 164, D-53117 Bonn (Germany)
* Pascal Costanza
| This contradicts Erik's assessment that compile-time checks don't
^Pascal Costanza's understanding of
| guarantee the absence of bugs.
Accept and take responsibility for your own contribution, will you?
--
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 <········@web.de> writes:
> Nils Goesche wrote:
> > Pascal Costanza <········@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.
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
Pascal Costanza <········@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.
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,
·····@telus.net The Rhythm has my soul.
Ray Blaak wrote:
> Pascal Costanza <········@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
--
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 <········@web.de> writes:
| 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
--
http://www.dfan.org
Dan Schmidt <····@dfan.org> writes:
> Pascal Costanza <········@web.de> writes:
>
> | 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.
Then you could have 'units' and unit-checking.
> 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
>
> --
> http://www.dfan.org
--
__Pascal_Bourguignon__ http://www.informatimago.com/
----------------------------------------------------------------------
There is a fault in reality. do not adjust your minds. -- Salman Rushdie
Pascal Costanza wrote:
> Ray Blaak wrote:
>
>> Pascal Costanza <········@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
Kenny Tilton wrote:
> 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
···············@web.de Institute of Computer Science III
http://www.pascalcostanza.de R�merstr. 164, D-53117 Bonn (Germany)
Pascal Costanza wrote:
> Kenny Tilton wrote:
>
>> 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...
Maybe wait for Cello so you can goof around with a GUI and even 3D
stuff? And I promised Jans at ILC 2002 I would write some kinder,
gentler doc than the first stuff I tossed together.
> P.S.: Do you pay for surreptitious adertising? ;)
Actually, just getting a reaction at all is a thrill! Only heard back
from a couple of folks, perhaps because of the doc. i also think not
having a GUI with which to actually use Cells was an interest-stopper.
Or maybe they just hated it. We'll see.
I just stumbled onto OpenRM which is the 3GL to OpenGLs 2GL (speaking
loosely), and it has a little RMaux side library which offers basic
Window management. Works for Win32 and X11. I'll be looking at that as
an alternative to GLUT. One of the project bigs said some false starts
had been made on a Mac OS X version, and also made it sound like not too
fierce an effort. And of course there is an X11 for OS X, so a pure
X11-based port would be possible.
--
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
Pascal Costanza <········@web.de> writes:
> 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 :-).
--
Cheers, The Rhythm is around me,
The Rhythm has control.
Ray Blaak The Rhythm is inside me,
·····@telus.net The Rhythm has my soul.
Ray Blaak wrote:
> Pascal Costanza <········@web.de> writes:
>
>>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/
Thanks a lot!
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
In article <·············@telus.net>, Ray Blaak <·····@telus.net>
wrote:
> Pascal Costanza <········@web.de> writes:
> > 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.
And slots in objects.
> When known, the compiler will check statically. If not
> known at compile time, the check is deferred till runtime.
And if not known, the compiler can often figure out the type by itself,
though current ones (http://www.functional-objects-com,
http://www.gwydiondylan.org) don't go to the same lengths at finding the
least fixed point type as ML-family compilers.
> So, if you wish to be anal you can. If you wish maximum flexibility, say
> during prototyping, you can do that too.
Right. That's the thing I like best about Dylan. You can write things
in about as much code as a scripting language such as Perl or Python and
get much the same peformance, and then tweak just the critical parts to
get close to C speeds.
I've just finished writing a program at work. It needs to take a 300+
MB comma-separated text file containing mappings from all the phone
numbers in Australia to post codes and munge it and sort it and compress
it and turn it into a binary format suitable for fast lookups that can
be loaded wholesale into another program. As an experiement I tried
parallel versions in Dylan and Perl. Perl was a couple of times faster
at just reading the file by lines (Gwydion Dylan's stream I/O frankly
sucks and is far too generalized for speed :-( ), but as soon as I added
the code to parse the lines into four CSV fields (using "split" in Perl,
an explicit loop in Dylan) the Dylan version leap ahead. In fact all
the rest of the processing I'm doing (including a sort of 7m phone
number ranges) in Dylan takes less time than just 'while(<>){chomp; my
($a, $b, $c, $d) = split ","}' in Perl.
I expect C would be faster than the Dylan (especially if I didn't heap
allocate each phone number object), but it would be far more lines of
code, and would have taken far longer to hack around with the data and
discover the best encoding method.
C++ with the STL would be fewer (but more grotty) lines of code than
Dylan, but I suspect it would be only on a par with it, or worse.
perhaps I'll try it as an exercise...
> ObLisp: The main thing that makes Dylan shitty is the syntax :-).
I like it myself. I came to Dylan because its position on the dynamism
scale and execution/delivery model fits better into the world I'm
working in (traditional C/C++/Java development, delivering binaries to
customers) than do CL and Smalltalk. I stayed for the cleaned up
built-in functions and collection classes (relative to CL) and for the
syntax. I can write a program in Dylan and then ask a C/C++/Java
programmer to modify it and they don't have a heart attack.
-- Bruce
* 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.
| 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.
--
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.
Erik Naggum wrote:
> * 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.
(············@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"?
Pascal
--
Pascal Costanza University of Bonn
···············@web.de Institute of Computer Science III
http://www.pascalcostanza.de R�merstr. 164, D-53117 Bonn (Germany)
* Pascal Costanza
| 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, 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.
Erik Naggum wrote:
> * 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.
Pascal
--
Pascal Costanza University of Bonn
···············@web.de Institute of Computer Science III
http://www.pascalcostanza.de R�merstr. 164, D-53117 Bonn (Germany)
* 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.
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!
--
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.
Erik Naggum wrote:
> * 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
--
Pascal Costanza University of Bonn
···············@web.de Institute of Computer Science III
http://www.pascalcostanza.de R�merstr. 164, D-53117 Bonn (Germany)
* Pascal Costanza
| 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.
--
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.
Erik Naggum wrote:
> 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.
--
Pascal Costanza University of Bonn
···············@web.de Institute of Computer Science III
http://www.pascalcostanza.de R�merstr. 164, D-53117 Bonn (Germany)
* Pascal Costanza
| 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.
--
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 <········@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. 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:
···················································@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
·····················································@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
Nils Goesche wrote:
> Pascal Costanza <········@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.
Pascal
--
Pascal Costanza University of Bonn
···············@web.de Institute of Computer Science III
http://www.pascalcostanza.de R�merstr. 164, D-53117 Bonn (Germany)
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) 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
Frank A. Adrian wrote:
> 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.
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
| 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!
--
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.
Erik Naggum wrote:
> * Pascal Costanza
> | 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:
[...]
> It is /indecent/ to make the kind of demands that Pascal Costanza
> keeps making when people reject his ideas or opinions.
Interesting elaboration - except that these are not my ideas...
> 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.
The "accepted" bit was exaggerated - I am sorry for that, and I don't
have a real excuse. However, I stand by my assessment that this is the
best terminology I have seen so far with regard to the topic at hand,
because of its consistency and well-definedness. I also stand by my
assessment that your wording was incosistent _according to the
terminology I propose_ - and I don't see how your wording could be made
more consistent (according to which (?) other terminology - you still
haven't made any suggestion). Your statement that your wording was
context-dependent is irrelevant here. You have made it very clear that
you wanted to restrict the term "statically typed language" to languages
like C# because of the context that you were referring to - in other
words: You deliberately used an inconsistent terminology for a ceratain
purpose (and again, it was inconsistent with regard to the terminology I
propose - what other alternatives are there to understand the term
"statically typed" than for languages that are statically checked? Heck,
how often shall I repeat the question: _Is there a useful alternative
terminology that makes your wording consistent?_)
However, you really seem to have a hard time understanding what was
going on here. You have started to nitpick about whether my example was
a counter-example or not. Because of some constructive feedback by other
people outside of our current "conversation", I have learned that I
shouldn't have used the term "counter-example", but for totally
different reasons than you seem to think. So what was your point again?
What actual content did our "conversation" have? It was zero, wasn't it?
For a long time in this thread, it has already been clear that we have
based our wording on different terminology, and that this was
essentially a misunderstanding. Why did you waste your time on an
essentially content-free topic while you could have contributed to the
discussion in far more productive ways? Instead you continually decide
to give your standard highly abusive rants. What's the matter with you?
What conclusions should one draw from your behavior?
You're one of the most ridiculous people I have met in my entire life.
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
| Interesting elaboration - except that these are not my ideas...
Amazing. Accepting responsibility for anything is so foreign to
you that you even have to make such pathetic evasive actions.
| What conclusions should one draw from your behavior?
You /could/ conclude that you have done something wrong and that
someone cares enough about you to try to communicate to you not
only what you have done wrong, but some of the underlying reasons
/why/ it is wrong. I am beginning to arrive at the conclusion that
you are unable to accept input from the external world, however.
| You're one of the most ridiculous people I have met in my entire
| life.
What we know for certain about you is that you construct your own
little world in which you are the omnipotent, omniscient ruler who
never makes mistakes and can never learn anything from anyone.
What consequence could a statement from a deranged lunatic like you
possibly have /outside/ that little world of yours? Of /course/
you have to make that kind of statement in pure self-preservation.
I have never had the opportunity to watch a human being who has not
grasped the concept of context /at all/ before. It has been quite
fascinating to try to make you realize that just because you think
something is true does not make it The Truth and that just because
you think something is important does not mean that /everybody/
else must agree with you. Even seriously mentally sick people have
/some/ notion of their own contribution to their grasp of the world
around them, Most people, regardless of intelligence, are able to
understand that they can look at the same things from a different
point of view and see something new and different. Even people who
experience ravaging psychotic episodes are aware at /some/ level
that what they see is not the /same as/ the external world; they do
not live entirely in a world of their own construction. You do.
I must admit that I have for too long refused to believe that it is
possible to maintain such a state of mind for an extended period of
time. I have therefore tried to reach you in many different ways,
but you are actually impervious to any signal that tells you that
/perhaps/ Pascal Costanza is not God, after all. Of /course/ you
must find me ridiculous. What else could you do? If you had but a
glimpse of your own mental state, you would need therapy for years.
If, by a miracle you should wake up one morning and think "Mein
Gott, I can /think/ about something unpleasant without my entire
central nervous system shutting down in self-defense", what would
we see here in comp.lang.lisp? I would like to believe that the
first thing you would do would be to accept responsibility for your
own emotional well-being (and therefore stop demanding that others
take care of it) and for the things you want others to believe to
be true (so that you could learn something from discussing them).
But I fear that it /will/ take a miracle for any of this to happen.
--
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.
Summary: By any means, you're trying to avoid to state wether you
believe that you have used a consistent wording in your original post or
not.
I will not continue this discussion unless you get on-topic again.
Pascal
--
Pascal Costanza University of Bonn
···············@web.de Institute of Computer Science III
http://www.pascalcostanza.de R�merstr. 164, D-53117 Bonn (Germany)
Pascal Costanza wrote:
>
> Do you mean the Cardelli paper? If you think its contents are crappy,
> then just come up with a better alternative.
No, I've read Cardelli's paper in the past and it's quite fine. I was
referring to the one that was delivered at the Perl conference that you
touted as an "unbiased view" of your precious typing systems.
And you're still rude.
faa
Frank A. Adrian wrote:
> Pascal Costanza wrote:
>
>
>>Do you mean the Cardelli paper? If you think its contents are crappy,
>>then just come up with a better alternative.
>
>
> No, I've read Cardelli's paper in the past and it's quite fine. I was
> referring to the one that was delivered at the Perl conference that you
> touted as an "unbiased view" of your precious typing systems.
Neither did I say anything about the latter paper, nor did I mention it
at all. I was always referring to the Cardelli paper.
Pascal
--
Pascal Costanza University of Bonn
···············@web.de Institute of Computer Science III
http://www.pascalcostanza.de R�merstr. 164, D-53117 Bonn (Germany)
> 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
I thought all the links that's provided here by many experts here are very
valuable
to people who are less informed. Surely, providing reference links is not a
sin......?
marcel haesok wrote:
> I thought all the links that's provided here by many experts here are very
> valuable
> to people who are less informed. Surely, providing reference links is not
> a sin......?
No. But not doing your best to communicate and forcing others to parse
extraneous material is rude at best and probably on the border of sinning
:-).
faa
"marcel haesok" <·········@attbi.com> writes:
> > 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
>
> I thought all the links that's provided here by many experts here are very
> valuable
> to people who are less informed. Surely, providing reference links is not a
> sin......?
That is not a problem. The problem is:
Here is my point, you go make it for me.
That went allong with the links.
marc.
* Pascal Costanza
| 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.
--
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.
Nils Goesche <······@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? 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.
--
Cheers, The Rhythm is around me,
The Rhythm has control.
Ray Blaak The Rhythm is inside me,
·····@telus.net The Rhythm has my soul.
On 12/10/02 12:48 AM, in article ·············@telus.net, "Ray Blaak"
<·····@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>
-----= 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! =-----
Ray Blaak <·····@telus.net> writes:
> 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.
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?
Pascal
--
Pascal Costanza University of Bonn
···············@web.de Institute of Computer Science III
http://www.pascalcostanza.de R�merstr. 164, D-53117 Bonn (Germany)
Pascal Costanza <········@web.de> writes:
> 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.
In article <················@web.de>, Pascal Costanza <········@web.de>
wrote:
> 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?
That's the idea with Dylan. How close a given implementation (e.g.
Gwydion) comes to "doing as much as it possibly can" is debatable :-)
One point about "I'm not at all willing to decorate my program with
hints for the type checking" is that when you're using the OO features
(which are similar to CLOS), you simply *have* to declare the types of
method arguments in order for generic function method selection to work.
Once you do that, the compiler can usually get a lot of mileage out of
using type inferencing to figure out what is going on in the rest of the
function.
-- Bruce
Ray Blaak <·····@telus.net> writes:
> Nils Goesche <······@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
Nils Goesche <······@cartan.de> writes:
> 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.
--
Cheers, The Rhythm is around me,
The Rhythm has control.
Ray Blaak The Rhythm is inside me,
·····@telus.net The Rhythm has my soul.
From: ·············@cetp.ipsl.fr
Subject: Re: type safety in LISP
Date:
Message-ID: <u8yyxpyt6.fsf@cetp.ipsl.fr>
Nils Goesche <······@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 ?
> 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_
·············@cetp.ipsl.fr writes:
> 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')
·············@cetp.ipsl.fr writes:
> Nils Goesche <······@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 ;-|
Regards,
--
Nils G�sche
"Don't ask for whom the <CTRL-G> tolls."
PGP key ID 0x0655CFA0
In article <··············@cartan.de>, Nils Goesche <······@cartan.de> wrote:
> This is just something that doesn't happen in practice.
> Bugs like this just don't happen.
I'd love to live in your world. Maybe having a string in a list of
numbers doesn't happen often, but I can't count the number of times I've
seen "ERROR: NIL is not of the expected type ...".
> If I call
> REDUCE with #'+ on it, I am successively invoking methods on objects.
That would be true if + were a generic function, but it's not.
E.
···@jpl.nasa.gov (Erann Gat) writes:
> In article <··············@cartan.de>, Nils Goesche <······@cartan.de> wrote:
>
> > This is just something that doesn't happen in practice.
>
> > Bugs like this just don't happen.
>
> I'd love to live in your world.
Oh, you do, I think.
> Maybe having a string in a list of numbers doesn't happen often, but
> I can't count the number of times I've seen "ERROR: NIL is not of
> the expected type ...".
Heh, maybe so. I don't know about you, but my typical experience with
other people's Java programs is: First, you have to install a
different version of the JRE. Then you have to wait for about 40
seconds of heavy disc activity until the first window pops up. After
a few mouse clicks the program type safely crashes with an uncaught
null pointer exception.
But where, OTOH, do you typically see your "ERROR: NIL is not of
type..." message? Are you telling me that your deployed Lisp programs
regularly crash with this message? I don't believe you :-) I rather
suspect that you see this message when you quickly and carelessly
invoke a function you've just written a few seconds before with some
test input directly in a Lisp listener. This is not the same.
If static typing prevents such bugs, or only helps to prevent them, as
I admit it certainly seems at first glance as you can't put, say, Nil
into an int list, why is it that most the software written in
static(ally typed) languages like C, C++, Java, SML, OCaml and Haskell
is just as rotten, crashing and burning as we see it everywhere?
Sure, at least ML and Haskell software is perceived to be better, but
remember who uses these languages. And did you ever really try to use
a program written in them by somebody else? Apart from some diamonds
everybody knows are good programs, what makes you think the great
majority of software written in them is so great? Next time you look
at the ICFP contest entries, have a closer look at the entries at the
/last/ third of entries. You'll see that they are /also/ written by
bright people in supposedly oh so safe languages like Haskell and ML,
but they somehow crash and burn with uncaught exceptions or simply
barf out with incorrect output.
The general believe that static typing makes those errors somehow go
away is mistaken. Sure, the type checker finds a lot of ``errors�� at
compile time, but somehow this doesn't help make the software better.
And, OTOH, my experience with Lisp software (and even with Perl
or Tcl software!) is not worse, rather better, in fact. How can that
be if static typing didn't ``help�� its programmers?
I am trying at the moment to look at the problem in a different way to
find an answer to this question.
Of course I am /not/ arguing against the type inference algorithm.
That would obviously be a rather stupid thing to do, and I am rather
annoyed that some people seem to think I was trying doing that.
The question is whether it helps to force the programmer to narrow his
types, which is precisely what statically typed languages do, in order
to have the type inference algorithm to terminate with a definite
answer: They do /not/ want to accept programs when they can't prove
there will be no runtime type errors. They rather reject a valid
program than answer ``I don't know��. To make working with such a
language possible at all, the programmer must be forced to narrow his
types even before the program is run for the first time. I think that
/this/ is the source of problems, /this/ is the time where what would
be runtime type errors in a Lisp program are merely /shifted/ to a
more abstract level and continue to be runtime errors, although not
runtime type errors anymore, under some meaning of the word.
> > If I call REDUCE with #'+ on it, I am successively invoking
> > methods on objects.
>
> That would be true if + were a generic function, but it's not.
Come on! Earlier you were ridiculing people wanting to discuss
irrelevant things like the meaning of ``is�� and now you do the same?
+ is generic in the sense that it takes objects of any type as
arguments, does the right thing according to their types, and signals
a TYPE-ERROR if it doesn't like any of its arguments. That's all that
counts here. That it isn't a ``generic function�� in the Common Lisp
sense is totally irrelevant for the argument.
Regards,
--
Nils G�sche
"Don't ask for whom the <CTRL-G> tolls."
PGP key ID 0x0655CFA0
···@jpl.nasa.gov (Erann Gat) writes:
> In article <··············@cartan.de>, Nils Goesche <······@cartan.de> wrote:
>
> > But for some reason, you and me hang out here and not in
> > comp.lang.java. I am trying to find out why.
>
> I can't speak for you, but I hang out here because I hate Java and I
> love Lisp. (Duh!) I think Java sucks, but the reason I think Java
> sucks is not that it doesn't work. It does. It didn't used to, but
> it mostly does now.
Sure, YMMV. But if you /hate/ Java and /love/ Lisp I would be
surprised it you thought that Java works ``better�� than Lisp. Well,
at least I don't. I think Lisp works better than all of the
statically typed languages; nobody here is interested in opinions of
people who think otherwise because we meet people who think that Lisp
/doesn't/ work everywhere: In academia, in other newsgroups, in
magazines, in bars where programmers hang out, in our workplaces,
everywhere. All of their arguments are ubiquitous and well known.
Repeating the usual ``ML and Java are oh so safe because they are
statically typed�� sermon is not interesting at all because it is very
unlikely that anybody reading comp.lang.lisp hasn't already heard
every single argument from that side. Heck, back when I was an ML fan
myself, /I/ used to go on everybody's nerves by telling them how great
type inference in connection with static typing is (just as I drive
them mad by telling them that Lisp is even better now ;-).
What would be /interesting/ and /new/ is collecting arguments
explaining why we like Lisp /despite/ the fact that it is dynamically
typed (or rather: /because/!).
> > Ok, look at this:
> >
> > Objective Caml version 3.01
> >
> > # let f x = x + 42;;
> > val f : int -> int = <fun>
> > # f "2";;
> > Characters 2-5:
> > This expression has type string but is here used with type int
> > #
> >
> > Hmmmmmmm.
>
> And your point is...?
You said you saw the ``NIL is not of type...�� message very often. I
said you see it most often not in your running, deployed programs but
mainly at a listener right after you've written a function a few
seconds ago, when you test it by randomly and carelessly providing it
with some test input. You said that testing doesn't count and in ML
that wouldn't happen. The above interaction at an ML prompt shows how
exactly the same thing happens when I test my ML code.
> > I am claiming that the /real/ bugs, the one we worry about and we
> > need the testing for, will not be found by something like ML's
> > type checker.
>
> Yes, I know. I'm saying you're wrong. I think something like ML's
> type checker and related static analysis technologies can find
> (some, not all) real bugs that we really worry about.
Somehow I doubt that we really disagree here. You still seem to
believe that I am a kind of moron who thinks that + is a CLOS generic
function and we shouldn't make use of ``static analysis�� and ``type
inference�� because he somehow doesn't like it when his compiler finds
bugs for him.
I /do/ hope that our compiler vendors read every paper on type
inference and static analysis they can get! Whenever there is
something they can make use of to make our Lisps better, sure: Go
ahead and take it! Put it in! Make extensions, if necessary!
I am not arguing ``against�� research on type theory or some such.
In fact I am a big fan of denotational semantics and type theory. I
come from mathematics. I like such things. They are beautiful and
adding to mankinds knowledge is always a great thing. That goes
without saying!
There is one danger, though, one must always be aware of when reading
beautiful mathematical theories: Very often, it is not the most
beautiful, but the most *disgusting* theory that best models the real
world, as everybody who ever tried to properly describe quantum
mechanics rigorously in terms of functional analysis will tell you.
Physicists know that they can't simply adopt the real world to the
most beautiful mathematical model.
Some theoretical computer scientists, however, apparently have not
grasped this fact fully yet and think they can improve the real world
by changing our programming languages in a way that they most easily
fit to some mathematical models of type theory. The result of which
is languages like Haskell and ML. This is where I believe they are
wrong. While static typing certainly looks good on paper, I believe
that it doesn't really work in practice as good as it should if the
real world behaved like they seem to believe.
> > Then add all the Perl and Tcl code running in production if you
> > want. I know people selling a giant Tcl application used by
> > brokers where /every bug/ costs millions of dollars when it stops
> > the system from functioning just for a few minutes.
>
> I don't understand. Are you saying that there is a higher
> proportion of good Perl and TCL code in production than good C++ or
> Java code? Do you have any non-anecdotal data to support this
> claim?
I don't have to :-) I am /not/ trying to prove to anybody who doesn't
already believe it that dynamic typing works in practice. I shouldn't
have to do that in comp.lang.lisp. I am encouraging people to think
about /why/ this can be despite the claims of the static typing camp.
Where do they go wrong? What is their main mistake? There /is/ some
mistake they are making; if I didn't believe that I wouldn't waste any
more time here and go away and use SML again. This is simply an
axiom, an assumption. Let's see where we can get from there. Let's
think /differently/ about the whole thing for a while. Maybe there
will be some insight in the end. That's also why I said that the
/real/ goal of static typing wasn't security but speed. Sure, they
talk about security a lot, but let's simply look, for a moment, at
their activity in some different light. In a different light, their
very same activities look entirely different: They are posing all
kinds of restrictions unto their users only so they can eliminate as
much runtime checks and type information as possible. You can look at
it that way, that's all. Maybe it helps finding out where they go
wrong (which, again, I take for granted at the moment. If somebody
thinks otherwise, his opinion is uninteresting for this argument).
And maybe not. Let's look for something else, then. We'll see.
> > The general problem is this:
> >
> > FACT -- We can write good software (and ``good�� implies ``safe��, at
> > least in my eyes, contrary what some somebody else in this thread was
> > trying to imply) in Lisp. In fact, we can write /better/ software in
> > Lisp than in whatever fashionable static language there is out there.
> >
> > If anybody does not take this FACT for granted, there is no point in
> > participating in this discussion for him /at all/. In fact, I
> > wouldn't know what the f*ck he is /doing/ in comp.lang.lisp, anyway!
>
> Goodness, what a narrow view of the world! I do happen to believe
> that "we can write better software in Lisp than in whatever
> fashionable static language there is out there" so I guess I'm still
> welcome here. But I do not take this as an article of faith, and as
> the repertoire of currently fashionable languages isn't static I do
> not believe it's necessarily an eternal truth either. (Bt then
> again, it's already well known that I'm a Lisp apostate.)
Look at it this way: I am trying to find arguments that might, far in
the future, be a proof for a statement of the kind IF A THEN B. Any
such proof always starts with collecting ideas and vague feelings
about what might be relevant. If somebody doesn't believe A anyway,
fine, but then he has no reason to participate in this business.
> > If somebody believes he can write better software in OCaml or
> > Dylan, he should shut the f*ck up and go to comp.lang.ml or
> > comp.lang.dylan and *use* those languages rather than complaining
> > and whining all the time how Lisp isn't ``type-safe�� or whatever
> > else it is he is here for.
>
> When have you ever heard me "whine" that Lisp isn't type safe?
I didn't mean you. Be assured that if I want to insult you, I'll do
it in the second person :-)
> [Much vitriol elided]
Be fair: You /quoted/ all the vitriol and snipped everything else :-)
> This love-it-or-leave-it attitude seems to be very common in the
> Lisp community, and I find it very troublesome. One can love Lisp,
> indeed think Lisp is the best programming language in existence,
> while at the same time believing that it isn't perfect and could be
> improved, and that some ideas for improvement might even come from
> other programming languages. This attitude often meets tremendous
> hostility here, and I can't help but wonder what the people who
> generate this hostility are hoping to accomplish with it.
I think this is a misunderstanding on your side. The only thing that
is /not/ welcome is totally destructive criticism along the lines of
``Lisp sucks because it is not statically typed, or because it is not
like Smalltalk, or because it has lots of parentheses.�� If somebody
does not have at least /some/ faith that Lisp is on the right track,
it is really not clear why he would waste his time here only to
contribute to all the Lisp hatred we are used to hear everywhere else,
anyway. There are enough places in the world where people are free to
do as much Lisp bashing as they want. People will even cheer them.
Regards,
--
Nils G�sche
"Don't ask for whom the <CTRL-G> tolls."
PGP key ID 0x0655CFA0
In article <··············@cartan.de>, Nils Goesche <······@cartan.de> wrote:
> ···@jpl.nasa.gov (Erann Gat) writes:
>
> > In article <··············@cartan.de>, Nils Goesche <······@cartan.de>
wrote:
> >
> > > But for some reason, you and me hang out here and not in
> > > comp.lang.java. I am trying to find out why.
> >
> > I can't speak for you, but I hang out here because I hate Java and I
> > love Lisp. (Duh!) I think Java sucks, but the reason I think Java
> > sucks is not that it doesn't work. It does. It didn't used to, but
> > it mostly does now.
>
> Sure, YMMV. But if you /hate/ Java and /love/ Lisp I would be
> surprised it you thought that Java works ``better�� than Lisp.
Java does work better than Lisp for some things, like Web browser plug-ins.
> What would be /interesting/ and /new/ is collecting arguments
> explaining why we like Lisp /despite/ the fact that it is dynamically
> typed (or rather: /because/!).
What would be even more interesting and more new is figuring out a way to
get Dylan-style type inference into Common Lisp so that this whole
argument would be rendered moot.
> You said you saw the ``NIL is not of type...�� message very often. I
> said you see it most often not in your running, deployed programs but
> mainly at a listener right after you've written a function a few
> seconds ago, when you test it by randomly and carelessly providing it
> with some test input.
That is true, but irrelevant. That more errors occur during development
than after deployment is hardly controversial. What matters is whether
the number of errors that happen after deployment is >0. In my line of
work, a single error in deployment can cost many hundreds of millions of
dollars, if not billions, if not human lives. When the stakes are that
high, an error in deployment that could have been caught during
development but wasn't because of someone's ideology is unforgivable.
(NB: this actually happens all the time, but usually it's half-assed
static-typing ideology (a.k.a. C/C++) that is at fault.)
> You said that testing doesn't count and in ML that wouldn't happen.
No, that's not what I said (or if it is it's not what I meant). My
position is that type analysis can catch some (not all) errors. Some of
the errors it can catch are both 1) difficult or expensive to find by
testing, and 2) important. Therefore, type analysis should be used.
> > > I am claiming that the /real/ bugs, the one we worry about and we
> > > need the testing for, will not be found by something like ML's
> > > type checker.
> >
> > Yes, I know. I'm saying you're wrong. I think something like ML's
> > type checker and related static analysis technologies can find
> > (some, not all) real bugs that we really worry about.
>
> Somehow I doubt that we really disagree here.
If you say so. I just said "you're wrong". That sounds like a
disagreement to me.
> You still seem to
> believe that I am a kind of moron who thinks that + is a CLOS generic
> function and we shouldn't make use of ``static analysis�� and ``type
> inference�� because he somehow doesn't like it when his compiler finds
> bugs for him.
No, that's not at all what I believe. (Where did you get the idea that I
think you're a moron?) I think you believe that "the /real/ bugs, the one
we worry about and we need the testing for, will not be found by something
like ML's type checker." Those are your exact words, and I say again: I
think you are wrong. I think you are wrong because my first-hand
experience shows that static analysis can find "real bugs, the ones we
worry about."
> I /do/ hope that our compiler vendors read every paper on type
> inference and static analysis they can get! Whenever there is
> something they can make use of to make our Lisps better, sure: Go
> ahead and take it! Put it in! Make extensions, if necessary!
I certainly agree with that, but it seems to contradict your earlier
statement. Why bother with type inferencing at all if, as you say, it
will not find "real bugs, the kind we worry about"? If it doesn't do
that, what is it good for?
> > > Then add all the Perl and Tcl code running in production if you
> > > want. I know people selling a giant Tcl application used by
> > > brokers where /every bug/ costs millions of dollars when it stops
> > > the system from functioning just for a few minutes.
> >
> > I don't understand. Are you saying that there is a higher
> > proportion of good Perl and TCL code in production than good C++ or
> > Java code? Do you have any non-anecdotal data to support this
> > claim?
>
> I don't have to :-) I am /not/ trying to prove to anybody who doesn't
> already believe it that dynamic typing works in practice.
The problem is that "practice" has an enormous range of meanings. The
level of quality you need to achieve is different for a video game than
for a spacecraft or a controller for a nuclear reactor. (Unfortunately,
the current state of the practice seems to me just barely adequate even
for video games.)
> What is their main mistake?
I'll tell you what I think their main mistake is. It's the same as the
mistake that you seem to be making in some (not all) of your arguments.
You are failing to consider the universal validity of Gat's First Law: all
extreme positions are wrong. ;-) Static typing when taken to an extreme
(a la ML or Haskell) has problems. It does not follow that the opposite
extreme - ubiquitous dynamism - is the right answer. In fact, ubiquitous
dynamism (Python is actually a much better example of this extreme than
Common Lisp) has just as many problems as fascist type checking. They're
just different problems.
The Right Answer IMO is to be somewhere in the middle. Use static type
checking where it's appropriate, and fall back on dynamism when it's not.
Unfortunately, the only language that really supports this at the moment
is Dylan, and it has its own set of problems.
> > > The general problem is this:
> > >
> > > FACT -- We can write good software (and ``good�� implies ``safe��, at
> > > least in my eyes, contrary what some somebody else in this thread was
> > > trying to imply) in Lisp. In fact, we can write /better/ software in
> > > Lisp than in whatever fashionable static language there is out there.
> > >
> > > If anybody does not take this FACT for granted, there is no point in
> > > participating in this discussion for him /at all/. In fact, I
> > > wouldn't know what the f*ck he is /doing/ in comp.lang.lisp, anyway!
> >
> > Goodness, what a narrow view of the world! I do happen to believe
> > that "we can write better software in Lisp than in whatever
> > fashionable static language there is out there" so I guess I'm still
> > welcome here. But I do not take this as an article of faith, and as
> > the repertoire of currently fashionable languages isn't static I do
> > not believe it's necessarily an eternal truth either. (Bt then
> > again, it's already well known that I'm a Lisp apostate.)
>
> Look at it this way: I am trying to find arguments that might, far in
> the future, be a proof for a statement of the kind IF A THEN B. Any
> such proof always starts with collecting ideas and vague feelings
> about what might be relevant. If somebody doesn't believe A anyway,
> fine, but then he has no reason to participate in this business.
What are "A" and "B"? If you start with the premise that "we can write
better software in Lisp than in [any other language]" what is there left
to prove? You're done. I don't see how this is going to help convince
anyone of anything who doesn't already believe.
> > > If somebody believes he can write better software in OCaml or
> > > Dylan, he should shut the f*ck up and go to comp.lang.ml or
> > > comp.lang.dylan and *use* those languages rather than complaining
> > > and whining all the time how Lisp isn't ``type-safe�� or whatever
> > > else it is he is here for.
> >
> > When have you ever heard me "whine" that Lisp isn't type safe?
>
> I didn't mean you. Be assured that if I want to insult you, I'll do
> it in the second person :-)
>
> > [Much vitriol elided]
>
> Be fair: You /quoted/ all the vitriol and snipped everything else :-)
I was referring to this:
> So guess I can again expect a bunch of answers now
> along the lines of ``You just don't know any languages besides C, if
> you only would have a look at ML or Haskell! You don't care about
> runtime errors, that's fine for you, but I do! You are just too
> stupid to understand sophisticated stuff like type theories! You are
> just too stupid to think in types! You are just too stupid to choose
> types that suit your needs! etcetcetc��
Perhaps I should have used the word "frustration" instead of "vitriol"
(but I was starting to get a little frustrated myself at that point).
> I think this is a misunderstanding on your side. The only thing that
> is /not/ welcome is totally destructive criticism along the lines of
> ``Lisp sucks because it is not statically typed, or because it is not
> like Smalltalk, or because it has lots of parentheses.��
That has not been my experience. I have in the past made comments of the
form, "Lisp is great, but I think it would be improved if we changed X"
and gotten some pretty hostile responses.
> If somebody
> does not have at least /some/ faith that Lisp is on the right track,
> it is really not clear why he would waste his time here only to
> contribute to all the Lisp hatred we are used to hear everywhere else,
> anyway. There are enough places in the world where people are free to
> do as much Lisp bashing as they want. People will even cheer them.
Lisp is my favorite programming language. Ten years ago it was so far
ahead of everything else that using Lisp was a complete no-brainer. Ten
years ago there was C, Fortran, Ada, Cobol, PL/I. Lisp was unique in
offering dynamism, automatic memory management, an object system, and
about a dozen other features.
In the past ten years Lisp has become moribund. It has changed not at
all, while other languages have made great advances. Lisp is still the
best of the lot, but the situation is no longer anywhere near as clear as
it was ten years ago. It's not a no-brainer any more. Lisp is no longer
unique in offering dynamism (Python and Perl have it), automatic memory
management (just about everything has it nowadays, including C++), an
object system. In fact, about the only feature that Lisp offers uniquely
nowadays is macros.
It's like the tortoise and the hare. Lisp is the hare, and it's been
snoozing for the past ten years. I keep hearing that Lisp is on the rise,
and that would be great, but I don't see any evidence of it from where I
sit. And I find it hard to imagine how Lisp will rise now that its
advantages over the competition are so much smaller than they were ten
years ago.
Lisp isn't going to die. It has a niche market that isn't going to go
away, kind of like COBOL. But that doesn't do *me* any good because niche
products are a really hard sell in the space business. (Lisp and COBOL
are pretty much in an equivalence class as far as most people around here
are concerned, along with PL/I, SNOBOL, Simula, and a host of other
languages that are not quite dead either. In fact, there is more Simula
work going on at JPL than Lisp work at the moment.)
So, do I have some faith that Lisp is on the right track? I don't know.
It certainly *was* on the right track, but now it seems to me to be
sitting on a siding. To me, being on the right track is less important
than simply getting the Lisp train rolling again.
If you think the Lisp train is rolling, then help me answer this question
that my managers ask me whenever I bring the subject up: who uses it?
E.
On 12/12/02 12:54 PM, in article
····················@k-137-79-50-101.jpl.nasa.gov, "Erann Gat"
<···@jpl.nasa.gov> wrote:
> My
> position is that type analysis can catch some (not all) errors. Some of
> the errors it can catch are both 1) difficult or expensive to find by
> testing, and 2) important. Therefore, type analysis should be used.
But the conclusion doesn't follow from the premise. If initial development
is harder in the language with static typing and/or unit testing for the
errors that static typing won't find is more difficult, the difficulty and
expense of the increased testing in a dynamically typed language may be well
justified.
To me this isn't just theoretical because some programmers that I respect
are abandoning Haskell for this very reason. They don't say that Haskell
gained them nothing. They simply say that on balance the increased code
size, and decreased expressiveness of Haskell cost more than they gained in
terms of easier testing.
-----= 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! =-----
In article <······················@fastq.com>, Chris Gehlker
<·······@fastq.com> wrote:
> On 12/12/02 12:54 PM, in article
> ····················@k-137-79-50-101.jpl.nasa.gov, "Erann Gat"
> <···@jpl.nasa.gov> wrote:
>
> > My
> > position is that type analysis can catch some (not all) errors. Some of
> > the errors it can catch are both 1) difficult or expensive to find by
> > testing, and 2) important. Therefore, type analysis should be used.
>
> But the conclusion doesn't follow from the premise. If initial development
> is harder in the language with static typing and/or unit testing for the
> errors that static typing won't find is more difficult, the difficulty and
> expense of the increased testing in a dynamically typed language may be well
> justified.
I think you may be misinterpreting what I mean by "type analysis should be
used." By this I do not mean that we should write code in Haskell and
ML. What I do mean is that we should do what Dylan does, and integrate a
type analysis system into a dynamic language.
But, of course, this all depends on the cost of production errors in your
particular application. As I have noted previously, the costs of such
errors in my line of work is extraordinarily high. If you're writing
video games it may not matter so much.
E.
On 12/12/02 6:29 PM, in article
····················@k-137-79-50-101.jpl.nasa.gov, "Erann Gat"
<···@jpl.nasa.gov> wrote:
> In article <······················@fastq.com>, Chris Gehlker
> <·······@fastq.com> wrote:
>
>> On 12/12/02 12:54 PM, in article
>> ····················@k-137-79-50-101.jpl.nasa.gov, "Erann Gat"
>> <···@jpl.nasa.gov> wrote:
>>
>>> My
>>> position is that type analysis can catch some (not all) errors. Some of
>>> the errors it can catch are both 1) difficult or expensive to find by
>>> testing, and 2) important. Therefore, type analysis should be used.
>>
>> But the conclusion doesn't follow from the premise. If initial development
>> is harder in the language with static typing and/or unit testing for the
>> errors that static typing won't find is more difficult, the difficulty and
>> expense of the increased testing in a dynamically typed language may be well
>> justified.
>
> I think you may be misinterpreting what I mean by "type analysis should be
> used." By this I do not mean that we should write code in Haskell and
> ML. What I do mean is that we should do what Dylan does, and integrate a
> type analysis system into a dynamic language.
Yes, I did misunderstand.
> But, of course, this all depends on the cost of production errors in your
> particular application. As I have noted previously, the costs of such
> errors in my line of work is extraordinarily high. If you're writing
> video games it may not matter so much.
I suppose at some point, the cost of a single error becomes so high as to
justify parallel development efforts.
-----= 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! =-----
Chris Gehlker <·······@fastq.com> writes:
> To me this isn't just theoretical because some programmers that I respect
> are abandoning Haskell for this very reason. They don't say that Haskell
> gained them nothing. They simply say that on balance the increased code
> size, and decreased expressiveness of Haskell cost more than they gained in
> terms of easier testing.
I'm curious about this, because in my experience the difference in
expressiveness between Lisp and Haskell is mainly due to Haskell being
a lazy functional language and has nothing really to do with static
typing.
--
Pertti Kellom\"aki, Tampere Univ. of Technology, Software Systems Lab
On 12/13/02 1:03 AM, in article ···············@kuovi.cs.tut.fi, "Kellom{ki
Pertti" <··@kuovi.cs.tut.fi> wrote:
> Chris Gehlker <·······@fastq.com> writes:
>> To me this isn't just theoretical because some programmers that I respect
>> are abandoning Haskell for this very reason. They don't say that Haskell
>> gained them nothing. They simply say that on balance the increased code
>> size, and decreased expressiveness of Haskell cost more than they gained in
>> terms of easier testing.
>
> I'm curious about this, because in my experience the difference in
> expressiveness between Lisp and Haskell is mainly due to Haskell being
> a lazy functional language and has nothing really to do with static
> typing.
This could well be. I didn't actually ask *why* they found Haskell less
expressive. My impression was that it was mostly just because it was too
verbose.
It's a good question. I'll explore more.
-----= 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! =-----
On Thu, 12 Dec 2002, Erann Gat wrote:
[snip]
> The Right Answer IMO is to be somewhere in the middle. Use static type
> checking where it's appropriate, and fall back on dynamism when it's not.
> Unfortunately, the only language that really supports this at the moment
> is Dylan, and it has its own set of problems.
[snip]
Just as an aside, there are some Smalltalk dialects that do a pretty
intereting job of this. StrongTalk (which also had a Self inspired
dynamic optimizing jit, win runtime profile directed inline) has had an
influence, and the actual early 90s implementation has been released to
play with (the class libraries are open source, I believe, and people have
been playing with them).
IIRC, the (optional) typing was *not* primarily used for
efficiency/optimization, but for documentation and "safety".
I think SmallScript (a current commerical Smalltalk dialect) also has such
a typing system, but I've really been out of it so can't swear :)
But I'm confused, I thought Common Lisp had optional type checking, if not
as "strong" or systematic as Dylan's. Indeed, when discussing adding
typing to Smalltalk, Common Lisp usually pops up as a thing to study!
Cheers,
Bijan Parsia.
Bijan Parsia <·······@email.unc.edu> writes:
> But I'm confused, I thought Common Lisp had optional type checking
It does. Optional for the user to use and optional for the vendor to implement.
--
Cheers, The Rhythm is around me,
The Rhythm has control.
Ray Blaak The Rhythm is inside me,
·····@telus.net The Rhythm has my soul.
Ray Blaak wrote:
> Bijan Parsia <·······@email.unc.edu> writes:
>
>>But I'm confused, I thought Common Lisp had optional type checking
>
>
> It does. Optional for the user to use and optional for the vendor to implement.
Which Common Lisp implementations offer static type checking on demand?
(Your statement seems to imply their existence.)
Pascal
--
Pascal Costanza University of Bonn
···············@web.de Institute of Computer Science III
http://www.pascalcostanza.de R�merstr. 164, D-53117 Bonn (Germany)
On Fri, Dec 13, 2002 at 09:58:38AM +0100, Pascal Costanza wrote:
> Ray Blaak wrote:
> > Bijan Parsia <·······@email.unc.edu> writes:
> >
> >>But I'm confused, I thought Common Lisp had optional type checking
> >
> >
> > It does. Optional for the user to use and optional for the vendor to implement.
>
> Which Common Lisp implementations offer static type checking on demand?
> (Your statement seems to imply their existence.)
Python (CMUCL, SBCL, and SCL) will do static type-inference as much as it
can, and emit efficiency notes and warnings at you for various things.
CMU Common Lisp release x86-linux 3.1.2 18d+ 29 August 2002
Loaded subsystems:
Python 1.0, target Intel x86
CLOS based on PCL version: September 16 92 PCL (f)
* (defun foo (x) (+ x "a"))
FOO
* (compile 'foo)
Compiling LAMBDA (X):
In: LAMBDA (X)
(+ X "a")
Warning: This is not a (VALUES &OPTIONAL NUMBER &REST T):
"a"
Compiling Top-Level Form:
Compilation unit finished.
1 warning
FOO
T
T
*
And FOO will signal an error if you really try to call it.
--
; Matthew Danish <·······@andrew.cmu.edu>
; OpenPGP public key: C24B6010 on keyring.debian.org
; Signed or encrypted mail welcome.
; "There is no dark side of the moon really; matter of fact, it's all dark."
Pascal Costanza <········@web.de> writes:
> Which Common Lisp implementations offer static type checking on demand?
> (Your statement seems to imply their existence.)
I don't know. Maybe none.
I am referring to the (declare (type ...)) declaration and (the type ...)
forms that are available for use as per the language spec, but are not
required to be implemented. Or more precisely, the consequences of type
violations are undefined.
See: http://www.lispworks.com/reference/HyperSpec/Body/d_type.htm
Actually, I would imagine decent use is made of these declarations for numeric
optimizations, at least, when generating compiled code.
--
Cheers, The Rhythm is around me,
The Rhythm has control.
Ray Blaak The Rhythm is inside me,
·····@telus.net The Rhythm has my soul.
Ray Blaak <·····@telus.net> writes:
> Pascal Costanza <········@web.de> writes:
> > Which Common Lisp implementations offer static type checking on demand?
> > (Your statement seems to imply their existence.)
>
> I don't know. Maybe none.
>
> I am referring to the (declare (type ...)) declaration and (the type ...)
> forms that are available for use as per the language spec, but are not
> required to be implemented. Or more precisely, the consequences of type
> violations are undefined.
I originally didn't answer Pascal's question, because I was thinking
of it in terms of the feature that some CLs implement, and which we
are considering for future versions of Allegro CL, where type-safe
but fast code can be generated, which first checks a value for the
expected (i.e. declared) type, and then proceeds with fast code which
assumes that type. Of course, there is an issue as to where exactly to
place such initial checks, and the tupe inferences that the compiler
makes must be perfect, but it is an interesting enhancement...
However, it just struck me - we are talking about type inference and
checking as if they are one thing, and yet CL _does_ explicitly provide
a portable way to check types (can you guess what it's called?) See:
http://www.franz.com/support/documentation/6.2/ansicl/dictentr/check-ty.htm
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
I don't worry so much about the optimizations you can apply because of
type inference, but more about the feedback on potential bugs you can
have at compile-time, before running your test-suite. Here's an
imaginary session log:
> (defun foo (x)
(plus x "n"))
Warning: "plus" doesn't seem to accept strings as parameters - shall I
accept the definition of "foo" anyway? (y/n)
> y
function "foo"
>
Of course, the environment should allow you to disable the interactive
mode and either automatically accept or reject everything. Such a
feature would make everybody happy: fans of dynamic typing as well as
people who generally or perhaps only occasionally prefer static typing.
> (let ((*static-typing* t))
(defun foo (x)
(plus x 5)))
Pascal
Duane Rettig wrote:
> Ray Blaak <·····@telus.net> writes:
>
>
>>Pascal Costanza <········@web.de> writes:
>>
>>>Which Common Lisp implementations offer static type checking on demand?
>>>(Your statement seems to imply their existence.)
>>
>>I don't know. Maybe none.
>>
>>I am referring to the (declare (type ...)) declaration and (the type ...)
>>forms that are available for use as per the language spec, but are not
>>required to be implemented. Or more precisely, the consequences of type
>>violations are undefined.
>
>
> I originally didn't answer Pascal's question, because I was thinking
> of it in terms of the feature that some CLs implement, and which we
> are considering for future versions of Allegro CL, where type-safe
> but fast code can be generated, which first checks a value for the
> expected (i.e. declared) type, and then proceeds with fast code which
> assumes that type. Of course, there is an issue as to where exactly to
> place such initial checks, and the tupe inferences that the compiler
> makes must be perfect, but it is an interesting enhancement...
>
> However, it just struck me - we are talking about type inference and
> checking as if they are one thing, and yet CL _does_ explicitly provide
> a portable way to check types (can you guess what it's called?) See:
>
> http://www.franz.com/support/documentation/6.2/ansicl/dictentr/check-ty.htm
>
--
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 wrote:
> Here's an imaginary session log:
>
> > (defun foo (x)
> (plus x "n"))
> Warning: "plus" doesn't seem to accept strings as parameters - shall I
> accept the definition of "foo" anyway? (y/n)
> > y
> function "foo"
Here's a real session log (with CMUCL):
* (defun plus (x y)
(declare (type number x y))
(+ x y))
PLUS
* (defun foo (x) (plus x "n"))
FOO
* (compile 'foo)
Compiling LAMBDA (X):
In: LAMBDA (X)
(PLUS X "n")
Warning: This is not a (VALUES &OPTIONAL NUMBER &REST T):
"n"
Compiling Top-Level Form:
Compilation unit finished.
1 warning
FOO
T
T
*
Jeremy.
Yes, Matthew already mentioned this - this is very nice!
Thanks,
Pascal
Jeremy Yallop wrote:
> Here's a real session log (with CMUCL):
>
> * (defun plus (x y)
> (declare (type number x y))
> (+ x y))
>
> PLUS
> * (defun foo (x) (plus x "n"))
>
> FOO
> * (compile 'foo)
> Compiling LAMBDA (X):
>
> In: LAMBDA (X)
> (PLUS X "n")
> Warning: This is not a (VALUES &OPTIONAL NUMBER &REST T):
> "n"
>
> Compiling Top-Level Form:
>
> Compilation unit finished.
> 1 warning
>
>
> FOO
> T
> T
> *
>
> Jeremy.
--
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 <········@web.de> writes:
> > (defun foo (x)
> (plus x "n"))
> Warning: "plus" doesn't seem to accept strings as parameters - shall I
> accept the definition of "foo" anyway? (y/n)
> > y
> function "foo"
> >
>
> Of course, the environment should allow you to disable the interactive
> mode and either automatically accept or reject everything. Such a
> feature would make everybody happy: fans of dynamic typing as well as
> people who generally or perhaps only occasionally prefer static typing.
Actually I think an interactive approach would be quite tedious. It require
the user to wait on messages while the compilation/analysis is executing.
It is more efficient to do the usual thing: errors and warnings are simply
logged. You then deal with them at your leisure after the fact.
Pragmas or some otherwise special forms can be used to demarcate those code
regions where strictness can be suppressed. If strictness is to be suppressed
(or enabled) in general, that is equivalent to setting an overall
warning-level switch.
--
Cheers, The Rhythm is around me,
The Rhythm has control.
Ray Blaak The Rhythm is inside me,
·····@telus.net The Rhythm has my soul.
On Fri, 13 Dec 2002, Ray Blaak wrote:
> Bijan Parsia <·······@email.unc.edu> writes:
> > But I'm confused, I thought Common Lisp had optional type checking
>
> It does. Optional for the user to use and optional for the vendor to implement.
Sure.
Hmm.
Is it option to implement in Dylan? I mean, Erann claimed that Dylan was
the only langauge that had this type of type system, but there's no formal
Dylan standard, and I imagine that there are implementations that don't do
much with typing (though I don't actually know; corrections welcome). So
we're back to particular implementations anyway.
Hmm. Maybe the class sealing stuff in Dylan is what Erann was referring
to?
Cheers,
Bijan Parsia.
In article
<············································@login1.isis.unc.edu>,
Bijan Parsia <·······@email.unc.edu> wrote:
> On Fri, 13 Dec 2002, Ray Blaak wrote:
>
> > Bijan Parsia <·······@email.unc.edu> writes:
> > > But I'm confused, I thought Common Lisp had optional type checking
> >
> > It does. Optional for the user to use and optional for the vendor to
> > implement.
>
> Sure.
>
> Hmm.
>
> Is it option to implement in Dylan? I mean, Erann claimed that Dylan was
> the only langauge that had this type of type system, but there's no formal
> Dylan standard,
True. There was no formal Common Lisp standard until quite recently.
> and I imagine that there are implementations that don't do
> much with typing (though I don't actually know; corrections welcome). So
> we're back to particular implementations anyway.
Functional-Objects (nee Harlequin) Dylan and Gwydion "d2c" both do a lot
with types at compile time. They also try to implement exactly the same
language, which is the DRM plus some agreed extensions. That
compatability falls down in some areas of course, but that's considered
a bug.
Gwydion's "Mindy" implementation does essentially nothing with types at
compile time -- it parses the source and turns it into bytecodes and
that's it. Since Mindy is only used to bootstrap Dylan on platforms
that have no preexisting d2c binary we don't think it matters a lot if
Mindy is inefficient.
-- Bruce
Erann Gat wrote:
> If you think the Lisp train is rolling, then help me answer this question
> that my managers ask me whenever I bring the subject up: who uses it?
Can't speak for the others, but all I am saying is that I see signs that
the tide has turned. We're still at low tide, and Fortune 500 will
likely be the last to get on board. This is little consolation to those
looking for a job tomorrow, but it suggests to me that I am better off
doing Cello and getting better at Lisp (and, accidentally, OpenGL) than
selling my soul and porting Cells to Java so I can get that steaming
pile of turd on my resume. :)
As for who uses it, ILC 2002 revealed some pretty bright people using it
for very neat stuff. But I imagine a conference for VB would leave me
with the same impression.
Aside: Speaking of Cello, just got a quick response from the folks
working on FreeGlut re my need for a DLL to load from ACL. Glut might be
our window manager, but it needs development and an open license, both
of which FreeGlut offer/make possible. Meanwhile I /almost/ have a
pushbutton working (OpenGL and my thick skull are the only holdups). And
the hyphenated names are a pain where I sit, thank you very little. :)
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Cells let us walk, talk, think, make love and realize
the bath water is cold." -- Lorraine Lee Cudmore
"Erann Gat" <···@jpl.nasa.gov> wrote
> If you think the Lisp train is rolling, then help me answer this question
> that my managers ask me whenever I bring the subject up: who uses it?
My current company and the last 3 I worked for. And about 20 places I
applied to when I was looking.
--
Coby Beck
(remove #\Space "coby 101 @ bigpond . com")
In article <············@otis.netspace.net.au>, "Coby Beck"
<·····@mercury.bc.ca> wrote:
> "Erann Gat" <···@jpl.nasa.gov> wrote
> > If you think the Lisp train is rolling, then help me answer this question
> > that my managers ask me whenever I bring the subject up: who uses it?
>
> My current company and the last 3 I worked for. And about 20 places I
> applied to when I was looking.
Well, thank you for that helpful answer. The next time my managers ask me
"who uses Lisp?" I'll just say, "The last twenty places that Coby Beck
sent his resume all use it." I'm sure their response will be to slap
themselves on the forehead and immediately repent of their years of
foolishness in rejecting Lisp. I'm sure they won't ask the names of those
twenty companies are, or what they were using Lisp for, which is a good
thing because if they did I'd look like a complete idiot.
Hm, I just realized I do know the identity of at least one of those twenty
companies you applied at. Bonus points to the first person who can guess
how I know.
E.
"Erann Gat" <···@jpl.nasa.gov> wrote in message
·························@k-137-79-50-101.jpl.nasa.gov...
> In article <············@otis.netspace.net.au>, "Coby Beck"
> <·····@mercury.bc.ca> wrote:
>
> > "Erann Gat" <···@jpl.nasa.gov> wrote
> > > If you think the Lisp train is rolling, then help me answer this
question
> > > that my managers ask me whenever I bring the subject up: who uses it?
> >
> > My current company and the last 3 I worked for. And about 20 places I
> > applied to when I was looking.
>
> Well, thank you for that helpful answer.
Sorry if I ticked you off, it was kind of a rhetorical answer (i thought it
was a rhetorical question!) - it had a point though. Really, the question
"who uses it" can have a lot of different motivations and different kinds of
satisfactory answers. Often, people just want to know they are not alone.
> The next time my managers ask me
> "who uses Lisp?" I'll just say, "The last twenty places that Coby Beck
> sent his resume all use it." I'm sure their response will be to slap
> themselves on the forehead and immediately repent of their years of
> foolishness in rejecting Lisp. I'm sure they won't ask the names of those
> twenty companies are, or what they were using Lisp for, which is a good
> thing because if they did I'd look like a complete idiot.
Mercury Scheduling (www.mercury.bc.ca) Memetrics (www.memetrics.com.au )
Open Technologies Group www.opentechgroup.com - people I worked for in the
past - applications sent to the companies on www.franz.com's employment
pages and some of the companies that came up with a www.flipdog.com search
for lisp. Some notable names: gensym, orbitz, ITA software (I think that's
the same as orbitz..?) Cyc.
I ended up able to chose between different offers (but it took a while of
searching)
I know you are dealing with alot of politics and unfortunately I have no
advice (assuming you would like to see lisp back there). It is around
though.
--
Coby Beck
(remove #\Space "coby 101 @ bigpond . com")
···@jpl.nasa.gov (Erann Gat) writes:
> If you think the Lisp train is rolling, then help me answer this question
> that my managers ask me whenever I bring the subject up: who uses it?
I seem to recall a Lisp project that won the NASA Software of the Year
competition not too long ago.
In article <············@ccs.neu.edu>, Joe Marshall <···@ccs.neu.edu> wrote:
> ···@jpl.nasa.gov (Erann Gat) writes:
>
> > If you think the Lisp train is rolling, then help me answer this question
> > that my managers ask me whenever I bring the subject up: who uses it?
^^^^
>
> I seem to recall a Lisp project that won the NASA Software of the Year
> competition not too long ago.
Uses. Present tense. See http://www.flownet.com/gat/jpl-lisp.html
E.
On Thu, 12 Dec 2002 11:54:15 -0800, ···@jpl.nasa.gov (Erann Gat) wrote:
> In the past ten years Lisp has become moribund. It has changed not at
> all, while other languages have made great advances. Lisp is still the
Maybe Common Lisp [was|is|will be] mature enough[*], and other languages
are just slowly catching up.
> best of the lot, but the situation is no longer anywhere near as clear as
> it was ten years ago. It's not a no-brainer any more. Lisp is no longer
> unique in offering dynamism (Python and Perl have it), automatic memory
> management (just about everything has it nowadays, including C++), an
> object system. In fact, about the only feature that Lisp offers uniquely
> nowadays is macros.
I often hear such lists of languages with a few Lisp features. But I don't
know whether there are other languages with _all_ of Lisp features. In the
case of Lisp, the whole is much more than the sum of its parts.
> snoozing for the past ten years. I keep hearing that Lisp is on the rise,
> and that would be great, but I don't see any evidence of it from where I
> sit. And I find it hard to imagine how Lisp will rise now that its
Maybe you don't look hard enough?
> If you think the Lisp train is rolling, then help me answer this question
> that my managers ask me whenever I bring the subject up: who uses it?
I will be happy to oblige :-) As part of my contribution to the new ALU
site, I am putting together _up to date_ lists of Lisp users in both
industry and research. The list already looks interesting, but I am working
slowly and it will take some time to complete it: Lispers seem more
interested in searching for evidence that Lisp is not used, so help is
limited ;-)
Paolo
[*] I.e. productively usable for large and complex problems.
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://www.paoloamoroso.it/ency/README
Paolo Amoroso wrote:
> On Thu, 12 Dec 2002 11:54:15 -0800, ···@jpl.nasa.gov (Erann Gat) wrote:
>
>>best of the lot, but the situation is no longer anywhere near as clear as
>>it was ten years ago. It's not a no-brainer any more. Lisp is no longer
>>unique in offering dynamism (Python and Perl have it)...
>
> I often hear such lists of languages with a few Lisp features. But I don't
> know whether there are other languages with _all_ of Lisp features. In the
> case of Lisp, the whole is much more than the sum of its parts.
Genius is in the details. Python should not even come up when the
question is What language compares with Lisp? My brief visit to that
world revealed that Python and Lisp should not even be compared. Lisp is
a serious programming language, Python is a serious scripting language.
Pythonians don't even aspire to great language-hood for Python, they
want simple and practical. It's fun that Python has some neat, Lispy
qualities, just don't start thinking they are comparable.
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Cells let us walk, talk, think, make love and realize
the bath water is cold." -- Lorraine Lee Cudmore
In article <················@nyc.rr.com>, Kenny Tilton
<·······@nyc.rr.com> wrote:
> Genius is in the details. Python should not even come up when the
> question is What language compares with Lisp?
Peter Norvig doesn't agree. (Neither do I.) See
http://www.norvig.com/python-lisp.html
> My brief visit to that
> world revealed that Python and Lisp should not even be compared.
You know, I can see the exact same sentence being written in
comp.lang.python, with "that world" meaning the Lisp world. Imagine what
would happen if someone posted that comment to comp.lang.lisp. No, wait,
you don't have to imagine. All you have to do is look though the c.l.l.
archives to see what would happen. They'd get raked over the coals for
passing judgement on Lisp without first obtaining a full and complete
understanding of it. I'll wager high stakes that the usual band of thugs
who excoriate people for posting poorly-informed comments here are going
to be oddly silent this time. Hypocrites!
> Lisp is
> a serious programming language, Python is a serious scripting language.
I asked this question a while back but you didn't weigh in then so I'll
ask again now: what is the difference between a programming language and a
scripting language?
> Pythonians don't even aspire to great language-hood for Python, they
> want simple and practical. It's fun that Python has some neat, Lispy
> qualities, just don't start thinking they are comparable.
Wow, it really takes balls to first admit you know next to nothing about
Python and then pontificate about what the Python community does and
doesn't want. Imagine a Pythonian saying, "My brief visit to the Lisp
world reveal that Python and Lisp should not even be compared. Lispers
don't even aspire to practical utility in their language. They want it
abstruse and inaccessible. They revel in weird, confusing features (like
that stupid syntax of theirs). Lisp has some historical interest, but
don't go confusing it with something that's actually useful." How would
you react?
E.
Erann Gat wrote:
> In article <················@nyc.rr.com>, Kenny Tilton
> <·······@nyc.rr.com> wrote:
>>My brief visit to that
>>world revealed that Python and Lisp should not even be compared.
>
>
> You know, I can see the exact same sentence being written in
> comp.lang.python, with "that world" meaning the Lisp world.
Yes, and I made the same comment over in clp. And when I say "should not
even be compared", I went that in the sense of apples and oranges, ie,
not meaning one is better than another. I can see how it could be taken
that way since one way to put down something is to say it can't compare,
but I was speaking more precisely in this case.
> They'd get raked over the coals for
> passing judgement on Lisp without first obtaining a full and complete
> understanding of it.
For this assessment, viz, that Python is not a serious language the way
Lisp is, it only takes a brief acquaintance to determine that. And
again, I do not mean it as an insult. Python is just an incredibly good
scripting language, with no pretensions to anything more.
> I'll wager high stakes that the usual band of thugs
> who excoriate people for posting poorly-informed comments here are going
> to be oddly silent this time. Hypocrites!
No, they may know what I am talking about in re Python just being one
guy's pet project that has picked up steam and all sorts of cool new
features. But it's a toy language and must always be, because they do
not want to break with the past.
>>Lisp is
>>a serious programming language, Python is a serious scripting language.
>
>
> I asked this question a while back but you didn't weigh in then so I'll
> ask again now: what is the difference between a programming language and a
> scripting language?
Looked like a thread to avoid. :) Well, i would say a scripting language
just needs to drive other stuff, which will be doing all the interesting
work. So the scripting language does not have to be all that expressive.
You are not building a world in the language, you are driving the
outside world.
>
>
>>Pythonians don't even aspire to great language-hood for Python, they
>>want simple and practical. It's fun that Python has some neat, Lispy
>>qualities, just don't start thinking they are comparable.
>
>
> Wow, it really takes balls to first admit you know next to nothing about
> Python and then pontificate about what the Python community does and
> doesn't want.
(a) here we go again with my manhood
(b) pontification? this is Usenet and I am a Leo; move over, Pope.
(c) back off, man. I'm a scientist. i did not say I knew next to
nothing, I said I made a brief visit. At the time I was porting Cells,
so I got into Python internals to enhance both readers and writers, shit
most Pythoners never dream of. And like I said above, the comparison is
easy. The BDFL's own words make clear he just wants to keep things
simple. Last of all, I said the same thing on c.l.p, and no one took
issue with it. (This in a thread comparing Lisp and Python where people
were weighing in on all sorts of stuff.)
> Imagine a Pythonian saying, "My brief visit to the Lisp
> world reveal that Python and Lisp should not even be compared. Lispers
> don't even aspire to practical utility in their language. They want it
> abstruse and inaccessible. They revel in weird, confusing features (like
> that stupid syntax of theirs). Lisp has some historical interest, but
> don't go confusing it with something that's actually useful." How would
> you react?
Well obviously i would agree, tho I would protest mildly the
impracticality. I'd probably respond that we Lispers had found that,
whenever we try to do something with our language we find that we have
to put so many alpha characters in the source that it makes it hard to
make pretty patterns with the parentheses, so mostly we try to write
code that does not do anything. and my is it fast.
:)
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Cells let us walk, talk, think, make love and realize
the bath water is cold." -- Lorraine Lee Cudmore
In article <················@nyc.rr.com>, Kenny Tilton
<·······@nyc.rr.com> wrote:
> (c) back off, man.
Sorry. My bad.
> The BDFL's own words make clear he just wants to keep things
> simple.
IMO keeping things simple is not at odds with being a serious programming
language. Having written one deployed application entirely in Python (the
Google Translation Console) I consider it a serious programming language,
and the best overall choice for many applications (though not, alas,
programming spacecraft, or I wouldn't be here).
> Last of all, I said the same thing on c.l.p, and no one took
> issue with it.
OK. I apologise for my rant. I was out of line.
E.
Kenny Tilton <·······@nyc.rr.com> writes:
> Genius is in the details. Python should not even come up when the
> question is What language compares with Lisp?
Right, because Python gets the first order details right (a language
that "would appeal to Unix/C hackers"), while Lisp is still mired in
the idea that the whole world is an interactive user sitting at the
console of a Lisp Machine (tm).
Scott Schwartz <··········@usenet ·@bio.cse.psu.edu> writes:
> Right, because Python gets the first order details right (a language
> that "would appeal to Unix/C hackers"), while Lisp is still mired in
> the idea that the whole world is an interactive user sitting at the
> console of a Lisp Machine (tm).
Yawn.
It is quite clear that you have not investigated the way contemporary
Lisp systems interoperate with their host environment (nor have you
ever been the user of a Lisp Machine).
Scott Schwartz wrote:
> Kenny Tilton <·······@nyc.rr.com> writes:
>
>>Genius is in the details. Python should not even come up when the
>>question is What language compares with Lisp?
>
>
> Right, because Python gets the first order details right (a language
> that "would appeal to Unix/C hackers"), while Lisp is still mired in
> the idea that the whole world is an interactive user sitting at the
> console of a Lisp Machine (tm).
>
EXEs? We don't nee dno stinkin' EXEs!
:)
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Cells let us walk, talk, think, make love and realize
the bath water is cold." -- Lorraine Lee Cudmore
Kenny Tilton wrote:
> Genius is in the details. Python should not even come up when the
> question is What language compares with Lisp? My brief visit to that
> world revealed that Python and Lisp should not even be compared. Lisp is
> a serious programming language, Python is a serious scripting language.
> Pythonians don't even aspire to great language-hood for Python, they
> want simple and practical. It's fun that Python has some neat, Lispy
> qualities, just don't start thinking they are comparable.
Most Pythonistas (no Pythonista would use the word "Pythonian",
even though "Pythonic" is a common word to apply, e.g., to language
features or ways of solving a problem) would disagree with your
statement that Python is "a serious scripting language", if you
intend that to imply that it isn't "a serious programming language".
I don't see what's so incomparable about them. There are plenty of
sensible comparisons one can make. [At this point there used to be
7 concrete examples, but I decided they were superfluous.] I'm sure
I'm being too literal-minded here; do you mean that there are
no applications for which one would seriously be choosing between
Lisp and Python as implementation languages? I don't think I believe you,
if so.
--
Gareth McCaughan ················@pobox.com
.sig under construc
Gareth McCaughan wrote:
> Kenny Tilton wrote:
>
>
>> Genius is in the details. Python should not even come up when the
>> question is What language compares with Lisp? My brief visit to that
>> world revealed that Python and Lisp should not even be compared. Lisp is
>> a serious programming language, Python is a serious scripting language.
>> Pythonians don't even aspire to great language-hood for Python, they
>> want simple and practical. It's fun that Python has some neat, Lispy
>> qualities, just don't start thinking they are comparable.
>
>
> Most Pythonistas (no Pythonista would use the word "Pythonian",
Thx, I had a feeling Pythonian was wrong.
> do you mean that there are
> no applications for which one would seriously be choosing between
> Lisp and Python as implementation languages?
Ah, all i said was that the languages were not comparable because their
design imperatives were so different. So use Python where it gets you at
the libraries you cannot get to from CL, use CL where the fun stuff will
be in the code you right (not some library). And sure, in some
situations those considerations won't produce a clear-cut decision.
Maybe the CL advantages will be of enough value that interfacing CL to
some library will be worth the effort of building a C wrapper or doing
CORBA or whatever that crap is. :)
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Cells let us walk, talk, think, make love and realize
the bath water is cold." -- Lorraine Lee Cudmore
Paolo Amoroso <·······@mclink.it> writes:
> On Thu, 12 Dec 2002 11:54:15 -0800, ···@jpl.nasa.gov (Erann Gat) wrote:
>
> > In the past ten years Lisp has become moribund. It has changed not at
> > all, while other languages have made great advances. Lisp is still the
>
> Maybe Common Lisp [was|is|will be] mature enough[*], and other languages
> are just slowly catching up.
And this can and should easily be a source of pride, and not scorn. We
can take a positive view of it or a negative view. We can also search for
status quo or for change, and find whatever we search for. Erann searches
for stagnation (qua the standard being a whole 8 years old and not looking
likely to change much) and of course finds it. I look for changes in the
implementations (more of them, better compilers, better gcs, _much_ better
connectivity, work on de facto standardization and macrology for the same,
and work going on in other areas) and find them. It's just a difference in
how one looks at the elephant.
> > best of the lot, but the situation is no longer anywhere near as clear as
> > it was ten years ago. It's not a no-brainer any more. Lisp is no longer
> > unique in offering dynamism (Python and Perl have it), automatic memory
> > management (just about everything has it nowadays, including C++), an
> > object system. In fact, about the only feature that Lisp offers uniquely
> > nowadays is macros.
>
> I often hear such lists of languages with a few Lisp features. But I don't
> know whether there are other languages with _all_ of Lisp features. In the
> case of Lisp, the whole is much more than the sum of its parts.
My thoughts, exactly. I would say that the greatest feature Lisp offers to
the programming community is Lisp itself.
> > snoozing for the past ten years. I keep hearing that Lisp is on the rise,
> > and that would be great, but I don't see any evidence of it from where I
> > sit. And I find it hard to imagine how Lisp will rise now that its
>
> Maybe you don't look hard enough?
I have to admit, that we have dropped the ball in that area, and the ALU
site has become grossly outdated. But, as you imply below, there is new
vigor and efforts to bring the information that Erann needs to the surface,
to where he will be able to show his bosses if he wishes.
> > If you think the Lisp train is rolling, then help me answer this question
> > that my managers ask me whenever I bring the subject up: who uses it?
>
> I will be happy to oblige :-) As part of my contribution to the new ALU
> site, I am putting together _up to date_ lists of Lisp users in both
> industry and research. The list already looks interesting, but I am working
> slowly and it will take some time to complete it: Lispers seem more
> interested in searching for evidence that Lisp is not used, so help is
> limited ;-)
Don't get discouraged. Let me know how I can help. And thanks for doing
this work.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
On Fri, 13 Dec 2002 20:00:03 GMT, Duane Rettig <·····@franz.com> wrote:
> Paolo Amoroso <·······@mclink.it> writes:
[...]
> > Maybe Common Lisp [was|is|will be] mature enough[*], and other languages
> > are just slowly catching up.
>
> And this can and should easily be a source of pride, and not scorn. We
Yes, this is what I meant.
> Don't get discouraged. Let me know how I can help. And thanks for doing
Who said I am discouraged? :)
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://www.paoloamoroso.it/ency/README
"Erann Gat" <···@jpl.nasa.gov> wrote in message
·························@k-137-79-50-101.jpl.nasa.gov...
> In the past ten years Lisp has become moribund. It has changed not at
> all, while other languages have made great advances. Lisp is still the
> best of the lot, but the situation is no longer anywhere near as clear as
> it was ten years ago. It's not a no-brainer any more. Lisp is no longer
> unique in offering dynamism (Python and Perl have it), automatic memory
> management (just about everything has it nowadays, including C++), an
> object system. In fact, about the only feature that Lisp offers uniquely
> nowadays is macros.
>
> It's like the tortoise and the hare. Lisp is the hare, and it's been
> snoozing for the past ten years. I keep hearing that Lisp is on the rise,
> and that would be great, but I don't see any evidence of it from where I
> sit. And I find it hard to imagine how Lisp will rise now that its
> advantages over the competition are so much smaller than they were ten
> years ago.
>
You have an inherent assumption that programming languages can
advance anymore. Commercial aircraft look like and are basically the
same as their 1960's versions. Do we fret over that? Well some people
do, forever hoping for some technological magic to be discovered to
allow SSTs to exist in an economic form. Well the reality is that
new programming innovations are now few and far between. Programming
has hit a ceiling based on the realities of computing. Lisp hit the
ceiling first, the others are catching up (though they alo do not want to
admit to this ceiling and keep trying to re-invent the wheel, only to
end up with the same wheels).
If someone invents a new Lisp will it be better than CL? Or just different?
Maybe programmers as a group are easily bored and dissatisfied and
do not have the discipline to stick with something. Sticking with
something is now needed to make new advances as a deeper
understanding from actual usage (experience) is the only thing
that will bring new insights. (Writing that poem everyday)
> Lisp isn't going to die. It has a niche market that isn't going to go
> away, kind of like COBOL. But that doesn't do *me* any good because niche
> products are a really hard sell in the space business. (Lisp and COBOL
> are pretty much in an equivalence class as far as most people around here
> are concerned, along with PL/I, SNOBOL, Simula, and a host of other
> languages that are not quite dead either. In fact, there is more Simula
> work going on at JPL than Lisp work at the moment.)
>
> So, do I have some faith that Lisp is on the right track? I don't know.
> It certainly *was* on the right track, but now it seems to me to be
> sitting on a siding. To me, being on the right track is less important
> than simply getting the Lisp train rolling again.
>
What is the right track? This is a serious question. Perhaps you
could flesh out that concept? Is being in a niche the wrong track?
> If you think the Lisp train is rolling, then help me answer this question
> that my managers ask me whenever I bring the subject up: who uses it?
JPL does (or did). Is that not good enough? Your Lisp projects at JPL
were a success.
Wade
In article <·····················@news1.telusplanet.net>, "Wade Humeniuk"
<····@nospam.nowhere> wrote:
> "Erann Gat" <···@jpl.nasa.gov> wrote in message
> ·························@k-137-79-50-101.jpl.nasa.gov...
> > In the past ten years Lisp has become moribund. It has changed not at
> > all, while other languages have made great advances. Lisp is still the
> > best of the lot, but the situation is no longer anywhere near as clear as
> > it was ten years ago. It's not a no-brainer any more. Lisp is no longer
> > unique in offering dynamism (Python and Perl have it), automatic memory
> > management (just about everything has it nowadays, including C++), an
> > object system. In fact, about the only feature that Lisp offers uniquely
> > nowadays is macros.
> >
> > It's like the tortoise and the hare. Lisp is the hare, and it's been
> > snoozing for the past ten years. I keep hearing that Lisp is on the rise,
> > and that would be great, but I don't see any evidence of it from where I
> > sit. And I find it hard to imagine how Lisp will rise now that its
> > advantages over the competition are so much smaller than they were ten
> > years ago.
> >
>
> You have an inherent assumption that programming languages can
> advance anymore. Commercial aircraft look like and are basically the
> same as their 1960's versions. Do we fret over that? Well some people
> do, forever hoping for some technological magic to be discovered to
> allow SSTs to exist in an economic form. Well the reality is that
> new programming innovations are now few and far between. Programming
> has hit a ceiling based on the realities of computing. Lisp hit the
> ceiling first, the others are catching up (though they alo do not want to
> admit to this ceiling and keep trying to re-invent the wheel, only to
> end up with the same wheels).
Comparison with airplanes is a good analogy. Even though commercial
aircraft are all "basically" the same as their 1960's versions, you would
never mistake a 777 for a 707. The new jets are quieter, they have glass
cockpits, etc. etc. Even the aerodynamics have incremental improvements,
e.g. winglets.
BTW, I don't believe that Lisp (or any language) has hit a capability
ceiling, but that's another argument.
> If someone invents a new Lisp will it be better than CL? Or just different?
"Es ist nicht gesagt das es besser wird wenn es anders wird. Wenn es aber
besser werden soll muss es anders werden." (With apologies to people who
actually know German for my atrocious spelling.) -- G. Ch. Lichtenberg.
Loosely translated: different is not necessarily better. But better is
necessarily different.
> Maybe programmers as a group are easily bored and dissatisfied and
> do not have the discipline to stick with something. Sticking with
> something is now needed to make new advances as a deeper
> understanding from actual usage (experience) is the only thing
> that will bring new insights.
I've been programming in Lisp for twenty years. It has served me well. I
have been at my current job going on forteen years now (with a one-year
sabbatical). I think I can safely claim that any changes I advocate are
not because I don't have the discipline to stick with something.
> (Writing that poem everyday)
I finished my first screenplay two days ago. :-)
> What is the right track? This is a serious question. Perhaps you
> could flesh out that concept? Is being in a niche the wrong track?
From where I sit, yes. I'm in the aerospace industry, which is run by
people who don't understand software and who are intensely conservative
(and justifiably so). In this business, niche == dead.
There's also this whole thing about making the world at large a better
place. How many work-centuries have been wasted by programmers tracking
down memory leaks and dangling pointers? By ordinary people rebooting
their machines and re-typing their documents because Windows crashed
again? How many people might have better lives if that effort had been
put to more productive uses? Yes, I think that niche is the wrong track.
The whole world ought to be using Lisp. It would be a better place.
Finally, I'm just sick and tired of having to explain myself all the time
when I say I want to use Lisp. "What do you mean? Everyone uses Visual
Basic. It's just the Way Things Are Done. If you don't know Visual Basic
(or Perl or Java) you're obviously not a real software professional."
AARRRGGHHH!!!!
> > If you think the Lisp train is rolling, then help me answer this question
> > that my managers ask me whenever I bring the subject up: who uses it?
>
> JPL does (or did). Is that not good enough? Your Lisp projects at JPL
> were a success.
You apparently haven't read http://www.flownet.com/gat/jpl-lisp.html. But
be that as it may, I do not want to grow old resting on my laurels.
Nothing is ever good enough (at least not for long). "Good enough" is the
death knell of progress.
E.
···@jpl.nasa.gov (Erann Gat) writes:
> Comparison with airplanes is a good analogy. Even though commercial
> aircraft are all "basically" the same as their 1960's versions, you would
> never mistake a 777 for a 707. The new jets are quieter, they have glass
> cockpits, etc. etc. Even the aerodynamics have incremental improvements,
> e.g. winglets.
Ah, yes, the 777. A great machine, built by Boeing, using ICAD to design
it (running on top of Allegro CL)...
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
In article <·············@beta.franz.com>, Duane Rettig <·····@franz.com> wrote:
> Ah, yes, the 777. A great machine, built by Boeing, using ICAD to design
> it (running on top of Allegro CL)...
So Boeing uses Lisp? Now *that* would carry some weight around here. Can
you provide some more details?
E.
···@jpl.nasa.gov (Erann Gat) writes:
> In article <·············@beta.franz.com>, Duane Rettig <·····@franz.com> wrote:
>
> > Ah, yes, the 777. A great machine, built by Boeing, using ICAD to design
> > it (running on top of Allegro CL)...
>
> So Boeing uses Lisp? Now *that* would carry some weight around here. Can
> you provide some more details?
Actually, I was just going to give you a URL, but when I looked it
up there were too many of them. Go to our website and click the
"Search" button at the top, and type Boeing into the "search the Franz
Inc Website" box. There are quite a few divisions of Boeing that use
our product, some directly, some indirectly (through ICAD) and some
both. Some of these divisions list their successes, including the 777
designers.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
On Sat, 14 Dec 2002 00:51:00 -0800, ···@jpl.nasa.gov (Erann Gat) wrote:
> So Boeing uses Lisp? Now *that* would carry some weight around here. Can
> you provide some more details?
See:
Knowledge-Based Applications That Employ Dynamic Objects Technology
http://www.franz.com/support/tutorials/docompanies.lhtml
CL/CLOS and C++ - An Overview of C++: The Good, the Bad and the Ugly
http://www.franz.com/resources/educational_resources/clos_versus_other/cpp.lhtml
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://www.paoloamoroso.it/ency/README
Erann Gat wrote:
> So Boeing uses Lisp? Now *that* would carry some weight around here. Can
> you provide some more details?
>
The following isn't Boeing, but it is related to the 777. The design for the 777's main fly-by-wire command and control bus was validated by a temporal reasoning program called TMM.
TMM was written in Lisp at Honeywell Technology Center. I heard about
it when I got involved in a near-real-time satellite data acquisition
and processing system at NASA Goddard. We ended up using TMM to do our
compute resource allocation and monitoring.
TMM is described on the web at:
http://www.htc.honeywell.com/cap/systems/sched/tmm/tmm.html
In article <················@removeme.gst.com>, Bob Bane
<····@removeme.gst.com> wrote:
> Erann Gat wrote:
>
>
> > So Boeing uses Lisp? Now *that* would carry some weight around here. Can
> > you provide some more details?
> >
>
>
>
> The following isn't Boeing, but it is related to the 777. The design
for the 777's main fly-by-wire command and control bus was validated by a
temporal reasoning program called TMM.
>
>
> TMM was written in Lisp at Honeywell Technology Center. I heard about
> it when I got involved in a near-real-time satellite data acquisition
> and processing system at NASA Goddard. We ended up using TMM to do our
> compute resource allocation and monitoring.
>
> TMM is described on the web at:
>
> http://www.htc.honeywell.com/cap/systems/sched/tmm/tmm.html
Thanks! I remember studying TMM when I was a grad student. I'm glad to
see it's been put to practical use.
E.
···@jpl.nasa.gov (Erann Gat) writes:
>
> > What is the right track? This is a serious question. Perhaps you
> > could flesh out that concept? Is being in a niche the wrong track?
>
> From where I sit, yes. I'm in the aerospace industry, which is run by
> people who don't understand software and who are intensely conservative
> (and justifiably so). In this business, niche == dead.
I work in aerospace too and the industry funds a lot of niche markets-
look at all the funky radhard processors and custom hardware that ends
up being used on spacecraft. While I agree people in the space racket
are often hysterically conservative and lots of projects act more like
cargo cults than groups of rational people, they also fund lots of
things that would otherwise be long abandoned.
The recent evolution of missions to faster processors and bigger
memories will open up the possiblities for very different and much
more complicated flight code. When you don't have to count very
nearly every cycle and shoehorn code into little bits of memory,
something like CL becomes lots more palatable, and when you start
raising the spectre of updating the system while in operation, quite
attractive.
Gregm
In article <··············@europa.pienet>, Greg Menke
<··········@toadmail.com> wrote:
> ···@jpl.nasa.gov (Erann Gat) writes:
>
> >
> > > What is the right track? This is a serious question. Perhaps you
> > > could flesh out that concept? Is being in a niche the wrong track?
> >
> > From where I sit, yes. I'm in the aerospace industry, which is run by
> > people who don't understand software and who are intensely conservative
> > (and justifiably so). In this business, niche == dead.
>
> I work in aerospace too and the industry funds a lot of niche markets-
> look at all the funky radhard processors and custom hardware that ends
> up being used on spacecraft. While I agree people in the space racket
> are often hysterically conservative and lots of projects act more like
> cargo cults than groups of rational people, they also fund lots of
> things that would otherwise be long abandoned.
Oh, sure. They're funding *me*, and I'm fast becoming a one-man niche.
:-( But most of the niches are hardware, not software, and the hardware
niches also have a hard time getting out of the lab and into space.
> The recent evolution of missions to faster processors and bigger
> memories will open up the possiblities for very different and much
> more complicated flight code. When you don't have to count very
> nearly every cycle and shoehorn code into little bits of memory,
> something like CL becomes lots more palatable, and when you start
> raising the spectre of updating the system while in operation, quite
> attractive.
Yes, in a few years I think they will realize that they have a problem.
When they do I want to be ready with a solution. And I don't think that
just saying "Common Lisp" will do it because their response will be,
"Didn't we already try that five years ago?"
E.
···@jpl.nasa.gov (Erann Gat) writes:
> From where I sit, yes. I'm in the aerospace industry, which is run by
> people who don't understand software and who are intensely conservative
> (and justifiably so). In this business, niche == dead.
This makes no sense to me. You are in an industry with extraordinary
requirements, so it should be easy to make the case that you need
extraordinary tools. Indeed, it seems almost self-evident.
I'm in a much different sort of industry; a small startup. My argument
for using lisp is: "If you want to outcompete the herd, you can't do/use
what the herd uses: you have to be smarter and faster". Again, to me, this
is self-evident, and my managers agree with me and let me choose the
technologies on their technological merit.
Perhaps all these companies refusing to use anything but Java are all,
in essence, afraid of real competition?
In article <··············@optushome.com.au>, Alain Picard
<·······················@optushome.com.au> wrote:
> ···@jpl.nasa.gov (Erann Gat) writes:
>
> > From where I sit, yes. I'm in the aerospace industry, which is run by
> > people who don't understand software and who are intensely conservative
> > (and justifiably so). In this business, niche == dead.
>
> This makes no sense to me. You are in an industry with extraordinary
> requirements, so it should be easy to make the case that you need
> extraordinary tools. Indeed, it seems almost self-evident.
Two things that are important to understand:
First, getting something to work in space is hard. Really, really hard.
And the software is only a very small part of what makes it hard. You
almost have to build an entire technological infrastructure from the
ground up. You've got materials engineers, mechanical engineers,
electronics engineers, propulsion engineers, thermal engineers, navigation
experts (they're the ones who figure out where the spacecraft is by
measuring the doppler shift of its radio signal). You have to worry about
things that you never have to think about here on Earth, like how much
dust in on your solar panels. None of these people are software people.
That is not to say that they do not use (or even write) software, just
that software is not their primary expertise. (I can drive a car, and
even do some maintenance and modifications on it, but I'm not an
automotive engineer.)
These people are open to all sorts of wild and crazy ideas if they are
convinced that they will actually solve real problems. I was in a meeting
just the other day where someone was talking about a proposal called
"Rover on a rope". The idea is that to land a rover on Mars you hang it
underneath a propulsion module on a long rope. My knee-jerk reaction to
this was, "What a nutty idea. Why on earth would anyone want to do that?
It has to be a control nightmare. (To say nothing of the fact that it's a
silly name.)" But that's because I'm a software person, and I don't (or
didn't) know enough about how to land a rover on Mars. It turns out there
are good and sound reasons for doing it, and these reasons can be
explained in five minutes.
A non-software-person's knee-jerk reaction (or even a software person
whose training has been mainstream) to Lisp is exactly the same: "What a
nutty idea. What's with all the parentheses? (To say nothing of the fact
that it's a silly name.)" But in the case of Lisp it is not possible to
explain why it's a good idea in five minutes. The issues are much more
complex, and they defy mechanical intuition. So that's one problem.
Second, NASA is driven by fear. Our failures tend to be much more visible
than our successes, and we have much more to lose from a visible failure
than we have to gain from a less visible success, so our managers tend to
optimise not so much for success as for failure prevention. The worst
kind of failure is one that is caused by trying something new. That can
be a career killer. Imagine the scene at the board of inquiry: "You lost
a two hundred million dollar spacecraft because of this thing called
Lisp. Tell us again why you decided to use it?"
> Perhaps all these companies refusing to use anything but Java are all,
> in essence, afraid of real competition?
I think there's a lot of truth to that.
E.
On 12/14/02 10:22 AM, in article ····················@192.168.1.51, "Erann
Gat" <···@jpl.nasa.gov> wrote:
> You've got materials engineers, mechanical engineers,
> electronics engineers, propulsion engineers, thermal engineers, navigation
> experts (they're the ones who figure out where the spacecraft is by
> measuring the doppler shift of its radio signal).
So how much of the problem is that people in all these disciplines have used
C/C++ personally at some point in their education or professional life? How
much of the resistance to Lisp is really just a preference for tools that
they personally understand, or think they understand?
-----= 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! =-----
In article <······················@fastq.com>, Chris Gehlker
<·······@fastq.com> wrote:
> So how much of the problem is that people in all these disciplines have used
> C/C++ personally at some point in their education or professional life? How
> much of the resistance to Lisp is really just a preference for tools that
> they personally understand, or think they understand?
47.2%. ;-)
Seriously, I don't know how much of a factor it is, but I'm sure it's
significant. It goes beyond people's personal experience. The mainstream
mindset (which today pretty much means C/C++, Java, UML, XML and Perl)
permeates nearly every aspect of the computer world as seen from these
people's persepctive. Pick up a copy of any non-academic CS publication
(CACM, IT Week, Linux Journal, PC World). Look at the ciriculum of
Universities (at least in the US). Even MIT is teaching Java noawadays.
These people ask themselves, if Lisp is so great, why don't I hear about
it from more places than just this Erann Gat nut? Why don't more people
use it? BTW, this is a rhetorical question from them. They don't really
care what the reasons are. The only answer that can possibly satisfy them
is to find out that they are simply mistaken and that lots of people *do*
use it to good effect, and for some reason they simply haven't heard about
it. If in fact no one uses it (outside of a few research departments and
a startup in someone's garage) then it doesn't matter what the reasons
are. The market has spoken, and they accept its judgement. The fact that
Lisp is mature technology is, ironically, a liability in this regard.
If you think all this makes it sound hopeless then you're not using your
imagination. There is at least one very simple and obvious strategy that
will allow Lisp to win despite all this: repackage Lisp as something new
and try again. There may be other strategies that I haven't thought of,
and maybe someone here will come up with a bright idea as a result of this
exchange. That would be good.
Notwithstanding the Dylan experience, I believe the repackaging strategy
has good prospects of success. Bill Gates applied the same strategy to
CP/M (repackaged it as DOS), and then to MacOS (repackaged as Win95), and
made himself the richest man in the world. He's now repackaging Java as
C#, the Web as .net, and, arguably, unix as NT [1]. Whatever its chances
are, I believe they are higher than the strategy of doing nothing and
waiting for the world to come to its senses.
E.
[1] Linux can also be viewed as successful effort at repackaging unix as
itself with a different name. Just the other day I happened to be walking
past a conference room and heard a presenter say, "we should use Linux
because Linux systems are cheaper than Unix systems." What he *meant*, of
course, was that PC hardware is cheaper than Sun hardware. But the point
is that Linux and Unix are now considered two different things in people's
minds. Linux is good because it's cheap, and Unix is bad because it's
expensive.
On 12/14/02 1:57 PM, in article ····················@192.168.1.51, "Erann
Gat" <···@jpl.nasa.gov> wrote:
> There is at least one very simple and obvious strategy that
> will allow Lisp to win despite all this: repackage Lisp as something new
> and try again
I was actually thinking this when you mentioned the fact that Lisp is
mature technology works against it. My second thought was "isn't that Arc?"
-----= 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! =-----
Erann Gat wrote:
> There is at least one very simple and obvious strategy that
> will allow Lisp to win despite all this: repackage Lisp as something new
> and try again. There may be other strategies that I haven't thought of,
> and maybe someone here will come up with a bright idea as a result of this
> exchange. That would be good.
Here are my 0.02�:
* I think that quasi-standards could help Common Lisp a lot in order to
attract some new people / application domains. Sure, it's possible to do
some sophisticated stuff, for example, web applications in Common Lisp.
But it's comparatively tedious to find the good libraries, and it's
certainly not possible to do these things out of the box.
Doesn't Kent Pitman have plans to install an SRFI-like process? This
would be great.
* Another possibility is a book that describes some of the existing
libraries that go beyond the ANSI stuff. A particularly well-written
book could also provide a de-facto standard.
* I don't think that approaches like Arc or lush are very helpful,
because they break too many of Common Lisp's principles. (For example,
Arc is a Lisp-1 and lush doesn't have lexical closures.) A New Dialect
of Lisp (tm) should have a compatible core in order to enable vendors to
release new products with relatively little effort.
It's a complex task to write a good Lisp implementation - a new dialect
should head for reusing the investments and efforts made in the past two
decades in order to be successful.
* In the long run, I don't think that strict conformance to the ANSI
standard should be an absolute goal. For example, there seems to be room
for improvement wrt to the MOP, but it would break the spec to a certain
extent. (That's what I get from the book by Forman/Danforth so far -
http://makeashorterlink.com/?F546326C2. Sorry that I am a little vague
on this at the moment, but I haven't yet finished reading that book.)
The class precedence rules are also among the things that could be
fixed. Why not fix them?
Just some ideas...
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
···@jpl.nasa.gov (Erann Gat) writes:
> [...] There is at least one very simple and obvious strategy that
> will allow Lisp to win despite all this: repackage Lisp as something
> new and try again.
Do you have any concept of how this might be done? Which attributes
of Lisp make it Lisp, in your opinion?
In article <··············@key.localdomain>, Patrick W
<···········@yahoo.com.au> wrote:
> ···@jpl.nasa.gov (Erann Gat) writes:
>
> > [...] There is at least one very simple and obvious strategy that
> > will allow Lisp to win despite all this: repackage Lisp as something
> > new and try again.
>
> Do you have any concept of how this might be done?
Some concept? Yes. A fully detailed plan? No. Parts of the concept are
1) design a surface syntax that resembles a traditional syntax but maps
directly onto S-expressions. 2) Clean up a few odds and ends, 3) add
optional strong typing a la Dylan and 4) give the result a new name. The
prototype I'm working on is called Ciel (a name suggested by Kenny
Tilton). (Why not use Arc? Two reasons. One, it's not available yet and
two, it is specifically designed *not* to be mainstream, so it doesn't
serve my purpose.)
> Which attributes of Lisp make it Lisp, in your opinion?
For me the crucial feature is a representation of code as a data structure
(not necessarily a linked list) so you can do macros. This is the one
feature that Lisp has that no other language has, and it's central to the
style of programming that I think is the Right Way: raising the level of
abstraction of your language until it meets your problem, rather than
manually compiling your problem down until it meets your language.
E.
···@jpl.nasa.gov (Erann Gat) writes:
> In article <··············@key.localdomain>, Patrick W
> <···········@yahoo.com.au> wrote:
>
> > Do you have any concept of how this might be done?
>
> Some concept? Yes. A fully detailed plan? No. Parts of the
> concept are 1) design a surface syntax that resembles a traditional
> syntax but maps directly onto S-expressions. 2) Clean up a few odds
> and ends, 3) add optional strong typing a la Dylan and 4) give the
> result a new name.
>
> The prototype I'm working on is called Ciel (a name suggested by
> Kenny Tilton).
Well, best of luck to you. I've often thought that, if a new language
with all of the important attributes of Common Lisp appeared on the
scene today, seemingly out of nowhere, it would generate a lot more
excitement than the current crop of (old, tired, stale) 'innovations'
like Java and C#.
I even think that many people who regard raw S-expressions as an
obstacle to Lisp's acceptance today would be singing the praises of
this simple stroke of genius tomorrow, if only the idea could be
presented as "*new!*" and "*innovative!*". (It's far too late for
that, but using S-expressions as an 'assembly language' for an
alternative syntax might induce people to discover the riches therein.
And ditch the suface syntax. Again ;-)).
> > Which attributes of Lisp make it Lisp, in your opinion?
>
> For me the crucial feature is a representation of code as a data structure
> (not necessarily a linked list) so you can do macros. This is the one
> feature that Lisp has that no other language has, and it's central to the
> style of programming that I think is the Right Way: raising the level of
> abstraction of your language until it meets your problem, rather than
> manually compiling your problem down until it meets your language.
Too right.
I'm not very enthusiastic about popularity, myself, but seeing great
ideas dying on the vine is nothing to cheer about either. I hope you
attract some interest with Ciel.
···@jpl.nasa.gov (Erann Gat) writes:
> If you think all this makes it sound hopeless then you're not using your
> imagination. There is at least one very simple and obvious strategy that
> will allow Lisp to win despite all this: repackage Lisp as something new
> and try again. There may be other strategies that I haven't thought of,
Earlier in this thread you said your managers' first question is "Who
uses it?". With a repackaged, hence new, Lisp, you'd have even less
chance to answer this to their satisfaction.
> Notwithstanding the Dylan experience, I believe the repackaging strategy
> has good prospects of success. Bill Gates applied the same strategy to
> CP/M (repackaged it as DOS), and then to MacOS (repackaged as Win95), and
> made himself the richest man in the world. He's now repackaging Java as
> C#, the Web as .net, and, arguably, unix as NT [1]. Whatever its chances
The Dylan experience is much more relevant than the others on your
list, which are repackagings of successful, mainstream stuff.
Why would Dylan II (Ciel?) be any better off than Dylan? Even if it's
better? I'm really curious.
> are, I believe they are higher than the strategy of doing nothing and
> waiting for the world to come to its senses.
Even if you stick to Common Lisp, there are other strategies you can
follow. Build libraries, bridges to other languages, improve one of
the free implementations, etc. People are doing this, and the rest of us
find that there are less and less excuses for not using Common Lisp.
Andras
In article <···············@tarski.math.bme.hu>, ······@math.bme.hu (Simon
Andr�s) wrote:
> ···@jpl.nasa.gov (Erann Gat) writes:
>
>
> > If you think all this makes it sound hopeless then you're not using your
> > imagination. There is at least one very simple and obvious strategy that
> > will allow Lisp to win despite all this: repackage Lisp as something new
> > and try again. There may be other strategies that I haven't thought of,
>
> Earlier in this thread you said your managers' first question is "Who
> uses it?". With a repackaged, hence new, Lisp, you'd have even less
> chance to answer this to their satisfaction.
A most perceptive point. That is why I'm planning to pitch it to my
managers not as a programming language but as a spacecraft control
system. Look up SCL (Spacecraft Control Language) for an example of this
marketing tactic at work.
> > Notwithstanding the Dylan experience, I believe the repackaging strategy
> > has good prospects of success. Bill Gates applied the same strategy to
> > CP/M (repackaged it as DOS), and then to MacOS (repackaged as Win95), and
> > made himself the richest man in the world. He's now repackaging Java as
> > C#, the Web as .net, and, arguably, unix as NT [1]. Whatever its chances
>
> The Dylan experience is much more relevant than the others on your
> list, which are repackagings of successful, mainstream stuff.
>
> Why would Dylan II (Ciel?) be any better off than Dylan? Even if it's
> better? I'm really curious.
Because it won't be called Dylan. Seriously. Remember, the point here is
not (necessarily) to make something better, it's to make something new.
> > are, I believe they are higher than the strategy of doing nothing and
> > waiting for the world to come to its senses.
>
> Even if you stick to Common Lisp, there are other strategies you can
> follow. Build libraries, bridges to other languages, improve one of
> the free implementations, etc. People are doing this, and the rest of us
> find that there are less and less excuses for not using Common Lisp.
I think you may have missed some of the context of this discussion. Using
Common Lisp is not an option that is currently open to me if I want to
write software that anyone other than me is going to use. If it were I
would happily stick with it.
E.
On 12/16/02 12:08 AM, in article ····················@192.168.1.51, "Erann
Gat" <···@jpl.nasa.gov> wrote:
> A most perceptive point. That is why I'm planning to pitch it to my
> managers not as a programming language but as a spacecraft control
> system. Look up SCL (Spacecraft Control Language) for an example of this
> marketing tactic at work.
I don't think this is the best strategy for NASA but it many environments it
works to sell a new language as a prototyping system, or so I hear in
Ruby/Python discussions.
Step 1:
Tell PHB that you are making a quick prototype to validate the spec before
you start coding the real version.
Step 2:
Add requested features to the "prototype" until time/budget is exhausted.
Step 3:
When PHB asks why you can't deploy the "prototype", say with great
reluctance, "Well, I guess you could?" But for only $x and in only y months,
we can code this in Java as we planned.
At this point, PHB will realize that x and y are probably off by a factor of
at least 3 and order you to deploy the prototype.
-----= 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! =-----
From: Christopher C. Stacy
Subject: Re: type safety in LISP
Date:
Message-ID: <u1y4ifhu5.fsf@dtpq.com>
···@jpl.nasa.gov (Erann Gat) writes:
> In article <···············@tarski.math.bme.hu>, ······@math.bme.hu (Simon
> Andr�s) wrote:
>
> > Earlier in this thread you said your managers' first question is "Who
> > uses it?". With a repackaged, hence new, Lisp, you'd have even less
> > chance to answer this to their satisfaction.
>
> A most perceptive point. That is why I'm planning to pitch it to my
> managers not as a programming language but as a spacecraft control
> system. Look up SCL (Spacecraft Control Language) for an example of this
> marketing tactic at work.
If this tactic works, why don't you tell them CL stands for Control
Language :-) Stupid jokes aside, couldn't you build a real Spacecraft
Control Language on top of CL, maybe provide a prefix syntax for it so
your engineer colleagues feel comfortable with it, and sell the whole
system? (They can even rewrite it in C++ if they really want to. As
long as you can do development in CL, it shouldn't matter.) But
perhaps I'm being naive. You know these possiblities much better than
I do.
> > Why would Dylan II (Ciel?) be any better off than Dylan? Even if it's
> > better? I'm really curious.
>
> Because it won't be called Dylan. Seriously. Remember, the point here is
> not (necessarily) to make something better, it's to make something new.
I must be missing something here. From you description of your
managers, I gather that Dylan would be as new to them as Ciel. Not to
mention that I see conflicting requirements here: they need something
that is both new and extensively used? Or do they want new _systems_
in estabilished languages? Even then, I don't see how a new/repackaged
Lisp (a language) would help.
> > Even if you stick to Common Lisp, there are other strategies you can
> > follow. Build libraries, bridges to other languages, improve one of
> > the free implementations, etc. People are doing this, and the rest of us
> > find that there are less and less excuses for not using Common Lisp.
>
> I think you may have missed some of the context of this discussion. Using
> Common Lisp is not an option that is currently open to me if I want to
> write software that anyone other than me is going to use. If it were I
> would happily stick with it.
Indeed, I may have. I thought the reason why CL was not an option for
you is its small market share. And that is what you can help change by
the above strategies. Or so I believe.
Andras
In article <···············@tarski.math.bme.hu>, ······@math.bme.hu (Simon
Andr�s) wrote:
> ···@jpl.nasa.gov (Erann Gat) writes:
>
> > In article <···············@tarski.math.bme.hu>, ······@math.bme.hu (Simon
> > Andr�s) wrote:
> >
> > > Earlier in this thread you said your managers' first question is "Who
> > > uses it?". With a repackaged, hence new, Lisp, you'd have even less
> > > chance to answer this to their satisfaction.
> >
> > A most perceptive point. That is why I'm planning to pitch it to my
> > managers not as a programming language but as a spacecraft control
> > system. Look up SCL (Spacecraft Control Language) for an example of this
> > marketing tactic at work.
>
> If this tactic works, why don't you tell them CL stands for Control
> Language :-) Stupid jokes aside, couldn't you build a real Spacecraft
> Control Language on top of CL, maybe provide a prefix syntax for it so
> your engineer colleagues feel comfortable with it, and sell the whole
> system? (They can even rewrite it in C++ if they really want to. As
> long as you can do development in CL, it shouldn't matter.) But
> perhaps I'm being naive. You know these possiblities much better than
> I do.
That is more or less my strategy. I'm prototyping in CL, but I'm pretty
sure that I won't be able to sell the prototype because, as I said, I'm
not dealing with idiots. If there's actual Common Lisp underneath they
will eventually find out, and if I they find out and I didn't tell them
that up front then my credibility is toast. I would love to be proven
wrong about this, though.
> I must be missing something here. From you description of your
> managers, I gather that Dylan would be as new to them as Ciel.
New to them, yes, but not new to the world, and they will eventually find
this out. Also, the state of Dylan seems to be even sorrier than the
state of Common Lisp. Dylan has been around for how many years now? And
who uses it? Even the one commercial vendor of Dylan compilers (that fact
alone is enough to kill the idea) doesn't use Dylan for its own web site.
At least Franz uses Allegroserve to run franz.com.
I have not actually tried to pitch Dylan in a serious way, so I could be
wrong about this, but I doubt it. I've floated a few trial balloons for
Eiffel to no effect.
> Not to
> mention that I see conflicting requirements here: they need something
> that is both new and extensively used? Or do they want new _systems_
> in estabilished languages? Even then, I don't see how a new/repackaged
> Lisp (a language) would help.
The best thing is to be old and widely used with a good track record. The
next best thing is to be old and widely used with a track record that can
be plausibly defended as good even if it isn't (e.g. C++, Java). Having
lots of people still using it is enough for a plausible argument of
goodness. The next best thing is to be new. That's not really a good
thing, but it will at least get you a shot at a fair hearing. The
second-to-worst situation is to be old and not widely used. That's not
quite a death sentence, but it's a really tough hole to dig yourself out
of. The worst situation is to be old and to be perceived as the cause of
a major failure. Lisp is somewhere in between the last two situations.
It's old, not widely used, and widely perceived to be the cause of a
failure, though not a major one.
BTW, note that WRT failure what matters is perception, not reality. It
doesn't matter whether you were in fact the cause of a failure (or even if
there really was a failure). The perception is enough. This can cut both
ways. In the early 90's there was a demonstration of rover technology
(the Mars Science Microrover) that was in fact a failure but was widely
perceived to be a success. The result of that perception was a green
light for the Pathfinder mission. (This is all documented in Donna
Shirley's book.)
Yes, it's twisted. No, it's not how it should be. And some day when they
make me Lab Director (ha!) I'll change it. Until then I have no choice
but to deal with it as best I can.
> Indeed, I may have. I thought the reason why CL was not an option for
> you is its small market share. And that is what you can help change by
> the above strategies. Or so I believe.
Small market share is only one of many contributing factors.
E.
In article <····················@192.168.1.51>, Erann Gat wrote:
> That is more or less my strategy. I'm prototyping in CL, but
> I'm pretty sure that I won't be able to sell the prototype
> because, as I said, I'm not dealing with idiots.
To remind you of the obvious -- eventually, they may well read
this conversation. :)
-- Larry
p.s. Apologies for the below add-on. My ISP has contracted with
newsfeeds.com to do their news system. *sigh*
-----= 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! =-----
In article <·············@127.0.0.1>, Larry Clapp <·····@theclapp.org> wrote:
> In article <····················@192.168.1.51>, Erann Gat wrote:
> > That is more or less my strategy. I'm prototyping in CL, but
> > I'm pretty sure that I won't be able to sell the prototype
> > because, as I said, I'm not dealing with idiots.
>
> To remind you of the obvious -- eventually, they may well read
> this conversation. :)
I know, but I'm not sure why you would point that out. (Perhaps you
missed the word "not"?)
E.
In article <····················@k-137-79-50-101.jpl.nasa.gov>, Erann Gat wrote:
> In article <·············@127.0.0.1>, Larry Clapp <·····@theclapp.org> wrote:
>> In article <····················@192.168.1.51>, Erann Gat wrote:
>> > That is more or less my strategy. I'm prototyping in CL,
>> > but I'm pretty sure that I won't be able to sell the
>> > prototype because, as I said, I'm not dealing with idiots.
>>
>> To remind you of the obvious -- eventually, they may well read
>> this conversation. :)
>
> I know, but I'm not sure why you would point that out.
> (Perhaps you missed the word "not"?)
No, not (*cough*) at all. In some way difficult to clarify, it
just seemed vaguely amusing to me that you might someday propose
a big project or make a big presentation with your "new" language
or system or whatever, the design and evolution of which you've
perhaps patiently elaborated here on cll, and one of your
audience members (who's Googled for your name and read the last N
years of your cll posts) stands up and does his best Monty Python
impression of "It's a Lisp!"[1].
Sorry for the silliness. :)
-- Larry
p.s. 'Pon further consideration, though, you could then continue
with, "It is not a Lisp, it is *not* a Lisp!" "But it's dressed
that way." "*They* dressed it up like this! And those aren't
its parentheses, they're false ones!" Etc ...
[1] http://bau2.uibk.ac.at/sg/python/Scripts/HolyGrail/grail-05.html
-----= 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! =-----
In article <·············@127.0.0.1>, Larry Clapp <·····@theclapp.org> wrote:
> In article <····················@k-137-79-50-101.jpl.nasa.gov>, Erann
Gat wrote:
> > In article <·············@127.0.0.1>, Larry Clapp <·····@theclapp.org>
wrote:
> >> In article <····················@192.168.1.51>, Erann Gat wrote:
> >> > That is more or less my strategy. I'm prototyping in CL,
> >> > but I'm pretty sure that I won't be able to sell the
> >> > prototype because, as I said, I'm not dealing with idiots.
> >>
> >> To remind you of the obvious -- eventually, they may well read
> >> this conversation. :)
> >
> > I know, but I'm not sure why you would point that out.
> > (Perhaps you missed the word "not"?)
>
> No, not (*cough*) at all. In some way difficult to clarify, it
> just seemed vaguely amusing to me that you might someday propose
> a big project or make a big presentation with your "new" language
> or system or whatever, the design and evolution of which you've
> perhaps patiently elaborated here on cll, and one of your
> audience members (who's Googled for your name and read the last N
> years of your cll posts) stands up and does his best Monty Python
> impression of "It's a Lisp!"[1].
I just finished a conversation with a colleague in which I mentioned that
I was going to use S-expressions for something (not related to this
discussion). He said, "Oh, you shouldn't use S-expressions. You should
use XML syntax and DTD's." But as has been often observed (and
occasionally lamented) here, XML syntax *is* S-expressions, modulo a
little parser tweaking. Despite this, XML is perceived as good, while
S-expressions are perceived as bad. It would be completely untenable for
someone to object to XML on the grounds that "it's an S-expression." (For
one thing, most of the people who realize that XML syntax is S-expressions
think that S-expressions are a good thing.)
Sure, it's a Lisp. But stretch the meaning of the word "a" far enough and
*everything* is a Lisp, except C++, which is a Fortran. :-)
E.
···@jpl.nasa.gov (Erann Gat) writes:
> I just finished a conversation with a colleague in which I mentioned that
> I was going to use S-expressions for something (not related to this
> discussion). He said, "Oh, you shouldn't use S-expressions. You should
> use XML syntax and DTD's." But as has been often observed (and
> occasionally lamented) here, XML syntax *is* S-expressions, modulo a
> little parser tweaking.
And a lot of extra noise and machinery.
You could write the s-expressions then type C-M-q to validate them, or
you could write the XML, write the DTD, get the DTD through the DTD
parser, and run the XML through a validating parser.
Then, of course, you want to manipulate the structure. I suggest you
put on your best poker face and suggest using the Perl bindings to
Xerces. I bet you a nickel that this suggestion is met with instant
approval.
* Simon Andr�s wrote:
> If this tactic works, why don't you tell them CL stands for Control
> Language :-) Stupid jokes aside, couldn't you build a real Spacecraft
> Control Language on top of CL, maybe provide a prefix syntax for it so
> your engineer colleagues feel comfortable with it, and sell the whole
> system? (They can even rewrite it in C++ if they really want to. As
> long as you can do development in CL, it shouldn't matter.) But
> perhaps I'm being naive. You know these possiblities much better than
> I do.
Yurr, you could use a syntax like, erm:
<define-function name='foo' arglist='(x y z)'>
<plus><x/><y/><z/></plus></define-function>
Now they pretty much have to use it because it's XML, which is, as we
all know, the solution to any problem whatsoever. Just think: a
fully-fledged OO programming language with a syntax that's so
trivially different than XML (yet, much easier to use), but *still*
people rail against the syntax. What do we have to do to make them
shut up?
--tim (:-)
Tim Bradshaw <···@cley.com> writes:
> Yurr, you could use a syntax like, erm:
>
> <define-function name='foo' arglist='(x y z)'>
> <plus><x/><y/><z/></plus></define-function>
You think you can get away with arglist='(x y z)' :-) At the very least,
it should be
<arguments>
<argument name="x" type="double-float"/>
<argument name="y" type="double-float"/>
<argument name="z" type="double-float"/>
</arguments>
(this thread is about type safety, after all).
Andras
Tim Bradshaw <···@cley.com> writes:
> Yurr, you could use a syntax like, erm:
>
> <define-function name='foo' arglist='(x y z)'>
> <plus><x/><y/><z/></plus></define-function>
>
> Now they pretty much have to use it because it's XML, which is, as we
> all know, the solution to any problem whatsoever.
It is not nice to try and actively sabotage the space program. It is in
humanity's interest that we reach the stars ;-).
--
Cheers, The Rhythm is around me,
The Rhythm has control.
Ray Blaak The Rhythm is inside me,
·····@telus.net The Rhythm has my soul.
From: Pascal Costanza
Subject: Re: type safety in LISP
Date:
Message-ID: <3DFDDE11.700@web.de>
Simon Andr�s wrote:
>>>Why would Dylan II (Ciel?) be any better off than Dylan? Even if it's
>>>better? I'm really curious.
>>
>>Because it won't be called Dylan. Seriously. Remember, the point here is
>>not (necessarily) to make something better, it's to make something new.
>
>
> I must be missing something here. From you description of your
> managers, I gather that Dylan would be as new to them as Ciel. Not to
> mention that I see conflicting requirements here: they need something
> that is both new and extensively used? Or do they want new _systems_
> in estabilished languages? Even then, I don't see how a new/repackaged
> Lisp (a language) would help.
This is not how the American capitalist culture works. Either something
is old and widely used, or it is new, perhaps in some superficial way,
and "experts" say it's gonna be the next big thing.
(let ((*irony* t))
Something that's old and not widely used
is bad by definition, isn't it?!?)
Java was successful, because they said they had only incorporated the
best bits of various influences. A designer of a New Dialect of Lisp
(tm) should claim to have found the bits in Common Lisp that made it
unsuccessful, and to have eliminated those bits. (And of course, he/she
should also claim to have incorporated some wonderful new stuff.) In
these post-modern times, it doesn't matter wether these claims are
justified or not.
Pascal
--
Pascal Costanza University of Bonn
···············@web.de Institute of Computer Science III
http://www.pascalcostanza.de R�merstr. 164, D-53117 Bonn (Germany)
Pascal Costanza <········@web.de> writes:
> This is not how the American capitalist culture works. Either something
> is old and widely used, or it is new, perhaps in some superficial way,
> and "experts" say it's gonna be the next big thing.
You're right, I'm afraid :-(
Though NASA may (should?) not be a typical representative of American
capitalist culture.
Andras
From: Eduardo Muñoz
Subject: Re: type safety in LISP
Date:
Message-ID: <uel8kb5nc.fsf@jet.es>
···@jpl.nasa.gov (Erann Gat) writes:
> Second, NASA is driven by fear. Our failures tend to be much more visible
> than our successes, and we have much more to lose from a visible failure
> than we have to gain from a less visible success, so our managers tend to
> optimise not so much for success as for failure prevention. The worst
> kind of failure is one that is caused by trying something new. That can
> be a career killer. Imagine the scene at the board of inquiry: "You lost
> a two hundred million dollar spacecraft because of this thing called
> Lisp. Tell us again why you decided to use it?"
Maybe sending lisp to the space is not a good idea
after all, but here is an idea for you.
Parallel development. The "Real" team will develop
the program that will be used in the spacecraft,
the "Verification" team will develop an equivalent
program using the same general architecture and
test cases.
Given that one of the strengths of lisp is fast
developement you should have a team 1/5 (or 1/10)
the size of the "Real" team. You should also
emulate any 3rd-party components so they can be
validated too. For big projects you could develop
in parallel only the modules wich have the highest
return/investment ratio (the idea is to have a
fixed ceiling for verification cost). You can
generate random (within a range) input to see if
the parallel components have the same output (and
if no, why not)
This has a number of selling points: reduced risk,
some concepts could be verified (tried) before "Real"
(expensive) coding is done, if the "Real" team
finds a bottleneck the "Verification" team (faster
development) can explore alternative solutions,
some of the flawed requirements of size, speed of
hardware (or budget) of the "Real" team can be
conterclaimed, ...
Take this "cum grano salis", I know next to
nothing about NASA after all :)
--
Eduardo Mu�oz
"Eduardo Mu�oz" <···@jet.es> wrote in message ··················@jet.es...
> Maybe sending lisp to the space is not a good idea
> after all, but here is an idea for you.
> Parallel development. The "Real" team will develop
> the program that will be used in the spacecraft,
> the "Verification" team will develop an equivalent
> program using the same general architecture and
> test cases.
> Given that one of the strengths of lisp is fast
> developement you should have a team 1/5 (or 1/10)
> the size of the "Real" team. You should also
> emulate any 3rd-party components so they can be
> validated too. For big projects you could develop
> in parallel only the modules wich have the highest
> return/investment ratio (the idea is to have a
> fixed ceiling for verification cost). You can
> generate random (within a range) input to see if
> the parallel components have the same output (and
> if no, why not)
> This has a number of selling points: reduced risk,
> some concepts could be verified (tried) before "Real"
> (expensive) coding is done, if the "Real" team
> finds a bottleneck the "Verification" team (faster
> development) can explore alternative solutions,
> some of the flawed requirements of size, speed of
> hardware (or budget) of the "Real" team can be
> conterclaimed, ...
Or an alternative approach could be,
Find a project which is in difficulty at JPL, from
the sounds of it it is not difficult. Also if possible choose a troubled
project whose Manager is the "get the job done" type. Approach
the Manager and say that you are working on a study of alternate
software development and that you wish to attempt implementing
the same project in parallel. If the Manager insists on knowing what
the language and methodology are, appeal to the "double blind"
nature of the study and you cannot reveal the details. Then
spend "your own time" on the writing a Lisp version of the project.
Hopefully the Manager will cooperate and provide all the
technical specs and references needed. Co-opt other Lispers
(I am sure you can get some volunteers) into helping. The minimal benefits
are that you will get a greater understanding of the engineering
involved in using Lisp (experience) and a maximal benefit in that
if the project fails and the Lisp version works that they may
consider using it instead. Just stay out of the actual team's way
and do not push this alternate as a replacement. Just
show some results, let the manager put two and two together.
Wade
* Erann Gat wrote:
> First, getting something to work in space is hard. Really, really hard.
> And the software is only a very small part of what makes it hard.
This is something that I thought about after writing my other article
in this thread. One question that occurs to me is that space is very
expensive indeed. How much of the cost of doing something (other than
something, ehem, mundane like a TV satellite or something) in space is
software? If it's a fairly small fraction of the cost, wouldn't this
be an ideal (and rare) chance to do some kind of competitive thing,
and play off various languages and implementation strategies? If Lisp
is actually any good, it should win here!
--tim
In article <···············@cley.com>, Tim Bradshaw <···@cley.com> wrote:
> * Erann Gat wrote:
>
> > First, getting something to work in space is hard. Really, really hard.
> > And the software is only a very small part of what makes it hard.
>
> This is something that I thought about after writing my other article
> in this thread. One question that occurs to me is that space is very
> expensive indeed. How much of the cost of doing something (other than
> something, ehem, mundane like a TV satellite or something) in space is
> software?
The software per se is a significant but not overwhelming fraction of the
total cost of mission development, like 10-20% or so (I think -- this is
off the top of my head at midnight on a Saturday. I could be off quite a
bit.) The real killer is operations cost. Keeping a spacecraft running
currently takes a small army of ground controllers. Operations are made
more difficult by the fact that the software tends to be brittle and hard
to use. If the software were better then operations costs could be
reduced, and I think that's really the big win. Of course, getting
development costs down wouldn't hurt either.
> If it's a fairly small fraction of the cost, wouldn't this
> be an ideal (and rare) chance to do some kind of competitive thing,
> and play off various languages and implementation strategies? If Lisp
> is actually any good, it should win here!
I don't think competition is the way to go. It was tried in the early
90's to decide between two competing approaches to writing software for
rovers. The result was a bloody turf battle, and the departure of half a
dozen of the brightest people ever to work at JPL (Lisp programmers all).
I don't want to live through that again. You don't really win by making
people in your own organization look bad, even if you don't agree with
them.
E.
* Erann Gat wrote:
> I don't think competition is the way to go. It was tried in the early
> 90's to decide between two competing approaches to writing software for
> rovers. The result was a bloody turf battle, and the departure of half a
> dozen of the brightest people ever to work at JPL (Lisp programmers all).
> I don't want to live through that again. You don't really win by making
> people in your own organization look bad, even if you don't agree with
> them.
Well, I think that this itself indicates something bad (but common,
alas). The issue should be about whether languages or systems look
bad, not whether people look bad. If programmers are getting so
emotionally attached to their tools that they can't cope with losing
(or feel that they need to destroy the `losers' when they `win') then
there is a large problem, because you can never trust anything these
people say, since they are so emotionally involved.
It seems to me that what you want (and what NASA is probably rather
rare in being able to afford) is some way of making a *technical*
choice among languages or systems. I don't really know how one would
do this, but, given the sad state of the rest of the SW industry, I
don't think `looking at what they do' is a good answer - you'd be
flying Windows, Visual Basic and Perl in that case.
I don't really have any other suggestions then: I think you are likely
doomed to endless turf wars and irrationality.
--tim
On 15 Dec 2002 14:54:42 +0000, Tim Bradshaw <···@cley.com> wrote:
> choice among languages or systems. I don't really know how one would
> do this, but, given the sad state of the rest of the SW industry, I
> don't think `looking at what they do' is a good answer - you'd be
> flying Windows, Visual Basic and Perl in that case.
This actually already happened. DOS, and later Windows, were the operating
systems of laptops used at least by MIR cosmonauts and Shuttle astronauts,
and probably also on ISS. Even a shareware DOS application, the CompuShow
image viewing software, was used in space by Shuttle astronauts. Those
laptops are usually stock IBM ThinkPads with ordinary RAM replaced by
better error correction chips.
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://www.paoloamoroso.it/ency/README
···@jpl.nasa.gov (Erann Gat) writes:
> Two things that are important to understand:
> First, getting something to work in space is hard. Really, really hard.
You don't have to tell me that, I have a PhD in Astronomy from
Caltech; 5 miles down the road from JPL. Not only do I believe you, I
think you guys [basically, anyone involved in getting anything to work
in space] are truly heroic. I'm forever amazed that you can get _any_
mission to succeed. Getting stuff to work on the ground is hard
enough. Up there!? [shakes head incredulously].
But you know what? That's because you guys ARE the "rocket scientists".
After all, that's where the expression came from, isn't it? So if management
doesn't trust the rocket scientists to make the right technical decisions,
be it hardware or software, I'd say the space program is utterly screwed.
> Second, NASA is driven by fear. Our failures tend to be much more visible
> than our successes,
Now we're talking. NASA has had its great successes (man on the moon, voyager, etc)
so in some sense from now on it's a lose-lose situation. You've picked the cherries,
and it's not clear that there is now a real goal and vision (and political support)
behind space exploration. These, not lisp, are the reasons for NASA's woes.
So Lisp ends up being a spacegoat. Something needs to get the bad rap; fine,
that's political reality. But I think trying to change Lisp itself to get it back
in through the back door is misguided, because, as you'll no doubt agree, there's
nothing wrong with Lisp /per se/ which needs fixing.
> Imagine the scene at the board of inquiry: "You lost
> a two hundred million dollar spacecraft because of this thing called
> Lisp. Tell us again why you decided to use it?"
Well, you know what Frank Boreman told the board of inquiry after Apollo 1.
The reality is that space is insanely hard and insanely dangerous. Thinking
that you can say: "Lisp! That's the problem! Get rid of it, and all will be OK"
is idiotic. I'm sure NASA management is not that stupid, and, if they are, well,
you'll never have another successful mission anyway, so it doesn't matter.
> Tell us again why you decided to use it?"
So the answer is: because it was the best tool for the job. You don't
trust us? Get some better rocket scientists. If I was an american
voter, I'd vote for the rocket scientists, not for the fearful CYA
managers.
Well, if nothing else, you now know that my na�vet� and idealism know no bounds.
FWIW, I don't know if you were right or wrong to push Lisp at JPL, I
wasn't there. But you got something to fly, and I view your
accomplishments with the deepest admiration I can muster.
To repeat your words:
> Our failures tend to be much more visible than our successes,
That may be true to someone who doesn't think about it very long or
very deeply, but I think the track record of NASA makes it the most
successful human enterprise ever, period. The risks were great, and
the payoffs even greater. Even if NASA never gets _anything_ right
again, it will have expanded the horizons of human thought in ways
which we will never be able to repay.
In article <··············@optushome.com.au>, Alain Picard
<·······················@optushome.com.au> wrote:
[Overly generous complements snipped]
On behalf of all my colleagues I thank you for the kind words.
> So if management
> doesn't trust the rocket scientists to make the right technical decisions,
> be it hardware or software, I'd say the space program is utterly screwed.
Of course they trust the rocket scientists. Trouble is that the rocket
scientists understand rocket science and not computer science. (The real
rocket scientists don't understand why we don't just do everything in
Fortran.) Then you get the electronics engineers who want to do
everything in C. Then you got your Java faction and your C++ faction.
And then there's me.
> But I think trying to change Lisp itself to get it back
> in through the back door is misguided, because, as you'll no doubt
agree, there's
> nothing wrong with Lisp /per se/ which needs fixing.
Actually, I don't agree with that. If I had my druthers there are a few
things I'd change. (For those who care, I like first-class environments,
what in T were called locales. Common Lisp doesn't have them, and the
result is that packages and dynamic binding are a mess. This is just my
opinion.)
> > Tell us again why you decided to use it [Lisp]?"
> So the answer is: because it was the best tool for the job. You don't
> trust us? Get some better rocket scientists.
They did. They got themselves a bunch of C++ people, who I often see
walking by in the halls with glum expressions on their faces nowadays.
These guys are trying to do some really hard stuff, and I think they're
going to hit a wall. If they don't, that's great. But if they do I would
like to be there ready with a solution that is both technically and
politically tenable.
E.
On Sun, 15 Dec 2002 13:25:07 +1100, Alain Picard
<·······················@optushome.com.au> wrote:
> Well, you know what Frank Boreman told the board of inquiry after Apollo 1.
^^^^^^^
Borman
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://www.paoloamoroso.it/ency/README
Alain Picard wrote:
> Perhaps all these companies refusing to use anything but Java are all,
> in essence, afraid of real competition?
What they're actually afraid of is not having lack of working software as a
scapegoat when their unrealistic business models come crashing to the
ground or (even worse) having the flaws in their concepts pointed out by
the software (as often happens).
faa
* Alain Picard
| Perhaps all these companies refusing to use anything but Java are
| all, in essence, afraid of real competition?
Perhaps they are mortally afraid of betting their money on the
competence of their programmers?
--
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.
Erik Naggum <····@naggum.no> writes:
> * Alain Picard
> | Perhaps all these companies refusing to use anything but Java are
> | all, in essence, afraid of real competition?
>
> Perhaps they are mortally afraid of betting their money on the
> competence of their programmers?
Heh. The way they treat them [their hordes of java programmers], they
probably ought to be.
"Wade Humeniuk" <····@nospam.nowhere> writes:
> "Erann Gat" <···@jpl.nasa.gov> wrote in message
> ·························@k-137-79-50-101.jpl.nasa.gov...
> > So, do I have some faith that Lisp is on the right track? I don't know.
> > It certainly *was* on the right track, but now it seems to me to be
> > sitting on a siding. To me, being on the right track is less important
> > than simply getting the Lisp train rolling again.
>
> What is the right track? This is a serious question. Perhaps you
> could flesh out that concept? Is being in a niche the wrong track?
My own interpretation of Erann's viewpoint about Lisp's "track" is that it
is a local one - there is a specific and localized dislike of Lisp at
JPL (and perhaps in a portion of the space community) and that is precisely
what I think "getting off track" means here. So of course, "getting back
on the right track" means fixing this perception problem with the space
community. <shameless-plug-for-ALU> It may be a hard job, but I think
we are starting to become poised to do this, if we can work together
</shameless-plug-for-ALU>
> > If you think the Lisp train is rolling, then help me answer this question
> > that my managers ask me whenever I bring the subject up: who uses it?
>
> JPL does (or did). Is that not good enough? Your Lisp projects at JPL
> were a success.
No, it's not good enough; his Lisp projects at JPL were _not_ a success.
We need to be careful not to make the mistake of couching our definition
of success in the technical realm only, because that is what has always
gotten Lisp into trouble. It is precisely the arrogance we have (I
include myself in this) of thinking that Lisp's technical superiority
automatically makes it successful, or _should_ make it successful, that
eventually makes us blind to other aspects of success and failure, including
timliness, out-and-out politics, prejudice, NIH, and other factors. We
must take _all_ factors into consideration when viewing a project as a
success or not, and work on our weak areas.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
In article <·············@beta.franz.com>, Duane Rettig <·····@franz.com> wrote:
> My own interpretation of Erann's viewpoint about Lisp's "track" is that it
> is a local one - there is a specific and localized dislike of Lisp at
> JPL (and perhaps in a portion of the space community) and that is precisely
> what I think "getting off track" means here. So of course, "getting back
> on the right track" means fixing this perception problem with the space
> community. <shameless-plug-for-ALU> It may be a hard job, but I think
> we are starting to become poised to do this, if we can work together
> </shameless-plug-for-ALU>
Yes, except that this prejudice seems to extend far beyond the space
community. I have three first-hand data points: JPL, Google, and a
financial firm where I'm doing some consulting. All three of them were
(are) vehemently anti-lisp. Actually, it's not so much anti-lisp as
anti-anything-that-isn't-mainstream.
> > JPL does (or did). Is that not good enough? Your Lisp projects at JPL
> > were a success.
>
> No, it's not good enough; his Lisp projects at JPL were _not_ a success.
> We need to be careful not to make the mistake of couching our definition
> of success in the technical realm only, because that is what has always
> gotten Lisp into trouble. It is precisely the arrogance we have (I
> include myself in this) of thinking that Lisp's technical superiority
> automatically makes it successful, or _should_ make it successful, that
> eventually makes us blind to other aspects of success and failure, including
> timliness, out-and-out politics, prejudice, NIH, and other factors. We
> must take _all_ factors into consideration when viewing a project as a
> success or not, and work on our weak areas.
Yes, exactly. Thanks, Duane, for saying this so much better than I can.
E.
"Erann Gat" <···@jpl.nasa.gov> wrote in message
·························@k-137-79-50-101.jpl.nasa.gov...
> In article <·············@beta.franz.com>, Duane Rettig <·····@franz.com>
wrote:
>
> > > JPL does (or did). Is that not good enough? Your Lisp projects at
JPL
> > > were a success.
> >
> > No, it's not good enough; his Lisp projects at JPL were _not_ a success.
> > We need to be careful not to make the mistake of couching our definition
> > of success in the technical realm only, because that is what has always
> > gotten Lisp into trouble. It is precisely the arrogance we have (I
> > include myself in this) of thinking that Lisp's technical superiority
> > automatically makes it successful, or _should_ make it successful, that
> > eventually makes us blind to other aspects of success and failure,
including
> > timliness, out-and-out politics, prejudice, NIH, and other factors. We
> > must take _all_ factors into consideration when viewing a project as a
> > success or not, and work on our weak areas.
>
> Yes, exactly. Thanks, Duane, for saying this so much better than I can.
>
[useless "me too!" post follows]
I agree, that was very well put...should be pinned on a wall here, somewhere
;)
--
Coby Beck
(remove #\Space "coby 101 @ bigpond . com")
"Duane Rettig" <·····@franz.com> wrote in message ··················@beta.franz.com...
> "Wade Humeniuk" <····@nospam.nowhere> writes:
> >
> > JPL does (or did). Is that not good enough? Your Lisp projects at JPL
> > were a success.
>
> No, it's not good enough; his Lisp projects at JPL were _not_ a success.
> We need to be careful not to make the mistake of couching our definition
> of success in the technical realm only, because that is what has always
> gotten Lisp into trouble. It is precisely the arrogance we have (I
> include myself in this) of thinking that Lisp's technical superiority
> automatically makes it successful, or _should_ make it successful, that
> eventually makes us blind to other aspects of success and failure, including
> timliness, out-and-out politics, prejudice, NIH, and other factors. We
> must take _all_ factors into consideration when viewing a project as a
> success or not, and work on our weak areas.
But my statement that the Lisp projects at JPL were successful is
mostly political. Its the perception and statments made about those
projects that my statement is meant to counteract. IF you support
something like Lisp, do a good job and THEN accept criticism,
and even voice it back then you are contributing to the negative
politics about Lisp. When I read Eran's accounts of using Lisp
at JPL, I could see nothing but success. He
got the jobs done, quickly, on-time, within requirements. It
was a little confusing to see him say that they were not
successful. My only conclusion so far is that he was
politically jumped on and (sadly) it seems he has accepted
much of that beating as his fault (or Lisp's fault). It's gotta
wear anybody down and my statement is meant as an attempt
at compassion to pull a bad situation out of the fire by not
giving into the negative rhetoric.
What I think the problem is that people who use Lisp are more aware of
trade-offs and problems in computing and are more upfront
with admitting the problems that occurs with any software
development. They accept the criticisms too easily and do
not voice enough positive statments in response.
Wade
In article <·······················@news2.telusplanet.net>, "Wade
Humeniuk" <····@nospam.nowhere> wrote:
> But my statement that the Lisp projects at JPL were successful is
> mostly political. Its the perception and statments made about those
> projects that my statement is meant to counteract. IF you support
> something like Lisp, do a good job and THEN accept criticism,
> and even voice it back then you are contributing to the negative
> politics about Lisp. When I read Eran's accounts of using Lisp
> at JPL, I could see nothing but success. He
> got the jobs done, quickly, on-time, within requirements.
But those are all technical and managerial criteria, not political ones.
> It was a little confusing to see him say that they were not
> successful. My only conclusion so far is that he was
> politically jumped on and (sadly) it seems he has accepted
> much of that beating as his fault (or Lisp's fault).
Actually, Wade, I blame you personally.
;-) ;-) ;-)
Seriously, I don't blame myself (I'm actually very proud of my role in
getting Lisp into space, and there's very little I would change if I had
it to do over again) and I don't blame Lisp. I don't blame anyone (with
one very narrow exception). Shit happens. The management giveth, and the
management taketh away. :-)
I'm not agitating for change because I'm bitter, I'm agitating for change
because I have a problem to solve and I think change is necessary to solve
it. That's the long and the short of it.
> It's gotta
> wear anybody down and my statement is meant as an attempt
> at compassion to pull a bad situation out of the fire by not
> giving into the negative rhetoric.
I appreciate that. There's always a fine line to walk between positive
and negative feedback. Too much positive feedback and people get
complacent. Too much negative feedback and people get discouraged. It
takes the right balance to keep people motivated. (Gat's First Law at
work.) From what I see in the Lisp community things are tilted too far
towards the positive-feedback/complacent side of the scale, because
negative feedback from outsiders is forcefully rejected. My hope is that
I'm enough of an insider that I won't be beaten off with a stick (because
if I get drummed out of the Lisp community I'll have to go learn Haskell
or something equally distasteful ;-) ;-) ;-)
(Goodness, I'm in a mood today.)
E.
"Erann Gat" <···@jpl.nasa.gov> wrote in message
·························@k-137-79-50-101.jpl.nasa.gov...
> In article <·······················@news2.telusplanet.net>, "Wade
> Humeniuk" <····@nospam.nowhere> wrote:
>
> > But my statement that the Lisp projects at JPL were successful is
> > mostly political. Its the perception and statments made about those
> > projects that my statement is meant to counteract. IF you support
> > something like Lisp, do a good job and THEN accept criticism,
> > and even voice it back then you are contributing to the negative
> > politics about Lisp. When I read Eran's accounts of using Lisp
> > at JPL, I could see nothing but success. He
> > got the jobs done, quickly, on-time, within requirements.
>
> But those are all technical and managerial criteria, not political ones.
>
Really??? Name a political criteria. I will try one, getting your
fellow workers to accept Lisp as a viable programming language?
> > It was a little confusing to see him say that they were not
> > successful. My only conclusion so far is that he was
> > politically jumped on and (sadly) it seems he has accepted
> > much of that beating as his fault (or Lisp's fault).
>
> Actually, Wade, I blame you personally.
>
> ;-) ;-) ;-)
In the end they will all blame the devil, oops..., I mean Wade.
Wade
"Duane Rettig" <·····@franz.com> wrote in message ··················@beta.franz.com...
> No, it's not good enough; his Lisp projects at JPL were _not_ a success.
> We need to be careful not to make the mistake of couching our definition
> of success in the technical realm only, because that is what has always
> gotten Lisp into trouble. It is precisely the arrogance we have (I
> include myself in this) of thinking that Lisp's technical superiority
> automatically makes it successful, or _should_ make it successful, that
> eventually makes us blind to other aspects of success and failure, including
> timliness, out-and-out politics, prejudice, NIH, and other factors. We
> must take _all_ factors into consideration when viewing a project as a
> success or not, and work on our weak areas.
I am really trying to get my head around what you are saying. Are you
saying financial success and the prestige of working on "important"
projects? You do not seem to be talking about success of Lisp but
success with Lisp.
It seems to be the essence of the American definition of success. Competition,
eating your young and weak. I worked for a small company up here
in Canada with some American clients. The boss sat us all down and said,
"Don't make any mistakes with our clients, they will use it against us". And
you know, they did, they would rub the mistakes right in our faces. Good
thing my ego was not dependent on their approval.
Wade
"Wade Humeniuk" <····@nospam.nowhere> writes:
> "Duane Rettig" <·····@franz.com> wrote in message ··················@beta.franz.com...
> > No, it's not good enough; his Lisp projects at JPL were _not_ a success.
> > We need to be careful not to make the mistake of couching our definition
> > of success in the technical realm only, because that is what has always
> > gotten Lisp into trouble. It is precisely the arrogance we have (I
> > include myself in this) of thinking that Lisp's technical superiority
> > automatically makes it successful, or _should_ make it successful, that
> > eventually makes us blind to other aspects of success and failure, including
> > timliness, out-and-out politics, prejudice, NIH, and other factors. We
> > must take _all_ factors into consideration when viewing a project as a
> > success or not, and work on our weak areas.
>
>
> I am really trying to get my head around what you are saying. Are you
> saying financial success and the prestige of working on "important"
> projects? You do not seem to be talking about success of Lisp but
> success with Lisp.
You're asking what my definition of suceess is. I never stated it. In
fact, my point was not to define what success _is_, but what it is _not_.
> It seems to be the essence of the American definition of success. Competition,
> eating your young and weak. I worked for a small company up here
> in Canada with some American clients. The boss sat us all down and said,
> "Don't make any mistakes with our clients, they will use it against us". And
> you know, they did, they would rub the mistakes right in our faces. Good
> thing my ego was not dependent on their approval.
Well, obviously there is more to success and competition than not making
mistakes. If you thought that not making mistakes was the only way to
succeed, you would be wrong, in the same way you would be wrong if you
thought that success depends only on technical superiority. (I am not
saying that you think either of these things, but it is possible that
a reader of your paragraph could come away with the perception that
you believe that success was equated to not making mistakes).
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
"Duane Rettig" <·····@franz.com> wrote in message ··················@beta.franz.com...
> Well, obviously there is more to success and competition than not making
> mistakes. If you thought that not making mistakes was the only way to
> succeed, you would be wrong, in the same way you would be wrong if you
> thought that success depends only on technical superiority. (I am not
> saying that you think either of these things, but it is possible that
> a reader of your paragraph could come away with the perception that
> you believe that success was equated to not making mistakes).
As this could go on forever, I will just try to skip to the end.
A quote from the Tao Te Ching. Perhaps in this book Eran
can find some answers and some success.
3
When praise is lavished upon the famous,
the people contend and compete with one another.
When exotic goods are traded and treasured,
the compulsion to steal is felt.
When desires are constantly stimulated,
people become disturbed and confused.
Therefore, the wise person sets an example by
emptying her mind,
opening her heart,
relaxing her ambitions,
relinquishing her desires,
cultivating her character.
Having conquered her own cunning and cravings,
she can't be manipulated by anyone.
Do by not-doing.
Act with nonaction.
Allow order to rise of itself.
The Tao Te Ching of Lao Tzu
Translated by Brian Browne Walker
"Wade Humeniuk" <····@nospam.nowhere> writes:
> Do by not-doing.
> Act with nonaction.
> Allow order to rise of itself.
I think there's a bug in this - it doesn't seem to work on my desk,
anyway.
-dan
--
http://www.cliki.net/ - Link farm for free CL-on-Unix resources
"Daniel Barlow" <···@telent.net> wrote in message ···················@noetbook.telent.net...
> "Wade Humeniuk" <····@nospam.nowhere> writes:
>
> > Do by not-doing.
> > Act with nonaction.
> > Allow order to rise of itself.
>
> I think there's a bug in this - it doesn't seem to work on my desk,
> anyway.
You need a translation?
True learning does not come from doing and acting from what one
knows (memory and dogmatic beliefs).
Learning occurs when you let go of what you think you know
and allow the brain to change and learn. Allowing
your mind to detect a new order. A person is not
the be all and end all of what is right, its the world that
determines that. We just discover it. It takes an open
mind.
Try to detect how you actually learn, are you "doing" anything?
Wade
"Wade Humeniuk" <····@nospam.nowhere> writes:
> "Daniel Barlow" <···@telent.net> wrote in message ···················@noetbook.telent.net...
> > "Wade Humeniuk" <····@nospam.nowhere> writes:
> >
> > > Do by not-doing.
> > > Act with nonaction.
> > > Allow order to rise of itself.
> >
> > I think there's a bug in this - it doesn't seem to work on my desk,
> > anyway.
>
> You need a translation?
>
> True learning does not come from doing and acting from what one
> knows (memory and dogmatic beliefs).
> Learning occurs when you let go of what you think you know
> and allow the brain to change and learn. Allowing
> your mind to detect a new order. A person is not
> the be all and end all of what is right, its the world that
> determines that. We just discover it. It takes an open
> mind.
>
> Try to detect how you actually learn, are you "doing" anything?
Yeah, but how does it help with his desk? I'd like to know because
mine desk could use some self-rising order as well... ;)
Gregm
"Greg Menke" <··········@toadmail.com> wrote in message ···················@europa.pienet...
> Yeah, but how does it help with his desk? I'd like to know because
> mine desk could use some self-rising order as well... ;)
People are the result of self-rising order, thus that would make
your desk self-rising order. Or do you believe you are a soul
(for lack of better word) that is outside the system that imposes its
order on the chaos of the universe? That would make for a pretty big ego.
Too bad about your chaotic desk, I guess its just a reflection of you
and you will have to put some work into it. ;)
Dead Thread.
Wade
* Erann Gat wrote:
> If you think the Lisp train is rolling, then help me answer this question
> that my managers ask me whenever I bring the subject up: who uses it?
We do, and we do for money, both directly in terms of software we get
paid for and indirectly in terms of all the course notes &c our
lisp-based (well, Lisp and perl based) document-preparation system
produces, and (shortly, I hope), a course-scheduling system so people
who sell our courses can bespeak them on the fly.
Now a more interesting question, I think is: I bet lots and lots of
people are doing this kind of thing, why doesn't it count? This isn't
ironic: somehow it *isn't* the right kind of answer, even though I bet
plenty of people could give just this answer. I don't quite know why
it isn't the right answer!
--tim
In article <···············@cley.com>, Tim Bradshaw <···@cley.com> wrote:
> * Erann Gat wrote:
> > If you think the Lisp train is rolling, then help me answer this question
> > that my managers ask me whenever I bring the subject up: who uses it?
>
> We do,
Who is "we"?
Look, my managers are not idiots. It's not enough to say that WebSnoz.com
is using Lisp. They want to know: who is WebSnoz.com? Are they a real
company, or just a guy in a garage with a Web page? Are they really using
it as a matter of corporate policy, or do they just have one nut in the
research department who happens to buy a copy of ACL? Are they happy with
their decision?
Orbitz is about the only real Lisp success story I know of nowadays.
"What about ViaWeb?" you say? Well, ViaWeb was bought by Yahoo. So now
Yahoo is happily using Lisp? Well, no, actually they've been desperately
trying to get rid of the Lisp code and replace it with C++. That is not a
fact that's going to help make the case.
> Now a more interesting question, I think is: I bet lots and lots of
> people are doing this kind of thing, why doesn't it count?
I've been puzzling over this for years. Here's my theory: Lisp is good
for making individuals and small teams productive, but it's not good for
large-team development. This is not necessarily because the language is
inherently unsuitable for large-team development (though the lack of
static typing is arguably a factor). It might be that Lisp simply tends
to attract people who are not "team players."
E.
···@jpl.nasa.gov (Erann Gat) writes:
> Look, my managers are not idiots.
I read http://www.flownet.com/gat/jpl-lisp.html
Your managers seem to have abandoned a language that has produced
award winning software with the ability to diagnose and repair errors
on *extremely* remote systems in favor of a brittle language that has
a track record of incomplete projects and expensive code.
That fits *my* definition of `idiot'.
> Orbitz is about the only real Lisp success story I know of nowadays.
> "What about ViaWeb?" you say? Well, ViaWeb was bought by Yahoo. So now
> Yahoo is happily using Lisp? Well, no, actually they've been desperately
> trying to get rid of the Lisp code and replace it with C++. That is not a
> fact that's going to help make the case.
This must be because of the numerous success stories concerning
rewriting Lisp projects in C++.
In article <············@ccs.neu.edu>, Joe Marshall <···@ccs.neu.edu> wrote:
> ···@jpl.nasa.gov (Erann Gat) writes:
>
> > Look, my managers are not idiots.
>
> I read http://www.flownet.com/gat/jpl-lisp.html
>
> Your managers seem to have abandoned a language that has produced
> award winning software with the ability to diagnose and repair errors
> on *extremely* remote systems in favor of a brittle language that has
> a track record of incomplete projects and expensive code.
>
> That fits *my* definition of `idiot'.
First, making one idiotic decision doesn't make someone an idiot.
Second, whether abandoning Lisp is idiotic really depends on the spin you
put on it. With the spin you chose (which is certainly the spin I would
choose) it does look like an idiotic decision. But here's an alternative
spin: they abandoned a language which had a track record on only one major
project, and on that project it was a neverending management nightmare
because the Lisp programmers seemed to think that they were smarter than
everyone else. The result was a breakdown in team coherence and a
year-long delay in mission launch (which is a very serious matter I might
add). And then in the end the code was buggy and required ground
intervention in order to save the spacecraft.
See? When you look at it like that it suddenly doesn't seem quite so
idiotic, does it? I'm not saying this is a fair view of the situation (it
isn't), but it is defensible, and that's how a lot of people around here
remember it.
E.
···@jpl.nasa.gov (Erann Gat) writes:
> spin: they abandoned a language which had a track record on only one major
> project, and on that project it was a neverending management nightmare
> because the Lisp programmers seemed to think that they were smarter than
> everyone else. The result was a breakdown in team coherence and a
> year-long delay in mission launch (which is a very serious matter I might
> add).
I guess that working in team with you might be a nightmare. That does
not make working together with any Lisp programmer a nightmare,
though.
Nicolas.
In article <··············@ortler.iwr.uni-heidelberg.de>, Nicolas Neuss
<·············@iwr.uni-heidelberg.de> wrote:
> I guess that working in team with you might be a nightmare.
Really? Why would you guess that? (I'm not saying it's not true, I'm
just wondering what basis you have for thinking so, given that we've never
met, and your less-than-stellar track record of assessing my bona fides
over Usenet.)
E.
···@jpl.nasa.gov (Erann Gat) writes:
> In article <··············@ortler.iwr.uni-heidelberg.de>, Nicolas Neuss
> <·············@iwr.uni-heidelberg.de> wrote:
>
> > I guess that working in team with you might be a nightmare.
>
> Really? Why would you guess that?
You said so yourself. And I am not inclined to disbelieve you.
Nicolas.
···@jpl.nasa.gov (Erann Gat) wrote:
> spin: they abandoned a language which had a track record on only one
> major project, and on that project it was a neverending management
> nightmare because the Lisp programmers seemed to think that they
> were smarter than everyone else. The result was a breakdown in team
> coherence and a year-long delay in mission launch (which is a very
> serious matter I might add).
In article <··············@ortler.iwr.uni-heidelberg.de>, Nicolas Neuss
<·············@iwr.uni-heidelberg.de> wrote:
> ···@jpl.nasa.gov (Erann Gat) writes:
>
> > In article <··············@ortler.iwr.uni-heidelberg.de>, Nicolas Neuss
> > <·············@iwr.uni-heidelberg.de> wrote:
> >
> > > I guess that working in team with you might be a nightmare.
> >
> > Really? Why would you guess that?
>
> You said so yourself. And I am not inclined to disbelieve you.
Ah! Well, that's good. I was worried that it was something I said.
I'm pleased to learn I have so much credibility with you now. That has
not always been the case if you recall.
Since you have this newfound respect for my views I'll offer you this bit
of advice: go find a native English speaker and have them explain to you
the meaning of the word "spin" in the context in which you quote it:
> Nicolas.
>
>
> ···@jpl.nasa.gov (Erann Gat) wrote:
>
> > spin: they abandoned a language which had a track record on only one
> > major project, and on that project it was a neverending management
> > nightmare because the Lisp programmers seemed to think that they
> > were smarter than everyone else. The result was a breakdown in team
> > coherence and a year-long delay in mission launch (which is a very
> > serious matter I might add).
E.
From: Bulent Murtezaoglu
Subject: Re: type safety in LISP
Date:
Message-ID: <87pts5tmuj.fsf@acm.org>
>>>>> "JM" == Joe Marshall <···@ccs.neu.edu> writes:
EN> ... So now Yahoo is happily using Lisp? Well,
EN> no, actually they've been desperately trying to get rid of the
EN> Lisp code and replace it with C++. That is not a fact that's
EN> going to help make the case.
JM> This must be because of the numerous success stories
JM> concerning rewriting Lisp projects in C++.
Please don't ever quit posting here Joe. Laughter aside, I have heard
this rumor about yahoo wanting to rid itself of Lisp before. Why?
[Where] is this written up?
cheers,
BM
In article <··············@acm.org>, Bulent Murtezaoglu <··@acm.org> wrote:
> >>>>> "JM" == Joe Marshall <···@ccs.neu.edu> writes:
>
> EN> ... So now Yahoo is happily using Lisp? Well,
> EN> no, actually they've been desperately trying to get rid of the
> EN> Lisp code and replace it with C++. That is not a fact that's
> EN> going to help make the case.
>
> JM> This must be because of the numerous success stories
> JM> concerning rewriting Lisp projects in C++.
>
> Please don't ever quit posting here Joe. Laughter aside, I have heard
> this rumor about yahoo wanting to rid itself of Lisp before. Why?
> [Where] is this written up?
First, that should be EG, not EN. (!)
Second, Yahoo's desire to get rid of Lisp is not documented. I know it's
so because I interviewed for the job of porting the code to C++. (I
didn't get the job because I could not keep a straight face during the
interview, and eventually ran screaming from the room. Well, not quite,
but close.)
E. (G.)
On Fri, 13 Dec 2002 12:27:40 -0800, ···@jpl.nasa.gov (Erann Gat) wrote:
> In article <···············@cley.com>, Tim Bradshaw <···@cley.com> wrote:
>
> > * Erann Gat wrote:
> > > If you think the Lisp train is rolling, then help me answer this question
> > > that my managers ask me whenever I bring the subject up: who uses it?
> >
> > We do,
>
> Who is "we"?
>
> Look, my managers are not idiots. It's not enough to say that WebSnoz.com
> is using Lisp. They want to know: who is WebSnoz.com? Are they a real
> company, or just a guy in a garage with a Web page? Are they really using
> it as a matter of corporate policy, or do they just have one nut in the
> research department who happens to buy a copy of ACL? Are they happy with
> their decision?
First you asked for information. When provided with some information, you
demand more. This is increasingly looking like a moving target--a.k.a. a
strawman.
If managers need that amount of detail, they should probably be willing to
hire those market analysts who sell reports printed on glossy paper.
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://www.paoloamoroso.it/ency/README
* Erann Gat wrote:
> Who is "we"?
Cley (and indirectly its clients, who are generally larger than us (:-)).
> Look, my managers are not idiots. It's not enough to say that WebSnoz.com
> is using Lisp. They want to know: who is WebSnoz.com? Are they a real
> company, or just a guy in a garage with a Web page? Are they really using
> it as a matter of corporate policy, or do they just have one nut in the
> research department who happens to buy a copy of ACL? Are they happy with
> their decision?
We don't even have a web page, really: the one we have is just there
because we felt bad about having www.cley.com not respond...
But I understand your point - it clearly matters whether Lisp is
actually used in anger by people who are making money. Except, maybe
it doesn't...
Here's my theory about these kind of questions. Really, what is being
asked here is `OK, so you're suggesting that we do x, well, before we
make a decision I'd like to know who else is doing x?'. Perhaps an
expansion of the question would be `who else that is like us is doing
x?'. Why ask this question? I think the reason is often `because we
don't want to do anything unusual, we want to be just like other
people'. If that's what is driving these questions, is it a
reasonable attitude? Sometimes it probably is: `what accounting system
do other companies our size use? Probably we should use that too'
seems pretty reasonable (it's certainly how *we* decided what
accounting package to buy!). But in other cases it reeks of
cowardice or stupidity.
The cowardice case is this: `we're a company doing x, we have n
competitors and there are a bunch of other companies about the same
size: let's look at what they do, and do the same thing'. The likely
outcome of this is that you'll do about as well as they do, and you'll
probably stay in business, and you didn't have to think too hard to do
it. Of course, if `what they do' is something that's very
inefficient, you'll be doomed to be inefficient too, but at least
you'll only be as inefficient as they are. In the case of software,
well, your projects will be late, over budget and 80% will just fail,
like theirs do. But no one ever got sacked for choosing C++.
The stupidity case is this: `we're an organisation that put people on
the moon, and now wants to land a man on Mars in the next 10 years:
there aren't any other people doing what we do, but lets look at some
other people who are doing something different and much less
demanding, but perhaps we can convince ourselves that they're like us
in some nebulous sense, and see what they do, and do that'. This
organisation has forgotten how it got people to the moon.
Me, I'd like to work somewhere where people made decisions based on
their own opinions, rather than herd instinct or stupidity.
Unfortunately it's hard to find such places, unless you make them up
yourself.
--tim
In article <···············@cley.com>, Tim Bradshaw <···@cley.com> wrote:
> Here's my theory about these kind of questions. Really, what is being
> asked here is `OK, so you're suggesting that we do x, well, before we
> make a decision I'd like to know who else is doing x?'. Perhaps an
> expansion of the question would be `who else that is like us is doing
> x?'. Why ask this question? I think the reason is often `because we
> don't want to do anything unusual, we want to be just like other
> people'.
Or "because we are engaged in a high-risk endeavor and we want to avail
ourselves of as much prior experience as possible."
> Me, I'd like to work somewhere where people made decisions based on
> their own opinions, rather than herd instinct or stupidity.
> Unfortunately it's hard to find such places, unless you make them up
> yourself.
Indeed.
E.
* Erann Gat wrote:
> Or "because we are engaged in a high-risk endeavor and we want to avail
> ourselves of as much prior experience as possible."
Yes, that's a good reason. But when the the prior experience of large
C/C++ systems is an 80% project failure rate (or whatever it is), and
buffer overflows in critical software, and so forth, I'd tend to do
something else. Almost anything else.
--tim
On 14 Dec 2002 16:22:57 +0000, Tim Bradshaw <···@cley.com> wrote:
> The stupidity case is this: `we're an organisation that put people on
> the moon, and now wants to land a man on Mars in the next 10 years:
> there aren't any other people doing what we do, but lets look at some
> other people who are doing something different and much less
> demanding, but perhaps we can convince ourselves that they're like us
> in some nebulous sense, and see what they do, and do that'. This
> organisation has forgotten how it got people to the moon.
It may be even worse than that: that organization may have also forgotten
how to get people to low Earth orbit.
I read about plans for a new ISS crew rotation vehicle. It looks like it
will take a decade to have the vehicle in operation. In the sixties, in the
same time frame (i.e. a decade), the same organization run 3 successful
manned projects, one of which brought 50 tons worth of hardware to lunar
orbit. But that is mature technology, never mind.
Incidentally, exactly 30 years ago the Apollo 17 crew was on its way back
to Earth after leaving the Moon, possibly forever.
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://www.paoloamoroso.it/ency/README
Tim Bradshaw <···@cley.com> writes:
> * Erann Gat wrote:
> > If you think the Lisp train is rolling, then help me answer this question
> > that my managers ask me whenever I bring the subject up: who uses it?
>
> We do, and we do for money, both directly in terms of software we get
> paid for and indirectly in terms of all the course notes &c our
> lisp-based (well, Lisp and perl based) document-preparation system
> produces, and (shortly, I hope), a course-scheduling system so people
> who sell our courses can bespeak them on the fly.
>
> Now a more interesting question, I think is: I bet lots and lots of
> people are doing this kind of thing, why doesn't it count? This isn't
> ironic: somehow it *isn't* the right kind of answer, even though I bet
> plenty of people could give just this answer. I don't quite know why
> it isn't the right answer!
Because what other people are doing doesn't affect Erann's efforts
in his own local anti-lisp section of the world.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
* Duane Rettig wrote:
> Because what other people are doing doesn't affect Erann's efforts
> in his own local anti-lisp section of the world.
No, I think it's more complicated than that. I think the real answer
is `because unless it's a large company, that I've heard of, who make
extensive use of Lisp in a product/system I've heard of, it doesn't
count'. Or something like that. 2 years ago everyone would have been
trumpeting Enron's use of Lisp...
--tim
···@jpl.nasa.gov (Erann Gat) writes:
> If you think the Lisp train is rolling, then help me answer this question
> that my managers ask me whenever I bring the subject up: who uses it?
"Just now (2002 on), I am working on a project for Sun Microsystems to
develop the next generation of search system, so far over the horizon
that Google is out of sight. Paint by numbers, plug in ready to run
pieces like Visual Basic? Not likely, we need to be able to work from
custom GUI tools level right down to highly optimized assembly level
stuff. We use Lisp (and not Franz lisp either, but that is another
matter), I use Genera and MCL for much of my work."
<http://www.abstractscience.freeserve.co.uk/symbolics/power.html>
Does anybody know more about this?
Regards
Henrik
Nils Goesche <······@cartan.de> writes:
> 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?
So people who disparage static typing because of the effort involved in doing
type declarations are suddenly willing to take the effort to write the
multitudes of such tests?
For these kinds of type errors, writing type declarations is less effort than
writing explicit tests. Indeed, these kinds of tests are implicitly done by
the compiler instead, freeing the user from needing to write and maintain
them.
> 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.
So you use some one else's function that returns an error string instead of
the expected number for error situations. Your incomplete testing simply did
not cover the error case.
So in Lisp you get a nice run time error. The error maybe easily fixed. In a
static situation one could not even construct the incorrect call, at least not
by accident.
Seems fine both ways. But maybe the runtime error happened during a situation
where runtime errors could not be tolerated.
> The kind of bug compilers of statically typed languages protect us
> from is a kind of bug that hardly ever occurs in practice.
My experience with large projects, integrating large numbers of separately
written modules, indicates the opposite.
This kind of thing is amenable to measurement. Does anyone know of official
studies?
> 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...
In ML maybe. Not in general. It depends entirely on the language involved. A
"lisp with declarations" (Dylan for example -- I'm sure there are others too)
that is statically typed can still behave in exactly the same way at runtime.
It is only that there are *additional* abilities for error checking at compile
time.
--
Cheers, The Rhythm is around me,
The Rhythm has control.
Ray Blaak The Rhythm is inside me,
·····@telus.net The Rhythm has my soul.
Nils Goesche <······@cartan.de> writes:
> 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.
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.
--
Pertti Kellom\"aki, Tampere Univ. of Technology, Software Systems Lab
On Tue, Dec 10, 2002 at 09:37:28PM +0200, Kellom{ki Pertti wrote:
> 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>).
Existential types aren't the same as lists. These are used to construct
``modules'' and for data abstraction. Maybe you were thinking also of
tuples in ML, but they aren't like lists either, being fixed in length
and type specification.
> 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.
But the fact is:
Standard ML of New Jersey, Version 110.0.3, January 30, 1998 [CM;
autoload enabled]
- 10000000000000000000000 + 1000000000000000000;
stdIn:17.1-17.24 Error: int constant too large
and
- 3 div 4;
val it = 0 : int
This is completely unacceptable in a language that emphasizes
correctness, but acceptable in a language which emphasizes efficiency
paramount to other concerns (C, for example). That is why I agree with
Nils; these are issues which would simply not appear if the designers of
Standard ML truly cared about correctness.
--
; Matthew Danish <·······@andrew.cmu.edu>
; OpenPGP public key: C24B6010 on keyring.debian.org
; Signed or encrypted mail welcome.
; "There is no dark side of the moon really; matter of fact, it's all dark."
Matthew Danish <·······@andrew.cmu.edu> writes:
> On Tue, Dec 10, 2002 at 09:37:28PM +0200, Kellom{ki Pertti wrote:
> > 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>).
>
> Existential types aren't the same as lists.
Indeed they are not, but they can be used to create lists with
hetrogeneous elements e.g. a list containing a circle and a
rectangle.
> > 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.
[ two examples snipped ]
> This is completely unacceptable in a language that emphasizes
> correctness, but acceptable in a language which emphasizes efficiency
> paramount to other concerns (C, for example). That is why I agree with
> Nils; these are issues which would simply not appear if the designers of
> Standard ML truly cared about correctness.
What would you prefer the answer to each computation to be and what
static types would you give to the arguments and results if you were a
designer of Standard ML who truly cared about correctness?
Here's the result of the computations in Haskell which has a more
expressive static type system than SML in the area of numerics :-
Prelude> 10000000000000000000000 + 1000000000000000000
10001000000000000000000
Prelude> 3/4
0.75
The above relies on the use of type classes which were cutting edge
when the SML'90 standard was created. By the time of the SML'97
standard they'd been around a while but the '97 standard was mostly a
cleanup and didn't introduce new things, they were pushed off to
SML'2000 which never really happened.
On Wed, Dec 11, 2002 at 12:25:36AM +0000, Stephen J. Bevan wrote:
> Matthew Danish <·······@andrew.cmu.edu> writes:
> > On Tue, Dec 10, 2002 at 09:37:28PM +0200, Kellom{ki Pertti wrote:
> > > 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>).
> >
> > Existential types aren't the same as lists.
>
> Indeed they are not, but they can be used to create lists with
> hetrogeneous elements e.g. a list containing a circle and a
> rectangle.
I don't see how existential types are required for this, other than
maybe to hide this:
datatype shape = Circle of circle | Rect of rectangle
... use shape list ...
After covering this, I've seen authors conclude, incorrectly, that what
is needed to simulate dynamic typing is simply an ``infinite disjoint
union'' type. What they forget is that the generativity property of
types in a statically-typed language destroys the ability to redefine a
type in the sense that a dynamically-typed language allows you to.
> > > 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.
> [ two examples snipped ]
> > This is completely unacceptable in a language that emphasizes
> > correctness, but acceptable in a language which emphasizes efficiency
> > paramount to other concerns (C, for example). That is why I agree with
> > Nils; these are issues which would simply not appear if the designers of
> > Standard ML truly cared about correctness.
>
> What would you prefer the answer to each computation to be and what
> static types would you give to the arguments and results if you were a
> designer of Standard ML who truly cared about correctness?
>
> Here's the result of the computations in Haskell which has a more
> expressive static type system than SML in the area of numerics :-
>
> Prelude> 10000000000000000000000 + 1000000000000000000
> 10001000000000000000000
This is good.
> Prelude> 3/4
> 0.75
But this is not:
Prelude> 1/3
0.3333333333333333
Any mathematician will tell you that 1/3 is not equal to
0.3333333333333333.
> The above relies on the use of type classes which were cutting edge
> when the SML'90 standard was created. By the time of the SML'97
> standard they'd been around a while but the '97 standard was mostly a
> cleanup and didn't introduce new things, they were pushed off to
> SML'2000 which never really happened.
``Cutting-edge''?
In '90 both Lisp and Scheme had proper numeric support (and earlier too,
no doubt).
I tried to track down a discussion of these type classes in relation to
SML '90 and '97, but wasn't able to find any information online.
--
; Matthew Danish <·······@andrew.cmu.edu>
; OpenPGP public key: C24B6010 on keyring.debian.org
; Signed or encrypted mail welcome.
; "There is no dark side of the moon really; matter of fact, it's all dark."
Nils Goesche wrote:
> 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.
Your Fundamental Theorem #2 is doubtless correct, but note that
what static typing does is not *only* to remove type information.
In a statically typed system, there is *more* type information
available at compile time: either because the user has been
required to provide it, or because more type inference has been
done, or both.
Well, that's not *strictly* true. Some Lisp compilers are very
clever; some Lisp programmers, sometimes, put in a great deal
of discretionary type information; so some Lisp code, for some
compilers, has all the type information available at compile
time. However, this is an exceptional situation (though having
a good deal of type information available at compile time
might not be). And in every dynamically typed language I know
other than Lisp and Dylan, it's an impossible situation :-).
So I don't understand how NFT#2 refutes the claim that static
typing leads to safer software. It doubtless refutes the claim
that every piece of software developed without static typing
can be made safer by imposing static typing on it, but that's
not the claim anyone's making. I suppose it also refutes the
claim that software written in, say, ML is safer than it would
be if all the same static analysis were done and then the
type information were preserved at runtime, but that's not
a claim I've heard anyone make either.
--
Gareth McCaughan ················@pobox.com
.sig under construc
Ray Blaak <·····@telus.net> writes:
> 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
"Ray Blaak" <·····@telus.net> wrote in message ··················@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
"Wade Humeniuk" <····@nospam.nowhere> writes:
> "Ray Blaak" <·····@telus.net> wrote in message ··················@telus.net...
> >
> > 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
This is not true. CL allows the compiler to accept type declarations and,
for the nost part, to do what it wants to do, depending on optimization
qualities. This might include generating faster but less safe code, and
it might include generating runtime type checks as well.
> and is dangerous in all
> but the most tested and stable code. (declare (optimize (safety 0)))
Eh, did you mean (safety 3) here?
> If you want a dynamic language, this decison is pretty well made for you.
What decision is that?
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
"Duane Rettig" <·····@franz.com> wrote in message ··················@beta.franz.com...
> "Wade Humeniuk" <····@nospam.nowhere> writes:
>
> > "Ray Blaak" <·····@telus.net> wrote in message ··················@telus.net...
> > >
> > > 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
>
> This is not true. CL allows the compiler to accept type declarations and,
> for the nost part, to do what it wants to do, depending on optimization
> qualities. This might include generating faster but less safe code, and
> it might include generating runtime type checks as well.
>
But aren't these local optimizations within functions or some kind
of coding blocks (within the extent of a declare or the binding of a var that
has a definite inferred type)?
The compiler does not insist that all callers pass the right types,
and their callers, and their callers.... Am I wrong? Can ACL perform
optimizations or call-time checks between caller and callee functions
based on type?
> > and is dangerous in all
> > but the most tested and stable code. (declare (optimize (safety 0)))
>
> Eh, did you mean (safety 3) here?
>
> > If you want a dynamic language, this decison is pretty well made for you.
>
> What decision is that?
To use Lisp of course! :)
Wade
"Wade Humeniuk" <····@nospam.nowhere> wrote in message
·························@news1.telusplanet.net...
>
> But aren't these local optimizations within functions or some kind
> of coding blocks (within the extent of a declare or the binding of a var that
> has a definite inferred type)?
> The compiler does not insist that all callers pass the right types,
> and their callers, and their callers.... Am I wrong? Can ACL perform
> optimizations or call-time checks between caller and callee functions
> based on type?
All it takes sometimes is just to step away for a minute. Of course
CL has call-time checks in defmethod. Dispatch based on type
and optimization of the method based on the specialized types
in defmethod.
Wade
Pascal Costanza <········@web.de> writes:
> 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.
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.
Patrick W wrote:
> Pascal Costanza <········@web.de> writes:
>
>
>>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.
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
--
Pascal Costanza University of Bonn
···············@web.de Institute of Computer Science III
http://www.pascalcostanza.de R�merstr. 164, D-53117 Bonn (Germany)
* Pascal Costanza
| 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.
--
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 <········@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).
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.
Patrick W wrote:
> Pascal Costanza <········@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?
Pascal
--
Pascal Costanza University of Bonn
···············@web.de Institute of Computer Science III
http://www.pascalcostanza.de R�merstr. 164, D-53117 Bonn (Germany)
* Pascal Costanza
| 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.
--
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.
Why don't you just stop posting messages that are essentially free of
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?
Pascal
--
Pascal Costanza University of Bonn
···············@web.de Institute of Computer Science III
http://www.pascalcostanza.de R�merstr. 164, D-53117 Bonn (Germany)
* Pascal Costanza
| 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!
--
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 <········@web.de> writes:
> 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>
"marcel haesok" <·········@attbi.com> wrote in message news:<·····················@sccrnsc02>...
> 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.
···@ashi.footprints.net (Kaz Kylheku) writes:
> ... having everything declared in
> the program text so that a computer science sophomore can write an
> optimizing compiler.
that is really funny, but perhaps unintentionally so.
oz
---
music is the space between the notes. -- claude debussy
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.
(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.
* marcel haesok wrote:
> 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)
On 09 Dec 2002 20:44:55 +0000, Tim Bradshaw <···@cley.com> wrote:
> 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
"Paolo Amoroso" wrote:
> 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.
>
Yeah, the risk is real. But I think C# is sort of an improved rip-off of C,
JAVA and C++ maybe,
so that I don't think I will regret it even if the dotnet platform crashes
down the road. If that
really happens, it would a breeze, hopefully, for me to pick up JAVA and C.
Anyways, there is an
Iranian ( am not) Proverb which says that when you learn one more language,
you become one more
person. I think that applies also to computer language. A complete new
perspective----