Arthur Lemmens wrote:
>
> There's one big advantage to finding errors at run-time rather than
> compile-time: you can get a lot more information about the situation
> that caused the error.
No, you get different information. Static analysis can infer global
information that won't be available during runtime, where you just look at
one execution path at a time.
That's why should have both.
- Andreas
--
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.
In article <············@grizzly.ps.uni-sb.de>, ········@ps.uni-sb.de wrote:
> Arthur Lemmens wrote:
> >
> > There's one big advantage to finding errors at run-time rather than
> > compile-time: you can get a lot more information about the situation
> > that caused the error.
>
> No, you get different information. Static analysis can infer global
> information that won't be available during runtime, where you just look at
> one execution path at a time.
>
> That's why should have both.
Yes. The story was not meant to be a warning against *using* static
typing, merely against *relying* on it. I believe that languages that
enforce static typing (as opposed to offering it as an optional tool) tend
to drive people towards relying on it.
E.
Erann Gat wrote:
>>
>> No, you get different information. Static analysis can infer global
>> information that won't be available during runtime, where you just look
>> at one execution path at a time.
>>
>> That's why should have both.
>
> Yes. The story was not meant to be a warning against *using* static
> typing, merely against *relying* on it. I believe that languages that
> enforce static typing (as opposed to offering it as an optional tool) tend
> to drive people towards relying on it.
The subject line you chose suggested otherwise. And I found your reasoning
mildly absurd, especially since the problem in question would be completely
unaffected by any preference wrt typing. You could equally well deduce that
higher-level languages give a false sense of security, because they used
C++ or Java rather than assembly language.
And having been bitten by concurrency issues myself more than once, I would
suspect that the actual bug wasn't in the changes, but already lied buried
in the original code, as somebody else pointed out before.
- Andreas
--
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.
In article <············@grizzly.ps.uni-sb.de>, ········@ps.uni-sb.de wrote:
> Erann Gat wrote:
> >>
> >> No, you get different information. Static analysis can infer global
> >> information that won't be available during runtime, where you just look
> >> at one execution path at a time.
> >>
> >> That's why should have both.
> >
> > Yes. The story was not meant to be a warning against *using* static
> > typing, merely against *relying* on it. I believe that languages that
> > enforce static typing (as opposed to offering it as an optional tool) tend
> > to drive people towards relying on it.
>
> The subject line you chose suggested otherwise.
Well, I chose a title that was deliberately provocative to stir up
debate. This is usenet after all :-)
> And I found your reasoning
> mildly absurd, especially since the problem in question would be completely
> unaffected by any preference wrt typing.
Not directly, no. But I do believe that there was indirect causation. An
overemphasis on static typing led to other issues not receiving the
attention they deserved.
The important point here is not what the programmer did, it's what the
manager did. His reasoning was: we can't use language X because it
doesn't have static typing, and any language that doesn't have static
typing could produce run-time type errors and that would be bad. So we'll
use C++, which has static typing, instead. The use of C++ was, IMO,
directly causal in this case because it was not only a race condition, but
it was a race condition that involved an implicit call to a destructor,
which can only happen in a language without automatic memory management.
So this manager traded one potential problem (run-time type errors) for a
different potential problem with (nearly) disastrous results. But I don't
believe he made this decision consciously. I believe - based on the
conversation I had with him about development methodlogy - that he simply
believed that static type checking trumps everything else, or at the very
least that it has inherent value independent of all other considerations.
And I'm saying that it doesn't.
E.
From: Steven E. Harris
Subject: Re: Why I don't believe in static typing
Date:
Message-ID: <q671xs5nz48.fsf@raytheon.com>
···@jpl.nasa.gov (Erann Gat) writes:
> The use of C++ was, IMO, directly causal in this case because it was
> not only a race condition, but it was a race condition that involved
> an implicit call to a destructor, which can only happen in a
> language without automatic memory management.
That's either the fault of the person who wrote the destructor or the
person who let the object die under unfit circumstances. It's not
C++'s fault. Rather, you could turn it around and look at all the bugs
prevented by having a proper place to put cleanup operations,
guaranteed to run deterministically.
The "implicit call to [the] destructor" is a great source of
reliability in the C++ programs I've worked on. RAII is entirely
founded upon it.
--
Steven E. Harris :: ········@raytheon.com
Raytheon :: http://www.raytheon.com
In article <···············@raytheon.com>, "Steven E. Harris"
<········@raytheon.com> wrote:
> ···@jpl.nasa.gov (Erann Gat) writes:
>
> > The use of C++ was, IMO, directly causal in this case because it was
> > not only a race condition, but it was a race condition that involved
> > an implicit call to a destructor, which can only happen in a
> > language without automatic memory management.
>
> That's either the fault of the person who wrote the destructor or the
> person who let the object die under unfit circumstances. It's not
> C++'s fault. Rather, you could turn it around and look at all the bugs
> prevented by having a proper place to put cleanup operations,
> guaranteed to run deterministically.
>
> The "implicit call to [the] destructor" is a great source of
> reliability in the C++ programs I've worked on. RAII is entirely
> founded upon it.
Well, hurm...
UNWIND-PROTECT is a very useful facility. Whether or not conflating it
with object destruction is the best way to provide it is IMHO highly
questionable.
E.
From: Steven E. Harris
Subject: Re: Why I don't believe in static typing
Date:
Message-ID: <q67wu9xmhyb.fsf@raytheon.com>
···@jpl.nasa.gov (Erann Gat) writes:
> UNWIND-PROTECT is a very useful facility. Whether or not conflating
> it with object destruction is the best way to provide it is IMHO
> highly questionable.
And I agree to that. It makes for a different mode when reading C++
code. For every (especially automatic) object constructed, one must
consider that something just as significant may be happening when that
object goes out of scope.
Perhaps like you, I appreciate how CL calls out these special cases
with unwind-protect, much like C++98 (and beyond) encourages verbosity
in casting operators (such as the deliberately ugly and hard to type
reinterpret_cast<>).
Somewhere in between quiet destructors and unwind-protect lies Andrei
Alexandrescu's ScopeGuard�, albeit raising the same suspicion at what
happens at the closing curly brace.
Footnotes:
� http://www.cuj.com/documents/s=8000/cujcexp1812alexandr/
(In particular, look at ON_BLOCK_EXIT near the end.)
--
Steven E. Harris :: ········@raytheon.com
Raytheon :: http://www.raytheon.com
Erann Gat wrote:
>>The "implicit call to [the] destructor" is a great source of
>>reliability in the C++ programs I've worked on. RAII is entirely
>>founded upon it.
>
>
> Well, hurm...
>
> UNWIND-PROTECT is a very useful facility. Whether or not conflating it
> with object destruction is the best way to provide it is IMHO highly
> questionable.
Conflation is a good idea as long as you can guarantee that the
destructor has no side effects /on the program/.
In other words: you are safe if all side effects that the destructor
causes are unnoticeable for the program (after all, the destructor is
supposed to be called when it becomes known that the object in question
becomes inaccessible).
You are unsafe if the object stays accessible after the destructor was
called (possibly due to aliasing, or inadvertent explicit calls to the
destructor - that's probably what caused the race condition). You are
also unsafe if the destructor has side effects such as modifying global
data, since it's an effect that isn't represented syntactically (which
means that the effect will most likely be overlooked during code review
- a nasty source of potential errors).
In other words: the conflation is a rather bad idea in C++, but if used
carefully, it can help improve code quality. (This can be said about a
lot of facilities in C++. C++ is a language for the paranoid who're
permanently ultra-careful.)
The conflation should work beautifully in languages that exert control
over side effects. I think Mercury and/or Clean do this: side effects
are allowed, but language rules make sure that mutable objects are never
aliased. (It's a bit Draconian in my eyes, but right now I'm not talking
about the usefulness of such an approach but about conditions under
which C++-style destructor logic makes sense. Besides, it may entirely
be that preventing aliasing is the best compromise available even if
it's Draconian; time may tell.)
Regards,
Jo
From: Steven E. Harris
Subject: Re: Why I don't believe in static typing
Date:
Message-ID: <q67brr813tn.fsf@raytheon.com>
Joachim Durchholz <·················@web.de> writes:
> You are also unsafe if the destructor has side effects such as
> modifying global data, since it's an effect that isn't represented
> syntactically (which means that the effect will most likely be
> overlooked during code review - a nasty source of potential errors).
Sometimes using a destructor in the RAII idiom is the only way to
achieve safety without code duplication, whether or not it has effect
on "global" data or any data with wider scope. Consider that
destruction may be triggered by exception-induced stack
unwinding. RAII makes "do/undo" actions both safe and concise.
Consider this simple example, from production code:
,----[ overlay.hh ]
| #ifndef OVERLAY_HH
| #define OVERLAY_HH
|
| #include "noncopyable.hh"
|
|
| template <typename T>
| class overlay : noncopyable
| {
| public:
| typedef T value_type;
|
| overlay(value_type& val,
| const value_type& overlaid_value)
| : val_( val ),
| original_value_( val_ )
| { val_ = overlaid_value; }
|
| ~overlay()
| { val_ = original_value_; }
|
| private:
| value_type& val_;
| const value_type original_value_;
| };
|
|
| #endif // OVERLAY_HH
`----
An "overlay" is temporary, scoped assignment to some other mutable
variable that will be undone upon the overlay's destruction, similar
to Perl's "local" declaration or layered assignment to special
variables in CL.
Assuming that the value_type's assignment operator can't throw an
exception, using an overlay is safe and is safer than writing four
separate, explicit assignment statements (one to store the original
value, one to change the value, another to restore the original value
under normal exit, and yet another to restore the value in case of a
caught exception, presumably before rethrowing).
The cleanup is not represented syntactically, but the symmetric
promise is: I may change this variable here, and I will change it back
before going away.
{
int i = 0;
try
{
const overlay<int> o( i, 1 );
// We're not leaving until i is 0 again.
std::cout << i << '\n';
throw std::runtime_error( "bang!" );
}
catch ( ... )
{ std::cout << i << '\n'; }
}
--
Steven E. Harris :: ········@raytheon.com
Raytheon :: http://www.raytheon.com
Steven E. Harris wrote:
> Joachim Durchholz <·················@web.de> writes:
>
>
>>You are also unsafe if the destructor has side effects such as
>>modifying global data, since it's an effect that isn't represented
>>syntactically (which means that the effect will most likely be
>>overlooked during code review - a nasty source of potential errors).
>
> Sometimes using a destructor in the RAII idiom is the only way to
> achieve safety without code duplication, whether or not it has effect
> on "global" data or any data with wider scope. Consider that
> destruction may be triggered by exception-induced stack
> unwinding. RAII makes "do/undo" actions both safe and concise.
>
> Consider this simple example, from production code:
>
> ,----[ overlay.hh ]
> | #ifndef OVERLAY_HH
> | #define OVERLAY_HH
> |
> | #include "noncopyable.hh"
> |
> |
> | template <typename T>
> | class overlay : noncopyable
> | {
> | public:
> | typedef T value_type;
> |
> | overlay(value_type& val,
> | const value_type& overlaid_value)
> | : val_( val ),
> | original_value_( val_ )
> | { val_ = overlaid_value; }
> |
> | ~overlay()
> | { val_ = original_value_; }
> |
> | private:
> | value_type& val_;
> | const value_type original_value_;
> | };
> |
> |
> | #endif // OVERLAY_HH
> `----
>
> An "overlay" is temporary, scoped assignment to some other mutable
> variable that will be undone upon the overlay's destruction, similar
> to Perl's "local" declaration or layered assignment to special
> variables in CL.
Hmm... in a functional language, I don't need this since there is no
assignment.
In other words, a functional language would create new nodes for those
that would be changed, and shares the rest of the tree (since data is
immutable, sharing is always harmless).
Under that regime, I simply don't need overlays. I just use the modified
data, and the caller retains his copy of the unmodified data.
But that's just an aside note. The problem is still interesting in itself.
What's to the point is that restoring the original value actually undoes
the global side effect; from a caller's perspective, the destructor
restores things to an "unchanged, no global side effects" state.
Bad things might happen if an overlay is passed down as a parameter, or
ever escapes lexical scope (but inheriting from "noncopyable" might
restrict that...)
... which brings me back to the above off-topic point: that overlay
class is an ingenious way of doing the Wrong Thing. But then C++ often
doesn't offer a way to do the Right Thing with a reasonable effort
(which, in the above case, would have been to use immutable data
structures and use copying and garbage collection, but that would
probably have required too much code rewriting in the project's context).
> Assuming that the value_type's assignment operator can't throw an
> exception,
Which, unfortunately, is one of those things that you have to keep a
permanent lookout for in C++. Since you can't enforce this property for
any future data type that might be used with that overlay idiom, this is
a catastrophe waiting to happen, a long time after the error was
actually made.
It's one of those little things that make C++ programming error-prone.
OK, I keep digressing. It's not the point you're trying to make.
Sorry.
> using an overlay is safe and is safer than writing four
> separate, explicit assignment statements (one to store the original
> value, one to change the value, another to restore the original value
> under normal exit, and yet another to restore the value in case of a
> caught exception, presumably before rethrowing).
Agreed (modulo that I wouldn't use overlays in the first place, see above).
> The cleanup is not represented syntactically, but the symmetric
> promise is: I may change this variable here, and I will change it back
> before going away.
Agreed.
Regards,
Jo
Erann Gat wrote:
> Joachim Durchholz <·················@web.de> wrote:
>
>> Conflation [of object destruction and resource deallocation] is a
>> good idea as long as you can guarantee that the destructor has no
>> side effects /on the program/.
>
> That's true, but this can never be the case in general because the
> destructor *always* has, by definition, the side-effect of destroying
> the object. This is safe only if the object is not shared among
> threads, which is a very severe (and generally unenforcable)
> constraint.
Threading doesn't make much of a difference, destroying an object and
calling the destructor is dangerous whether the aliases live within the
same thread or elsewhere. (Note that aliasing happens if there is
sharing and vice versa. The two are describing the same thing.)
BTW Erlang philosophy states that objects should /never/ be shared
across threads, and Erlang enforces this simply by offering no way to do
that, so it's easy enough to enfoce.
From what I hear from the Erlang camp, the constraint isn't severe as
well; in fact, they consider this as a key property of systems that
remain stable in the presence of software errors.
Regards,
Jo
On Wed, 19 Nov 2003 21:35:52 +0100, Joachim Durchholz wrote:
> BTW Erlang philosophy states that objects should /never/ be shared
> across threads, and Erlang enforces this simply by offering no way to do
> that, so it's easy enough to enfoce.
Aren't processes themselves shared by other processes which communicate
with them? Passing a process handle between processes is equivalent to
passing a reference to shared mutable data.
--
__("< Marcin Kowalczyk
\__/ ······@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
Marcin 'Qrczak' Kowalczyk <······@knm.org.pl> wrote in message news:<······························@knm.org.pl>...
> On Wed, 19 Nov 2003 21:35:52 +0100, Joachim Durchholz wrote:
>
> > BTW Erlang philosophy states that objects should /never/ be shared
> > across threads, and Erlang enforces this simply by offering no way to do
> > that, so it's easy enough to enfoce.
>
> Aren't processes themselves shared by other processes which communicate
> with them? Passing a process handle between processes is equivalent to
> passing a reference to shared mutable data.
In what way is "passing a process handle between processes" equivalent to
passing a reference to shared mutable data?
"The Erlang view of the world...
Message passing is the only way for processes to interact.
Processes have unique names.
If you know the name of a process you can send it a message.
Processes share no resources..." p40
http://www.sics.se/~joe/thesis/armstrong_thesis_2003.pdf
In my understanding, nothing is shared, values are copied.
best wishes, Isaac
On Thu, 20 Nov 2003 07:29:32 -0800, Isaac Gouy wrote:
> In what way is "passing a process handle between processes" equivalent to
> passing a reference to shared mutable data?
Processes are used to implement mutable data (by responding to messages
which change and query their internal state).
> In my understanding, nothing is shared, values are copied.
Processes themselves are shared. Don't look just at terms; a process can
represent mutable data, and process handle is a pointer to it. When you
pass a process handle to another process, both processes refer to the same
process and it responds to messages from both in whatever order they arrive.
Erlang models mutable data by processes and they are shared, not copied.
--
__("< Marcin Kowalczyk
\__/ ······@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
Isaac Gouy wrote:
> Marcin 'Qrczak' Kowalczyk <······@knm.org.pl> wrote:
>>
>> Aren't processes themselves shared by other processes which
>> communicate with them? Passing a process handle between processes
>> is equivalent to passing a reference to shared mutable data.
>
> In what way is "passing a process handle between processes"
> equivalent to passing a reference to shared mutable data?
>
> "The Erlang view of the world... Message passing is the only way for
> processes to interact. Processes have unique names. If you know the
> name of a process you can send it a message. Processes share no
> resources..." p40
>
> http://www.sics.se/~joe/thesis/armstrong_thesis_2003.pdf
>
> In my understanding, nothing is shared, values are copied.
It's not "shared memory" in the Unix sense, but it's not Unix shared
memory that's the problem, it's sharing of mutable data (aka aliasing).
Since a process ID is essentially a reference to mutable data (namely
the process itself, why by definition is mutable), this is a an exception.
Well, if you want interacting processes, it's kind of unavoidable :-)
I don't know why this Erlangers don't consider this much of a
difference. I can offer several possibilities:
* Process IDs are just a tiny fraction of data exchange. Moreover, they
are typically exchanged during process setup and never further
propagated further. This restricted use eliminates many failure modes
related to shared memory.
* Possibly, the problems are there but not perceived as a deficit in
Erlang's semantics.
Regards,
Jo
> I don't know why this Erlangers don't consider this much of a
> difference. I can offer several possibilities
thanks, Marcin, Jo
we should probably just ask on the Erlang list
Marcin 'Qrczak' Kowalczyk wrote:
> On Wed, 19 Nov 2003 21:35:52 +0100, Joachim Durchholz wrote:
>
>>BTW Erlang philosophy states that objects should /never/ be shared
>>across threads, and Erlang enforces this simply by offering no way to do
>>that, so it's easy enough to enfoce.
>
> Aren't processes themselves shared by other processes which communicate
> with them? Passing a process handle between processes is equivalent to
> passing a reference to shared mutable data.
Right.
Regards,
Jo
···@jpl.nasa.gov (Erann Gat) writes:
> The important point here is not what the programmer did, it's what the
> manager did. His reasoning was: we can't use language X because it
> doesn't have static typing, and any language that doesn't have static
> typing could produce run-time type errors and that would be bad. So we'll
> use C++, which has static typing, instead.
Any manager that believes that C++ does not have runtime errors is grossly
incompetent.
--
Cheers, The Rhythm is around me,
The Rhythm has control.
Ray Blaak The Rhythm is inside me,
········@STRIPCAPStelus.net The Rhythm has my soul.
In article <·············@STRIPCAPStelus.net>, Ray Blaak
<········@STRIPCAPStelus.net> wrote:
> ···@jpl.nasa.gov (Erann Gat) writes:
> > The important point here is not what the programmer did, it's what the
> > manager did. His reasoning was: we can't use language X because it
> > doesn't have static typing, and any language that doesn't have static
> > typing could produce run-time type errors and that would be bad. So we'll
^^^^^^^^^^^
> > use C++, which has static typing, instead.
>
> Any manager that believes that C++ does not have runtime errors is grossly
> incompetent.
That is certainly true, but it has nothing to do with what I said.
E.
···@jpl.nasa.gov (Erann Gat) writes:
> In article <·············@STRIPCAPStelus.net>, Ray Blaak
> > ···@jpl.nasa.gov (Erann Gat) writes:
> > > The important point here is not what the programmer did, it's what the
> > > manager did. His reasoning was: we can't use language X because it
> > > doesn't have static typing, and any language that doesn't have static
> > > typing could produce run-time type errors and that would be bad. So we'll
> ^^^^^^^^^^^
> > > use C++, which has static typing, instead.
> >
> > Any manager that believes that C++ does not have runtime errors is grossly
> > incompetent.
>
> That is certainly true, but it has nothing to do with what I said.
Ah. I stand corrected. However, now that I think about it:
Any manager that believes that C++ does not have runtime *type* errors is
grossly incompetent.
--
Cheers, The Rhythm is around me,
The Rhythm has control.
Ray Blaak The Rhythm is inside me,
········@STRIPCAPStelus.net The Rhythm has my soul.
In article <····················@k-137-79-50-101.jpl.nasa.gov>,
Erann Gat <···@jpl.nasa.gov> wrote:
>The important point here is not what the programmer did, it's what the
>manager did. His reasoning was: we can't use language X because it
>doesn't have static typing, and any language that doesn't have static
>typing could produce run-time type errors and that would be bad. So we'll
>use C++, which has static typing, instead. The use of C++ was, IMO,
>directly causal in this case because it was not only a race condition, but
>it was a race condition that involved an implicit call to a destructor,
>which can only happen in a language without automatic memory management.
>So this manager traded one potential problem (run-time type errors) for a
>different potential problem with (nearly) disastrous results. But I don't
>believe he made this decision consciously. I believe - based on the
>conversation I had with him about development methodlogy - that he simply
>believed that static type checking trumps everything else, or at the very
>least that it has inherent value independent of all other considerations.
>And I'm saying that it doesn't.
On the other hand, Lisp doesn't have destructors at all because of its
automatic memory management. If you need to take care of cleaning up
state, you have to do some extra programming to handle it, whereas C's
implicit destructor calls are often just the right thing. This isn't going
to be familiar territory to Lisp programmers, so the chance of them getting
it right goes down.
Choosing a language almost always involves some trade-offs -- there's no
ultimate language that solves every problem. You pick your poison.
His logic isn't all that flawed. Program validation involves lots of
testing, and anything that reduces the dynamic conditions that you need to
test for seems like a good thing. All other things being equal (yes, I
know they aren't), static typing means that you don't have to do as much
testing for potential type errors, and can concentrate more on other things
during testing. Unfortunately, it seems like the programmers dropped the
ball on that -- they somehow seemed to be of the mind-set that using this
language allowed them to do even less testing than was necessary, so they
never discovered the timing problem.
--
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.
Erann Gat <···@jpl.nasa.gov> wrote:
>
> Well, I chose a title that was deliberately provocative to stir up
> debate. This is usenet after all :-)
True, but even on usenet there is mildly constructive debate and much less
constructive debate, and different ways to stir them up effectively. ;-)
> The important point here is not what the programmer did, it's what the
> manager did. His reasoning was: we can't use language X because it
> doesn't have static typing, and any language that doesn't have static
> typing could produce run-time type errors and that would be bad. So we'll
> use C++, which has static typing, instead. The use of C++ was, IMO,
> directly causal in this case because it was not only a race condition, but
> it was a race condition that involved an implicit call to a destructor,
> which can only happen in a language without automatic memory management.
That GC usually is much more important than typing I happily agree with. But
that's a much narrower claim.
> So this manager traded one potential problem (run-time type errors) for a
> different potential problem with (nearly) disastrous results. But I don't
> believe he made this decision consciously. I believe - based on the
> conversation I had with him about development methodlogy - that he simply
> believed that static type checking trumps everything else,
Nobody in his sane mind would think that - particular when it comes in the
lumps of C++.
> or at the very
> least that it has inherent value independent of all other considerations.
> And I'm saying that it doesn't.
Not sure how you mean that. I'd say it has inherent value, but not
necessarily high enough to outweigh other considerations.
- Andreas
Erann Gat wrote:
>
> The important point here is not what the programmer did, it's what
> the manager did. His reasoning was: we can't use language X because
> it doesn't have static typing, and any language that doesn't have
> static typing could produce run-time type errors and that would be
> bad. So we'll use C++, which has static typing, instead. The use of
> C++ was, IMO, directly causal in this case because it was not only a
> race condition, but it was a race condition that involved an implicit
> call to a destructor, which can only happen in a language without
> automatic memory management.
It's an entirely valid case against assuming that static types are a
panacea, and it's an even more compelling case that C++ is a language
that gives you enough rope to hang yourself and a pistol to ensure success.
It's even less about static typing than your initial description. A
dynamically-typed language could have implicitly-called constructors
just a well (but nobody does that, with good reasons).
> So this manager traded one potential problem (run-time type errors)
> for a different potential problem with (nearly) disastrous results.
> But I don't believe he made this decision consciously. I believe -
> based on the conversation I had with him about development methodlogy
> - that he simply believed that static type checking trumps everything
> else, or at the very least that it has inherent value independent of
> all other considerations. And I'm saying that it doesn't.
Well, I didn't read a single post that shared that manager's opinion.
Which says a lot about the assumptions of managers on the benefits of
static typing, and very little about the actual benefits of static typing.
In other words: no, you didn't make a point about static typing. You
made a point about some particular misconception about static typing.
Actually, I agree with your implicit argument that programming is mostly
not a technical problem but a social and mental one: programming
languages have to take programmer and manager expectation into account.
If the particular misconception of that manager were widespread, I'd
indeed strongly advocate designing languages in a way that discourages it.
However, I don't think it's that widespread. The vast majority of
managers that I met had a quite healthy idea about what programming was
and what the various techniques could (or could not) achieve.
Typical knee-jerk reactions are "dynamic typing is bad because then I'd
have to do far more testing, and I'd never be sure to catch all type
errors", or (even more telling, so never stated flatly) "static typing
will move an entire class of errors out of the scope of things I have to
think about, and I like to think less".
These reactions prevent serious debate on the virtues and flaws of
either method, which is unfortunate. They also tend to make managers and
programmers shoehorn problems into static type systems that weren't
designed for the task (one of the reasons why most type systems,
including those of Java and C++, suck: they aren't expressive enough,
yet too unsafe).
Which is also a great case for immutable data. Mutability destroys most
subtype relationships, which sort of buries all hopes of ever making
traditional OO languages work well. I also heard it makes type inference
more difficult, but I don't know what's the problem here (could anybody
clarify?).
Regards,
Jo
In article <··························@k-137-79-50-101.jpl.nasa.gov>,
Erann Gat <·········@jpl.nasa.gov> wrote:
>In article <············@news.oberberg.net>, Joachim Durchholz
><·················@web.de> wrote:
>
>> Well, I didn't read a single post that shared that manager's opinion.
>> Which says a lot about the assumptions of managers on the benefits of
>> static typing, and very little about the actual benefits of static typing.
>
>I think it says more about the mindset of people who hang out on
>comp.lang.lisp and comp.lang.functional. But this particular manager was
>not your typical PHB either. He came from academia, where he was a well
>known and respected researcher. He was, in fact, a very smart person.
Even Very Smart People can have mental blocks, get stuck in a paradigm,
etc. It took a long time for Einstein to be convinced of the validity of
Quantum Mechanics, and if String Theory turns out to be correct many
modern, well-respected physicists will have to recant.
There's also an issue that a mind-set that works in academia may not
translate well to industry, because the constraints are different. The
need to get product out the door often requires cutting corners, so you
can't apply all the cool ideas you developed in the research lab.
--
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.
Jesse Tov wrote:
> Joachim Durchholz <·················@web.de>:
>
>>traditional OO languages work well. I also heard it makes type inference
>>more difficult, but I don't know what's the problem here (could anybody
>>clarify?).
>
> Well, consider the value restriction in Standard ML. If I write:
>
> val r = ref []
>
> Then r would have the type 'a list ref. So, I should be able to do
> something like:
>
> r := 2 :: !r
>
> and also something like:
>
> r := "three" :: !r
>
> But this is obviously unsound.
Ah, I see.
Essentially it's the same as the process that destroys subtyping
relationships:
Reading from a name restricts the allowable types for that name to the
type that the reader expects, plus all types that are subtypes.
Writing to a name has the reverse effect, allowable types are restricted
upwards towards supertypes. I'm not sure whether HM typing can handle
this kind of constraint at all.
Reading and writing the same name usually results in having both an
upwards /and/ a downwards restriction, making the name monomorphic.
In an OO context, this means that the name cannot be redefined at all in
a subclass without making the subclass a non-subtype.
In an FPL context, I suspect that HM typing will either be forced into
making the name monomorphic (not desirable since that directly inhibits
many forms of reuse), or fail because there is no valid types-to-names
association. (Hope I understood this correctly. Corrections welcome.)
Regards,
Jo
On Wed, 19 Nov 2003 18:51:23 +0000, Jesse Tov wrote:
> SML'90 had a different restriction, and I don't know what Ocaml does.
Basically the same as SML'97.
Recently it got extended to allow to generalize a bit more, I think it
generalizes type variables which appear only in covariant positions.
Haskell can generalize all type variables because creation of a reference
is not expressed as an application of a function but as a monadic action
(obviously, because it's not referentially transparent), and thus the
variable which hands the reference is lambda-bound instead of let-bound,
so references don't cause problems in generalizing all type variables in
types of let-bound variables.
There is a so called monomorphism restriction which looks related, but
it has a different reason: to avoid recomputation where it would not be
obvious that it's performed multiple times. It can be circumvented by
providing an explicit type signature.
--
__("< Marcin Kowalczyk
\__/ ······@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
Marcin 'Qrczak' Kowalczyk wrote:
>
> Haskell can generalize all type variables because creation of a reference
> is not expressed as an application of a function but as a monadic action
> (obviously, because it's not referentially transparent), and thus the
> variable which hands the reference is lambda-bound instead of let-bound,
> so references don't cause problems in generalizing all type variables in
> types of let-bound variables.
Haskell programmers can still encounter this problem, though, if they use
the unsafePerformIO primitive that is provided by most implementations. It
is unsound for precisely the same reason.
> There is a so called monomorphism restriction which looks related, but
> it has a different reason: to avoid recomputation where it would not be
> obvious that it's performed multiple times.
I always found it obscure that Haskell gave up its obvious advantage here
for such unconvincing reasons. As if a warning wouldn't suffice.
- Andreas
--
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.
Andreas Rossberg wrote:
> I always found it obscure that Haskell gave up its obvious advantage here
> for such unconvincing reasons. As if a warning wouldn't suffice.
I seem to recall that the restriction does Good Things for type-
checking existentials.
David
Don't ask /me/ why.
Feuer wrote:
>
> I seem to recall that the [monorphism] restriction does Good Things for
type-
> checking existentials.
Mh, that's news to me. If you happen to rediscover some pointer, please let
me know.
I only remember subtle issues with implicit parameters.
- Andreas
--
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.
Feuer <·····@his.com> writes:
>Andreas Rossberg wrote:
>
>> I always found it obscure that Haskell gave up its obvious advantage here
>> for such unconvincing reasons. As if a warning wouldn't suffice.
>
>I seem to recall that the restriction does Good Things for type-
>checking existentials.
Please elaborate?
--
Fergus Henderson <···@cs.mu.oz.au> | "I have always known that the pursuit
The University of Melbourne | of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh> | -- the last words of T. S. Garp.
Fergus Henderson wrote:
>
> Feuer <·····@his.com> writes:
>
> >Andreas Rossberg wrote:
> >
> >> I always found it obscure that Haskell gave up its obvious advantage here
> >> for such unconvincing reasons. As if a warning wouldn't suffice.
> >
> >I seem to recall that the restriction does Good Things for type-
> >checking existentials.
>
> Please elaborate?
I can't. Maybe someone who knows something abou ttype systems can.
David
Andreas Rossberg wrote:
> Haskell programmers can still encounter this problem, though, if they use
> the unsafePerformIO primitive that is provided by most implementations. It
> is unsound for precisely the same reason.
People who use unsafePerformIO had better be doing something
fundamentally unimportant with it or be wizards writing IO libraries.
David
Marcin 'Qrczak' Kowalczyk wrote:
> There is a so called monomorphism restriction which looks related, but
> it has a different reason: to avoid recomputation where it would not be
> obvious that it's performed multiple times. It can be circumvented by
> providing an explicit type signature.
Sometimes it can; sometimes it can't. I don't remember when it can
or can't, but something should definitely be done to make it
make more sense.
David
From: Joe Marshall
Subject: Re: Why I don't believe in static typing
Date:
Message-ID: <smkj58wt.fsf@ccs.neu.edu>
Joachim Durchholz <·················@web.de> writes:
> It's an entirely valid case against assuming that static types are a
> panacea, and it's an even more compelling case that C++ is a language
> that gives you enough rope to hang yourself and a pistol to ensure success.
More like a grenade. You can aim a pistol.
Joe Marshall wrote:
> Joachim Durchholz <·················@web.de> writes:
>
>>It's an entirely valid case against assuming that static types are a
>>panacea, and it's an even more compelling case that C++ is a language
>>that gives you enough rope to hang yourself and a pistol to ensure success.
>
> More like a grenade. You can aim a pistol.
ROTFL!
Regards,
Jo
Jesse Tov <···@eecs.harvREMOVEard.edu> wrote:
>
> SML'90 had a different restriction, and I don't know what Ocaml does.
Ocaml does the same (and actually was first to do so). SML'90 distinguished
"imperative" from "applicative" type variables (SML/NJ went even further and
introduced several levels of imperativeness). That allowed more functions to
be polymorphic, but was more difficult to understand and particularly had
the unpleasent effect that implementation details of abstractions could leak
through the imperativeness attribute of type variables and pollute
interfaces. So it was abandoned for the simpler rule we have now (which is:
treating every type variable as fully imperative).
- Andreas
···@jpl.nasa.gov (Erann Gat) writes:
> Yes. The story was not meant to be a warning against *using* static
> typing, merely against *relying* on it. I believe that languages that
> enforce static typing (as opposed to offering it as an optional tool) tend
> to drive people towards relying on it.
As Barry pointed out elsewhere, a similar argument can be made about
garbage collection. If you want annecdotes about people *relying* on
it and the resulting processes that growing wildly and have to be
killed then I have some. That doesn't mean I think GC is bad, on the
contrary I'll use it whenever I can, I just don't think that as soon
as I use it I can forget about other kinds of errors. Same goes for
static types.
Erann Gat wrote:
> Yes. The story was not meant to be a warning against *using* static
> typing, merely against *relying* on it.
The subject line you chose essentially says the opposite. (It's possible
that it doesn't say what you wanted it so say.)
Regards,
Jo
From: Isaac Gouy
Subject: Re: Why I don't believe in static typing to the same extent that those who advocate static typing seem to believe in it
Date:
Message-ID: <ce7ef1c8.0311191636.1b83d329@posting.google.com>
·········@jpl.nasa.gov (Erann Gat) wrote in message news:<··························@k-137-79-50-101.jpl.nasa.gov>...
> In article <············@news.oberberg.net>, Joachim Durchholz
> <·················@web.de> wrote:
>
> > Erann Gat wrote:
> > > Yes. The story was not meant to be a warning against *using* static
> > > typing, merely against *relying* on it.
> >
> > The subject line you chose essentially says the opposite. (It's possible
> > that it doesn't say what you wanted it so say.)
>
> The opposite? "I don't believe in X" means the opposite of "I don't
> believe in relying on X?" That's news to me.
>
> I have changed the subject line to more accurately reflect my position.
we could have pizza for dinner, but you don't like pizza
i just don't like pizza as-much-as you like pizza
The original subject line was a little more absolute ;-)
best wishes, Isaac
Andreas Rossberg <········@ps.uni-sb.de> wrote:
> No, you get different information. Static analysis can infer global
> information that won't be available during runtime, where you just
> look at one execution path at a time.
>
> That's why should have both.
Definitely. Getting static type *information* is great. But getting an
impenetrable static type *barrier*, that won't let you run a program
just because it might cause a type error at run-time, is not so great.
It makes it more difficult to explore many paths in the search space from
ideas to useful programs.
Arthur Lemmens
Arthur Lemmens wrote:
>
> Getting static type *information* is great. But getting an
> impenetrable static type *barrier*, that won't let you run a program
> just because it might cause a type error at run-time, is not so great.
> It makes it more difficult to explore many paths in the search space from
> ideas to useful programs.
OTOH, erecting barriers of one kind or the other is the only way to
*localise* (confine) errors.
- Andreas
--
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.