In article <··············@ID-7776.user.dfncis.de>, Dirk Thierbach
<··········@gmx.de> wrote:
> Erann Gat <···@jpl.nasa.gov> wrote:
>
> > But the ad-server was multi-threaded, and it turned out that
> > there was a race condition.
>
> Nobody expects static typing to guard against race conditions.
Not consciously, no. But tacitly, yes, I think people do expect this,
even if they don't realize it.
> You guard against race conditions by careful programming, and by
> planning in advance.
Or by putting in run-time sanity checks. If I had had the foresight and
the strength of my own convictions I would have put code into the biller
that stopped the billing process immediately as soon as a request was made
to bill a ridiculously high amount, for some value of "ridiculously
high". That would have solved the problem too.
Neither static nor dynamic typing would have helped in this situation.
But I do believe that a dynamic typing *mindset* would have been more
likely to produce a correct solution because it encourages you to think
more about possible run-time errors.
E.
···@jpl.nasa.gov (Erann Gat) wrote in message news:<····················@192.168.1.51>...
> In article <··············@ID-7776.user.dfncis.de>, Dirk Thierbach
> <··········@gmx.de> wrote:
> > You guard against race conditions by careful programming, and by
> > planning in advance.
>
> Or by putting in run-time sanity checks. If I had had the foresight and
> the strength of my own convictions I would have put code into the biller
> that stopped the billing process immediately as soon as a request was made
> to bill a ridiculously high amount, for some value of "ridiculously
> high". That would have solved the problem too.
>
> Neither static nor dynamic typing would have helped in this situation.
> But I do believe that a dynamic typing *mindset* would have been more
> likely to produce a correct solution because it encourages you to think
> more about possible run-time errors.
Neither a static nor dynamic typing *mindset* would have helped,
that's clear as soon as you say "more likely to produce a correct
solution".
Maybe the interesting question is "How can we program systems which
behave in a reasonable manner in the presence of software errors?"
The Erlang community seems to have some coherent ideas about that
question.
(Thanks for starting a new discussion, the old thread had become
difficult to follow.)
best wishes, Isaac
Isaac Gouy wrote:
> Maybe the interesting question is "How can we program systems which
> behave in a reasonable manner in the presence of software errors?"
>
> The Erlang community seems to have some coherent ideas about that
> question.
For those who don't want to dig it up, here's the Erlang "philosophy" in
a nutshell, filtered through my understanding:
1) Decouple the task at hand into many (>> 100, often >> 10.000)
processes. (You need your own scheduler to do that, OS schedulers
usually aren't up to that task. Processes also need to be extremely
lightweight, both in terms of size overhead and in terms of process
switching time.)
2) Use copying semantics to communicate between processes. No "shared
memory", at least not conceptually. That way, if one process crashes
(something that we expect since software is buggy), it will not be able
to affect the data that other processes are working with. (This is what
Erlangers mean if they say "message passing semantics" - the messages
are copied, not transmitted by reference.)
3) If a process runs into a problem, let it crash as quickly as
possible. "Problem" in this context means /uncorrectable/ problem, that
is, if the programmer has no idea what the process should do in some
specific circumstance. (Actually the advice goes even further: if the
specification is incomplete and a situation occurs that's not described,
the programmer shouldn't try to fill in the gaps, he should simply throw
an exception that will crash the process.)
4) Processes have supervisor processes. If a process crashes, the
supervisor is reliably informed that the process has crashed. Usually,
the supervisor should also get a stack dump and other information that
might help diagnose the crash, but that's more for giving the
programmers a clue than for the operation of the system itself. (It's
still important, of course.)
5) If a supervisor finds that a child has crashed, it should restart it
(possibly after restarting other processes that must be restarted
together with it). This is to work around transient problems, such as
read errors, nonfatal race conditions (they tend to be nonfatal because
processes crash at the earliest opportunity, i.e. usually before any
corrupted data makes it into a permanent data pool).
6) If restarting results in an immediate crash (for some
application-dependent definition of "immediate"), assume the failure is
permanent. Either let the supervisor itself crash (causing a
higher-level supervisor to inspect the problem). Alternatively, start a
simpler (set of) process(es) that will render a restricted set of
services. (In other words, if a telephone finds that its dialling
process crashes permanently, shut it down. Let the process for receiving
phone calls continue, or - if dialling and receiving processes are
interrelated - shut down the receiving process and restart a simpler
receiver process that doesn't interact with dialling.)
I haven't programmed with that paradigm, but from my experience with
other paradigms, I'd say that this has potential.
It isn't entirely necessay to map this all to processes. Processes with
a copying communication semantics are just the easiest and historically
most reliable strategy for achieving fail-safe independence between
program parts. A language that uses immutable data almost exlusively,
offers strong barriers between those domains that do use mutable data,
and has an Eiffel-style exception mechanism (designed for shutting down
faulty software, not for shortcut control transfers) should be able to
apply this mindset just as well.
Generally, it's a "let it crash, have other software layers correct the
problem if possible, have these other layers diagnose it anyway" philosophy.
As a side benefit, it allows "aggressive programming". You don't litter
your code with error handling, you simply trigger an exception if things
go wrong unexpectedly.
Just my understanding, as far as I gleaned it from Joe Armstrong's
doctoral thesis. (Thanks to Joe for explaining the issues so clearly, it
made a lot of things explicit that would have remained implicit for me
if not written down in his thesis.)
Regards,
Jo
Joachim Durchholz <·················@web.de> wrote in message news:<···········@news.oberberg.net>...
> Isaac Gouy wrote:
> > Maybe the interesting question is "How can we program systems which
> > behave in a reasonable manner in the presence of software errors?"
> >
> > The Erlang community seems to have some coherent ideas about that
> > question.
-snip-
> Just my understanding, as far as I gleaned it from Joe Armstrong's
> doctoral thesis. (Thanks to Joe for explaining the issues so clearly, it
> made a lot of things explicit that would have remained implicit for me
> if not written down in his thesis.)
Yes, now I've read through the thesis Erlang seems very pragmatic -
before Erlang just seemed cool ;-)
He repeatedly credits the fundamental principles in Jim Gray's work at
Tandem computers: "Why Do Computers Stop And What Can Be Done About
It?"
http://www.hpl.hp.com/techreports/tandem/TR-85.7.html
best wishes, Isaac
Isaac Gouy wrote:
> He repeatedly credits the fundamental principles in Jim Gray's work at
> Tandem computers: "Why Do Computers Stop And What Can Be Done About
> It?"
> http://www.hpl.hp.com/techreports/tandem/TR-85.7.html
An interesting link.
It seems to be a really early application (or even the invention) of the
ACID principle, but applied to a much wider scope than just databases.
Regards,
Jo
Joachim Durchholz <·················@web.de> wrote in message news:<············@news.oberberg.net>...
> Isaac Gouy wrote:
> > He repeatedly credits the fundamental principles in Jim Gray's work at
> > Tandem computers: "Why Do Computers Stop And What Can Be Done About
> > It?"
> > http://www.hpl.hp.com/techreports/tandem/TR-85.7.html
>
> An interesting link.
With some delightful terms: Bohrbugs & Heisenbugs ;-)
> It seems to be a really early application (or even the invention) of the
> ACID principle, but applied to a much wider scope than just databases.
Maybe this:
Haerder, T. and Reuter, A., `Principles of Transaction-Oriented
Database Recovery', ACM Computing Surveys, December 1983.
best wishes, Isaac
Erann Gat <···@jpl.nasa.gov> wrote:
> In article <··············@ID-7776.user.dfncis.de>, Dirk Thierbach
> <··········@gmx.de> wrote:
>> Nobody expects static typing to guard against race conditions.
> Not consciously, no. But tacitly, yes, I think people do expect this,
> even if they don't realize it.
So you say you don't believe in static typing because you have met
people who are stupid? Come on, you cannot be serious. That would
be like saying that I don't believe that dynamic typing can work
because I have seen people who treat it as a religion.
> Neither static nor dynamic typing would have helped in this situation.
> But I do believe that a dynamic typing *mindset* would have been more
> likely to produce a correct solution because it encourages you to think
> more about possible run-time errors.
You seem to have some strange ideas about a "static typing mindset".
I believe you that you have met incompetent people who were using
static typing, but they are also incompetent people who are using
dynamic typing. That really proves nothing.
And in this case, a static analysis (not a static type system) will
probably buy you much more, so some "static" thinking doesn't hurt.
- Dirk
In article <·············@ID-7776.user.dfncis.de>, Dirk Thierbach
<··········@gmx.de> wrote:
> Erann Gat <···@jpl.nasa.gov> wrote:
> > In article <··············@ID-7776.user.dfncis.de>, Dirk Thierbach
> > <··········@gmx.de> wrote:
>
> >> Nobody expects static typing to guard against race conditions.
>
> > Not consciously, no. But tacitly, yes, I think people do expect this,
> > even if they don't realize it.
>
> So you say you don't believe in static typing because you have met
> people who are stupid?
No, I am saying that I don't believe in static typing because I have met
very smart people who ended up doing very stupid things as a result (I
believe) of using static typing systems.
> Come on, you cannot be serious.
I am quite serious.
> You seem to have some strange ideas about a "static typing mindset".
> I believe you that you have met incompetent people who were using
> static typing, but they are also incompetent people who are using
> dynamic typing. That really proves nothing.
This all comes down to the question of whether the engineer in question
was smart or not. Of course, I can't prove he was; you have to take my
word for it. The only objective evidence I can offer is how long it took
to find the bug after it manifested itself. You'd have to believe that
the entire team was stupid. That may well be, but the company in question
is doing quite well and their product is very highly regarded so someone
there is doing something right.
You can also calibrate my assessment by asking anyone who knows me if I am
the least bit shy about levying a charge of stupidity if I think it is
warranted.
E.
···@jpl.nasa.gov (Erann Gat) wrote:
> No, I am saying that I don't believe in static typing because I have met
> very smart people who ended up doing very stupid things as a result (I
> believe) of using static typing systems.
so i take it you are opposed to four-wheel-drive and anti-lock
brakes in cars? i have seen many people do incredibly stupid
things around here when the weather is bad, because they
fail to realize that their spiffy new vehicles, alas, must still
obey the laws of physics.
if they knew they had no traction, and couldn't stop quickly
without spinning out, they might drive more carefully.
or maybe they'd just have more accidents.
----
Garry Hodgson, Technology Consultant, AT&T Labs
Be happy for this moment.
This moment is your life.
In article <······················@k2.sage.att.com>, Garry Hodgson
<·····@sage.att.com> wrote:
> ···@jpl.nasa.gov (Erann Gat) wrote:
>
> > No, I am saying that I don't believe in static typing because I have met
> > very smart people who ended up doing very stupid things as a result (I
> > believe) of using static typing systems.
>
> so i take it you are opposed to four-wheel-drive and anti-lock
> brakes in cars?
There's actually empirical evidence that anti-lock brakes don't reduce the
number of accidents because people just drive more carelessly as a result
of having them. (Interesting you should bring up this example. Just the
other day I ended up sailing through an intersection because my ABS kicked
in when I wasn't expecting it to. I was going about 20 MPH downhill on a
rainy day.)
E.
Erann Gat wrote:
> In article <······················@k2.sage.att.com>, Garry Hodgson
> <·····@sage.att.com> wrote:
>
>
>>···@jpl.nasa.gov (Erann Gat) wrote:
>>
>>
>>>No, I am saying that I don't believe in static typing because I have met
>>>very smart people who ended up doing very stupid things as a result (I
>>>believe) of using static typing systems.
>>
>>so i take it you are opposed to four-wheel-drive and anti-lock
>>brakes in cars?
>
>
> There's actually empirical evidence that anti-lock brakes don't reduce the
> number of accidents because people just drive more carelessly as a result
> of having them. (Interesting you should bring up this example. Just the
> other day I ended up sailing through an intersection because my ABS kicked
> in when I wasn't expecting it to. I was going about 20 MPH downhill on a
> rainy day.)
Not that I consider these analogies particularly enlightening, but the
theory behind anti-lock brakes is that you would have sailed through the
intersection anyway, only without the ability to steer.
-thant
Thant Tessman <·····@acm.org> writes:
> Erann Gat wrote:
> > In article <······················@k2.sage.att.com>, Garry Hodgson
> > <·····@sage.att.com> wrote:
> >
> >>···@jpl.nasa.gov (Erann Gat) wrote:
> >>
> >>
> >>>No, I am saying that I don't believe in static typing because I have met
> >>>very smart people who ended up doing very stupid things as a result (I
> >>>believe) of using static typing systems.
> >>
> >>so i take it you are opposed to four-wheel-drive and anti-lock
> >>brakes in cars?
> > There's actually empirical evidence that anti-lock brakes don't
> > reduce the
> > number of accidents because people just drive more carelessly as a result
> > of having them. (Interesting you should bring up this example. Just the
> > other day I ended up sailing through an intersection because my ABS kicked
> > in when I wasn't expecting it to. I was going about 20 MPH downhill on a
> > rainy day.)
>
> Not that I consider these analogies particularly enlightening, but the
> theory behind anti-lock brakes is that you would have sailed through
> the intersection anyway, only without the ability to steer.
At 20 MHP ???
--
__Pascal_Bourguignon__
http://www.informatimago.com/
In article <··············@thalassa.informatimago.com>, Pascal Bourguignon
<····@thalassa.informatimago.com> wrote:
> Thant Tessman <·····@acm.org> writes:
>
> > Erann Gat wrote:
> > > In article <······················@k2.sage.att.com>, Garry Hodgson
> > > <·····@sage.att.com> wrote:
> > >
> > >>···@jpl.nasa.gov (Erann Gat) wrote:
> > >>
> > >>
> > >>>No, I am saying that I don't believe in static typing because I have met
> > >>>very smart people who ended up doing very stupid things as a result (I
> > >>>believe) of using static typing systems.
> > >>
> > >>so i take it you are opposed to four-wheel-drive and anti-lock
> > >>brakes in cars?
> > > There's actually empirical evidence that anti-lock brakes don't
> > > reduce the
> > > number of accidents because people just drive more carelessly as a result
> > > of having them. (Interesting you should bring up this example. Just the
> > > other day I ended up sailing through an intersection because my ABS kicked
> > > in when I wasn't expecting it to. I was going about 20 MPH downhill on a
> > > rainy day.)
> >
> > Not that I consider these analogies particularly enlightening, but the
> > theory behind anti-lock brakes is that you would have sailed through
> > the intersection anyway, only without the ability to steer.
>
> At 20 MHP ???
The speed was not so much of a factor (I think) as the fact that it was a
downhill slope.
It's impossible to know what actually would have happened, of course, but
I can offer the following additional data:
One rainy day when I was young and foolish I discovered the joys of
applying the parking brake while moving and intentionally fishtailing my
car. I got fairly good at it, being able to bring the tail around 20 or
30 degrees before recovering. I thought it was great fun until I managed
to unintentionally spin it 720 degrees while going around a turn.
Fortunately, no damage was done, and I have since driven for decades
without ever losing control of my car -- until the other day. So while I
can't be sure, I'm fairly confident I could have done better without the
ABS.
But (no pun intended) YMMV. :-)
E.
Erann Gat wrote:
> So while I
> can't be sure, I'm fairly confident I could have done better without the
> ABS.
>
> But (no pun intended) YMMV. :-)
I believe the ABS in my car once saved the life of a drunken idiot
in a late-model Corvette who ran a stop-sign directly into my path
late at night. His car had ABS too. By the time we both came to
a stop, my headlights were six inches from his driver-side door,
bracketing the guy, so I got a real good look at him.
He asserted his sobriety by gunning his engine and fishtailing his
way out of there.
I'm not sure of the moral here. Don't drink and type?
Will
··········@verizon.net (William D Clinger) writes:
> I believe the ABS in my car once saved the life of a drunken idiot
> in a late-model Corvette who ran a stop-sign directly into my path
> late at night. His car had ABS too. By the time we both came to
> a stop, my headlights were six inches from his driver-side door,
> bracketing the guy, so I got a real good look at him.
>
> He asserted his sobriety by gunning his engine and fishtailing his
> way out of there.
>
> I'm not sure of the moral here. Don't drink and type?
Don't drink and *statically* type.
--
~jrm
Joe Marshall <·············@comcast.net> wrote:
>
> > I believe the ABS in my car once saved the life of a drunken idiot
> > in a late-model Corvette who ran a stop-sign directly into my path
> > late at night. His car had ABS too. By the time we both came to
> > a stop, my headlights were six inches from his driver-side door,
> > bracketing the guy, so I got a real good look at him.
> >
> > He asserted his sobriety by gunning his engine and fishtailing his
> > way out of there.
> >
> > I'm not sure of the moral here. Don't drink and type?
>
> Don't drink and *statically* type.
Reread the story. The proper analogy would be: Don't drink and *not*
statically type. Preferably, don't program at all.
"Andreas Rossberg" <········@ps.uni-sb.de> writes:
> Joe Marshall <·············@comcast.net> wrote:
>>
>> > I believe the ABS in my car once saved the life of a drunken idiot
>> > in a late-model Corvette who ran a stop-sign directly into my path
>> > late at night. His car had ABS too. By the time we both came to
>> > a stop, my headlights were six inches from his driver-side door,
>> > bracketing the guy, so I got a real good look at him.
>> >
>> > He asserted his sobriety by gunning his engine and fishtailing his
>> > way out of there.
>> >
>> > I'm not sure of the moral here. Don't drink and type?
>>
>> Don't drink and *statically* type.
>
> Reread the story. The proper analogy would be: Don't drink and *not*
> statically type. Preferably, don't program at all.
Sure looks to me that this was a runtime exception. If the
manufacturer of Will's car could have statically guaranteed that an
accident couldn't happen, why did they install brakes?
--
~jrm
Joe Marshall <·············@comcast.net> wrote:
>
> >> > I believe the ABS in my car once saved the life of a drunken idiot
> >> > in a late-model Corvette who ran a stop-sign directly into my path
> >> > late at night. His car had ABS too. By the time we both came to
> >> > a stop, my headlights were six inches from his driver-side door,
> >> > bracketing the guy, so I got a real good look at him.
> >> >
> >> > He asserted his sobriety by gunning his engine and fishtailing his
> >> > way out of there.
> >> >
> >> > I'm not sure of the moral here. Don't drink and type?
> >>
> >> Don't drink and *statically* type.
> >
> > Reread the story. The proper analogy would be: Don't drink and *not*
> > statically type. Preferably, don't program at all.
>
> Sure looks to me that this was a runtime exception. If the
> manufacturer of Will's car could have statically guaranteed that an
> accident couldn't happen, why did they install brakes?
Did you forget that ABS was introduced into this thread as an analogy to
static typing, in that it may also give an alleged false sense of security?
"Andreas Rossberg" <········@ps.uni-sb.de> writes:
> Joe Marshall <·············@comcast.net> wrote:
>>
>> >> > I believe the ABS in my car once saved the life of a drunken idiot
>> >> > in a late-model Corvette who ran a stop-sign directly into my path
>> >> > late at night. His car had ABS too. By the time we both came to
>> >> > a stop, my headlights were six inches from his driver-side door,
>> >> > bracketing the guy, so I got a real good look at him.
>> >> >
>> >> > He asserted his sobriety by gunning his engine and fishtailing his
>> >> > way out of there.
>> >> >
>> >> > I'm not sure of the moral here. Don't drink and type?
>> >>
>> >> Don't drink and *statically* type.
>> >
>> > Reread the story. The proper analogy would be: Don't drink and *not*
>> > statically type. Preferably, don't program at all.
>>
>> Sure looks to me that this was a runtime exception. If the
>> manufacturer of Will's car could have statically guaranteed that an
>> accident couldn't happen, why did they install brakes?
>
> Did you forget that ABS was introduced into this thread as an analogy to
> static typing, in that it may also give an alleged false sense of security?
I guess we've pushed this analogy as far as we can.
It's all downhill from here ... I hope the brakes hold...
--
~jrm
On Tue, 18 Nov 2003 15:17:47 -0800, ·········@jpl.nasa.gov (Erann Gat)
wrote:
>The speed was not so much of a factor (I think) as the fact that it was a
>downhill slope.
It's all about momentum and kinetic energy; how you acquire it doesn't
matter so much as the fact that you've got it.
>One rainy day when I was young and foolish I discovered the joys of
>applying the parking brake while moving and intentionally fishtailing my
>car. I got fairly good at it, being able to bring the tail around 20 or
>30 degrees before recovering. I thought it was great fun until I managed
>to unintentionally spin it 720 degrees while going around a turn.
>Fortunately, no damage was done, and I have since driven for decades
>without ever losing control of my car -- until the other day. So while I
>can't be sure, I'm fairly confident I could have done better without the
>ABS.
This is, of course, exactly the same kind of argument that people often
put up as "evidence" against seatbelts--they cite a personal anecdote
concerning some particular event in which they assert that the use of
seatbelts caused (or would have caused) more harm than good,
conveniently ignoring the vast body of knowledge supporting the value of
seatbelts in the great majority of accidents. It's the Creationist
approach.
I also have to say that your use of an example in which you present your
skill at causing a car to fishtail on demand to support your assertion
that you can control your car better without ABS than with doesn't
really bolster your reputation in the static/dynamic typing debate.
-Steve
Steve Schafer <···@reply.to.header> writes:
> It's the Creationist approach.
Hey now, let's keep this civil, insult his mother or something. We're
all scientists and engineers here. Erann was making an argument by
(questionable) analogy; call him on that, and be done with it. Those
aren't just fighting words, those are getting-stomped words.
> I also have to say that your use of an example in which you present your
> skill at causing a car to fishtail on demand to support your assertion
> that you can control your car better without ABS than with doesn't
> really bolster your reputation in the static/dynamic typing debate.
And you're making an ad hominem argument based on *analogy*. Careful,
that's taking Erann's error, and multiplying it by usenet:+troll+.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
In article <···············@famine.OCF.Berkeley.EDU>,
···@famine.OCF.Berkeley.EDU (Thomas F. Burdick) wrote:
> Steve Schafer <···@reply.to.header> writes:
>
> > It's the Creationist approach.
>
> Hey now, let's keep this civil, insult his mother or something.
[I'm only commenting on this because it was followed by another round of
meta-comments.]
Thanks for sticking up for me, but as Usenet insults go that one was
pretty tame. The best way to keep things civil IMO is to just let things
like this slide.
E.
On 21 Nov 2003 22:07:21 -0800, ···@famine.OCF.Berkeley.EDU (Thomas F.
Burdick) wrote:
>Hey now, let's keep this civil, insult his mother or something. We're
>all scientists and engineers here. Erann was making an argument by
>(questionable) analogy; call him on that, and be done with it. Those
>aren't just fighting words, those are getting-stomped words.
I stand by it. Whether it's USENET or Congress or any aspect of Real
Life, there's far too much Argument via Anecdote, and people need to be
called on it.
And scientists and engineers are capable of invoking it as well as
anyone, even though they ought to know better.
>And you're making an ad hominem argument based on *analogy*. Careful,
>that's taking Erann's error, and multiplying it by usenet:+troll+.
No, you misunderstand. An ad hominem argument is, of course, one in
which the arguer attempts to criticize a person's logic or reasoning by
way of an attack on that person's character (or other personal
attribute). But that's not what I was doing (or at least attempting to
do) here. Yes, I was drawing an analogy, but what I was trying to say
was that his comments about driving reflect a certain attitude, one that
is reinforced by his comments about programming (and vice versa), and
that that attitude is one that only reinforces the characterizations
that others involved in the dicussion are arriving at. So in some sense
my comment was "ad hominem" in that I was indeed criticizing his
attitude. However, I was not using that as a means to criticize his
logic or reasoning; rather, I was trying to give a "you're really not
helping yourself by bringing that up" kind of caution.
-Steve
On Fri, 21 Nov 2003 23:31:47 GMT, Steve Schafer <···@reply.to.header> wrote:
> On Tue, 18 Nov 2003 15:17:47 -0800, ·········@jpl.nasa.gov (Erann Gat)
> wrote:
>
>>The speed was not so much of a factor (I think) as the fact that it was a
>>downhill slope.
>
> It's all about momentum and kinetic energy; how you acquire it doesn't
> matter so much as the fact that you've got it.
I should note quickly that this isn't really true. On a downward
slope the normal force on the tire is lower than on flat ground by a
significant margin. Therefore it requires less braking force to cause
a skid.
Hmm, how did this relate to Lisp?
--
Kenneth P. Turvey <··@squeakydolphin.com>
Artificial Intelligence Algorithms Wiki
http://ai.squeakydolphin.com
On Sat, 22 Nov 2003 02:26:08 -0600, "Kenneth P. Turvey"
<··@squeakydolphin.com> wrote:
>I should note quickly that this isn't really true. On a downward
>slope the normal force on the tire is lower than on flat ground by a
>significant margin. Therefore it requires less braking force to cause
>a skid.
I was under the impression from the original discussion that the
downhill slope came _before_ the actual intersection, but perhaps I was
reading more into the description than was actually there.
However, I would take issue with the assertion that the reduction in
normal force is all that significant. A 15% grade, for example, is, from
a civil engineering point of view, a _very_ steep hill. Yet the
reduction in the gravitational force normal to the road surface is only
1.1%. On the other hand, the tangential component _is_ significantly
enhanced--nearly 15% of the weight of the car is manifested along the
surface of the road, in the direction of travel. But that just goes back
to what I said about momentum and kinetic energy: It doesn't matter
whether you acquire your momentum and kinetic energy via a hill or via
the accelerator pedal, you've still got it. You are correct that braking
while going down a hill is more difficult, but the reason that it's more
difficult is that it's like braking with your left foot while
simultaneously attempting to accelerate with your right foot, rather
than because of the decrease in normal force.
>Hmm, how did this relate to Lisp?
If you have to ask, you don't really want to know....
-Steve
On Sat, 22 Nov 2003 19:48:52 GMT, Steve Schafer <···@reply.to.header> wrote:
[Snip]
> However, I would take issue with the assertion that the reduction in
> normal force is all that significant. A 15% grade, for example, is, from
> a civil engineering point of view, a _very_ steep hill. Yet the
> reduction in the gravitational force normal to the road surface is only
> 1.1%. On the other hand, the tangential component _is_ significantly
> enhanced--nearly 15% of the weight of the car is manifested along the
> surface of the road, in the direction of travel.
You're read on the physics here is more in line with what is
happening, but your conclusion is wrong. The breaking required on a
slope is greater than that on flat ground. On the 15% grade you
discussed you exert 8% of the weight of the vehicle in breaking force
just to keep it from accelerating. The limit on the total breaking
force you have available is reduced by 1.1% (I actually got 0.4%, but
I only performed a cursory examination). If we assume a rolling
frictional coefficient of 10% (I really have no idea if this is in the
ballpark), and a two ton car, this works out to leave you only 37.8
lbs of breaking force, compared with the 200 lbs of breaking force you
would have before lock up on flat ground.
The math here is a bit fouled up because I haven't accounted for the
moment on the car driving down the front end and providing more normal
force. I focused on a single wheel.
.....
Dammit. I'm going to have to pull out a piece of paper and solve this
the slow diligent way. Why do I read posts like this?
.....
I believe the conclusion I'm going to come to is that breaking on a
hill is much more difficult to do right than breaking on flat ground
for any kinetic energy, but I'm going to have to do the numbers to
verify this.
I'll be back with results sometime tomorrow. I will even use the
wonders of common lisp to solve the problem, and if I do it in a
particularly interesting (for me) way then maybe I'll post the results
here, possibly even leading to an _on_topic_ post. :-)
--
Kenneth P. Turvey <··@squeakydolphin.com>
Artificial Intelligence Algorithms Wiki
http://ai.squeakydolphin.com
In article <··································@4ax.com>,
steve.at.fenestra.com wrote:
> On Tue, 18 Nov 2003 15:17:47 -0800, ·········@jpl.nasa.gov (Erann Gat)
> wrote:
>
> >The speed was not so much of a factor (I think) as the fact that it was a
> >downhill slope.
>
> It's all about momentum and kinetic energy; how you acquire it doesn't
> matter so much as the fact that you've got it.
Actually it does. If you're on a slope then you convert potential energy
to kinetic energy as you move. That's why in situations where traction is
marginal you can get into a situation where there is enough friction to
keep you in place once you are stopped, but not enough to actually bring
you to a halt. (The best place to experience this phenomenon is on a ski
slope.)
> >One rainy day when I was young and foolish I discovered the joys of
> >applying the parking brake while moving and intentionally fishtailing my
> >car. I got fairly good at it, being able to bring the tail around 20 or
> >30 degrees before recovering. I thought it was great fun until I managed
> >to unintentionally spin it 720 degrees while going around a turn.
> >Fortunately, no damage was done, and I have since driven for decades
> >without ever losing control of my car -- until the other day. So while I
> >can't be sure, I'm fairly confident I could have done better without the
> >ABS.
>
> This is, of course, exactly the same kind of argument that people often
> put up as "evidence" against seatbelts--they cite a personal anecdote
> concerning some particular event in which they assert that the use of
> seatbelts caused (or would have caused) more harm than good,
> conveniently ignoring the vast body of knowledge supporting the value of
> seatbelts in the great majority of accidents. It's the Creationist
> approach.
The main difference being that seatbelts don't materially impact how a car
handles. ABS brakes do.
> I also have to say that your use of an example in which you present your
> skill at causing a car to fishtail on demand to support your assertion
> that you can control your car better without ABS than with doesn't
> really bolster your reputation in the static/dynamic typing debate.
You missed the point. It's not that I could get my car to fishtail, it's
that afterwards (twenty years worth so far) I was able to prevent it from
fishtailing.
The analogy would be that early in my career I played around with
generating run-time type errors, got myself into one nearly catastrophic
bind, and then thereafter never had a problem again, until the change in
handling characteristics/focus-of-attention forced on me by antilock
brakes/static typing got me into another nearly catastrophic bind. Is
this an airtight scientific argument? No. Is it a (more) plausible
hypothesis (than Creationism)? I think so.
E.
Pascal Bourguignon wrote:
> Thant Tessman <·····@acm.org> writes:
[...]
>>Not that I consider these analogies particularly enlightening, but the
>>theory behind anti-lock brakes is that you would have sailed through
>>the intersection anyway, only without the ability to steer.
>
>
> At 20 MHP ???
If you slam on the brakes hard enough you bet. In snow I slide around on
purpose for fun all the time. Have to use the hand brake. The ABS won't
let me do it even at 5mph.
-thant
On Tue, 18 Nov 2003 12:09:52 -0800, ···@jpl.nasa.gov (Erann Gat) wrote:
>There's actually empirical evidence that anti-lock brakes don't reduce the
>number of accidents because people just drive more carelessly as a result
>of having them.
Not so much carelessness as simple unfamiliarity. The sensation the
driver gets when ABS kicks in is so strange (to those of us who learned
to drive in cars without ABS) that drivers often react in ways that
defeat the ABS. Drivers also don't realize that the principal benefit of
ABS is not reduced stopping distance but maintenance of directional
control--they forget that they can still steer the car.
Everyone with an ABS-equipped car owes it to themselves, their
passengers and their fellow motorists to visit an empty parking lot on a
rainy day and spend some time stomping on the brake and getting a feel
for what ABS does and how it does it.
-Steve
In article <··································@4ax.com>,
Steve Schafer <···@reply.to.header> wrote:
> Not so much carelessness as simple unfamiliarity. The sensation the
> driver gets when ABS kicks in is so strange (to those of us who learned
> to drive in cars without ABS) that drivers often react in ways that
> defeat the ABS. Drivers also don't realize that the principal benefit of
> ABS is not reduced stopping distance but maintenance of directional
> control--they forget that they can still steer the car.
We're way off topic here, but, FWIW, I think the problem with ABS is
that it's designed for people who habitually stomp on the brakes. As you
probably know, one is supposed to keep one's heel on the ground and,
using one's foot as a lever, gradually apply pressure to the brake
pedal. This prevents the wheels from locking when braking, and maintains
steerability, even on cars without ABS.
Many drivers, maybe most drivers, don't brake like this, however - they
just stomp on the brake pedal, foot off the floor, as hard as they can -
all the more so in an emergency situation. This more or less guarantees
that the wheels will lock, resulting in a skid, or at least, loss of
steerability. So ABS is a solution to a problem caused by bad driving -
or at least, bad braking habits. When a driver who brakes properly
drives a car with ABS, it almost never kicks in, even in an emergency,
because the wheels aren't locking up from excessive pressure to the
brake pedal. In the 3 cars I've driven with ABS, the only time I've ever
gotten it to engage is, as you suggested, intentionally in a wet, or
slushy, parking lot.
Raffael Cavallaro <················@junk.mail.me.not.mac.com> writes:
> In article <··································@4ax.com>,
> Steve Schafer <···@reply.to.header> wrote:
>
> We're way off topic here, but, FWIW, I think the problem with ABS is
> that it's designed for people who habitually stomp on the brakes. As you
> probably know, one is supposed to keep one's heel on the ground and,
> using one's foot as a lever, gradually apply pressure to the brake
> pedal. This prevents the wheels from locking when braking, and maintains
> steerability, even on cars without ABS.
>
> Many drivers, maybe most drivers, don't brake like this, however - they
> just stomp on the brake pedal, foot off the floor, as hard as they can -
> all the more so in an emergency situation. This more or less guarantees
> that the wheels will lock, resulting in a skid, or at least, loss of
> steerability. So ABS is a solution to a problem caused by bad driving -
> or at least, bad braking habits. When a driver who brakes properly
> drives a car with ABS, it almost never kicks in, even in an emergency,
> because the wheels aren't locking up from excessive pressure to the
> brake pedal. In the 3 cars I've driven with ABS, the only time I've ever
> gotten it to engage is, as you suggested, intentionally in a wet, or
> slushy, parking lot.
Sorry if I post a followup to this off topic stuff, but I can't resist.
Its not bad driving. Point is, the fastest way to brake is to keep
the wheels close to locking up. So if you do not lock up your wheels, it
is most likely that you do not break with maximum power. Only ABS which
watches every single wheel and reduces the breaking power to the wheels
which are starting to block ensures that you get maximum break performance.
(For this reason even the Formula 1 top teams developed ABS for their
cars, because it braked more efficiently than their top pilots, who were
not "good enough" to do it with their feet).
Peter
--
Peter Herth
Dawn of the Ages
http://dawn.netcologne.de
In article <··············@uranus.local>,
Peter Herth <·····@netcologne.de> wrote:
> Its not bad driving.
It's bad driving because not all cars have ABS brakes. In an emergency,
one doesn't really have time to think, "does this car have ABS brakes?"
One simply reacts according to training/habit, and either applies
pressure gradually, or just stomps on the brake pedal. If one does the
latter in a car with ordinary brakes, the wheels will lock, and loss of
steering control, and/or a skid will result.
I'm sure race drives can rely on their race vehicles to always have ABS
brakes, so they can afford to acquire the habit of always putting
maximum pressure on the brake pedal. This way they gain the advantage
you describe of maximum braking every time they apply the pedal. This
suggests, BTW, that what is best for trained professionals (here, race
car drives), under controlled circumstances (vehicles which they know,
as a certainty, will always have ABS brakes) is not necessarily what is
best for the general public.
The rest of us, who drive more than one car (e.g., rentals, friends' or
spouses' cars, company cars, etc.) need automatic reactions that serve
us well in any emergency, not just if we're lucky enough to be in a car
with ABS brakes when an emergency arises. When all cars have ABS brakes,
then stomping on the brake will not be bad driving. Until then, stomping
on the brakes is a *bad* idea - it causes skids in cars with ordinary
brakes.
Raffael Cavallaro wrote:
> The rest of us, who drive more than one car (e.g., rentals, friends' or
> spouses' cars, company cars, etc.) need automatic reactions that serve
> us well in any emergency, not just if we're lucky enough to be in a car
> with ABS brakes when an emergency arises.
Do you want your compiler to optimize for the exceptional case or for
the common case?
Until recently, I did well over 99% of my driving in one car, which
has antilock brakes. (I now do about 5% of my driving in another car,
which also has antilock brakes.) I want to optimize my automatic
reaction for the overwhelmingly likely case, not for the exceedingly
unlikely case of being the driver of a car that doesn't have antilock
brakes.
> When all cars have ABS brakes,
> then stomping on the brake will not be bad driving. Until then, stomping
> on the brakes is a *bad* idea - it causes skids in cars with ordinary
> brakes.
My first car did not have antilock brakes. In the 12 years I owned
it, I needed maximum braking exactly once, on black ice, downhill,
with a car in front in me that had stopped for a red traffic signal.
At crunch time, despite practice on empty parking lots and so forth,
I slammed on the brakes and threw the car into a skid. Fortunately
the half second delay before I began to brake properly had no adverse
consequences.
It is much easier to train oneself to stomp on the brakes than to
train oneself to modulate the brakes, and no matter how hard you try
you will never train yourself to brake as well as an antilock braking
system. I admire your John Henry act, but computers really can brake
better than people.
And to bring this back on topic: Computers really are better than
people when it comes to static checking for the class of errors that
we usually refer to as type errors. Do you want to optimize your
error checking for the exceptional case in which an apparent type
error isn't really an error, or for the common case in which it is?
Will
··········@verizon.net (William D Clinger) writes:
> And to bring this back on topic: Computers really are better than
> people when it comes to static checking for the class of errors that
> we usually refer to as type errors. Do you want to optimize your
> error checking for the exceptional case in which an apparent type
> error isn't really an error, or for the common case in which it is?
What do you mean by `Computers really are better than people...'?
Do you mean that
a) Computers can prove bogus code is wrong with a higher success
rate than people (especially when the people are only casually
examining the code)
or
b) When a computer fails to prove code right it is more likely that
the code is in error than it is that the computer is baffled
or both?
I'll certainly agree with part a, but not part b. Do you have a
persuasive argument?
--
~jrm
Joe Marshall asked:
> What do you mean by `Computers really are better than people...'?
> Do you mean that
>
> a) Computers can prove bogus code is wrong with a higher success
> rate than people (especially when the people are only casually
> examining the code)
>
> or
>
> b) When a computer fails to prove code right it is more likely that
> the code is in error than it is that the computer is baffled
>
> or both?
I meant a), but in my experience b) is true also.
In a follow-up post you referred to Hindley-Milner type inference.
I believe that much of the futility of these cross-posted threads
is a consequence of failing to distinguish between
1. static typing
2. type inference
3. parametric polymorphism
together with various other hidden assumptions. I have written only
a few thousand lines of real code in languages with type inference,
but I have written over 100,000 lines of code in languages like C and
Java. In my experience, when the C or Java compiler fails to prove
the type-correctness of my code, my code has been in error more often
than not.
This is hardly surprising, since the typing rules of these languages
are fairly well-defined, and the compiler is supposed to incorporate
a decision procedure for the language's type logic. Absent compiler
and hardware bugs, the computer would always be right, since it is
the programmer's responsibility to write programs that are well-typed
by the rules of the language, just as it is the programmer's job to
write programs that are generated by the grammar of the language, no
matter how bizarre that grammar may be.
I have found and reported a few compiler bugs, so I know the computer
isn't always right.
Will
··········@verizon.net (William D Clinger) writes:
> Joe Marshall asked:
>> What do you mean by `Computers really are better than people...'?
>> Do you mean that
>>
>> a) Computers can prove bogus code is wrong with a higher success
>> rate than people (especially when the people are only casually
>> examining the code)
>>
>> or
>>
>> b) When a computer fails to prove code right it is more likely that
>> the code is in error than it is that the computer is baffled
>>
>> or both?
>
> I meant a), but in my experience b) is true also.
>
> In a follow-up post you referred to Hindley-Milner type inference.
> I believe that much of the futility of these cross-posted threads
> is a consequence of failing to distinguish between
>
> 1. static typing
> 2. type inference
> 3. parametric polymorphism
>
> together with various other hidden assumptions. I have written only
> a few thousand lines of real code in languages with type inference,
> but I have written over 100,000 lines of code in languages like C and
> Java. In my experience, when the C or Java compiler fails to prove
> the type-correctness of my code, my code has been in error more often
> than not.
I think you are misunderstanding what I meant by part b.
I'm interested not in those cases where the compiler says `this is
obviously bogus' but when the compiler says `I don't see anything
actually *wrong* here, but since I'm not sure it is *right* either,
I'm going to rule in favor of it being an error.'
In C or in Java you have to explicitly hand-hold the compiler through
the entire type checking process, so you really can't get the second
kind of error (every variable has to be explicitly typed).
Joe Marshall wrote:
> I think you are misunderstanding what I meant by part b.
No, I think your post shows that I understood you. I pointed out
that you are making a hidden assumption (namely type inference)
that I regard as unwarranted. It's ok to make that assumption,
of course, but you shouldn't argue from such assumptions without
making them explicit. If this principle were generally followed,
the signal/noise ratio of these threads would be much improved.
> In C or in Java you have to explicitly hand-hold the compiler through
> the entire type checking process, so you really can't get the second
> kind of error (every variable has to be explicitly typed).
Precisely. That is why, in my experience, the second kind of
error is quite rare.
If you want to argue that the second kind of error happens more
often than static detection of actual type errors, then you are
going to have to argue that most programmers use languages with
type inference far more often than I do.
:)
Will
··········@verizon.net (William D Clinger) writes:
> Joe Marshall wrote:
>> I think you are misunderstanding what I meant by part b.
>
> No, I think your post shows that I understood you.
Ok, so I misunderstood when I understood that you were
misunderstanding.
> I pointed out that you are making a hidden assumption (namely type
> inference) that I regard as unwarranted. It's ok to make that
> assumption, of course, but you shouldn't argue from such assumptions
> without making them explicit. If this principle were generally
> followed, the signal/noise ratio of these threads would be much
> improved.
True, I should be explicit. I was assuming that *everyone* thought
that the C and Java type systems were so lame as to be beneath
contempt.
>> In C or in Java you have to explicitly hand-hold the compiler through
>> the entire type checking process, so you really can't get the second
>> kind of error (every variable has to be explicitly typed).
>
> Precisely. That is why, in my experience, the second kind of
> error is quite rare.
>
> If you want to argue that the second kind of error happens more
> often than static detection of actual type errors, then you are
> going to have to argue that most programmers use languages with
> type inference far more often than I do.
> :)
Actually, I was looking for a data point rather than an argument.
Joe Marshall wrote:
> True, I should be explicit. I was assuming that *everyone* thought
> that the C and Java type systems were so lame as to be beneath
> contempt.
*That* goes without saying. Nonetheless, lame type systems
detect most of the type errors that are detected in practice.
Will
William D Clinger wrote:
>
> Joe Marshall wrote:
> > True, I should be explicit. I was assuming that *everyone* thought
> > that the C and Java type systems were so lame as to be beneath
> > contempt.
>
> *That* goes without saying. Nonetheless, lame type systems
> detect most of the type errors that are detected in practice.
You write compilers (chock full of discriminated unions or whatever
you want to call them) and you don't find it completely impossible
to express your desired types in C or Java? The little work I've
done in Java (for a class) made me really appreciate just how limited
its type system is. My experience in SML and Haskell made me think
over and over "how do I express the type I want this object/method
to have" and after careful consideration my conclusion was usually
"can't do that in Java".
David
Feuer finds Java difficult:
> You write compilers (chock full of discriminated unions or whatever
> you want to call them) and you don't find it completely impossible
> to express your desired types in C or Java?
Discriminated unions are a nightmare in C, but have a natural
representation in Java as an abstract class with the various
summands represented as concrete subclasses. In my opinion,
sum-of-product types are the basic paradigm for Java-like OO
languages, and are one of the few things they do well.
You'd have to use a wrapper class if one of the summands is
what Java calls a primitive type, but that rarely happens in
the types that compilers need to express.
I don't intend to make a career out of defending Java's type
system, but as I do criticize such type systems as part of my
main business I feel a professional obligation to criticize
them fairly.
Will
William D Clinger wrote:
>
> Feuer finds Java difficult:
> > You write compilers (chock full of discriminated unions or whatever
> > you want to call them) and you don't find it completely impossible
> > to express your desired types in C or Java?
>
> Discriminated unions are a nightmare in C, but have a natural
> representation in Java as an abstract class with the various
> summands represented as concrete subclasses. In my opinion,
> sum-of-product types are the basic paradigm for Java-like OO
> languages, and are one of the few things they do well.
Problem one: someone (yourself) might add a new subclass without
changing all the old code to deal with it. There is no way to detect
this at compile time.
Problem two: Discriminated unions in Java are far less efficient
than in decent statically typed languages, both because Java does not
(cannot) support fast pattern matching and because a redundant type
check is always done when you perform a cast.
David
Of course where Java really _stinks_ is when you want parametric
polymorphism and can't get it. That would have been a much better
example for me to have given.
Feuer wrote:
> Problem two: Discriminated unions in Java are far less efficient
> than in decent statically typed languages, both because Java does not
> (cannot) support fast pattern matching and because a redundant type
> check is always done when you perform a cast.
You lost me on this one. The "pattern matching" is normally done by
the call to a dynamic method, which (in the worst case) involves a
null check, a couple of loads, and an indirect jump. There is no
cast, and no redundant type check.
> Of course where Java really _stinks_ is when you want parametric
> polymorphism and can't get it. That would have been a much better
> example for me to have given.
Agreed.
Will
William D Clinger wrote:
>
> Feuer wrote:
> > Problem two: Discriminated unions in Java are far less efficient
> > than in decent statically typed languages, both because Java does not
> > (cannot) support fast pattern matching and because a redundant type
> > check is always done when you perform a cast.
>
> You lost me on this one. The "pattern matching" is normally done by
> the call to a dynamic method, which (in the worst case) involves a
> null check, a couple of loads, and an indirect jump. There is no
> cast, and no redundant type check.
Now you've lost me. I'm talking of code like:
if(isAFoo(x))
{
treatAsFoo((Foo) x);
}
else if(isABar(x))
{
treatasBar((Bar) x);
}
else if ....
Even though _you_ know that passing "isAFoo" means that the cast
to Foo will succeed, the compiler doesn't. And the compiler doesn't
know in advance what might be passed in, so it can't try any fancy
pattern-matching optimization.
David
Feuer wrote:
> Now you've lost me. I'm talking of code like:
>
> if(isAFoo(x))
> {
> treatAsFoo((Foo) x);
> }
> else if(isABar(x))
> {
> treatasBar((Bar) x);
> }
> else if ....
The Java idiom for this is
x.treat();
Fast, no casts, no redundant type check.
Will
··········@verizon.net (William D Clinger) writes:
>Feuer wrote:
>> Now you've lost me. I'm talking of code like:
>>
>> if(isAFoo(x))
>> {
>> treatAsFoo((Foo) x);
>> }
>> else if(isABar(x))
>> {
>> treatasBar((Bar) x);
>> }
>> else if ....
>
>The Java idiom for this is
>
> x.treat();
>
>Fast, no casts, no redundant type check.
That's the Java idiom for an open sum, not a closed sum.
Of course it is idiomatic in Java to use open sums in preference to
closed sums, because Java has much better support for open sums than
for closed sums. But this sub-thread was about Feuer having difficulty
expressing closed sums.
--
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:
> Of course it is idiomatic in Java to use open sums in preference to
> closed sums, because Java has much better support for open sums than
> for closed sums. But this sub-thread was about Feuer having difficulty
> expressing closed sums.
Is it a serious problem if a closed sum is implemented as an open one?
(This reminds me of the static typing debate, and your remark that it's
OK if you can't write everything in a static language if equivalent
idioms are available. Is not having closed sums a similar case, or are
there important differences?)
Regards,
Jo
Feuer <·····@his.com> writes:
> William D Clinger wrote:
> > You lost me on this one. The "pattern matching" is normally done by
> > the call to a dynamic method, which (in the worst case) involves a
> > null check, a couple of loads, and an indirect jump. There is no
> > cast, and no redundant type check.
>
> Now you've lost me. I'm talking of code like:
>
> if(isAFoo(x))
> {
> treatAsFoo((Foo) x);
> }
> else if(isABar(x))
> {
> treatasBar((Bar) x);
> }
> else if ....
The point of "OO" programming is that you do not do these case
switches. Instead, your objects know how to "doSomething". Instead of saying
"if x then doSomethingAsX", you simply ask the object to just
doSomething. Each object customizes its implementation of doSomething as
appropriate, e.g,
class X
{
// sublcasses will override as appropriate
public void doSomething() {...}
}
class Foo extends X
{
public void doSomething() {...maybe call super.doSomething(), maybe not}
}
class Bar extends X
{
public void doSomething() {...specific to Bar...}
}
then, when you need to "doSomething" you just say:
x.doSomething();
with no testing or casting to the specific versions.
--
Cheers, The Rhythm is around me,
The Rhythm has control.
Ray Blaak The Rhythm is inside me,
········@STRIPCAPStelus.net The Rhythm has my soul.
Ray Blaak wrote:
> > if(isAFoo(x))
> > {
> > treatAsFoo((Foo) x);
> > }
> > else if(isABar(x))
> > {
> > treatasBar((Bar) x);
> > }
> > else if ....
>
> The point of "OO" programming is that you do not do these case
> switches. Instead, your objects know how to "doSomething". Instead of saying
> "if x then doSomethingAsX", you simply ask the object to just
> doSomething. Each object customizes its implementation of doSomething as
> appropriate, e.g,
Which is very nice, but not relevant. When I wrote "treatAsFoo",
etc, I was not intending something that would really make sense
as a method of the object. I meant some possibly complex
construct that could depend on various other objects and
do various strange things to local or even global variables.
I remember doing this sort of thing when writing a tail-recursive
Scheme interpreter in Java. Could I have written everything in
the style you suggest? Probably. Would the code have been anything
like readable? I doubt it.
David
Feuer <·····@his.com> writes:
> Ray Blaak wrote:
> > The point of "OO" programming is that you do not do these case
> > switches. Instead, your objects know how to "doSomething". Instead of saying
> > "if x then doSomethingAsX", you simply ask the object to just
> > doSomething. Each object customizes its implementation of doSomething as
> > appropriate, e.g,
>
> Which is very nice, but not relevant. When I wrote "treatAsFoo",
> etc, I was not intending something that would really make sense
> as a method of the object. I meant some possibly complex
> construct that could depend on various other objects and
> do various strange things to local or even global variables.
The trick is to try and structure things properly so that you can indeed
identify the high-level semantic steps that are happening. In your example,
the common theme is "treat".
As for being complex and depending on varying other objects, the trick there
is to structure things so that information is available in a standard
way. E.g. in a parser the current token stream should be available, so that a
foo might need to know the current token only, whereas a bar might need to
look ahead a few tokens, etc. In either case the token stream is available and
it is up to the client object to access it as desired.
The "shape" of the high level steps very often can be standardized across the
various implementations of them. Indeed, that's what the design process is
about -- identifying common themes and data dependencies.
> I remember doing this sort of thing when writing a tail-recursive
> Scheme interpreter in Java. Could I have written everything in
> the style you suggest? Probably. Would the code have been anything
> like readable? I doubt it.
I have written a full-blown Java interpreter in Java in the style I suggest. I
did not (consciously) encounter the limitations you point out, and I do believe
my code is quite readable.
The moral here is really one about mindsets I suppose. I just cringe in the
presence of n-way "instance checks" that vary behaviour based on the kind of
object encountered, and instinctively restructure things to eliminate them.
Note that I am not being a Java defender here, either. I want multi-methods!
--
Cheers, The Rhythm is around me,
The Rhythm has control.
Ray Blaak The Rhythm is inside me,
········@STRIPCAPStelus.net The Rhythm has my soul.
Ray Blaak <········@STRIPCAPStelus.net> writes:
> The trick is to try and structure things properly so that you can
> indeed identify the high-level semantic steps that are happening. In
> your example, the common theme is "treat".
Yes, this is the OO way of thinking. What I think is happening here is
that there are *three* (not two) different pieces of design in use
here, all of which are needed:
1) Decision logic [the case structure]
2) Implementation for each alternative
3) Platform [the base class]
Now, the OO way of thinking has only 2) and 3), the platform being the
common base class or common interface that provides commonalities
between each of the alternative implementations. The functional way of
thinking, however, provides 1) and 2), such that the decision logic
chooses which alternative to use. This effectively closes the module
such that the module only implements well-defined cases.
What you would want really is that you have all three of them. The
decision logic groups the alternatives into well-defined and closed
groups [the modules]. The implementation of each alternative provides
the implementation for each of the selected cases that should be
supported. And the (open) platform describes the commonalities that
these alternatives have.
Note that both the decision logic and the platform provide means to
access those implementations. However, the interface they provide is
completely different. The platform can only provide interface to
things that are *common* to every alternative. The decision logic,
however, mainly builds on *differences* between different
alternatives, and provides the implementation with information that is
specific to each alternative. Another way of saying this is that the
decision logic provides an interface to the whole *collection* of
supported objects and the platform provides an interface to each
individual object.
> As for being complex and depending on varying other objects, the
> trick there is to structure things so that information is available
> in a standard way. E.g. in a parser the current token stream should
> be available, so that a foo might need to know the current token
> only, whereas a bar might need to look ahead a few tokens, etc. In
> either case the token stream is available and it is up to the client
> object to access it as desired.
> The "shape" of the high level steps very often can be standardized
> across the various implementations of them. Indeed, that's what the
> design process is about -- identifying common themes and data
> dependencies.
Yes, but you should not ignore data flows and the differences between
the alternatives.
> The moral here is really one about mindsets I suppose. I just cringe
> in the presence of n-way "instance checks" that vary behaviour based
> on the kind of object encountered, and instinctively restructure
> things to eliminate them.
The code needs to *decide* when to use some particular types of
instances. This is what the 'if' structure is needed for. You are not
dispatching on the type of an existing object [that would be bad
design], instead, you are dispatching on your inputs [which are not
objects], and choose the type of the object to use based on that; once
the objects have done their job, you produce output from the results.
--
Esa Pulkkinen
Ray Blaak <········@STRIPCAPStelus.net> writes:
>Feuer <·····@his.com> writes:
>> Ray Blaak wrote:
>> > The point of "OO" programming is that you do not do these case
>> > switches. Instead, your objects know how to "doSomething". Instead of saying
>> > "if x then doSomethingAsX", you simply ask the object to just
>> > doSomething.
>>
>> Which is very nice, but not relevant. [...]
>
>The trick is to try and structure things properly so that you can indeed
>identify the high-level semantic steps that are happening. In your example,
>the common theme is "treat".
You still don't seem to be getting the point. OO style programming with
its use of open sum types and closed method sets is all very well and
good, and this style certainly has its place, but for many applications
functional style programming with closed sum types but open method sets
is preferable -- in particular those where adding new methods which need
to switch on the sum type alternatives is more common than adding new
alternatives to the sum type.
--
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:
> You still don't seem to be getting the point. OO style programming with
> its use of open sum types and closed method sets is all very well and
> good, and this style certainly has its place, but for many applications
> functional style programming with closed sum types but open method sets
> is preferable -- in particular those where adding new methods which need
> to switch on the sum type alternatives is more common than adding new
> alternatives to the sum type.
True, but let's remember how this topic intruded itself into our
discussion of antilock brakes: David Feuer expressed amazement
that I found it possible even to express the "discriminated unions
(or whatever you want to call them)" that are needed by a compiler.
The most important point is that the necessary sum types (by whatever
name you want to call them) are not only possible but easy to express
in most OO languages.
As you point out, another important point is whether adding new phases
to a compiler is more common than adding new summands. I have done
both, as I am sure you and other have also. In my experience, adding
new phases to a compiler is less common than adding new summands (e.g.
new code sequences, new operations, new kinds of expression, etc).
IMO this says that, for the compiler example that was chosen by Feuer
(and I again emphasize that this was not my choice), open sum types
are probably more desirable than closed sums.
There are many applications for which the opposite is true.
And I would point out that this point is entirely orthogonal to the
functional versus imperative aspect. I point this out because some
people seem to be identifying closed sums with functional programming
and open sums with imperative programming. There is no technical
justification for that prejudice.
Will
Fergus Henderson wrote:
> Ray Blaak <········@STRIPCAPStelus.net> writes:
>
>>Feuer <·····@his.com> writes:
>>
>>>Ray Blaak wrote:
>>>
>>>>The point of "OO" programming is that you do not do these case
>>>>switches. Instead, your objects know how to "doSomething". Instead of saying
>>>>"if x then doSomethingAsX", you simply ask the object to just
>>>>doSomething.
>>>
>>>Which is very nice, but not relevant. [...]
>>
>>The trick is to try and structure things properly so that you can indeed
>>identify the high-level semantic steps that are happening. In your example,
>>the common theme is "treat".
>
>
> You still don't seem to be getting the point. OO style programming with
> its use of open sum types and closed method sets is all very well and
> good, and this style certainly has its place, but for many applications
> functional style programming with closed sum types but open method sets
> is preferable -- in particular those where adding new methods which need
> to switch on the sum type alternatives is more common than adding new
> alternatives to the sum type.
In Common Lisp, classes don't have "closed method sets" by default. It's
up to the programmer to close the class hierarchy (for example via
validate-superclass) or the set of methods (for example via an
appropriate method for ensure-method).
Dynamic typers shouldn't use Java as an example of an advanced static
type system, and static typers shouldn't use Java as an example of an
advanced object-oriented programming language.
Pascal
--
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
On Wed, 26 Nov 2003 14:17:29 -0800, William D Clinger wrote:
> You lost me on this one. The "pattern matching" is normally done by
> the call to a dynamic method, which (in the worst case) involves a
> null check, a couple of loads, and an indirect jump. There is no
> cast, and no redundant type check.
But you must add a separate set of methods for each matching, which is
turned inside out (grouped by case instead of by matching point), you
don't have direct access to free variables from the point of matching,
and you must constantly extend the classes when new matching functions
arise. Shortly, the translation has a very different code structure.
--
__("< Marcin Kowalczyk
\__/ ······@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
Marcin 'Qrczak' Kowalczyk <······@knm.org.pl> writes:
> On Wed, 26 Nov 2003 14:17:29 -0800, William D Clinger wrote:
>
> > You lost me on this one. The "pattern matching" is normally done by
> > the call to a dynamic method, which (in the worst case) involves a
> > null check, a couple of loads, and an indirect jump. There is no
> > cast, and no redundant type check.
>
> But you must add a separate set of methods for each matching, which is
> turned inside out (grouped by case instead of by matching point), you
> don't have direct access to free variables from the point of matching,
> and you must constantly extend the classes when new matching functions
> arise. Shortly, the translation has a very different code structure.
>
The Visitor pattern of OO programing address all if not most of these
issues. I've written a frontend/optimizer using this Visitor pattern in
Java, and have to say, I miss pattern matching a bit less than I expected.
Marcin 'Qrczak' Kowalczyk wrote:
>
> On Wed, 26 Nov 2003 14:17:29 -0800, William D Clinger wrote:
>
> > You lost me on this one. The "pattern matching" is normally done by
> > the call to a dynamic method, which (in the worst case) involves a
> > null check, a couple of loads, and an indirect jump. There is no
> > cast, and no redundant type check.
>
> But you must add a separate set of methods for each matching, which is
> turned inside out (grouped by case instead of by matching point), you
> don't have direct access to free variables from the point of matching,
> and you must constantly extend the classes when new matching functions
> arise. Shortly, the translation has a very different code structure.
Ezzackly.
David
William D Clinger <··········@verizon.net> wrote:
>
> Discriminated unions are a nightmare in C, but have a natural
> representation in Java as an abstract class with the various
> summands represented as concrete subclasses. In my opinion,
> sum-of-product types are the basic paradigm for Java-like OO
> languages, and are one of the few things they do well.
I strongly disagree. "Discriminated unions" are disjoint, closed sums, while
subtyping gives you overlapping, open sums. Both are completely different
beasts with different trade-offs.
Representing syntax trees with objects is one of the worst cases of
inside-out programming I know.
- Andreas
"Andreas Rossberg" wrote:
> > Discriminated unions are a nightmare in C, but have a natural
> > representation in Java as an abstract class with the various
> > summands represented as concrete subclasses. In my opinion,
> > sum-of-product types are the basic paradigm for Java-like OO
> > languages, and are one of the few things they do well.
>
> I strongly disagree. "Discriminated unions" are disjoint, closed sums, while
> subtyping gives you overlapping, open sums. Both are completely different
> beasts with different trade-offs.
The open sums I described are better for the compiler example, which
was chosen by David Feuer, not by me. What you don't want is to have
to modify multiple pattern matches or case expressions every time you
add a new summand to the sum type.
> Representing syntax trees with objects is one of the worst cases of
> inside-out programming I know.
I know of worse.
Will
William D Clinger wrote:
>>
>> "Discriminated unions" are disjoint, closed sums,
>> while subtyping gives you overlapping, open sums. Both are completely
>> different beasts with different trade-offs.
>
> The open sums I described are better for the compiler example, which
> was chosen by David Feuer, not by me. What you don't want is to have
> to modify multiple pattern matches or case expressions every time you
> add a new summand to the sum type.
Well, actually, I want precisely that! And I want the compiler to help
finding out where I have to rethink my code in presence of the new case.
What I don't want is having my code generation, my type checking algorithm,
or the n optimization phases, spread over umpteen different methods and
having to add another method for every class each time I add a single
optimization transformation.
Neither do I want to split my case analysis for recognizing certain
non-trivial code patterns for optimization into a huge number of secondary,
ternary, and k-ary dispatch methods that I have to implement for every
single class (and note that multi dispatch is not good enough, because it
is flat).
So IMHO, for applications like these (symbolic processing), disjoint sums
with pattern matching are highly superior, and encoding them into a class
hierarchy is by no means natural.
(Sorry if the above should sound slightly hostile, that wasn't my intention.
I just have seen so horribly crappy and unreadable code trying to express
these things in an OO-approved way that my annoyance is showing through.
:-) )
Cheers,
- 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:
>
> Neither do I want to split my case analysis for recognizing certain
> non-trivial code patterns for optimization into a huge number of secondary,
> ternary, and k-ary dispatch methods that I have to implement for every
> single class (and note that multi dispatch is not good enough, because it
> is flat).
I agree that multi dispatch isn't good enough.
Do you know a better alternative? I'd love to hear about one.
Regards,
Jo
Joachim Durchholz wrote:
>>
>> Neither do I want to split my case analysis for recognizing certain
>> non-trivial code patterns for optimization into a huge number of
>> secondary, ternary, and k-ary dispatch methods that I have to implement
>> for every single class (and note that multi dispatch is not good enough,
>> because it is flat).
>
> I agree that multi dispatch isn't good enough.
> Do you know a better alternative? I'd love to hear about one.
Well, there always is a trade-off, but the scenario described above is
exactly what pattern matching is best at.
The ideal seems to be some unified framework of pattern matching and multi
dispatch, but I'm not aware of anything practical.
- 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.
··········@verizon.net (William D Clinger) writes:
>"Andreas Rossberg" wrote:
>> > Discriminated unions are a nightmare in C, but have a natural
>> > representation in Java as an abstract class with the various
>> > summands represented as concrete subclasses. In my opinion,
>> > sum-of-product types are the basic paradigm for Java-like OO
>> > languages, and are one of the few things they do well.
>>
>> I strongly disagree. "Discriminated unions" are disjoint, closed sums, while
>> subtyping gives you overlapping, open sums. Both are completely different
>> beasts with different trade-offs.
>
>The open sums I described are better for the compiler example, which
>was chosen by David Feuer, not by me. What you don't want is to have
>to modify multiple pattern matches or case expressions every time you
>add a new summand to the sum type.
I'm not at all convinced that open sums are better for compilers.
If the programming language is fixed, then you're far more likely to
add a new optimization pass than to add a new kind of language statement.
In those circumstances, I'd rather have to modify multiple pattern
matches when adding a new kind of language statement than to have to
modify multiple class definitions when adding a new optimization.
--
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:
> I'm not at all convinced that open sums are better for compilers.
> If the programming language is fixed, then you're far more likely to
> add a new optimization pass than to add a new kind of language statement.
This is very much the opposite of my experience. First of all,
the only fixed programming languages are the dead ones. Secondly,
new target architectures are more common than new compiler passes,
and the targets that a compiler supports should be an open sum type.
Thirdly, the target architecture instruction sets are themselves an
open sum: instructions get added over time, and are rarely deleted.
Fourthly, it is very common to add inline code sequences for new
operators over time, often motivated in part by the needs of a new
target architecture or user community.
Will
William D Clinger wrote:
>> I'm not at all convinced that open sums are better for compilers.
>> If the programming language is fixed, then you're far more likely to
>> add a new optimization pass than to add a new kind of language statement.
>
> This is very much the opposite of my experience.
See my comments to your specific points below. But first let me ask the,
IMO, most important question: How do you do non-local case switches? For
example, consider a simplifier for very arithmetic expressions:
data Exp = Const Int | Var String | Add Exp Exp
simplify (Add (Const 0) e) = simplify e
simplify (Add e (Const 0)) = simplify e
simplify (Add (Const i1) (Const i2)) = Const (i1 + i2)
simplify (Add e1 e2) = Add (simplify e1) (simplify e2)
simplify ·@(Const _ | Var _) = e
Now, this is a very simple example, patterns are only nested at depth 2. For
realistic applications - particularly in compilers - you often have much
more complex patterns. The case distinction is non-local, i.e. not just
based on one object at a time, but certain combinations. The OO idiom
doesn't give you anything reasonable to deal with this (and as I said, even
multi-dispatch isn't good enough for this).
Also, operations on ASTs are often complex algorithms. Splitting and
spreading them all over the place is a very bad idea with respect to
readability and maintainability. Furthermore, these algorithms may change
often themselves, probably introducing additional parameters, thus changing
the recursion pattern. You don't want to look into a thousand places
everytime you do this.
That's basically my main problem with the OO-approach to case switching: it
is not suitable for non-trivial algorithms.
> First of all,
> the only fixed programming languages are the dead ones.
True, but modifying a language (even merely extending it) is an intrusive
change already from the conceptual point of view. It needs much more care
anyway, so it isn't all that important that it is local or "easy".
(Although I wouldn't consider it "hard" with pattern matching either.)
OTOH, conceptually, a new optimizations is a much more local issue, so it is
natural and helpful to map it to a local change in the source.
If I have to choose, I rather structure my program along these lines, than
the other way round.
> Secondly,
> new target architectures are more common than new compiler passes,
Isn't a new backend a new "operation" on the AST, just like an optimization
phase?
> and the targets that a compiler supports should be an open sum type.
I don't necessarily see why the targets need to be in a sum at all. Do you
store backends in a list?
Moreover, different code generators may or may not adhere to a common
interface.
> Thirdly, the target architecture instruction sets are themselves an
> open sum: instructions get added over time, and are rarely deleted.
Is this relevant? The instruction set is just another form of AST, with
similar requirements, so you essentially repeat your argument here, in a
slightly different context.
> Fourthly, it is very common to add inline code sequences for new
> operators over time, often motivated in part by the needs of a new
> target architecture or user community.
Same here, AFAICS.
Cheers,
- 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.
From: Daniel C. Wang
Subject: Re: Sum types (Was: Re: OT: More Antilock brakes)
Date:
Message-ID: <u3cc4a99c.fsf@hotmail.com>
Andreas Rossberg <········@ps.uni-sb.de> writes:
{stuff deleted}
> Now, this is a very simple example, patterns are only nested at depth 2. For
> realistic applications - particularly in compilers - you often have much
> more complex patterns.
Having, written several compilers myself, I find that patterns are
relatively shallow. The only place where they many not be would be instruction
in selection.
Daniel C. Wang wrote:
>
>> Now, this is a very simple example, patterns are only nested at depth 2.
>> For realistic applications - particularly in compilers - you often have
>> much more complex patterns.
>
> Having, written several compilers myself, I find that patterns are
> relatively shallow. The only place where they many not be would be
> instruction in selection.
Yes, they rarely get deeper than, say, 3 levels. But the number of secondary
dispatch methods you need in an OO approach *per single case* is
exponential in that depth! If you have binary constructors, for example,
then a single case of depth 3 alone would require 7 additional methods in
every class (a few less with multi dispatch) - unless you use instanceof
after all.
Also note that the need for secondary dispatch practically destroys openness
anyway.
--
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.
From: Daniel C. Wang
Subject: Re: Sum types (Was: Re: OT: More Antilock brakes)
Date:
Message-ID: <uvfp08jq0.fsf@hotmail.com>
Andreas Rossberg <········@ps.uni-sb.de> writes:
{stuff deleted}
> Yes, they rarely get deeper than, say, 3 levels. But the number of secondary
> dispatch methods you need in an OO approach *per single case* is
> exponential in that depth! If you have binary constructors, for example,
> then a single case of depth 3 alone would require 7 additional methods in
> every class (a few less with multi dispatch) - unless you use instanceof
> after all.
>
> Also note that the need for secondary dispatch practically destroys openness
> anyway.
I'm not going to disputing this claim since it is true. I just want to
report that having written a frontend and optimizer in 100% pure Java, using
the visitor pattern and inner classes heavily, I fould the lack of pattern
matching to be annoying but not a real pain.* The lack of parametric
polymorphims and tuples/pairs I found more annoying then the lack of pattern
matching.
I were doing this in Java that supports generics, I would be hard pressed to
complain too much.
*Note I "cheated" in that I had to write a small pre-processor to turn AST
nodes into the appropriate Java classes, for my own sanity, but once that
was done using the AST nodes was quite pleasant.
·········@hotmail.com (Daniel C. Wang) wrote:
> Andreas Rossberg <········@ps.uni-sb.de> writes:
> {stuff deleted}
> > Yes, they rarely get deeper than, say, 3 levels. But the number of
> > secondary
> > dispatch methods you need in an OO approach *per single case* is
> > exponential in that depth! If you have binary constructors, for example,
> > then a single case of depth 3 alone would require 7 additional methods in
> > every class (a few less with multi dispatch) - unless you use instanceof
> > after all.
> >
> > Also note that the need for secondary dispatch practically destroys
> > openness
> > anyway.
>
> I'm not going to disputing this claim since it is true. I just want to
> report that having written a frontend and optimizer in 100% pure Java, using
> the visitor pattern and inner classes heavily, I fould the lack of pattern
> matching to be annoying but not a real pain.* The lack of parametric
> polymorphims and tuples/pairs I found more annoying then the lack of pattern
> matching.
>
> I were doing this in Java that supports generics, I would be hard pressed to
> complain too much.
I will second this comment.. I have done likewise (frontend and optimiser
in Java). Didn't miss patterns that much, but really missed parametric
polymorphism, and syntax for tuples and lists. Java 1.5 will address the
polymorphism issue.
graham
Andreas Rossberg <········@ps.uni-sb.de> wrote:
> Yes, they rarely get deeper than, say, 3 levels. But the number of secondary
> dispatch methods you need in an OO approach *per single case* is
> exponential in that depth! If you have binary constructors, for example,
> then a single case of depth 3 alone would require 7 additional methods in
> every class (a few less with multi dispatch) - unless you use instanceof
> after all.
As noted in a separate post, I would use pattern matching automata
for this, not dynamic/virtual method dispatch. I would _not_ use
instanceof to implement the pattern matching.
Will
I think you think you are arguing with me, but it appears to me
that your argument is based upon one or more misconceptions along
the lines of:
* pattern matching must be based on static types
* pattern matching implies closed rather than open sums
* open sums imply OO case-switching
None of these statements are correct.
Andreas Rossberg <········@ps.uni-sb.de> wrote:
> See my comments to your specific points below. But first let me ask the,
> IMO, most important question: How do you do non-local case switches?
I use pattern matching. On open sums.
Let me clarify. What I have done, what I would do, and what I
consider to be good practice are three potentially distinct things.
Most of the compilers I have written, including the MacScheme and
Twobit compilers, were written in Scheme, which cannot directly
express static types of any kind. I have written several toy
compilers in Java, but all were for compiler courses I have taught,
and none of them have anywhere near the level of optimization that
is present in Twobit. I have modified a small number of compilers
that others have written; one of these was written in C, one in C++,
and at least one in Java.
> For example, consider a simplifier for very arithmetic expressions:
In Twobit, your example would be written using an extension of the
pattern language used for hygienic macros in Scheme, e.g. along the
lines of
((simplify (Add (Const 0) e))
(simplify e))
((simplify (Add e (Const 0)))
(simplify e))
((simplify (Add (Const i1) (Const i2)))
(fold (+ i1 i2) x (Const x)))
((simplify (Add e1 e2))
(Add (simplify e1) (simplify e2)))
I have also implemented a general-purpose peephole optimizer by
translating libraries of peephole optimizations into decision-tree
automata, which I interpret. I am not sure this is good practice,
because many of the optimizations involve various side conditions
that made the translator and interpreter more complex and the
interpreter less efficient. I was also surprised by the sheer
size of the automaton for realistically large sets of optimizations.
A few things are worth noting here:
* Although Scheme is not statically typed, it does provide
pattern matching as part of its standard macro facility.
* Since Twobit is a Scheme compiler and must present this
macro facility to programmers, it might as well use this
macro pattern matcher for its own nefarious purposes.
* To the extent that the S-expressions are being used to
encode a sum type, the sum type is open, not closed.
So that is what I have done. If I were doing this in Java, I would
probably write the simplification rules approximately as above, and
compile them into a Java state machine. This would be a bit of a
bother, but I would not have to write much new code beyond what I
have already written for the hygienic macro facility and for a
scanner generator that outputs code for state machines written in
Java (and several other languages).
I could express these rules directly in Java, but it would be a lot
more painful.
Note that the real problem with Java here is not that it lacks closed
sums, since open sums work just as well if not better, but the lack
of pattern matching and the lack of any macro facility that I could
use to implement pattern matching.
Thinking back to compilers I have seen that were written in C and
Java, at least one of them deals with this sort of thing by
implementing its own pattern language and matcher, while others
express the rewrite rules procedurally. I prefer the pattern
language.
> The OO idiom doesn't give you anything reasonable to deal with
[pattern matching]
> That's basically my main problem with the OO-approach to case
> switching: it is not suitable for non-trivial algorithms.
True, but it doesn't get in the way either. OO and pattern matching
are orthogonal. The fact that Java doesn't provide pattern matching
and Standard ML does are just accidents of history. I think you're
arguing as if there were more to it.
> OTOH, conceptually, a new optimizations is a much more local issue,
> so it is natural and helpful to map it to a local change in the source.
I disagree with this. What you say is true of local optimizations,
but most of the important optimizations are seriously non-local.
> Isn't a new backend a new "operation" on the AST, just like an
> optimization phase?
It is if you prefer to think of it that way. I prefer to think of
the backend as an operation on the target architecture that yields
an operation defined on the output of the frontend. This is both
an OO and a (higher-order) functional point of view.
I will leave the rest of your questions as an exercise for the
reader.
Will
William D Clinger wrote:
> I think you think you are arguing with me, but it appears to me
> that your argument is based upon one or more misconceptions along
> the lines of:
>
> * pattern matching must be based on static types
> * pattern matching implies closed rather than open sums
> * open sums imply OO case-switching
>
> None of these statements are correct.
Completely agreed. (Note that closedness is not really expressible without
static types, though.)
But I don't know from where you inferred that I would assume any of the
above. I originally replied to the following statement of yours:
> Discriminated unions are a nightmare in C, but have a natural
> representation in Java as an abstract class with the various
> summands represented as concrete subclasses. In my opinion,
> sum-of-product types are the basic paradigm for Java-like OO
> languages, and are one of the few things they do well.
You obviously were speaking about doing sums the OO way, not pattern
matching (the application you were discussing was compilers). I argued that
pattern matching is highly superior to objects for ASTs, and AFAIU you
disagreed in a follow-up. So I'm slightly confused by your above comment.
>> See my comments to your specific points below. But first let me ask the,
>> IMO, most important question: How do you do non-local case switches?
>
> I use pattern matching. On open sums.
OK, but this somewhat contradicts your above statement.
> In Twobit, your example would be written using an extension of the
> pattern language used for hygienic macros in Scheme,
That's all perfectly fine, but we weren't discussing Scheme. (Well, at least
I wasn't, and rereading your posts I don't think you were either. You
definitely weren't in the quoted statement.) We were mainly discussing
method dispatch vs. pattern matching.
> If I were doing this in Java, I would
> probably write the simplification rules approximately as above, and
> compile them into a Java state machine. This would be a bit of a
> bother, but I would not have to write much new code beyond what I
> have already written for the hygienic macro facility and for a
> scanner generator that outputs code for state machines written in
> Java (and several other languages).
>
> I could express these rules directly in Java, but it would be a lot
> more painful.
>
> Note that the real problem with Java here is not that it lacks closed
> sums, since open sums work just as well if not better, but the lack
> of pattern matching and the lack of any macro facility that I could
> use to implement pattern matching.
Agreed (more or less - doing pattern matching based on an object encoding
doesn't sound like an overly pleasing idea to me).
In any case, how did you come to the conclusion that Java does these things
well in this light?
>> The OO idiom doesn't give you anything reasonable to deal with
> [pattern matching]
>> That's basically my main problem with the OO-approach to case
>> switching: it is not suitable for non-trivial algorithms.
>
> True, but it doesn't get in the way either. OO and pattern matching
> are orthogonal. The fact that Java doesn't provide pattern matching
> and Standard ML does are just accidents of history. I think you're
> arguing as if there were more to it.
Well, yes and no. In some sense they are dual approaches to the same thing,
namely "switching". One is "intensional", the other "extensional". While
both surely can coexist (and they do in some languages), I generally assume
it to be a conscious design decision not to have that kind of duplicate
machinery in one language.
>> OTOH, conceptually, a new optimizations is a much more local issue,
>> so it is natural and helpful to map it to a local change in the source.
>
> I disagree with this. What you say is true of local optimizations,
> but most of the important optimizations are seriously non-local.
You probably talk about a different dimension of locality here. I meant that
optimization in no way affects the way parsing has to be done, for example.
OTOH, when adding a new language feature you usually have to consider
interaction with all other language features. Hence it is much less local
by nature in its respective dimension.
Regards,
- 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.
Okay, it sounds like we are in substantial agreement on most things.
I apologize for thinking otherwise.
I also apologize for my confusing remarks. I stand by most of what
I said in the contexts I said them in, but the contexts have varied
as I have responded to different people. My first remarks, in the
context of antilock brakes as a metaphor for static typing, argued
that drivers of ABS-equipped autos should optimize for the common
case, not for the unlikely event of emergency braking in an vehicle
not their own; this was to argue that programmers should optimize
for the common case in which an apparent type error really is an
error, not for the uncommon case in which the programmer is smarter
than a static type system.
In response to a claim that most of the type errors that compilers
detect are spurious, I argued that this is false because most type
errors are reported by compilers for languages like C and Java.
Someone then suggested that a compiler's "discriminated unions or
whatever you want to call them" are "completely impossible to
express...in C or Java". I agreed that discriminated unions are
"a nightmare in C, but have a natural representation in Java".
I also expressed my opinion that "sum-of-product types are the
basic paradigm for Java-like OO languages, and are one of the few
things they do well."
This person then used the phrase "pattern matching" in a way that
made me think he didn't understand the basic Java idiom for
dispatching on a sum type. In my response, I put "pattern matching"
in quotes to emphasize that I consider this to be an extremely
primitive kind of pattern matching.
You, Andreas Rossberg, "strongly" disagreed, asserting that
"'discriminated unions' are disjoint, closed sums". I personally
have not seen the sacred tablets on which this is written, but no
matter. I replied that open sums are better than closed sums in
the compiler context. This has proved to be far more controversial
than I expected, but none of the counterarguments I have read have
changed my opinion on this.
You then asked how I do "non-local case switches" and followed
that by an example of local source transformations, which are
one of the very few cases in which SML-style pattern matching
really helps when writing a compiler. I responded by saying
I use pattern matching, pointing out that pattern matching is
compatible not only with open sums but also with the complete
absence of static types. I pointed these things out because,
in the context of your previous message, I mistakenly thought
you believe pattern matching has something to do with static
types and specifically with closed sums.
I mentioned Scheme only because you asked me how I do pattern
matching. You didn't ask how I would do pattern matching in
Java, but I told you anyway because I thought it was probably
more relevant than what I actually do.
> > Note that the real problem with Java here is not that it lacks closed
> > sums, since open sums work just as well if not better, but the lack
> > of pattern matching and the lack of any macro facility that I could
> > use to implement pattern matching.
>
> Agreed (more or less - doing pattern matching based on an object encoding
> doesn't sound like an overly pleasing idea to me).
I'm not sure we really agree here. I'm saying that the main
reason pattern matching in Java is more difficult than pattern
matching in Scheme is that Java doesn't have macros. You seem
to think that "object encoding", whatever that means, might be
a serious issue.
> In any case, how did you come to the conclusion that Java does
> these things well in this light?
I said Java does sum-of-product types well. I did not imply that
Java does SML-style pattern matching at all. From your remark
quoted above, I assume you think that SML-style pattern matching
is essential for doing sum-of-product types well. I agree that
SML-style pattern matching is nice, but I don't regard it as
essential. I don't even think it's terribly important.
For example, I think macros are more important than SML-style
pattern matching. With macros, I can construct purpose-built
matchers that are capable of expressing the side conditions of
a transformation rule.
Will
William D Clinger wrote:
> Okay, it sounds like we are in substantial agreement on most things.
Yes. Thanks for the clarifications.
> I replied that open sums are better than closed sums in
> the compiler context. This has proved to be far more controversial
> than I expected, but none of the counterarguments I have read have
> changed my opinion on this.
This seems to be one of the points where we disagree. Personally, I learnt
to appreciate how helpful closedness really is while having worked for
quite some time with an ML compiler that didn't yet implement the
exhaustiveness (i.e. closedness) check on patterns. Actually, I consider
these checks one of the biggest pros of static typing, particularly during
changes.
>> > Note that the real problem with Java here is not that it lacks closed
>> > sums, since open sums work just as well if not better, but the lack
>> > of pattern matching and the lack of any macro facility that I could
>> > use to implement pattern matching.
>>
>> Agreed (more or less - doing pattern matching based on an object encoding
>> doesn't sound like an overly pleasing idea to me).
>
> I'm not sure we really agree here. I'm saying that the main
> reason pattern matching in Java is more difficult than pattern
> matching in Scheme is that Java doesn't have macros. You seem
> to think that "object encoding", whatever that means, might be
> a serious issue.
Yes, IMO it is an issue for at least three reasons:
1. Objects tend to be *much* more heavyweight (at runtime) than simple
"tagged" values, due to all the additional machinery they support.
2. To simulate pattern matching you had to use instanceof, which also is
much more expensive than simple tag tests, particularly since its checks
are hierarchical.
3. I'm generally very sceptical about the macro argument when it comes to
non-trivial constructions. Pattern matching is a complex mechanism that
requires relatively elaborate compilation passes to be sufficiently
efficient. I don't think the average Java programmer wants to learn about
compiler techniques first. (You may say that it could be in the library -
true, but that would essentially be equivalent to being in the language.)
In short, you'd pay a pretty significant price in space, time and
programmer's work compared to a builtin mechanism. Consequently, in my
book, even a Java with fancy macros would be far from suitable for domains
requiring considerable amounts of symbolic computation.
And of course, pattern matching generally is against the advertised spirit
of OO. :-)
> From your remark
> quoted above, I assume you think that SML-style pattern matching
> is essential for doing sum-of-product types well. I agree that
> SML-style pattern matching is nice, but I don't regard it as
> essential. I don't even think it's terribly important.
>
> For example, I think macros are more important than SML-style
> pattern matching. With macros, I can construct purpose-built
> matchers that are capable of expressing the side conditions of
> a transformation rule.
Here we obviously disagree. I consider pattern matching indispensible, at
least for certain application domains. OTOH, I think macros are nice, but
not important, at least not in a language with lightweight functional
syntax. I can live with some standard preprocessor if there really is a
pressing need.
I guess it all depends on the application domain. As always, use the right
tool for the right problem.
- 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:
> 1. Objects tend to be *much* more heavyweight (at runtime) than simple
> "tagged" values, due to all the additional machinery they support.
In current implementations of Java, the object overhead is typically 64 bits.
> 2. To simulate pattern matching you had to use instanceof, which also is
> much more expensive than simple tag tests, particularly since its checks
> are hierarchical.
This is untrue. As noted in a previous post, I would not use instanceof
for pattern matching in Java. If you do not understand how to avoid the
use of instanceof, then let's start a new thread on that topic.
> 3. I'm generally very sceptical about the macro argument when it comes to
> non-trivial constructions. Pattern matching is a complex mechanism that
> requires relatively elaborate compilation passes to be sufficiently
> efficient. I don't think the average Java programmer wants to learn about
> compiler techniques first.
I didn't realize we were talking about the average Java programmer.
I thought we were talking about compiler writers, specifically me.
> (You may say that it could be in the library -
> true, but that would essentially be equivalent to being in the language.)
Yes, I would say that most programmers should get their pattern
matchers from a library. I would also say that the main reason
it isn't practical to put pattern matching into a Java library
is because Java doesn't have macros.
> In short, you'd pay a pretty significant price in space, time and
> programmer's work compared to a builtin mechanism.
I have nothing against built-in pattern matchers that are powerful
enough to attach side conditions to the patterns. I regard pattern
matchers that lack this power as pretty toys: elegant in the simple
cases where you don't really need pattern matching, and useless in
the hard cases where you do.
It seems to me that we have spent more time talking about pattern
matching than static sum types.
Will
From: Christopher Jeris
Subject: Re: Sum types (Was: Re: OT: More Antilock brakes)
Date:
Message-ID: <uwu9cw803.fsf@fake.address.us>
··········@verizon.net (William D Clinger) writes:
> This is untrue. As noted in a previous post, I would not use instanceof
> for pattern matching in Java. If you do not understand how to avoid the
> use of instanceof, then let's start a new thread on that topic.
Okay, I'm a novice everything, but curious: Manually put a type-tag
field in the direct superclass of your summands, and dispatch on that?
(If that's a blazingly stupid way to do it, please don't understand me
to impute such stupidity to you!)
peace, Chris Jeris ······@oinvzer.net
Apply (1 6 2 4)(3 7) to domainname to reply.
Christopher Jeris <······@fake.address.us> writes:
> ··········@verizon.net (William D Clinger) writes:
> > This is untrue. As noted in a previous post, I would not use instanceof
> > for pattern matching in Java. If you do not understand how to avoid the
> > use of instanceof, then let's start a new thread on that topic.
>
> Okay, I'm a novice everything, but curious: Manually put a type-tag
> field in the direct superclass of your summands, and dispatch on that?
> (If that's a blazingly stupid way to do it, please don't understand me
> to impute such stupidity to you!)
http://nice.sourceforge.net/visitor.html
--=-=-=
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
"Daniel C. Wang" <·········@hotmail.com> writes:
> Christopher Jeris <······@fake.address.us> writes:
>> ··········@verizon.net (William D Clinger) writes:
>>> This is untrue. As noted in a previous post, I would not use instanceof
>>> for pattern matching in Java. If you do not understand how to avoid the
>>> use of instanceof, then let's start a new thread on that topic.
>> Okay, I'm a novice everything, but curious: Manually put a type-tag
>> field in the direct superclass of your summands, and dispatch on that?
> http://nice.sourceforge.net/visitor.html
If you will forgive a na�
--=-=-=
Content-Transfer-Encoding: 8bit
��ve question; how is the 'Nice' approach
with multimethods different from instanceof and downcasts? Apart from
providing a neat syntax for it, that is? Is it doing something
fundamentally different?
In C++, ISTR that a "multimethod" implementation would statically
determine the dispatch, which more often than not would mean the
argument type would be determined to be the (abstract) base class. I
assume Nice dispatches on dynamic type?
-kzm
--
If I haven't seen further, it is by standing in the footprints of giants
--=-=-=--
·····@ii.uib.no wrote:
> ��ve question; how is the 'Nice' approach
> with multimethods different from instanceof and downcasts? Apart from
> providing a neat syntax for it, that is? Is it doing something
> fundamentally different?
How is the approach with function calls different from pushing
parameters and return addresses to a stack and using gotos to jump to
and returm from subroutines? Apart from providing a neat syntax for it,
that is? Is it doing something fundamentally different?
Pascal
--
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
Pascal Costanza <········@web.de> writes:
> ·····@ii.uib.no wrote:
>> how is the 'Nice' approach with multimethods different from
>> instanceof and downcasts? [...]
> How is the approach with function calls different from pushing [...]
I guess that means "no"?
-kzm
--
If I haven't seen further, it is by standing in the footprints of giants
From: Fergus Henderson
Subject: Re: Sum types (Was: Re: OT: More Antilock brakes)
Date:
Message-ID: <3fd41925$1@news.unimelb.edu.au>
Pascal Costanza <········@web.de> writes:
>·····@ii.uib.no wrote:
>
>> how is the 'Nice' approach
>> with multimethods different from instanceof and downcasts? Apart from
>> providing a neat syntax for it, that is? Is it doing something
>> fundamentally different?
>
>How is the approach with function calls different from pushing
>parameters and return addresses to a stack and using gotos to jump to
>and returm from subroutines? Apart from providing a neat syntax for it,
>that is? Is it doing something fundamentally different?
The approach with function calls is a much higher-level approach,
which helps programmers to think at a higher level of abstraction.
Some categories of errors, e.g. a function forgetting to pop all of its
parameters before returning, can be eliminated entirely, while others
can be reported at a higher level of abstraction, e.g. "call to foo()
with wrong number of arguments", and can be detected earlier.
So yes, the approach with function calls is doing something fundamentally
different.
--
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.
Daniel C. Wang wrote:
> Christopher Jeris <······@fake.address.us> writes:
>
>
>>··········@verizon.net (William D Clinger) writes:
>>
>>>This is untrue. As noted in a previous post, I would not use instanceof
>>>for pattern matching in Java. If you do not understand how to avoid the
>>>use of instanceof, then let's start a new thread on that topic.
>>
>>Okay, I'm a novice everything, but curious: Manually put a type-tag
>>field in the direct superclass of your summands, and dispatch on that?
>>(If that's a blazingly stupid way to do it, please don't understand me
>>to impute such stupidity to you!)
>
>
> http://nice.sourceforge.net/visitor.html
>
>
Well, NICE is nice, but I have not seen any references to Common Lisp in
the pages
--
Marco
Christopher Jeris quoting me:
> > This is untrue. As noted in a previous post, I would not use instanceof
> > for pattern matching in Java. If you do not understand how to avoid the
> > use of instanceof, then let's start a new thread on that topic.
>
> Okay, I'm a novice everything, but curious: Manually put a type-tag
> field in the direct superclass of your summands, and dispatch on that?
Yes, that works. You wouldn't do that for single dispatching, but it
lets you implement complex pattern matching in a straightforward and
efficient way.
> (If that's a blazingly stupid way to do it, please don't understand me
> to impute such stupidity to you!)
I don't think it's stupid, but if we're willing to wait a bit someone
may explain to us why it is.
Will
William D Clinger <··········@verizon.net> wrote:
> >
> > Okay, I'm a novice everything, but curious: Manually put a type-tag
> > field in the direct superclass of your summands, and dispatch on that?
>
> Yes, that works. You wouldn't do that for single dispatching, but it
> lets you implement complex pattern matching in a straightforward and
> efficient way.
>
> > (If that's a blazingly stupid way to do it, please don't understand me
> > to impute such stupidity to you!)
>
> I don't think it's stupid, but if we're willing to wait a bit someone
> may explain to us why it is.
Am I right guessing that you are alluding to me? Well, so be it. :-)
It's not a stupid idea - given the limitations of the language. But it
clearly is a workaround. I wouldn't even hesitate to call it a hack.
It means duplicating work that is supposed to be done by the type system. It
means giving up the static consistency checking that is supposed to be
performed by the type system. It means producing even more representational
overhead, which is supposed to be avoided by the type system. You are
basically have to fall back to the C level. Not exactly what I would expect
from a language with good support for sum types.
And of course, this encoding requires you to set up your classes
appropriately. So it could not be captured by a pattern matching macro
alone.
Does that reply meet your expectations? :-)
- Andreas
> Does that reply meet your expectations? :-)
>
> - Andreas
Bravo!
Will
From: Fergus Henderson
Subject: Re: Sum types (Was: Re: OT: More Antilock brakes)
Date:
Message-ID: <3fd41c28$1@news.unimelb.edu.au>
"Andreas Rossberg" <········@ps.uni-sb.de> writes:
>It means producing even more representational overhead
As Richard O'Keefe pointed out to me, a way to avoid the space overhead
of this technique is to use a virtual function that returns the type tag,
rather than a type tag field. Of course, this comes at the cost of
increasing the time overhead...
--
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.
William D Clinger wrote:
>> 1. Objects tend to be *much* more heavyweight (at runtime) than simple
>> "tagged" values, due to all the additional machinery they support.
>
> In current implementations of Java, the object overhead is typically 64
> bits.
I also had in mind the allocation/construction overhead. Moreover, I don't
generally consider 2 words per tag neglectable. For heavy symbolic stuff
this could amount to a more than two-fold increase in memory footprint.
Looking at the various attempts to implement functional languages on
OO-driven machines like the JVM or the Dotnet CLR you can usually identify
at least two serious performance bottlenecks: closures and sum types, both
due to the overhead of objects.
>> 2. To simulate pattern matching you had to use instanceof, which also is
>> much more expensive than simple tag tests, particularly since its checks
>> are hierarchical.
>
> This is untrue. As noted in a previous post, I would not use instanceof
> for pattern matching in Java. If you do not understand how to avoid the
> use of instanceof, then let's start a new thread on that topic.
I have to admit that I don't see how you can get full-blown pattern matching
without either using instanceof, or manual type tags, or a whole program
transformation.
> I have nothing against built-in pattern matchers that are powerful
> enough to attach side conditions to the patterns. I regard pattern
> matchers that lack this power as pretty toys: elegant in the simple
> cases where you don't really need pattern matching, and useless in
> the hard cases where you do.
I agree that side conditions are highly desirable. On the other hand I found
- very much to my own surprise, I must say - that I rarely have use for
them in practice.
> It seems to me that we have spent more time talking about pattern
> matching than static sum types.
:-) Is that a bad thing?
- 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.
From: Torben �gidius Mogensen
Subject: Re: Sum types (Was: Re: OT: More Antilock brakes)
Date:
Message-ID: <w5zne820br.fsf@pc-032.diku.dk>
Andreas Rossberg <········@ps.uni-sb.de> writes:
> Personally, I learnt to appreciate how helpful closedness really is
> while having worked for quite some time with an ML compiler that
> didn't yet implement the exhaustiveness (i.e. closedness) check on
> patterns. Actually, I consider these checks one of the biggest pros
> of static typing, particularly during changes.
While I tend to agree, I also occasionally become slightly irritated
by them. Example: I do pattern-matching on two lists I know to be of
equal length but I either have to specify cases where they aren't or
suffer compiler warnings.
Refinement types would help here, but they aren't part of SML.
Torben
From: Joachim Durchholz
Subject: Re: Sum types (Was: Re: OT: More Antilock brakes)
Date:
Message-ID: <bqfvoi$ifq$1@news.oberberg.net>
Andreas Rossberg wrote:
>
> Also, operations on ASTs are often complex algorithms. Splitting and
> spreading them all over the place is a very bad idea with respect to
> readability and maintainability. Furthermore, these algorithms may
> change often themselves, probably introducing additional parameters,
> thus changing the recursion pattern. You don't want to look into a
> thousand places everytime you do this.
>
> That's basically my main problem with the OO-approach to case
> switching: it is not suitable for non-trivial algorithms.
Splitting an algorithm across OO objects is generally a bad idea.
IOW the doctor says: "Don't do this if it hurts!" :-)
Personally, if I have to distribute an algorithm across various nodes,
I do exactly that, but I also document the invariants that the algorithm
leaves intact.
When I write the second algorithm, I usually find that I can keep a lot
of those invariants.
After a few iterations, I have a set of invariants that don't reflect
particular algorithms, but invariants of the data structures. The
invariants begin to describe rules that the various transformation
should obey (such as semantics preservation, some decreasing complexity
measure, or whatever); in other words, I can look at the invariants and
start to think about what other transformations these invariants would
allow (I still have to verify that these transformations still make
sense, since no set of written-down invariants will usually be 100%
foolproof - but an inspiration is an inspiration.)
OO is entirely unsuitable for ad-hockery.
But it can give excellent results for libraries.
Regards,
Jo
Feuer <·····@his.com> writes:
> William D Clinger wrote:
>>
>> Joe Marshall wrote:
>> > True, I should be explicit. I was assuming that *everyone* thought
>> > that the C and Java type systems were so lame as to be beneath
>> > contempt.
>>
>> *That* goes without saying. Nonetheless, lame type systems
>> detect most of the type errors that are detected in practice.
>
> You write compilers (chock full of discriminated unions or whatever
> you want to call them) and you don't find it completely impossible
> to express your desired types in C or Java?
It's trivial. In C just write a macro that casts via intptr_t, in
Java, just cast the damn thing to object and be done with it.
Oh, you want the compiler to *help*? That's a different story.
--
~jrm
Joe Marshall wrote:
> > You write compilers (chock full of discriminated unions or whatever
> > you want to call them) and you don't find it completely impossible
> > to express your desired types in C or Java?
>
> It's trivial. In C just write a macro that casts via intptr_t, in
> Java, just cast the damn thing to object and be done with it.
>
> Oh, you want the compiler to *help*? That's a different story.
Huh? I say "express your desired types" and you come back with
/casting/?
David
Feuer <·····@his.com> writes:
> Joe Marshall wrote:
>
>> > You write compilers (chock full of discriminated unions or whatever
>> > you want to call them) and you don't find it completely impossible
>> > to express your desired types in C or Java?
>>
>> It's trivial. In C just write a macro that casts via intptr_t, in
>> Java, just cast the damn thing to object and be done with it.
>>
>> Oh, you want the compiler to *help*? That's a different story.
>
> Huh? I say "express your desired types" and you come back with
> /casting/?
It's the macro that makes the expression. It allows you to `express'
to the next person that reads the code what it is you intend.
Unfortunately, it has no semantic meaning to the compiler, so it's a
rather limited form of expression. But hey, you work with what you
got.
··········@verizon.net (William D Clinger) writes:
> Joe Marshall wrote:
>> True, I should be explicit. I was assuming that *everyone* thought
>> that the C and Java type systems were so lame as to be beneath
>> contempt.
>
> *That* goes without saying. Nonetheless, lame type systems
> detect most of the type errors that are detected in practice.
Ummm... do they actually *detect* anything?
--
~jrm
Joe Marshall wrote:
> > *That* goes without saying. Nonetheless, lame type systems
> > detect most of the type errors that are detected in practice.
>
> Ummm... do they actually *detect* anything?
I'm not saying they can be compared to Sherlock Holmes.
Will
··········@verizon.net (William D Clinger) writes:
> Joe Marshall wrote:
>> > *That* goes without saying. Nonetheless, lame type systems
>> > detect most of the type errors that are detected in practice.
>>
>> Ummm... do they actually *detect* anything?
>
> I'm not saying they can be compared to Sherlock Holmes.
Chief Inspector Clouseau, then?
``What do we know..
ONE.. The a tahp erreur has been detected
TWO.. That something is of the wrong tahp
THREE.. My hand is on fire.''
In comp.lang.functional Joe Marshall <···@ccs.neu.edu> wrote:
> I'm interested not in those cases where the compiler says `this is
> obviously bogus' but when the compiler says `I don't see anything
> actually *wrong* here, but since I'm not sure it is *right* either,
> I'm going to rule in favor of it being an error.'
That would be well possible, e.g. with polymorphic recursion.
There are actually even cases where the compiler tells you that things
are wrong even though they are right from a type theoretic point of view -
and still has good reason to do so!
An example is recursive types in OCaml, e.g. (oversimplified):
type t = t * t
Even though type inference in the presence of such types is decidable
(using semi-unification), practice shows that users often write completely
bogus code that typechecks correctly. The reason is that the compiler
figures out completely mad types that fit perfectly, although the
programmer just wrote pure nonsense without noticing. That's why you
have to pass a compiler option in OCaml if you really mean it. In the
default mode the compiler will flag such things as an error. This, too,
is hardly a problem in practice, because even without the flag you can
easily work around it, e.g.:
type t = Foo of t * t
In this case the user would be forced to tag such recursive values
to create them, thus "proving" to the compiler that he knows what he
is doing.
Not every program that typechecks correctly makes sense. Sometimes it
is good for compilers to be a little bit fascist (that's not a political
statement, of course ;)...
Regards,
Markus Mottl
--
Markus Mottl http://www.oefai.at/~markus ······@oefai.at
In comp.lang.functional Joe Marshall <·············@comcast.net> wrote:
> ··········@verizon.net (William D Clinger) writes:
> What do you mean by `Computers really are better than people...'?
> Do you mean that
> a) Computers can prove bogus code is wrong with a higher success
> rate than people (especially when the people are only casually
> examining the code)
Though this is not a question to me, I'd like to answer it. My experience
shows that most errors I make are caught by the compiler. This starts
with simple syntax errors and goes on to type errors. Even if we leave
away syntax errors, I'd say that the compiler still catches more errors
than there are left in the code after static verification. So to me this
is a very big productivity gain.
> or
> b) When a computer fails to prove code right it is more likely that
> the code is in error than it is that the computer is baffled
That's definitely the case, too. I'd say that in such cases the
probability that the computer is right and the user is wrong exceeds
99.99%. But maybe you mean something else?
> or both?
Yes.
> I'll certainly agree with part a, but not part b. Do you have a
> persuasive argument?
My personal experience. I have near absolute trust in what the compiler
tells me after static verification, since everytime I thought that I
was still right, I had to learn that I was wrong.
Regards,
Markus Mottl
--
Markus Mottl http://www.oefai.at/~markus ······@oefai.at
"Markus Mottl" <······@oefai.at> writes:
> In comp.lang.functional Joe Marshall <·············@comcast.net> wrote:
>> ··········@verizon.net (William D Clinger) writes:
>> What do you mean by `Computers really are better than people...'?
>> Do you mean that
>
>> a) Computers can prove bogus code is wrong with a higher success
>> rate than people (especially when the people are only casually
>> examining the code)
>
> Though this is not a question to me, I'd like to answer it. My experience
> shows that most errors I make are caught by the compiler. This starts
> with simple syntax errors and goes on to type errors. Even if we leave
> away syntax errors, I'd say that the compiler still catches more errors
> than there are left in the code after static verification. So to me this
> is a very big productivity gain.
>
>> or
>
>> b) When a computer fails to prove code right it is more likely that
>> the code is in error than it is that the computer is baffled
>
> That's definitely the case, too. I'd say that in such cases the
> probability that the computer is right and the user is wrong exceeds
> 99.99%. But maybe you mean something else?
Well, now I have to ask `how do you know which one it was'?
If I understand correctly, H-M type systems are strongly normalizing,
i.e., the type inference always completes. There is only one failure
mode (code is not proven correct) rather than two (code is either
proven wrong or inference either fails to terminate or gives up). How
can you tell the difference between failures that can be proven wrong
and failures that simply cannot be proven correct?
> My personal experience. I have near absolute trust in what the compiler
> tells me after static verification, since everytime I thought that I
> was still right, I had to learn that I was wrong.
I absolutely believe the compiler if it has proven something wrong.
And I'm sure that H-M type systems often catch those cases.
I want to know about the ambiguous ones.
--
~jrm
In comp.lang.functional Joe Marshall <·············@comcast.net> wrote:
> "Markus Mottl" <······@oefai.at> writes:
>> That's definitely the case, too. I'd say that in such cases the
>> probability that the computer is right and the user is wrong exceeds
>> 99.99%. But maybe you mean something else?
> Well, now I have to ask `how do you know which one it was'?
> If I understand correctly, H-M type systems are strongly normalizing,
> i.e., the type inference always completes. There is only one failure
> mode (code is not proven correct) rather than two (code is either
> proven wrong or inference either fails to terminate or gives up). How
> can you tell the difference between failures that can be proven wrong
> and failures that simply cannot be proven correct?
Experience and knowledge about limitations. H-M type systems are fairly
expressive what concerns normal usage. There are, of course, instances
where the type inference machine cannot know that user code is indeed
correct, e.g. when you use polymorphic recursion. In Haskell it's up to
the user then to specify a type signature to help the compiler, whereas
in e.g. OCaml, which I prefer for most work, you have to work around
this in a slightly clumsy way, because you cannot specify mandatory
type constraints.
However, you can trust me here, it happens extraordinarily seldom
that you need such features. For me maybe once a year? Chris Okasaki,
for example, uses (generally undecidable) polymorphic recursion in his
book on "Purely Functional Datastructures" to specify some otherwise
highly complex datastructure very elegantly. So, yes, sometimes there
are limitations. But they do not matter much in practice.
There is actually another theoretic problem with H-M type systems:
type inference is generally NP-complete, i.e. though it terminates,
it may only do so after the heat death of the universe (or whatever
apocalyptic scenario you prefer ;), which may be a bit too late for us...
But in years of programming I have never encountered a practical example
where this occured to me. In fact, type checking + separate compilation in
OCaml is so fast (usually only fractions of a second for usual modules)
that I routinely just fire the compiler if I want to make sure that
my code as written so far makes at least some sense. Additionally,
some features of the newest release allow you to have inferred types
displayed in your favorite editor (Vim or Emacs), which is also very
helpful during programming.
> I absolutely believe the compiler if it has proven something wrong.
> And I'm sure that H-M type systems often catch those cases.
> I want to know about the ambiguous ones.
I hope this answers your questions?
Regards,
Markus Mottl
--
Markus Mottl http://www.oefai.at/~markus ······@oefai.at
"Markus Mottl" <······@oefai.at> writes:
> In comp.lang.functional Joe Marshall <·············@comcast.net> wrote:
>> "Markus Mottl" <······@oefai.at> writes:
>>> That's definitely the case, too. I'd say that in such cases the
>>> probability that the computer is right and the user is wrong exceeds
>>> 99.99%. But maybe you mean something else?
>
>> Well, now I have to ask `how do you know which one it was'?
>
>> If I understand correctly, H-M type systems are strongly normalizing,
>> i.e., the type inference always completes. There is only one failure
>> mode (code is not proven correct) rather than two (code is either
>> proven wrong or inference either fails to terminate or gives up). How
>> can you tell the difference between failures that can be proven wrong
>> and failures that simply cannot be proven correct?
>
> However, you can trust me here, it happens extraordinarily seldom
> that you need such features. For me maybe once a year? Chris Okasaki,
> for example, uses (generally undecidable) polymorphic recursion in his
> book on "Purely Functional Datastructures" to specify some otherwise
> highly complex datastructure very elegantly. So, yes, sometimes there
> are limitations. But they do not matter much in practice.
This seems to indicate that most errors found are those that are
provably incorrect and that there are few caused by `correct, but not
provably so' code. I'll buy that.
In comp.lang.functional Joe Marshall <···@ccs.neu.edu> wrote:
> This seems to indicate that most errors found are those that are
> provably incorrect and that there are few caused by `correct, but not
> provably so' code. I'll buy that.
Yes, that's it: the percentage of "correct, but not provably so" programs,
i.e. ones that do not pass the type checker although the code makes sense,
is so extremely small in practice that I cannot even meaningfully make
a guess due to lack of sufficiently many observations of this kind.
Regards,
Markus Mottl
--
Markus Mottl http://www.oefai.at/~markus ······@oefai.at
··········@verizon.net (William D Clinger) wrote in message news:<····························@posting.google.com>...
> Raffael Cavallaro wrote:
> > The rest of us, who drive more than one car (e.g., rentals, friends' or
> > spouses' cars, company cars, etc.) need automatic reactions that serve
> > us well in any emergency, not just if we're lucky enough to be in a car
> > with ABS brakes when an emergency arises.
>
> Do you want your compiler to optimize for the exceptional case or for
> the common case?
These are two different issues (brakes and compilers). In the case of
brakes, I always want to optimize for safety. In the case of compilers
there are different kinds of optimization as you know.
>
> Until recently, I did well over 99% of my driving in one car, which
> has antilock brakes. (I now do about 5% of my driving in another car,
> which also has antilock brakes.) I want to optimize my automatic
> reaction for the overwhelmingly likely case, not for the exceedingly
> unlikely case of being the driver of a car that doesn't have antilock
> brakes.
I apparently drive more different cars than you do. I suspect this may
be true of others. Others still will drive several cars, most of which
don't have ABS brakes.
[snip]
> It is much easier to train oneself to stomp on the brakes than to
> train oneself to modulate the brakes, and no matter how hard you try
> you will never train yourself to brake as well as an antilock braking
> system. I admire your John Henry act, but computers really can brake
> better than people.
No question that computers can brake better than people - it has never
been my contention that I am better than a computer at braking, so
there is no "John Henry act" here. But a computer will not help you
when the car you are in does not have ABS brakes. Then, the habits one
has developed on ABS brake equipped cars will serve one poorly.
>
> And to bring this back on topic: Computers really are better than
> people when it comes to static checking for the class of errors that
> we usually refer to as type errors. Do you want to optimize your
> error checking for the exceptional case in which an apparent type
> error isn't really an error, or for the common case in which it is?
I would love to optimize, as you say, for the common case in which the
apparent type error is a real error, but I would like to do so
unobtrusively - without having to constrain my thinking about the
problem to the type system of the compiler. I therefore prefer to do
without static type checking, and use dynamic typing instead.
P.S. sorry if this response is late - I've been busy with Thanksgiving
related things and not had access to usenet.
·······@mediaone.net (Raffael Cavallaro) wrote:
> P.S. sorry if this response is late - I've been busy with Thanksgiving
> related things and not had access to usenet.
No problem. This thread had become increasingly irrelevant to
antilock brakes, and I was pleased by your attempt to bring us
back off topic.
Will
··········@verizon.net (William D Clinger) writes:
> ·······@mediaone.net (Raffael Cavallaro) wrote:
> > P.S. sorry if this response is late - I've been busy with Thanksgiving
> > related things and not had access to usenet.
>
> No problem. This thread had become increasingly irrelevant to
> antilock brakes, and I was pleased by your attempt to bring us
> back off topic.
Oh, so you say it's off-topic then? And here was I, thinking the
whole time that "ABS" is some sort of code for something very much
on-topic... :-)
Raffael Cavallaro <················@junk.mail.me.not.mac.com> writes:
> In article <··············@uranus.local>,
> Peter Herth <·····@netcologne.de> wrote:
>
> > Its not bad driving.
>
> It's bad driving because not all cars have ABS brakes. In an emergency,
> one doesn't really have time to think, "does this car have ABS brakes?"
> One simply reacts according to training/habit, and either applies
> pressure gradually, or just stomps on the brake pedal. If one does the
> latter in a car with ordinary brakes, the wheels will lock, and loss of
> steering control, and/or a skid will result.
>
> I'm sure race drives can rely on their race vehicles to always have ABS
> brakes, so they can afford to acquire the habit of always putting
> maximum pressure on the brake pedal. This way they gain the advantage
> you describe of maximum braking every time they apply the pedal. This
> suggests, BTW, that what is best for trained professionals (here, race
> car drives), under controlled circumstances (vehicles which they know,
> as a certainty, will always have ABS brakes) is not necessarily what is
> best for the general public.
>
> The rest of us, who drive more than one car (e.g., rentals, friends' or
> spouses' cars, company cars, etc.) need automatic reactions that serve
> us well in any emergency, not just if we're lucky enough to be in a car
> with ABS brakes when an emergency arises. When all cars have ABS brakes,
> then stomping on the brake will not be bad driving. Until then, stomping
> on the brakes is a *bad* idea - it causes skids in cars with ordinary
> brakes.
The problem with all this is that stomping on the brakes in an
emergency situation is what comes naturally to most people. It takes
long and intensive training to avoid doing it. Most people do not
have that kind of training -- which is why ABS is almost always going
to be a win.
I have seen studies where ordinary drivers were given a fairly
extensive "advanced driving class" -- which tried to teach precisely
the techniques that avoid the kinds of wrong reactions which most
people exhibit naturally in emergency situations. At the end of the
course (during which most of the students finally seemed to catch on
and were able to do master most of the training situations) they sent
them through a different course with surprise obstacles in places that
they had never seen before. And almost all of them were back to square
one again... (i.e., they overreacted, stomped on the brakes, sent
their cars into catastrophic oversteer, etc.) Bottom line: This stuff
is *really hard*, and every help we mere mortals can get should be
welcome.
Matthias Blume <····@my.address.elsewhere> wrote in message news:<··············@hanabi-air.shimizu.blume>...
> Raffael Cavallaro <················@junk.mail.me.not.mac.com> writes:
>
> > In article <··············@uranus.local>,
> > Peter Herth <·····@netcologne.de> wrote:
> >
> > > Its not bad driving.
> >
> > It's bad driving because not all cars have ABS brakes. In an emergency,
> > one doesn't really have time to think, "does this car have ABS brakes?"
> > One simply reacts according to training/habit, and either applies
[[ Stuff removed]]
Check out what motor bike riders are taught - here in Victoria
Australia, I know that they were/are taught that braking is a double
action process - the first phase is to compress the suspension and
then put the brakes on as hard as you want - brakes don't lock up at
the same level of pressure as the weight of the vehicle and people are
now acting together with the brakes to slow down as when you don't
compress the suspension.
Lab testing has been done to show the effectiveness of the process.
I did the same process in my V8 1970 panel van (definitely no ABS) in
the wet and I stopped the vehicle without skidding in the shortest
distance I have ever achieved. It takes practice - which I don't do
today as I tend to a much more conservative driver than when I was
when younger. But I should really be practicing the process regularly.
regards
Bruce Rennie
(from God's Own Country Down Under)
In article <····························@posting.google.com>,
·······@dcsi.net.au (Bruce) wrote:
> Check out what motor bike riders are taught - here in Victoria
> Australia, I know that they were/are taught that braking is a double
> action process - the first phase is to compress the suspension and
> then put the brakes on as hard as you want - brakes don't lock up at
> the same level of pressure as the weight of the vehicle and people are
> now acting together with the brakes to slow down as when you don't
> compress the suspension.
Exactly the same principle applies to cornering too. Turn in a little,
wait until the weight transfers to the outside wheels, then turn in the
rest of the way. Virtually eliminates understeer on many cars, and lets
you corner *very* hard at speed.
-- Bruce
In article <····························@posting.google.com>,
Bruce <·······@dcsi.net.au> wrote:
>Matthias Blume <····@my.address.elsewhere> wrote in message news:<··············@hanabi-air.shimizu.blume>...
>> Raffael Cavallaro <················@junk.mail.me.not.mac.com> writes:
>>
>> > In article <··············@uranus.local>,
>> > Peter Herth <·····@netcologne.de> wrote:
>> >
>> > > Its not bad driving.
>> >
>> > It's bad driving because not all cars have ABS brakes. In an emergency,
>> > one doesn't really have time to think, "does this car have ABS brakes?"
>> > One simply reacts according to training/habit, and either applies
>[[ Stuff removed]]
>
>Check out what motor bike riders are taught - here in Victoria
>Australia, I know that they were/are taught that braking is a double
>action process - the first phase is to compress the suspension and
>then put the brakes on as hard as you want - brakes don't lock up at
>the same level of pressure as the weight of the vehicle and people are
>now acting together with the brakes to slow down as when you don't
>compress the suspension.
>
And how does one "compress the suspension"?
(Not only on motorcycles ("motor bikes"? Same thing?) -- but
how on autos, too?)
Thanks!
David
In article <············@reader2.panix.com>, David Combs wrote:
> And how does one "compress the suspension"?
Well, this is seriously off topic, but anyway.
You do it by first applying the brakes enough to, well, compress the
suspension. I.e. by moving the weight of the car/motorcycle to the
front. You *then* apply the brakes fully.
I was actually taught the same thing in our mandatory winter driving
school; in order to illustrate the difference between efficient
braking and locked brakes, you first have to learn how to lock the
brakes. And the only way to do that is to lift your foot of the pedal
and stomp hard on it (try it yourself). If you merely press down hard
on it with your foot you can lock the front wheels alright, but not
the rear wheels. Your only chance of locking them is *before* all the
weight has shifted onto the front. (The shift is not instantaneous
because of the suspension springs).
These days I drive ABS so it's a moot point anyway. Really makes a
difference in winter.
Stefan,
--
Stefan Axelsson (email at http://www.cs.chalmers.se/~sax)
Stefan Axelsson <···@csmisc72.cs.chalmers.se> writes:
...
> I was actually taught the same thing in our mandatory winter driving
> school; in order to illustrate the difference between efficient
> braking and locked brakes, you first have to learn how to lock the
> brakes. And the only way to do that is to lift your foot of the pedal
> and stomp hard on it (try it yourself). If you merely press down hard
> on it with your foot you can lock the front wheels alright, but not
> the rear wheels. Your only chance of locking them is *before* all the
> weight has shifted onto the front. (The shift is not instantaneous
> because of the suspension springs).
...
This is nonsense. If you press hard enough on your brake pedal, you
do not have ABS, and your brakes are in working order, you will almost
certainly lock the rear wheels. You'll probably lock the front ones
too. Anybody with a halfway decent sense of reality can see that
weight transfers onto the *front* wheels in braking, rendering the
back wheels easier to lock. The front wheels are equipped with bigger
brakes for this reason. But I guess those people don't teach
mandatory winter driving school.
Nonsense like this can actually get people hurt. If you lock up your
wheels, you cannot steer and do not stop efficiently. Think about
what you're saying. "And the only way to do that is to lift your
foot..." and take it out of your mouth.
-Tim, who learned how to drive in a sports car, on a road, and not
from some yutz in a "school".
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
In article <··············@hummer.intern>, Tim Daly Jr. wrote:
> This is nonsense. If you press hard enough on your brake pedal, you
> do not have ABS, and your brakes are in working order, you will almost
> certainly lock the rear wheels. You'll probably lock the front ones
> too. Anybody with a halfway decent sense of reality can see that
> weight transfers onto the *front* wheels in braking, rendering the
> back wheels easier to lock. The front wheels are equipped with bigger
> brakes for this reason. But I guess those people don't teach
> mandatory winter driving school.
Yes, that's all true. And because of this an ordinary car will not
allow 50/50 brake pressure to the front and read wheels. There's a
valve set to limit the braking power on the rear wheels. Otherwise
they'd always lock up. Now this valve is set quite conservatively in a
normal car since you do not want rear wheel lockup even when braking
hard, since that wouldn't make for great handling. At least in the
Volvo or SAAB, the only car manufacturers I've worked for/with and
hence have intimate knowledge of. Just pressing will rarely lock the
rear brakes. You need a good stomp. Which you cannot perform if you've
already started braking.
So it's more a question of 'when the weight has transferred to the
front wheels you're too late trying to lock the rear brakes'. In order
to fool the brake hydraulics you have to be quick. I didn't want to
write an essay on the subject though.
It's actually a problem in winter climates. The rear brakes aren't
ever used in normal circumstances, and tend to seize up as a result.
> Nonsense like this can actually get people hurt. If you lock up your
> wheels, you cannot steer and do not stop efficiently. Think about
> what you're saying. "And the only way to do that is to lift your
> foot..." and take it out of your mouth.
Nowhere did I actually *advocate* locking the wheels to brake
efficiently (you'll actually stop shorter on a gravel road doing so,
but that's about the only situation where that's true, and with
little/no control). Instead I went to great pains to explain that we
had to learn how to lock the brakes so that *we could compare* the
effect of doing so over the *proper* efficient braking techniques we
were taught.
Then again, as we're into ad hominems; if reading my previous post rid
the gene pool of people with your general reading comprehension, I'm
not too worried... In fact I'd prefer not to have to share the roads
with you.
> -Tim, who learned how to drive in a sports car, on a road, and not
> from some yutz in a "school".
Well, then if you actually have driven a sports/rally car maybe you
noticed the little valve/control that sets braking power
front/rear. Ever wonder what it was for?
Stefan, who learned to drive from a SAAB test driver,
--
Stefan Axelsson (email at http://www.cs.chalmers.se/~sax)
Stefan Axelsson <···@csmisc72.cs.chalmers.se> wrote in message news:<··················@csmisc72.cs.chalmers.se>...
> In article <··············@hummer.intern>, Tim Daly Jr. wrote:
> > This is nonsense. If you press hard enough on your brake pedal, you
> > do not have ABS, and your brakes are in working order, you will almost
> > certainly lock the rear wheels. You'll probably lock the front ones
> > too. Anybody with a halfway decent sense of reality can see that
> > weight transfers onto the *front* wheels in braking, rendering the
> > back wheels easier to lock. The front wheels are equipped with bigger
> > brakes for this reason. But I guess those people don't teach
> > mandatory winter driving school.
>
> Yes, that's all true. And because of this an ordinary car will not
> allow 50/50 brake pressure to the front and read wheels. There's a
> valve set to limit the braking power on the rear wheels. Otherwise
> they'd always lock up. Now this valve is set quite conservatively in a
> normal car since you do not want rear wheel lockup even when braking
> hard, since that wouldn't make for great handling. At least in the
> Volvo or SAAB, the only car manufacturers I've worked for/with and
> hence have intimate knowledge of. Just pressing will rarely lock the
> rear brakes. You need a good stomp. Which you cannot perform if you've
> already started braking.
>
> So it's more a question of 'when the weight has transferred to the
> front wheels you're too late trying to lock the rear brakes'. In order
> to fool the brake hydraulics you have to be quick. I didn't want to
> write an essay on the subject though.
>
> It's actually a problem in winter climates. The rear brakes aren't
> ever used in normal circumstances, and tend to seize up as a result.
>
> > Nonsense like this can actually get people hurt. If you lock up your
> > wheels, you cannot steer and do not stop efficiently. Think about
> > what you're saying. "And the only way to do that is to lift your
> > foot..." and take it out of your mouth.
>
> Nowhere did I actually *advocate* locking the wheels to brake
> efficiently (you'll actually stop shorter on a gravel road doing so,
> but that's about the only situation where that's true, and with
> little/no control). Instead I went to great pains to explain that we
> had to learn how to lock the brakes so that *we could compare* the
> effect of doing so over the *proper* efficient braking techniques we
> were taught.
>
> Then again, as we're into ad hominems; if reading my previous post rid
> the gene pool of people with your general reading comprehension, I'm
> not too worried... In fact I'd prefer not to have to share the roads
> with you.
>
> > -Tim, who learned how to drive in a sports car, on a road, and not
> > from some yutz in a "school".
>
> Well, then if you actually have driven a sports/rally car maybe you
> noticed the little valve/control that sets braking power
> front/rear. Ever wonder what it was for?
>
> Stefan, who learned to drive from a SAAB test driver,
OK
Matthias Blume <····@my.address.elsewhere> wrote:
> I have seen studies where ordinary drivers were given a fairly
> extensive "advanced driving class" -- which tried to teach precisely
> the techniques that avoid the kinds of wrong reactions which most
> people exhibit naturally in emergency situations. At the end of the
> course (during which most of the students finally seemed to catch on
> and were able to do master most of the training situations) they sent
> them through a different course with surprise obstacles in places that
> they had never seen before. And almost all of them were back to square
> one again... (i.e., they overreacted, stomped on the brakes, sent
> their cars into catastrophic oversteer, etc.) Bottom line: This stuff
> is *really hard*, and every help we mere mortals can get should be
> welcome.
abosultely. to get even more off topic, i would note that motorcyles
steer exactly the opposite of the way you think they steer. i.e., you turn
the bars to the right to go left. this is so counterintuitive that even after
years of actively working on training myself to countersteer correctly,
i still would sometimes find myself, in a tense moment, doing exactly
the wrong thing, and veering in the exact direction i did *not* want to go.
not recommended.
----
Garry Hodgson, Technology Consultant, AT&T Labs
Be happy for this moment.
This moment is your life.
Garry Hodgson wrote:
> Matthias Blume <····@my.address.elsewhere> wrote:
>
>
>>[...] Bottom line: This stuff
>>is *really hard*, and every help we mere mortals can get should be
>>welcome.
>
>
> abosultely. to get even more off topic, i would note that motorcyles
> steer exactly the opposite of the way you think they steer. i.e., you turn
> the bars to the right to go left. this is so counterintuitive that even after
> years of actively working on training myself to countersteer correctly,
> i still would sometimes find myself, in a tense moment, doing exactly
> the wrong thing, and veering in the exact direction i did *not* want to go.
> not recommended.
There's a better way to think about countersteering. The front wheel on
a motorcycle will at speed always tend to orient itself in such a way as
to bring the motorcycle upright. So when you're countersteering, you're
not so much turning the handlebars in the wrong direction as simply
pulling on them in the 'wrong' direction with just enough force to get
the motorcycle into a lean and keep it there. When you start your turn
this actually does mean turning the handlebars in the wrong direction to
put the bike into a lean, but once the bike is leaned into the turn
you're merely applying enough force to counteract the front wheel's
automatic tendency to steer into the turn and bring the bike upright.
Thinking about it this way helped me a lot, because the "steer in the
wrong direction" thing is obviously wrong if you take it too literally.
-thant
--
"In no part of the Constitution is more wisdom to be found than in the
clause which confides the question of war or peace to the legislature,
and not the executive department. ... The trust and the temptation would
be too great for any one man." -- James Madison, 1793
Thant Tessman <·····@acm.org> wrote:
> Garry Hodgson wrote:
> There's a better way to think about countersteering.
...
> Thinking about it this way helped me a lot, because the "steer in the
> wrong direction" thing is obviously wrong if you take it too literally.
yes. i never actually thought of it that way, but just used that
to describe the action. for me, thinking of "pushing the side i want
to go to down" was the most effective mental model. so to steer
right, i push the right bar (note to non-riders: the actual amount
of push/pull/turn on the bars is tiny), which causes it to lean the
correct way to turn right.
to the original point (it's very hard to break habits), i rode just
about daily for years, and thoroughly integrated this notion into
my conscious and unconscious actions when riding. but every
once in a while, when i needed it most (like coming too hot into
a turn), i'd revert to the wrong thing. i think the Hurt report may
even have called this out as a factor in many bike accidents,
but that was long ago, so i'm not sure.
as far as relevance to type theory, well, there is none.
but at least its better than this endless rehashing of the
same old static vs. dynamic arguments. it's been weeks,
folks, give it up. nobody's getting convinced, nor are they
likely to be.
----
Garry Hodgson, Technology Consultant, AT&T Labs
Be happy for this moment.
This moment is your life.
On Tue, 25 Nov 2003 20:25:54 GMT, Garry Hodgson <·····@sage.att.com> wrote:
>
> to the original point (it's very hard to break habits), i rode just
> about daily for years, and thoroughly integrated this notion into
> my conscious and unconscious actions when riding. but every
> once in a while, when i needed it most (like coming too hot into
> a turn), i'd revert to the wrong thing. i think the Hurt report may
> even have called this out as a factor in many bike accidents,
> but that was long ago, so i'm not sure.
Back on to our off-topic topic, the problem I always had on bikes, and
this is the same as that people have in cars, was not to slam on the
brakes in an emergency. In a car this may or may not be that big a
deal. On a bike it results in skin loss and a damaged ego when the
front wheel locks and promptly throws the rider to the pavement.
I've only actually wrecked this way once, but it was enough to cause
me to look into ABS for a later bike. I didn't actually shell out the
cash for it, but I really wish I had.
I guess it doesn't matter now. I recently had a new baby, my second,
and decided I just couldn't afford enough life insurance to alleviate
my guilt over riding a motorcycle. I'm selling it in the spring.
> as far as relevance to type theory, well, there is none.
> but at least its better than this endless rehashing of the
> same old static vs. dynamic arguments. it's been weeks,
> folks, give it up. nobody's getting convinced, nor are they
> likely to be.
This debate is as interesting as the scheme vs. lisp debates.
--
Kenneth P. Turvey <··@squeakydolphin.com>
Artificial Intelligence Algorithms Wiki
http://ai.squeakydolphin.com
In article <·················@premium.geo.yahoo.akadns.net>, Kenneth P. Turvey wrote:
> Back on to our off-topic topic, the problem I always had on bikes, and
> this is the same as that people have in cars, was not to slam on the
> brakes in an emergency. In a car this may or may not be that big a
> deal. On a bike it results in skin loss and a damaged ego when the
> front wheel locks and promptly throws the rider to the pavement.
> I've only actually wrecked this way once, but it was enough to cause
> me to look into ABS for a later bike. I didn't actually shell out the
> cash for it, but I really wish I had.
Yes, that's how the brain works unfortunately. In times of extreme
stress we revert (regress) to an earlier ("more natural")
behaviour. And the added adrenaline tends to make us jumpy, lose our
fine motor control and apply more force.
It's doesn't matter if it's breaking a car, turning a motorcycle (the
bicycle pattern breaking through I guess), climbing (my own area), or
firing your assault rifle on full automatic (I have it on good
authority that the controlled three round bursts that are taught in
basic training tends to become half or full magazine bursts in the
heat of battle, hence the M16A2 doing away with full auto and
introducing a mechanical three round burst instead.).
In order to "stress proof" an engram/behaviour to the point that it
will actually work in an emergency you have to repeat it under varying
and realistic circumstances so many times that it's not funny. At
all. Think years of practice.
That's why ABS is going to be a win, always, even if the wrong
breaking habits will kill the odd driver when he's in the wrong
car. It's completely unrealistic to provide the sheer amount of
training at the advanced level that would be necessary to teach
ordinary drivers correct breaking techniques in emergencies. It's akin
to making every driver a race car driver. It won't happen. That's not
to say that those who are willing to invest the time shouldn't, more
the power to them. Myself I choose to spend my copious free time
trying to get up mountains without killing myself instead. And drive a
Volvo with ABS. :-)
Stefan,
--
Stefan Axelsson (email at http://www.cs.chalmers.se/~sax)
Matthias Blume <····@my.address.elsewhere> wrote in message news:<··············@hanabi-air.shimizu.blume>...
> The problem with all this is that stomping on the brakes in an
> emergency situation is what comes naturally to most people. It takes
> long and intensive training to avoid doing it. Most people do not
> have that kind of training -- which is why ABS is almost always going
> to be a win.
If, and only if, the vehicle one is driving has ABS brakes. In all
other cases, stomping on the brakes, no matter how naturally it comes,
will result in the bad things described. ABS brakes cannot help you if
the car you are driving doesn't have them. Many cars, maybe even the
majority of cars, still do not have ABS brakes. So one's driving
habits should be based on safe, automatic reactions in common
circumstances (no ABS), and that means, not stomping on the brake
pedal.
These good habits can be aided by learning how to place one's foot
properly. The average driver doesn't use the brake pedal properly even
in non-emergency conditions. That is, he doesn't keep his heel on the
floor of the car, but rather, lifts his foot from the floor, or from
the accelerator pedal into the air before braking. This encourages
overbraking, because the driver has far less control when his leg is
in mid air than when his heel is fixed on the ground between the
accelerator and brake pedals. It is much more difficult to overbrake
when one's heel is in a fixed position on the floor of the car.
I wrote:
> > The problem with all this is that stomping on the brakes in an
> > emergency situation is what comes naturally to most people. It takes
> > long and intensive training to avoid doing it. Most people do not
> > have that kind of training -- which is why ABS is almost always going
> > to be a win.
·······@mediaone.net (Raffael Cavallaro) answered:
> If, and only if, the vehicle one is driving has ABS brakes. In all
> other cases, stomping on the brakes, no matter how naturally it comes,
> will result in the bad things described. ABS brakes cannot help you if
> the car you are driving doesn't have them. Many cars, maybe even the
> majority of cars, still do not have ABS brakes. So one's driving
> habits should be based on safe, automatic reactions in common
> circumstances (no ABS), and that means, not stomping on the brake
> pedal.
What I was saying is that PEOPLE CANNOT DO IT, on average. That's why
ABS is good, and that's why it will soon be the common case (if it is
not already).
> It is much more difficult to overbrake when one's heel is in a fixed
> position on the floor of the car.
But it is even more difficult to NOT overbrake if at the same time a
review of one's life passes in front of one's eyes. :-)
Erann Gat <···@jpl.nasa.gov> wrote:
> No, I am saying that I don't believe in static typing because I have met
> very smart people who ended up doing very stupid things as a result (I
> believe) of using static typing systems.
This does not match my experience at all. And, as you say,
the important point is:
> The story was not meant to be a warning against using static typing,
> merely against relying on it.
If there are indeed any people who are so stupid to think that because
they have static typing, their programs will be automatically
completely bug free, then it should be easy to explain to them
that no possible static type system in the world can achieve this.
> 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.
I still cannot believe this.
> The only objective evidence I can offer is how long it took
> to find the bug after it manifested itself.
That's somewhat typical for race conditions. If you don't invest
effort up front to combat them, they are really hard to catch.
> You'd have to believe that the entire team was stupid.
I'd probably believe that somebody in the team was sloppy. Race condition
bugs do happen, even to smart people.
> You can also calibrate my assessment by asking anyone who knows me if I am
> the least bit shy about levying a charge of stupidity if I think it is
> warranted.
I certainly think that any claim that your usual Java, C++, Haskell or
OCaml type system guards against race conditions is so completely stupid
that I cannot even imagine someone could make it.
And concluding that "one does not believe in static typing" based on
that evidence isn't really smart IMHO, either. (Sorry, but I am also
not shy in this respect).
- Dirk
In article <····················@192.168.1.51>,
Erann Gat <···@jpl.nasa.gov> wrote:
>No, I am saying that I don't believe in static typing because I have met
>very smart people who ended up doing very stupid things as a result (I
>believe) of using static typing systems.
What you're basically indicting is not static typing, but most forms of
automation. Any time we hand off some responsibility to the computer, we
end up relying on it, and sometimes we may expect the computers to do more
than they really can. Someone else pointed out that your complaint about
static typing is very similar to the complaints people have made about
automatic memory management. In fact, it goes much lower than that; it
took a long time before most of the CS community accepted that high level
languages were appropriate for OS programming (for many years Multics and
Unix were the only examples outside research groups).
I just can't fathom an experienced programmer thinking that if a program
compiles cleanly then it must be OK. In particular, if he's used to
programming in statically-typed languages, he doesn't generally encounter
type errors, but he must have experienced many bugs in his career. Since
they weren't type errors (because the language prevents those), he should
be used to dealing with non-type errors, and be on the lookout for them.
So what possible experience could have led him to do this stupid thing?
Perhaps "incompetent" wasn't the right word. In my career I've met some
excellent programmers who are sloppy. They know the system well, and they
produce lots of product, but bugs are frequently found during code reviews
and testing. We bitch about them and maybe make jokes behind their backs,
but we keep them on board because even with the bugs the net result is
better than if we didn't have them in the first place.
--
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.
In article <·············@news.level3.com>, Barry Margolin
<··············@level3.com> wrote:
> In article <····················@192.168.1.51>,
> Erann Gat <···@jpl.nasa.gov> wrote:
> >No, I am saying that I don't believe in static typing because I have met
> >very smart people who ended up doing very stupid things as a result (I
> >believe) of using static typing systems.
>
> What you're basically indicting is not static typing, but most forms of
> automation.
No, what I am indicting is what I perceive to be the undue emphasis placed
on static typing in some quarters, not static typing itself.
E.
In article <····················@k-137-79-50-101.jpl.nasa.gov>,
Erann Gat <···@jpl.nasa.gov> wrote:
>In article <·············@news.level3.com>, Barry Margolin
><··············@level3.com> wrote:
>
>> In article <····················@192.168.1.51>,
>> Erann Gat <···@jpl.nasa.gov> wrote:
>> >No, I am saying that I don't believe in static typing because I have met
>> >very smart people who ended up doing very stupid things as a result (I
>> >believe) of using static typing systems.
>>
>> What you're basically indicting is not static typing, but most forms of
>> automation.
>
>No, what I am indicting is what I perceive to be the undue emphasis placed
>on static typing in some quarters, not static typing itself.
So it's not that you don't believe in static typing at all, just that you
don't think it's more important than X, for various values of X (such as
automatic memory management). And the languages you prefer happen to have
X.
What I dislike about the way you started this whole thing is that you
picked one incident. I'm sure that manager could provide similar examples
where static typing solved problems. Individual cases don't prove anything
in debates like this, you need to point to a whole body of evidence.
--
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.
In article <·············@news.level3.com>, Barry Margolin
<··············@level3.com> wrote:
> What I dislike about the way you started this whole thing is that you
> picked one incident.
That's one data point more than most people have contributed in this discussion.
> I'm sure that manager could provide similar examples
> where static typing solved problems.
No, I'm not at all sure that this is true. The only way that he could
have done so it to cite an example where a run-time type error caused a
(near) catastrophic failure. He didn't do so at the time. In fact, the
same company ran a lot of Python code and during my tenure I was not aware
of a single example of a run-time type error causing a problem.
> Individual cases don't prove anything
> in debates like this, you need to point to a whole body of evidence.
I believe I just did.
E.
In article <·············@news.level3.com>,
Barry Margolin <··············@level3.com> wrote:
>What I dislike about the way you started this whole thing is that you
>picked one incident. I'm sure that manager could provide similar examples
>where static typing solved problems. Individual cases don't prove anything
>in debates like this, you need to point to a whole body of evidence.
I just realized something: your (perhaps subconscious) purpose wasn't
really to spark a proper debate.
You disagreed with the manager over the way to go, but ended up with a
problem that you think might have been avoided had he taken your advice.
Your post was actually just a public "I told you so" gloat.
--
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.
In article <··············@news.level3.com>, Barry Margolin
<··············@level3.com> wrote:
> In article <·············@news.level3.com>,
> Barry Margolin <··············@level3.com> wrote:
> >What I dislike about the way you started this whole thing is that you
> >picked one incident. I'm sure that manager could provide similar examples
> >where static typing solved problems. Individual cases don't prove anything
> >in debates like this, you need to point to a whole body of evidence.
>
> I just realized something: your (perhaps subconscious) purpose wasn't
> really to spark a proper debate.
>
> You disagreed with the manager over the way to go, but ended up with a
> problem that you think might have been avoided had he taken your advice.
> Your post was actually just a public "I told you so" gloat.
Actually, it was just what I said it was in the first paragraph of the
original post: a data point.
It was also an experiment of sorts: if static typing does indeed have the
value that people claim I would have expected the advocates of static
typing to have countered with at least one anecdote where a catastrophic
failure caused by a run-time type error. That no one has is not
conclusive (conclusive data is very hard to come by in matters like
these), but I think it is telling.
E.
Erann Gat wrote:
> It was also an experiment of sorts: if static typing does indeed have the
> value that people claim I would have expected the advocates of static
> typing to have countered with at least one anecdote where a catastrophic
> failure caused by a run-time type error. That no one has is not
> conclusive (conclusive data is very hard to come by in matters like
> these), but I think it is telling.
But then again, maybe it isn't. Your anecdote was entertaining but
irrelevant and if the fact nobody from the static camp has responded
with their own irrelevant anecdote is telling at all, it's not for
the reason you imply.
Regards
--
Adrian Hey
On Wed, 19 Nov 2003, Adrian Hey wrote:
>Erann Gat wrote:
>> It was also an experiment of sorts: if static typing does indeed have the
>> value that people claim I would have expected the advocates of static
>> typing to have countered with at least one anecdote where a catastrophic
>> failure caused by a run-time type error. That no one has is not
>> conclusive (conclusive data is very hard to come by in matters like
>> these), but I think it is telling.
>
>But then again, maybe it isn't. Your anecdote was entertaining but
>irrelevant and if the fact nobody from the static camp has responded
>with their own irrelevant anecdote is telling at all, it's not for
>the reason you imply.
On top of that, the static typing community almost certainly does not have
experience with large-scale LISP or Smalltalk programs (which is a niche
in the overall world of software development anyways). How would it be
possible to come up with an 'anecdote' where dynamic typing failed? Of
course, I am sure lots of people have seen the failure of C/C++/Java/Cobol
programs, but for abstraction reasons. Of course, static/dynamic typing
has absolutely nothing to do with the failure of these languages. To
date, there have been hardly any industrial-scale projects with high-level
statically typed languages. The only two companies I am aware of who
employ such languages are Galois Connections (http://www.galconn.com) and
PolySpace (http://www.polyspace.com). The former use Haskell and work
(a.o.) for the NSA. I don't think you will get many details. I also don't
think it would be easy to judge why a dynamically typed language useable
or not for their products. The latter company develops powerful
code-analyses (they use theorem-proving methods) for C and ADA, and guess
what, the analyses are almost entirely written in Standard ML. Same issue
of course: would it be possible to judge if a dynamically typed language
is less suitable or not?
regards,
Simon
Simon Helsen <·······@computer.org> writes:
>To date, there have been hardly any industrial-scale projects with high-level
>statically typed languages. The only two companies I am aware of who
>employ such languages are Galois Connections (http://www.galconn.com) and
>PolySpace (http://www.polyspace.com).
There's also Mission Critical <http://www.missioncriticalit.com/>,
who use Mercury.
--
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.
From: Lauri Alanko
Subject: Re: Why I don't believe in static typing
Date:
Message-ID: <bpfthh$296$1@la.iki.fi>
···@jpl.nasa.gov (Erann Gat) virkkoi:
> It was also an experiment of sorts: if static typing does indeed have the
> value that people claim I would have expected the advocates of static
> typing to have countered with at least one anecdote where a catastrophic
> failure caused by a run-time type error.
The Mars Climate Orbiter. Mixing between units is just the kind of silly
error that a good type system can eliminate reliably: just write a
simple module:
module Force(Force, newton, lbf, ....) where
newtype Force = MkForce { forceNewtons :: Double }
newton n = MkForce { forceNewtons = n }
lbf n = MkForce { forceNewtons = n * 4.4482216 }
....
After this you cannot create force values without explicitly
mentioning the unit. Attempt to use a plain Double, and you'll get a
type error. And for good reason.
Lauri Alanko
··@iki.fi
In article <············@la.iki.fi>, Lauri Alanko <··@iki.fi> wrote:
> ···@jpl.nasa.gov (Erann Gat) virkkoi:
> > It was also an experiment of sorts: if static typing does indeed have the
> > value that people claim I would have expected the advocates of static
> > typing to have countered with at least one anecdote where a catastrophic
> > failure caused by a run-time type error.
>
> The Mars Climate Orbiter. Mixing between units is just the kind of silly
> error that a good type system can eliminate reliably: just write a
> simple module:
>
> module Force(Force, newton, lbf, ....) where
> newtype Force = MkForce { forceNewtons :: Double }
> newton n = MkForce { forceNewtons = n }
> lbf n = MkForce { forceNewtons = n * 4.4482216 }
> ....
>
> After this you cannot create force values without explicitly
> mentioning the unit. Attempt to use a plain Double, and you'll get a
> type error. And for good reason.
A good example, but not really on point IMO. The problem there was that
units weren't modelled in the code at all. That was a (common) design
decision. Static typing won't help if you don't tell the system that this
floating point number is in newtons and that one is in pounds.
In fact, I often cite MCO as an example for my basic claim, which is that
languages mold people's thinking in often undesirable ways. People write
"1.2" and "3.4" when what they really mean is "1.2 newtons" and "3.4
pounds" because the languages that they use understand "1.2" and "3.4" and
they don't understand "1.2 newtons" and "3.4 pounds". If MCO code had
been written in a language that directly supported physical quantities (as
opposed to simply floating point numbers) or one where such a facility
could have been added things might have gone differently.
There are many, many examples of this sort of thing. People think that
"ints" are integers, "floats" and "doubles" are reals, or that char*'s are
strings when none of these things are really true. They do this because
the languages understand "int" and "float" and "double" and "char*" but
don't know about integers and reals and strings. I suspect most of the
people reading this know this, but a lot of programmers don't, or at least
don't think about it when they code.
E.
On Wed, 19 Nov 2003 14:08:49 +0000 (UTC), Lauri Alanko <··@iki.fi>
wrote:
>The Mars Climate Orbiter. Mixing between units is just the kind of silly
>error that a good type system can eliminate reliably: just write a
>simple module:
Much better and simpler yet: ban use of nonstandard units, then there
won't be anything to mix.
--
"Sore wa himitsu desu."
To reply by email, remove
the small snack from address.
http://www.esatclear.ie/~rwallace
Russell Wallace wrote:
> Lauri Alanko <··@iki.fi> wrote:
>
>>The Mars Climate Orbiter. Mixing between units is just the kind of silly
>>error that a good type system can eliminate reliably: just write a
>>simple module:
>
> Much better and simpler yet: ban use of nonstandard units, then there
> won't be anything to mix.
That's exactly Erann's point: you /still/ have a possibility to mix up
units - e.g. velocities and positions. Or just positions, of different
coordinate systems.
Just assuming that the problem will go away by a single, simple measure
will reduce the problem, but it will not abolish it.
There's another, more subtle point: Even if you (Russell) did understand
that issue completely, there's a good chance that somebody else
misunderstood it and takes your words as a confirmation of his thinking.
Usually it will be a person who isn't as intimately knowledgeable of the
issues, that is: managers.
Which explains a lot of misconceptions in the managers' heads. Most
managers aren't stupid, they just are not in day-to-day contact with the
nitty-gritty details (and they cannot be).
This is why I try to avoid blanked statements like "here's a simple and
effective solution", I always add a phrase that clearly says which kind
of problems is solved and (if necessary) what kind of problems isn't.
Regards,
Jo
On Thu, 20 Nov 2003 15:28:19 +0100, Joachim Durchholz
<·················@web.de> wrote:
>Russell Wallace wrote:
>
>> Much better and simpler yet: ban use of nonstandard units, then there
>> won't be anything to mix.
>
>That's exactly Erann's point: you /still/ have a possibility to mix up
>units - e.g. velocities and positions. Or just positions, of different
>coordinate systems.
>Just assuming that the problem will go away by a single, simple measure
>will reduce the problem, but it will not abolish it.
Well, it will eliminate the problem of mixed units of the same
dimensionality (which strikes me as the more likely problem, and was
the one that caused the loss of the spacecraft mentioned by the
previous poster).
I agree it wouldn't stop someone mixing dimensions; if one wishes to
use static typing for that, by all means go for it, but I think that
should be done as well as, not instead of, banning nonstandard units.
Put another way: I'd be concerned about people coming to rely on a
technical fix for a social problem.
--
"Sore wa himitsu desu."
To reply by email, remove
the small snack from address.
http://www.esatclear.ie/~rwallace
Erann Gat wrote:
> It was also an experiment of sorts: if static typing does indeed have the
> value that people claim I would have expected the advocates of static
> typing to have countered with at least one anecdote where a catastrophic
> failure caused by a run-time type error. That no one has is not
> conclusive (conclusive data is very hard to come by in matters like
> these), but I think it is telling.
Yes, but interpreting the results of an experiment is always subjective.
Personally, I was more interested in understanding what you really meant
than in putting up counter-evidence.
Besides, it's generally hard to list up problems that were avoided.
Also, besides, some people have repeated ad nauseam that static typing
(/good/ static typing � la Haskell or ML) had caught bugs in their
logic. They just happened not to repeat that report in this thread
(probably because they felt that it's off-topic here, maybe for other
reasons).
Good experimentation skills require not only good interpretive skills,
selecting relevant data is also important :-)
Regards,
Jo
From: Tim Bradshaw
Subject: Re: Why I don't believe in static typing
Date:
Message-ID: <ey3brr9n9nw.fsf@cley.com>
* Dirk Thierbach wrote:
> So you say you don't believe in static typing because you have met
> people who are stupid? Come on, you cannot be serious. That would
> be like saying that I don't believe that dynamic typing can work
> because I have seen people who treat it as a religion.
Yes indeed. Although you have the details and answer wrong you've
worked out the correct reasoning. The people are why you don't want
to have anything to do with static typing. It's not that they're
stupid (though don't get me wrong, I wouldn't want to imply that
they're *not* stupid), it's the religion. The fiery eyes and total
lack of self-doubt give it away: this isn't science, it's a cult. You
just know that if you get involved, you're going to end up shaving
your head, living on a diet of raw beetroot and rotten fish, bathing
in the leader's urine, and selling everything you own and giving the
proceeds to the cult. If you're lucky you'll then spend the rest of
your life handing out leaflets pushing some obscure programming
language on street corners and newsgroups. If you're not then you'll
end up strangled and burnt in a pit somewhere, a martyr to, well,
what?
And of *course* the cultists fulminate against the dynamic typing
people for their `religion', the same way the Wee Frees fulminate
against the Church of England for their religion. Fulminating is
pretty much their only remaining source of pleasure in life, after
all. Trust me, you'd fulminate too if you were living in a cave
wearing clothes made from bin-liners and nails and, worse, having to
put up with the other members of the cult. Of course, they don't
fulminate nearly so much against the rest of us as they do against
each other. It's a good thing their diet weakens them to the point
where they can't hurt each other, or not much anyway.
Lisp people are bad enough on the cult front, but they're really only
Catholics. Sure, they burn incense all the time and have some weird
beliefs and hang ups about sex, and they definitely think they're
morally above everyone else. You wouldn't want to deal with them more
than you can avoid, of course, but they gave up burning people a
little while ago now, and they won't, generally, try to convert you.
But steer well clear of the static typers: they're just dangerous.
--tim
Erann Gat wrote:
>
> Or by putting in run-time sanity checks. If I had had the foresight and
> the strength of my own convictions I would have put code into the biller
> that stopped the billing process immediately as soon as a request was made
> to bill a ridiculously high amount, for some value of "ridiculously
> high". That would have solved the problem too.
At the point where you'd like to put in the sanity checks, you usually
don't have the information that allows you to decide what's
"ridiculously high" and what isn't. For some site, an amount in excess
of 10.000$ would have been ridiculous, others might really have to pay
millions.
Actually, some of the bogus payments were actually caught, so this was
already being done. Maybe these checks could have been improved - but I
think they would also have obscured the original problem: instead of a
race condition, you'd have seen bills sometimes being sent and sometimes
not. The problem would have had roughly the same amount, it would just
have been extended over a longer time (if the billing system had worked
correctly, managers wouldn't have sent an entire team of expensive
people working on the problem, so it would have persisted far, far
longer, with the effect that the trust in the billing system would have
slowly eroded over months until somebody had finally decided to send a
fire squad in - the financial loss for the company would have reached
the same order of magnitude, in the form of disgruntled customers going
elsewhere, and more difficult to assess).
Regards,
Jo
In article <············@news.oberberg.net>, Joachim Durchholz
<·················@web.de> wrote:
> Erann Gat wrote:
> >
> > Or by putting in run-time sanity checks. If I had had the foresight and
> > the strength of my own convictions I would have put code into the biller
> > that stopped the billing process immediately as soon as a request was made
> > to bill a ridiculously high amount, for some value of "ridiculously
> > high". That would have solved the problem too.
>
> At the point where you'd like to put in the sanity checks, you usually
> don't have the information that allows you to decide what's
> "ridiculously high" and what isn't. For some site, an amount in excess
> of 10.000$ would have been ridiculous, others might really have to pay
> millions.
> Actually, some of the bogus payments were actually caught
Right, and as soon as the first one was caught the system should have
stopped and waited for human intervention instead of proceeding.
This would not have eliminated the problem, of course, but it would have
mitigated the damage and made recovery easier. IMO that is in general the
best you can hope for.
E.
Erann Gat wrote:
> Right, and as soon as the first one was caught the system should have
> stopped and waited for human intervention instead of proceeding.
>
> This would not have eliminated the problem, of course, but it would
> have mitigated the damage and made recovery easier. IMO that is in
> general the best you can hope for.
You simply can't stop a payment system, unless you wish to go out of
business. Continuing with errors is the only viable alternative.
Actually, I think even the customers would agree - with clenched teeth,
of course, but nevertheless.
Regards,
Jo
In article <············@news.oberberg.net>, Joachim Durchholz
<·················@web.de> wrote:
> Erann Gat wrote:
> > Right, and as soon as the first one was caught the system should have
> > stopped and waited for human intervention instead of proceeding.
> >
> > This would not have eliminated the problem, of course, but it would
> > have mitigated the damage and made recovery easier. IMO that is in
> > general the best you can hope for.
>
> You simply can't stop a payment system unless you wish to go out of
> business.
Do you bother to think at all before you post, or do you just blindly
contradict everything I say? Of course you can, and in fact we did, and
the company is still in business now many years later (and doing quite
well actually). Figuring out how we managed that is left as an excercise.
E.
On Wed, 19 Nov 2003 14:48:13 +0100, Joachim Durchholz
<·················@web.de> wrote:
>You simply can't stop a payment system, unless you wish to go out of
>business. Continuing with errors is the only viable alternative.
>Actually, I think even the customers would agree - with clenched teeth,
>of course, but nevertheless.
Depends on the business, but I had that decision to make once; a disk
with the month's direct debit instructions was due to go to the bank
by courier, when an operator noticed the printed statements (also due
to be sent out) didn't match the direct debit amounts; the question I
ended up being asked was, which (if either) was correct? The way
things were set up, if the direct debits didn't go out by close of
business, the company wouldn't get paid until next month.
I ended up giving my opinion that the direct debit values were correct
and the error was in the statements (and turned out to be right,
fortunately - particularly since that meant the problem wasn't with my
code! ^.^), but what surprised me at the time was when the manager
said he'd rather let the disk go out as long as I was sure the values
were at least mostly correct, on the basis that it'd be less of a
problem having to fix a few erroneous payments than having no cash
flow for a full month. So yes, sometimes the requirement is to
continue even when there may be errors.
--
"Sore wa himitsu desu."
To reply by email, remove
the small snack from address.
http://www.esatclear.ie/~rwallace
···@jpl.nasa.gov (Erann Gat) writes:
> Neither static nor dynamic typing would have helped in this situation.
> But I do believe that a dynamic typing *mindset* would have been more
> likely to produce a correct solution because it encourages you to think
> more about possible run-time errors.
Well, I quite liked your story, and in my experience the
sort of error you relate is absolutely typical.
What I also find interesting about this episode is, at
the meta level, that you got the responses I expected
right away:
* the programmers were incompetent (shoot the messenger)
* That's not a typing issue, it's a concurrency issue (head in the sand).
* refusal to learn from the experience (from your managers/team).
I would almost go so far as to say that KNOWING you're going
to get errors at runtime is BETTER, because it leads to safer/more
robust designs. Your programmer _knows_ he might have missed a
call path, and will think about where/how to handle those missed
errors, even if it's just to log the bug and continue in some sane
state.
An interesting war story. Thanks.
Alain Picard <·······················@optushome.com.au> wrote:
> What I also find interesting about this episode is, at
> the meta level, that you got the responses I expected
> right away:
> * the programmers were incompetent (shoot the messenger)
> * That's not a typing issue, it's a concurrency issue (head in the sand).
> * refusal to learn from the experience (from your managers/team).
Excuse me, so you're saying that if A claims he had an accident
on his way to work because you saw a black cat passing from left
to right, and if B points out that the black cat has nothing to
do with it, then B is automatically wrong? Come on.
> I would almost go so far as to say that KNOWING you're going
> to get errors at runtime is BETTER, because it leads to safer/more
> robust designs.
Yes, it is. With a static type system, you not even know that you're
going to get errors at runtime, you have a good idea about *what*a
kinds of errors you're going to get, and what kinds of errors
never won't happen.
- Dirk
Alain Picard <·······················@optushome.com.au> writes:
> What I also find interesting about this episode is, at
> the meta level, that you got the responses I expected
> right away:
> * the programmers were incompetent (shoot the messenger)
> * That's not a typing issue, it's a concurrency issue (head in the sand).
Umm. It *is* a concurrency issue. "Head in the sand" would be to pretend it's
something else.
> I would almost go so far as to say that KNOWING you're going
> to get errors at runtime is BETTER, because it leads to safer/more
> robust designs.
You are right.
But you have to deal with runtime errors in every "real" program, static vs
dynamic typing notwithstanding.
The incompetency, if there was any, is the assumption that one doesn't have
runtime errors just because a statically typed language is used.
(And I am not convinced this incompetency was present in this example either.
I think instead that they ran into a difficult concurrency bug. Perhaps a
better design could have avoided it, perhaps a language with better
concurrency support would have helped, I don't know.)
One maybe has little or no *typing* errors, but that is not the same thing.
The mantra of static typing freaks is that one still gets bugs, but just the
interesting ones, not the stupid tedious ones that result from things not
"fitting" together.
> Your programmer _knows_ he might have missed a call path, and will think
> about where/how to handle those missed errors, even if it's just to log the
> bug and continue in some sane state.
Wise advice for any programmer in any language.
--
Cheers, The Rhythm is around me,
The Rhythm has control.
Ray Blaak The Rhythm is inside me,
········@STRIPCAPStelus.net The Rhythm has my soul.