···@jpl.nasa.gov (Erann Gat) wrote in message news:<····················@k-137-79-50-101.jpl.nasa.gov>...
> After all, it is not unreasonable to expect that all
> the work required just to get the program to compile so you could run it
> for the first time should pay a dividend of some sort, and what else could
> that dividend possibly be other than having to do less testing?
"Compile time" -- what does this mean, the time when macros are
expanded?
Seriously, I can not imagine in this new millenium, that static
checking proponents are still talking about compile time. You must
have a bad assumption in your posting; perhaps you are explaining the
very real problem of how local fixes to satisfy a static system end up
damaging code globally.
So I'd ask: Could a lisp system be configured so that it runs a
static analysis upon runtime errors, or at arbitrary points on
arbitrary subsets of code? In fact, if the user is allowed to
incrementally supply type information, it can ask for specific info to
make certain guarantees. It may even be combined with runtime
analysis to recommend exactly which types and where they are most
sorely needed.
Tayss wrote:
>
> Seriously, I can not imagine in this new millenium, that static
> checking proponents are still talking about compile time.
Come on. 99% of all programmers still work with compilers. (This doesn't
make working with compilers superior, it just defines the standard case
from which people tend to argue. Abstract that away when weighing
arguments.)
> So I'd ask: Could a lisp system be configured so that it runs a
> static analysis upon runtime errors, or at arbitrary points on
> arbitrary subsets of code?
I'd prefer the latter: static checking when I want it.
Checking upon runtime errors is better than nothing, but checking before
the software hits the end user's desk is still better. Automated
checking as first pass of testing procedures would also make sense (it
remains to be seen whether it's better if the developers do the static
tests, or if the testers do it - assuming that these are different
people in the first place.)
> In fact, if the user is allowed to
> incrementally supply type information, it can ask for specific info to
> make certain guarantees.
That's what I'd like to see.
It's not limited to types BTW, there are other properties of a program
that one may want to guarantee.
Actually, a type error message is essentially such a question for
specific info - some kinds of type error anyway. (Type error messages
are a problem only if they prevent running the program.)
> It may even be combined with runtime
> analysis to recommend exactly which types and where they are most
> sorely needed.
I'm highly sceptical that runtime analysis can gather information that
is actually helpful for evaluating the relevance of missing information.
(I'd be interested to see such a system in practice, it's impossible to
tell for sure in advance.)
Regards,
Jo
BTW Erann, I didn't mean to sound hostile or critical; I had been
reading a flamewar and maybe a couple of rhetorical flourishes stuck
in my head. Especially strange since I mainly agree.
Joachim Durchholz <·················@web.de> wrote in message news:<············@news.oberberg.net>...
> Tayss wrote:
> > Seriously, I can not imagine in this new millenium, that static
> > checking proponents are still talking about compile time.
>
> Come on. 99% of all programmers still work with compilers.
I think that using this terminology, born from what many now regard as
an optimization, is mentally limiting. Even with Java, I can use an
incremental compiler as a step to making myself forget it's compiled
(from a developer's standpoint).
Further, if I conflate "compiletime and runtime" by making unit tests
a part of my compile process, then how relevant do those words become
to this discussion?
> Checking upon runtime errors is better than nothing, but checking before
> the software hits the end user's desk is still better. Automated
> checking as first pass of testing procedures would also make sense (it
> remains to be seen whether it's better if the developers do the static
> tests, or if the testers do it - assuming that these are different
> people in the first place.)
- Erann argues that local fixes to shut a static typechecker up causes
bad software overall. Many of us have seen this fix-and-run style.
- Static checking can point to more insidious errors, but this good
information is lost if we arbitrarily partition compiletime and
runtime errorhunting.
- This compiletime/runtime split can interfere with future engineering
methodologies. For example, an engineer may desire to test an Agile
Methodology hypothesis that errorfixing should occur at once, starting
from a compiled image. While it may fail, her experiments could
provide valuable insights for engineering improvements.
- Pull all the analysis from James W. Goodwin's 1981 paper "Why
Programming Environments Need Dynamic Data types": "Dynamic data
types... require that the distinction between compile and runtime
environments be removed, and that the explicit use of type information
at runtime be recognized as a valid and desirable abstraction
technique, not merely a symptom of some deficiency in the type
checking."
(Man, that _Interactive Programming Environment_ book recommended by
lispers comes in real handy.) For deeper analysis, you can consult
that paper and ask yourself is it's been obsoleted.
- Perhaps the ideas in Rich & Shrobe's "Initial Report on a LISP
Programmer's Apprentice" paper have led to some success (maybe amid
failures) that could be cannibalized to creating a working
static+dynamic system.
> I'm highly sceptical that runtime analysis can gather information that
> is actually helpful for evaluating the relevance of missing information.
> (I'd be interested to see such a system in practice, it's impossible to
> tell for sure in advance.)
This could strengthen code coverage tools, though I haven't used them.
In article <····························@posting.google.com>,
··········@yahoo.com (Tayss) wrote:
> BTW Erann, I didn't mean to sound hostile or critical; I had been
> reading a flamewar and maybe a couple of rhetorical flourishes stuck
> in my head. Especially strange since I mainly agree.
No worries, mate.
E.
··········@yahoo.com (Tayss) writes:
> BTW Erann, I didn't mean to sound hostile or critical; I had been
> reading a flamewar and maybe a couple of rhetorical flourishes stuck
> in my head. Especially strange since I mainly agree.
>
>
> Joachim Durchholz <·················@web.de> wrote in message news:<············@news.oberberg.net>...
> > Tayss wrote:
> > > Seriously, I can not imagine in this new millenium, that static
> > > checking proponents are still talking about compile time.
> >
> > Come on. 99% of all programmers still work with compilers.
>
> I think that using this terminology, born from what many now regard as
> an optimization, is mentally limiting. Even with Java, I can use an
> incremental compiler as a step to making myself forget it's compiled
> (from a developer's standpoint).
Even with C, C++ and Objective-C, with the new XCode IDE from Apple!
> [cutting the rest just to improve my OCR, but I deem it worth a
> second reading: go back to the refered message! :-)]
--
__Pascal_Bourguignon__
http://www.informatimago.com/
Tayss wrote:
> Joachim Durchholz <·················@web.de> wrote:
>
>> Tayss wrote:
>>
>>> Seriously, I can not imagine in this new millenium, that static
>>> checking proponents are still talking about compile time.
>>
>> Come on. 99% of all programmers still work with compilers.
>
> I think that using this terminology, born from what many now regard
> as an optimization, is mentally limiting.
There's a point.
The precise terminology would be to replace "compile-time" by "static".
The relevant point being that the code is checked for properties without
actually running it.
> Further, if I conflate "compiletime and runtime" by making unit tests
> a part of my compile process, then how relevant do those words
> become to this discussion?
By the above definition, unit tests are dynamic, not matter whether they
are run by the compiler or not. (This is what I'd expect of a good
terminology.)
>> Checking upon runtime errors is better than nothing, but checking
>> before the software hits the end user's desk is still better.
>> Automated checking as first pass of testing procedures would also
>> make sense (it remains to be seen whether it's better if the
>> developers do the static tests, or if the testers do it - assuming
>> that these are different people in the first place.)
>
> - Erann argues that local fixes to shut a static typechecker up
> causes bad software overall. Many of us have seen this fix-and-run
> style.
I agree that this style exists, but it's entirely compatible with unit
and regression testing. (Escaping a good type system isn't easier for a
bug than escaping a suite of regression tests.)
> - Static checking can point to more insidious errors,
Not sure about this (it depends on what you consider "insiduous"), but...
> but this good information is lost if we arbitrarily partition
> compiletime and runtime errorhunting.
... I agree that this distinction in itself isn't very interesting.
The interesting aspects are: programmer effort, computer effort (last
time I worked with regression testing, it took hours or days, is this
usual or just a sign of inappropriate technology?), test coverage,
complementing the sets of errors that a human thinks about with those
that the computer "thinks" about.
My experience says that static typing � la Haskel/ML wins hands down
against C/C++/Pascal/Java/Eiffel typing. My (limited) experience with
dynamic testing methods says that static typing alone also wins hands
down against dynamic testing alone, but that each method can complement
the other to cover each other's blind spots.
> - This compiletime/runtime split can interfere with future
> engineering methodologies. For example, an engineer may desire to
> test an Agile Methodology hypothesis that errorfixing should occur at
> once, starting from a compiled image. While it may fail, her
> experiments could provide valuable insights for engineering
> improvements.
>
> - Pull all the analysis from James W. Goodwin's 1981 paper "Why
> Programming Environments Need Dynamic Data types": "Dynamic data
> types... require that the distinction between compile and runtime
> environments be removed, and that the explicit use of type
> information at runtime be recognized as a valid and desirable
> abstraction technique, not merely a symptom of some deficiency in the
> type checking."
>
> (Man, that _Interactive Programming Environment_ book recommended by
> lispers comes in real handy.) For deeper analysis, you can consult
> that paper and ask yourself is it's been obsoleted.
Actually my favorite toy language (MFTL) project goes along these lines
of thinking.
And without ever having read that book. I must be good ;-)
Regards,
Jo
Joachim Durchholz wrote:
> I'd prefer the latter: static checking when I want it.
> Checking upon runtime errors is better than nothing, but checking before
> the software hits the end user's desk is still better.
Just to be clear, since it's not clear based on your comments that you're
coming from a "modern" lisp background - Common Lisp compilers DO typically
do a degree of static analysis at "compile-time", and some type-inference
e.g. CMUCL.
Also, and this is just a general comment, one must be clear on this:
| Strong | Weak |
--------+---------+----------
Dynamic | Lisp | Perl |
Static | ML | C |
"Strong" and "weak" here referring to how easy it is to violate the type
system. Common Lisp won't happily let you violate its type system, so it's
pretty strongly typed, though it is dynamically typed.
(In fact, the Lisp Machines of yore had hardware type-tagging, so violating
a type would have been a crime akin to a "segmentation violation" on a
conventional untagged CPU, nor did enforcing type safety dynamically have
much speed penalty on such hardware (note that such speed penalties are
themselves pretty irrelevant for most applications in these days of
multi-ghz CPUs)).
Some people assume strong and static go hand-in-hand, even define their
terminology in such a manner, but it's not particularly true.
From: Joe Marshall
Subject: Re: Why I don't believe in static typing
Date:
Message-ID: <d6bpvbim.fsf@ccs.neu.edu>
David Golden <············@oceanfree.net> writes:
> (In fact, the Lisp Machines of yore had hardware type-tagging, so violating
> a type would have been a crime akin to a "segmentation violation" on a
> conventional untagged CPU,
More like a `kernel panic' or `uncorrectable hardware fault'.
In article <············@ccs.neu.edu>, Joe Marshall <···@ccs.neu.edu> wrote:
>David Golden <············@oceanfree.net> writes:
>
>> (In fact, the Lisp Machines of yore had hardware type-tagging, so violating
>> a type would have been a crime akin to a "segmentation violation" on a
>> conventional untagged CPU,
>
>More like a `kernel panic' or `uncorrectable hardware fault'.
Only if it occured in the lowest levels of the OS. Type errors in
application programs are normally translated by the system into conditions
like WRONG-TYPE-ARGUMENT or UNBOUND-VARIABLE.
--
Barry Margolin, ··············@level3.com
Level(3), Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
From: Joe Marshall
Subject: Re: Why I don't believe in static typing
Date:
Message-ID: <ptfp5u3h.fsf@ccs.neu.edu>
Barry Margolin <··············@level3.com> writes:
> In article <············@ccs.neu.edu>, Joe Marshall <···@ccs.neu.edu> wrote:
>>David Golden <············@oceanfree.net> writes:
>>
>>> (In fact, the Lisp Machines of yore had hardware type-tagging, so violating
>>> a type would have been a crime akin to a "segmentation violation" on a
>>> conventional untagged CPU,
>>
>>More like a `kernel panic' or `uncorrectable hardware fault'.
>
> Only if it occured in the lowest levels of the OS. Type errors in
> application programs are normally translated by the system into conditions
> like WRONG-TYPE-ARGUMENT or UNBOUND-VARIABLE.
I was taking the phrase `violating a type' to mean something like
bashing the type code on an integer to make it a string.
Under `normal' operation, there is no mechanism by which you *could*
violate a type.
David Golden wrote:
> Joachim Durchholz wrote:
>
>>I'd prefer the latter: static checking when I want it.
>>Checking upon runtime errors is better than nothing, but checking before
>>the software hits the end user's desk is still better.
>
> Just to be clear, since it's not clear based on your comments that you're
> coming from a "modern" lisp background - Common Lisp compilers DO typically
> do a degree of static analysis at "compile-time", and some type-inference
> e.g. CMUCL.
I'm not sure how much static checking is done. I'm aware that research
in that area is underway, and that there are results which have been
applied, but I'm unsure about the extent to which this is actually useful.
(I'm always thinking about Strongtalk, a Smalltalk derivative with type
checking. I always felt that Strongtalk failed not because static typing
is useless, or that Smalltalk couldn't be improved with static typing,
but because Smalltalk was too flexible to allow static type systems to
give interesting guarantees. What added to the early confusion that some
people assumed that a type = a class; in Smalltalk, a type = an interface.)
> Also, and this is just a general comment, one must be clear on this:
>
> | Strong | Weak |
> --------+---------+----------
> Dynamic | Lisp | Perl |
> Static | ML | C |
>
>
> "Strong" and "weak" here referring to how easy it is to violate the type
> system. Common Lisp won't happily let you violate its type system, so it's
> pretty strongly typed, though it is dynamically typed.
While I agree with this distinction in general, I'm not sure that it is
so easy to draw the lines between strong and weak static typing. E.g.
Perl typing actually is "strong" in the sense that type errors never
cause the run-time system to crash with a segmentation violation. I
think the classification should be "how easy it is to violate the type
system /for user-defined types/" (I don't know enough about Perl to say
whether that's easy or difficult).
In general, it's difficult to give a precise definition of "type",
"violation", and "easy", so any classification wrt. strong vs. weak
typing is going to get you flames if you actually apply the
classification :-)
(I'm not in comp.lang.lisp, so I won't read responses to this post.)
Regards,
Jo
Joachim Durchholz <·················@web.de> wrote in message news:<············@news.oberberg.net>...
-snip-
> (I'm always thinking about Strongtalk, a Smalltalk derivative with type
> checking. I always felt that Strongtalk failed not because static typing
> is useless, or that Smalltalk couldn't be improved with static typing,
> but because Smalltalk was too flexible to allow static type systems to
> give interesting guarantees. What added to the early confusion that some
> people assumed that a type = a class; in Smalltalk, a type = an interface.)
Why do you say Strongtalk failed?
The technology was working nicely when the company was acquired by Sun
and the technology adapted to Java (HotSpot VM).
http://www.cs.ucsb.edu/projects/strongtalk/pages/history.html
-snip-
> In general, it's difficult to give a precise definition of "type",
> "violation", and "easy", so any classification wrt. strong vs. weak
> typing is going to get you flames if you actually apply the
> classification :-)
Let's be cowardly and defer to authority ;-)
| Safe | Unsafe |
--------+------+-----------+
Untyped | Lisp | Assembler |
Typed | ML | C |
http://citeseer.nj.nec.com/cardelli97type.html
best wishes, Isaac
·····@yahoo.com (Isaac Gouy) writes:
> Joachim Durchholz <·················@web.de> wrote in message news:<············@news.oberberg.net>...
...
> > In general, it's difficult to give a precise definition of "type",
> > "violation", and "easy", so any classification wrt. strong vs. weak
> > typing is going to get you flames if you actually apply the
> > classification :-)
>
> Let's be cowardly and defer to authority ;-)
>
> | Safe | Unsafe |
> --------+------+-----------+
> Untyped | Lisp | Assembler |
> Typed | ML | C |
Ick. "Untyped"? I assume Cardelli means that *variables*
in Lisp are untyped, or something, but if you expect
anyone who actually knows Lisp to refer to it as an
untyped language then you're off your head :-).
--
Gareth McCaughan
.sig under construc
Gareth McCaughan wrote:
>
>> Let's be cowardly and defer to authority ;-)
>>
>> | Safe | Unsafe |
>> --------+------+-----------+
>> Untyped | Lisp | Assembler |
>> Typed | ML | C |
>
> Ick. "Untyped"? I assume Cardelli means that *variables*
> in Lisp are untyped, or something, but if you expect
> anyone who actually knows Lisp to refer to it as an
> untyped language then you're off your head :-).
No, not at all, you obviously have missed that other raving thread, where
all this was just discussed in epic length. ;-)
But instead of digging through that thread I believe you're better off just
reading Cardelli.
--
Andreas Rossberg, ········@ps.uni-sb.de
"Computer games don't affect kids; I mean if Pac Man affected us
as kids, we would all be running around in darkened rooms, munching
magic pills, and listening to repetitive electronic music."
- Kristian Wilson, Nintendo Inc.
David Golden <············@oceanfree.net> wrote in message news:<···················@news.indigo.ie>...
> Isaac Gouy wrote:
>
> > As a Smalltalker I used to think like that as-well, then it started to
> > seem more like a glass-half-full thing. Cardelli's term 'untyped'
> > clearly expresses one of the things that Smalltalkers like - no
> > restrictions on the values that a variable or parameter can hold.
> > Cardelli's term 'safe' clearly expresses one of the other things that
> > Smalltalkers like.
>
> But that's the thing. It's not very clear, if you think types are something
> objects rather than variables have (except in the variable-metaobject
> manner I detailed in another post).
Clear enough, when we speak of Cardelli's terms.
Presumably you are speaking of some other definition, and to help
along discussions we could be more specific and talk of Lisp's terms?
> > Would you really want Lisp to be 'typed' in Cardelli's meaning?
>
> No, probably not. But I'm just not about to concede the unqualified word
> "type", seeing as it's the backbone of the lisp language specification,
> which expresses everything in terms of the types objects belong to. I'm
> perfectly happy to say "cardelli's term untyped".
Become equally happy to say "Lisp's term 'typed'" and we'll all have a
better idea what we're talking about.
> But temporarily ceding
> the word "type" when others might have an agenda to permanently co-opt it
> is dangerous...
FUD
best wishes, Isaac
Isaac Gouy wrote:
>
> Become equally happy to say "Lisp's term 'typed'" and we'll all have a
> better idea what we're talking about.
>
I am happy to do so in a cross-posted thread, provided pure-static-typers do
similar, rather than just assuming a dynamic-typer would be comfortable
using the unqualified term "types" to mean types[static].
I would also hold that in a comp.lang.lisp-only discussion rather than an
intergroup one, the lisp usage as defined in the language spec would
normally be native and no qualification would be necessary.
The lisp usage (I'll say types[dyn]) is defined (Hyperspec Glossary):
type n. 1. a set of objects, usually with common structure, behavior, or
purpose.
object n. 1. any Lisp datum.
Just because some parties feel that that's "trivial" is no reason to reject
it offhand, as far as I'm concerned, as, like most simple statements, its
ramifcations aren't so "trivial".
It is far from impossible to talk about some static analysis with
types[dyn], as evidenced by existing lisp compilers. Take it that a
static-checking compiler S is a program that processes some data (that
happen to be a program) P to an executable form P'. S does some clever
analyses of the types[dyn] of the data that constitute P. N.B. These
types[dyn] are Not The Same as the types[dyn] of the data that program P
itself might process! The types[dyn] that P itself might process may
however be an important input for human and compiler into working out the
types[dyn] of the-data-that-are-program-P.
You might do this to produce a faster P' (the usual CL reason for static
analysis) or perhaps tell you that P is "wrong", because the types[dyn]
that S worked out / you declared for the P data (probably based on the
types[dyn] of the data P will process) are inconsistent in the type[dyn]
system.
So thinking in those terms can allow you to come up with solutions similar
or near-identical to some types[static]-using languages anwyay, since
type[static] is quite close to "type[dyn] of datum in P"
David Golden <············@oceanfree.net>:
> But that's the thing. It's not very clear, if you think types are something
> objects rather than variables have (except in the variable-metaobject
> manner I detailed in another post).
In some typed languages (like Haskell), values and expression have types.
There are no variables. When I write
let x = big_hairy_expression in (f x, g x)
x is not a variable with some type, nor is it a
variable-that-holds-a-value-of-some-type. It's just a name that I use
in place of big_hairy_expression so that I don't have to type it twice.
B_h_e has a type, so x has the same type because it's just a stand-in
for b_h_e.
Jesse
I wasn't arguing for global "correctness" of a single usage of the word
type, just illustrating that the definitions can differ.
From: Joe Marshall
Subject: Re: Why I don't believe in static typing
Date:
Message-ID: <vfphqlcq.fsf@comcast.net>
·····@yahoo.com (Isaac Gouy) writes:
>
> Let's be cowardly and defer to authority ;-)
>
> | Safe | Unsafe |
> --------+------+-----------+
> Untyped | Lisp | Assembler |
> Typed | ML | C |
>
``I don't like that sir, don't like that at all.''
-- Caspar Gutman (Sydney Greenstreet in The Maltese Falcon)
--
~jrm
Joe Marshall <·············@comcast.net> wrote in message news:<············@comcast.net>...
> ·····@yahoo.com (Isaac Gouy) writes:
>
> >
> > Let's be cowardly and defer to authority ;-)
> >
> > | Safe | Unsafe |
> > --------+------+-----------+
> > Untyped | Lisp | Assembler |
> > Typed | ML | C |
> >
>
> ``I don't like that sir, don't like that at all.''
> -- Caspar Gutman (Sydney Greenstreet in The Maltese Falcon)
With a nod to Duane Rettig, we could say Cardelli's terms 'typed' and 'untyped'.
"How do you feel now, angel? Any better?" ;-)
From: Duane Rettig
Subject: Re: Why I don't believe in static typing
Date:
Message-ID: <4oev8napw.fsf@franz.com>
·····@yahoo.com (Isaac Gouy) writes:
> Joe Marshall <·············@comcast.net> wrote in message news:<············@comcast.net>...
> > ·····@yahoo.com (Isaac Gouy) writes:
> >
> > >
> > > Let's be cowardly and defer to authority ;-)
> > >
> > > | Safe | Unsafe |
> > > --------+------+-----------+
> > > Untyped | Lisp | Assembler |
> > > Typed | ML | C |
> > >
> >
> > ``I don't like that sir, don't like that at all.''
> > -- Caspar Gutman (Sydney Greenstreet in The Maltese Falcon)
>
> With a nod to Duane Rettig, we could say Cardelli's terms 'typed' and 'untyped'.
>
> "How do you feel now, angel? Any better?" ;-)
That's the spirit!
--
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
Isaac Gouy wrote:
> Joachim Durchholz <·················@web.de> wrote:
>
>> (I'm always thinking about Strongtalk, a Smalltalk derivative with
>> type checking. I always felt that Strongtalk failed not because
>> static typing is useless, or that Smalltalk couldn't be improved
>> with static typing, but because Smalltalk was too flexible to allow
>> static type systems to give interesting guarantees. [...])
>
> Why do you say Strongtalk failed? The technology was working nicely
> when the company was acquired by Sun and the technology adapted to
> Java (HotSpot VM).
It worked, but it wasn't accepted by the Smalltalk community.
Actually, mention of Strongtalk in a Smalltalk group is more likely to
start a flame war than anything else.
Regards,
Jo
Joachim Durchholz <·················@web.de> wrote in message news:<············@news.oberberg.net>...
> Isaac Gouy wrote:
> > Why do you say Strongtalk failed? The technology was working nicely
> > when the company was acquired by Sun and the technology adapted to
> > Java (HotSpot VM).
>
> It worked, but it wasn't accepted by the Smalltalk community.
> Actually, mention of Strongtalk in a Smalltalk group is more likely to
> start a flame war than anything else.
On the contrary!
The flame war would be about the extent to which Strongtalks
technology (polymorphic inline caches) have already been incorporated
into current Smalltalk implementations.
I find it helps to limit searches to Eliot Miranda's postings ;-)
http://groups.google.com/groups?q=strongtalk+miranda&hl=en&lr=&ie=UTF-8&oe=UTF-8&selm=3D2A7E46.2BFFB277%40pacbell.net&rnum=1
You may also find this seminar interesting:
"Bytecode-to-bytecode adaptive optimization for Smalltalk Compilation
and execution architecture for late-bound object-oriented programming
languages"
http://www.stanford.edu/class/ee380/Abstracts/030312.html
http://murl.microsoft.com/videos/stanford/ee380d/030312_OnDemand_100_50K_176x144.htm
best wishes, Isaac
Isaac Gouy wrote:
> Joachim Durchholz <·················@web.de>:
>
>>Isaac Gouy wrote:
>>>Why do you say Strongtalk failed? The technology was working nicely
>>>when the company was acquired by Sun and the technology adapted to
>>>Java (HotSpot VM).
>>
>>It worked, but it wasn't accepted by the Smalltalk community.
>>Actually, mention of Strongtalk in a Smalltalk group is more likely to
>>start a flame war than anything else.
>
> On the contrary!
>
> The flame war would be about the extent to which Strongtalks
> technology (polymorphic inline caches) have already been incorporated
> into current Smalltalk implementations.
OK. You need to mention "static typing" as well to get the flame war.
(Which was what Strongtalk was about IIRC.)
Regards,
Jo
Joachim Durchholz <·················@web.de> wrote in message news:<············@news.oberberg.net>...
> Isaac Gouy wrote:
> > Joachim Durchholz <·················@web.de>:
> >
> >>Isaac Gouy wrote:
> >>>Why do you say Strongtalk failed? The technology was working nicely
> >>>when the company was acquired by Sun and the technology adapted to
> >>>Java (HotSpot VM).
> >>
> >>It worked, but it wasn't accepted by the Smalltalk community.
> >>Actually, mention of Strongtalk in a Smalltalk group is more likely to
> >>start a flame war than anything else.
> >
> > On the contrary!
> >
> > The flame war would be about the extent to which Strongtalks
> > technology (polymorphic inline caches) have already been incorporated
> > into current Smalltalk implementations.
>
> OK. You need to mention "static typing" as well to get the flame war.
> (Which was what Strongtalk was about IIRC.)
The Strongtalk history page lists 3 concerns: speed, type system, native UIs.
best wishes, Isaac
Joachim Durchholz wrote:
> Tayss wrote:
>>
>> Seriously, I can not imagine in this new millenium, that static
>> checking proponents are still talking about compile time.
>
> Come on. 99% of all programmers still work with compilers. (This doesn't
> make working with compilers superior, it just defines the standard case
> from which people tend to argue. Abstract that away when weighing
> arguments.)
Nowadays, many programmers use languages like Perl, Python, Ruby, PHP,
and so on. So I wouldn't be so sure about your estimate.
>> So I'd ask: Could a lisp system be configured so that it runs a
>> static analysis upon runtime errors, or at arbitrary points on
>> arbitrary subsets of code?
>
> I'd prefer the latter: static checking when I want it.
> Checking upon runtime errors is better than nothing, but checking before
> the software hits the end user's desk is still better.
There is an important "class" of end-users who might not want to have
their programs checked before they run it. See
http://www.joint.org/use/2003/Papers/18500041.pdf
Pascal
--
Pascal Costanza University of Bonn
···············@web.de Institute of Computer Science III
http://www.pascalcostanza.de R�merstr. 164, D-53117 Bonn (Germany)
Tayss wrote:
> perhaps you are explaining the
> very real problem of how local fixes to satisfy a static system end up
> damaging code globally.
Huh? I don't understand this very real problem at all.
Can you provide a concrete example?
Regards
--
Adrian Hey
This is no longer interesting. As a result of these threads, I've
researched enough sources and dialogues on this subject that I can
trace to more holistic solutions to code soundness. (I've also
checked up on the philosophy and math issues.) This completely
artificial and bogus static vs. dynamic steel cage match is only a
facet of the larger subject of good programming interfaces.
But to your question...
Adrian Hey <····@NoSpicedHam.iee.org> wrote in message news:<·····················@news.demon.co.uk>...
> Tayss wrote:
> > perhaps you are explaining the
> > very real problem of how local fixes to satisfy a static system end up
> > damaging code globally.
>
> Huh? I don't understand this very real problem at all.
> Can you provide a concrete example?
Multiple static errors at compiletime. Quick fixes so static system
shuts up, with the assumption nothing more is likely wrong. Tests
show failure; bughunting proceeds without information gained from
compiletime (forgotten), the runtime existence of which may have
provided developer with a better interface, giving clues about a
deeper problem.
This scenario/argument claims static /compiletime/ checking loses the
theoretical advantage of pointing out potentially more insidious bugs.
In some cases, the effort of satisfying the type system ("Boy, the
static system caught a lot of them suckers.") can encourage laxness
with other methods of analysis.
This is not an argument against static checking systems in general.
Rather, it is against the mindset of arbitrarily partioning analysis
into "compiletime" and "runtime."
In another post under this topic, I outlined a scenario from the world
of software engineering where emphasis on static compiletime analysis
also suffers disadvantages.
Tayss wrote:
> Multiple static errors at compiletime. Quick fixes so static system
> shuts up, with the assumption nothing more is likely wrong. Tests
> show failure; bughunting proceeds without information gained from
> compiletime (forgotten), the runtime existence of which may have
> provided developer with a better interface, giving clues about a
> deeper problem.
>
> This scenario/argument claims static /compiletime/ checking loses the
> theoretical advantage of pointing out potentially more insidious bugs.
> In some cases, the effort of satisfying the type system ("Boy, the
> static system caught a lot of them suckers.") can encourage laxness
> with other methods of analysis.
>
> This is not an argument against static checking systems in general.
> Rather, it is against the mindset of arbitrarily partioning analysis
> into "compiletime" and "runtime."
I see what you mean, but as you say, this is not really a problem
with static typing. No language can prevent people from shooting
themselves in the foot if they're determined enough.
Regards
--
Adrian Hey
Adrian Hey <····@NoSpicedHam.iee.org> wrote in message news:<·····················@news.demon.co.uk>...
> Tayss wrote:
> > This is not an argument against static checking systems in general.
> > Rather, it is against the mindset of arbitrarily partioning analysis
> > into "compiletime" and "runtime."
>
> I see what you mean, but as you say, this is not really a problem
> with static typing. No language can prevent people from shooting
> themselves in the foot if they're determined enough.
Hmm, it becomes a problem if you give the wrong incentives to the
programmer. When we say, "I want to create a GOOD interface," we
usually mean that we never want to give the user an incentive to do a
bad job.
This is the study of economics; how incentives are used to promote
good behaviors. If you paid your developers based on the number of
bugs they fix, they'll just write more bugs so they can later fix
them. With a programming interface, if you "pay" the user to only
optimize a local maximum, the global may suffer.
Flamewars incentivize people to take one polarized side. Local
maximum, but they become incomplete, one-sided people.
I don't see why you think I disagree. I'm saying that static typing
is powerful enough to have its unique dangers. It takes skill to give
power to people. Lisp is very, very dangerous and I like it that way.
;)
Tayss wrote:
>> > perhaps you are explaining the
>> > very real problem of how local fixes to satisfy a static system end up
>> > damaging code globally.
>>
>> Huh? I don't understand this very real problem at all.
>> Can you provide a concrete example?
>
> Multiple static errors at compiletime. Quick fixes so static system
> shuts up, with the assumption nothing more is likely wrong.
I have no idea what kind of "quick fixes" you are talking about that would
make the type checker just "shut up". Casts, or what?
--
Andreas Rossberg, ········@ps.uni-sb.de
"Computer games don't affect kids; I mean if Pac Man affected us
as kids, we would all be running around in darkened rooms, munching
magic pills, and listening to repetitive electronic music."
- Kristian Wilson, Nintendo Inc.