A theoretical question: suppose I would like to create a Lisp
language, named CRA, that is Common Lisp, but statically typed with
type inference, pretty much like Haskell and ML-like languages. What
particular features of CL I'd have to leave out CRA? Would it hamper
the language as we know it?
Thanks. (This is not a homework excercise or anything close to that,
just a curiosity.)
In article <···························@posting.google.com>,
····@cyberspace.org (Hal Niner) wrote:
>A theoretical question: suppose I would like to create a Lisp
>language, named CRA, that is Common Lisp, but statically typed with
>type inference, pretty much like Haskell and ML-like languages. What
>particular features of CL I'd have to leave out CRA? Would it hamper
>the language as we know it?
Be sure to include a predicate so that programs can
test whether they are running in CL or CRA. Given
predicate naming conventions, it could be named
CLP or...
;-)
sv0f <····@vanderbilt.edu> writes:
> In article <···························@posting.google.com>,
> ····@cyberspace.org (Hal Niner) wrote:
>
> >A theoretical question: suppose I would like to create a Lisp
> >language, named CRA, that is Common Lisp, but statically typed with
> >type inference, pretty much like Haskell and ML-like languages. What
> >particular features of CL I'd have to leave out CRA? Would it hamper
> >the language as we know it?
>
> Be sure to include a predicate so that programs can
> test whether they are running in CL or CRA. Given
> predicate naming conventions, it could be named
> CLP or...
>
> ;-)
Actually, if you went to all this trouble, you should be able to use the
same data structures, and hence you should be able to co-reside with CL
functions. I don't know what CLP would take as an argument, or why.
There used to be a (typep x 'common) which was probably meant for similar
reasons but no one could figure out what it was for and it was gotten
rid of. It's an abstraction violation to ask of some user-defined or
system-defined type "how were you defined?" For a lot of system types,
the answer might be CL or it might be C or it might be Assembly. It isn't
supposed to matter as long as all the type/function protocols are satisfied.
····@cyberspace.org (Hal Niner) writes:
> A theoretical question: suppose I would like to create a Lisp
> language, named CRA, that is Common Lisp, but statically typed with
> type inference, pretty much like Haskell and ML-like languages. What
> particular features of CL I'd have to leave out CRA? Would it hamper
> the language as we know it?
>
> Thanks. (This is not a homework excercise or anything close to that,
> just a curiosity.)
Most of us stop this thought exercise when we get to the point of saying
"You'd be leaving out the ability to ignore declarations."
That, for me, is already fatal. If you told me my program would run
twice as fast if I only did that, I'd already say "it's not worth it".
I normally do not type-declare any of my programs and I don't find
that they run so slow that I mind.
You can't incentivize someone to do more work unless they think the
benefit is worth it.
To be honest, while I'd be interested to hear your results if you tried
this, just for academic reasons, the fact is that I haven't the slightest
interest in spending my personal time on a thought exercise like this
that does not address any of my personal goals.
Of all the things that stand between me and commercial success in Lisp,
speed is just not one of them. Neither is "finding bugs in my programs",
actually. Yes, it might find one once in a while, but most of the ones
I find myself wishing it would find, it could find already without type
declarations if the compiler writers would just put in the energy.
This is not to say that everyone is in my camp. It's just to help you
understand why people take the positions they do.
A long time ago (about 25 years), at the outset of my career, I wrote
a Fortran to Lisp translator. It took a substantial speed hit for
some of its emulation, but it worked semantically correctly. I met
Richard Fateman at a conference and he asked me about the speed hit.
I explained that my users didn't mind, and were just happy to have
answers. He said to me "Then you're talking to the wrong people." I
laughed in amazement then, and I still laugh today at that thought.
Speed is not just something that is always good--it comes at a price,
and the prices sometimes robs other important aspects. He was
probably right that most people with Fortran functions to run really
care about speed, but he was perhaps neglecting that some other people
just care about other aspects of things like "time to market", "ease
of use", "maintainability", etc. Then again, 25 years ago these other
quantities were nearly irrelevant in computer science. Back then,
everything was slow and anything that made things tolerably fast was a
Big Win. Nowadays, one can make serious money by increasing the time
to market of something that is, relatively speaking, slow, since in
many cases hardware changes and Moore's law will do more to correc the
speed problem for the next 15 years than will actual investment in
improving a speed problem involving "mere constant factors".
I suspect that requiring declarations all over the place would tend to
make macro writing way harder, too, btw, although it's hard to make such
beliefs concrete except through use.
In article <···············@shell01.TheWorld.com>,
Kent M Pitman <······@world.std.com> wrote:
> I suspect that requiring declarations all over the place would tend to
> make macro writing way harder, too, btw, although it's hard to make such
> beliefs concrete except through use.
Dylan's macro system has a built-in pattern that matches either a bare
variable name or else variable :: type. That seems to help a lot, at
least in the things I've used it for.
-- Bruce
Bruce Hoult <·····@hoult.org> writes:
> In article <···············@shell01.TheWorld.com>,
> Kent M Pitman <······@world.std.com> wrote:
>
> > I suspect that requiring declarations all over the place would tend to
> > make macro writing way harder, too, btw, although it's hard to make such
> > beliefs concrete except through use.
>
> Dylan's macro system has a built-in pattern that matches either a bare
> variable name or else variable :: type. That seems to help a lot, at
> least in the things I've used it for.
This is exactly what I personally would want to avoid.
Dylan's macro system is not something I want to use.
Macros in Lisp are not about 'variables', they are about 'symbols'.
Variables are a level above the abstraction level at which macros in
CL are operating. Having each macro have to be aware of a variable's
type either means using a higher-level abstraction to do the matching
(which means that I'm subtly guided away from syntaxes that do interesting
things with NON variable symbols) or else manually having to do a bunch
of function calls that presently I don't need to just to test types,
propagate types, etc., not to mention the problem of creating new bindings
for newly introduced variables of matching types, etc.
It all just sounds like a lot of extra work for a problem I don't
have at all now. I already don't spend any time saying "I wish Lisp would
run faster" nor "I wish Lisp would find more bugs at compile time"
so why would I want to do extra work to support each of these things.
Kent M Pitman <······@world.std.com> wrote in message news:<···············@shell01.TheWorld.com>...
> I suspect that requiring declarations all over the place would tend to
> make macro writing way harder, too, btw, although it's hard to make such
> beliefs concrete except through use.
Please note that in my original question I stated that this new
language would have type inference so that you wouldn't have to
declare all over the place. In fact, you wouldn't require any type
declaration at all.
Through private conversation with Paul Foley, though, he enlightened
me to my satisfaction: CMUCL has a sophisticated type inference system
that can catch at compile time type errors, which is probably good
enough.
····@cyberspace.org (Hal Niner) writes:
> Kent M Pitman <······@world.std.com> wrote in message news:<···············@shell01.TheWorld.com>...
>
> > I suspect that requiring declarations all over the place would tend to
> > make macro writing way harder, too, btw, although it's hard to make such
> > beliefs concrete except through use.
>
> Please note that in my original question I stated that this new
> language would have type inference so that you wouldn't have to
> declare all over the place. In fact, you wouldn't require any type
> declaration at all.
>
> Through private conversation with Paul Foley, though, he enlightened
> me to my satisfaction: CMUCL has a sophisticated type inference system
> that can catch at compile time type errors, which is probably good
> enough.
Precisely. There's nothing about the language that forbids optional
inferencing. The only way you can "improve" the language (and I use
so-called "scare quotes" advisedly) the langauge, if you think it's an
improvement, is to require declarations everywhere. Since that's not
what you're suggesting, the language already does what you want. It's
just an implementation issue.
And it's not an accident that CMU could do this. We designed the language
to permit that kind of ambition for compiler writers who wanted to put in
the extra mile. We just found that most don't. ;) Which is a pity in a
way. But I don't think requiring it would have meant more implementations
that do the right thing; rather, I think it would have meant fewer
implementations at all. It's just hard (read: expensive) to do.
····@cyberspace.org (Hal Niner) wrote in message news:<····························@posting.google.com>...
> Kent M Pitman <······@world.std.com> wrote in message news:<···············@shell01.TheWorld.com>...
>
> > I suspect that requiring declarations all over the place would tend to
> > make macro writing way harder, too, btw, although it's hard to make such
> > beliefs concrete except through use.
>
> Please note that in my original question I stated that this new
> language would have type inference so that you wouldn't have to
> declare all over the place. In fact, you wouldn't require any type
> declaration at all.
Sounds great! I could write exactly the same programs as I do now, yet
they would magically be statically typed!
What's wrong with this reasoning?
Hint: your language would have to reject some programs that are valid
dynamically typed programs, because being a static language, it has to
reject programs which it cannot prove to be free of type mismatch
errors.
The ``automatic declaration'' implicit in the type inference only
saves keystrokes, keystrokes which happen after you have already
racked your brain to fit the program to the constraints of the static
type system, so that when the keystrokes are done, it will not be
rejected by the compiler.
Just because the declarations are inferred doesn't mean they aren't
there! The programmer had to write the program such that the correct
inference will be made: namely that it is error free, and consequently
that a working executable program will result.
This is analogous to precedence. In infix notations, precedence is
implicit: it is inferred by a clever piece of software which knows how
to parse grammars. Great, you don't have to write parentheses! But in
order to write expressions that do what they want, programmers still
have to reason about the order of operations, and what parentheses
they can get away without. The design of the calculation has
parentheses; they just disappear when the program is keyed in..
> Through private conversation with Paul Foley, though, he enlightened
> me to my satisfaction: CMUCL has a sophisticated type inference system
> that can catch at compile time type errors, which is probably good
> enough.
Good enough with respect to what scale of values? According to one
viewpoint, this is better than good enough, because you get the static
type inference without the rejection of programs which cannot satisfy
it.
The difference is what you do with that class of programs for which
the static checks are inconclusive. A static language rejects such
programs, and this allows the compiler to get rid of type information
from objects, so that they can more closely correspond to the
representations demanded by the machine language architecture. Or so
that types can correspond to the layouts of external data formats.
These are the raisons d' etre for static typing: speed and compliance
to bitwise representations.
If it was just the safety, then you could keep dynamic typing. It's
good enough for the type inference machine to say ``I cannot conclude
that this program is type safe''. If, additionally, it does not let
you run that program, it's only because its run-time is not guaranteed
to handle such programs properly due to the lack of run-time type
information which is thrown away for the sake of speed.
In article <···························@posting.google.com>,
Hal Niner <····@cyberspace.org> wrote:
>A theoretical question: suppose I would like to create a Lisp
>language, named CRA, that is Common Lisp, but statically typed with
>type inference, pretty much like Haskell and ML-like languages. What
>particular features of CL I'd have to leave out CRA? Would it hamper
>the language as we know it?
I don't think you'd have to leave out anything. However, are many
functions that accept and/or return objects of any type, but that can be
handled by declaring them to accept/return type T (the union of all types).
--
Barry Margolin, ··············@level3.com
Genuity Managed Services, a Level(3) Company, 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.
On 14 May 2003 12:10:11 -0700, ····@cyberspace.org (Hal Niner) wrote:
>Thanks. (This is not a homework excercise or anything close to that,
>just a curiosity.)
God, I hope not. Any teacher that would assign this should be
executed.
--------------------------------------------------
Thaddeus L. Olczyk, PhD
Think twice, code once.
Well, if I'm not misunderstanding something like this has been done in
STELLA:
http://www.isi.edu/isd/LOOM/Stella/index.html
Cheers,
--
------------------------------------------
David E. Young
(format nil ···@~A.~A" 'youngde 'pobox 'com)
http://lisa.sourceforge.net
"For wisdom is more precious than rubies,
and nothing you desire can compare with her."
-- Proverbs 8:11
"But all the world understands my language."
-- Franz Joseph Haydn (1732-1809)
"Hal Niner" <····@cyberspace.org> wrote in message
································@posting.google.com...
> A theoretical question: suppose I would like to create a Lisp
> language, named CRA, that is Common Lisp, but statically typed with
> type inference, pretty much like Haskell and ML-like languages. What
> particular features of CL I'd have to leave out CRA? Would it hamper
> the language as we know it?
>
> Thanks. (This is not a homework excercise or anything close to that,
> just a curiosity.)
Hal Niner wrote:
> A theoretical question: suppose I would like to create a Lisp
> language, named CRA, that is Common Lisp, but statically typed with
> type inference, pretty much like Haskell and ML-like languages. What
> particular features of CL I'd have to leave out CRA? Would it hamper
> the language as we know it?
I use a statically typed version of Lisp called Nisp. (Downloadable
from http://www.cs.yale.edu/homes/dvm, my webpage.) Type declarations
are written using hyphens (i j - Integer). I am in the process of
completely rewriting it. For a preview of the result read the "Opt
Manual" (also available from my webpage), which describes a statically
typed KR language that looks a lot like Lisp (but has no recursive
functions).
I love static typing for the following reasons:
(a) It catches many bugs that are otherwise hard to track down. For
instance, you write 'car' where you meant 'caar', which eventually
generates an error far from the point where the error occurred. With
static typing, it's almost always the case that (car l) is of a
different type from (caar l), and the problem is caught as soon as the
context of (car l) is checked.
(b) It leads to conciseness. Yes, you have to write explicit
declarations, but in return you get a much cleaner and more compact
notation for slots. E.g., instead of
(defstruct Bound-variable name binding)
(defun fff (bv)
... (Bound-variable-name bv) ... (Bound-variable-binding bv) ...)
you can write
(def-type Bound-variable
(Structure name - Symbol binding - (Ref Obj)))
(defun fff (bv - Bound-variable) - (Lst Integer) ; type of result
;'fff' returns
... (!_name bv) ... (!_binding bv))
Slots are also indicated by a distinctive notation, clearly different
from function calls.
(c) It usually makes a program more readable. I really miss type
declarations when trying to read regular Lisp code.
(d) It possibly leads to greater efficiency because the types are so
easy to put in that you don't procrastinate doing it. However, in my
experience making a Lisp program truly efficient requires doing a lot
more than declaring variables, and, as Kent said, efficiency doesn't
seem like that big a deal most of the time.
-- Drew McDermott
In article <············@news.wss.yale.edu>, Drew McDermott
<··················@at.yale.dot.edu> wrote:
> I love static typing for the following reasons:
>
> (a) It catches many bugs that are otherwise hard to track down. For
> instance, you write 'car' where you meant 'caar', which eventually
> generates an error far from the point where the error occurred. With
> static typing, it's almost always the case that (car l) is of a
> different type from (caar l), and the problem is caught as soon as the
> context of (car l) is checked.
You don't need static typing to catch this kind of error. In fact, if you
are writing 'car' when you meant 'caar' that is usually an indication that
you really ought to be using a structure or a class with named slots
instead of cons cells. That makes it nearly impossible to make that kind
of error with a simple typo, and if you do make that kind of error you
catch it where the error happens, not downstream.
E.
From: Kenny Tilton
Subject: Re: Common Lisp as a statically typed language
Date:
Message-ID: <3EC84FE0.6020407@nyc.rr.com>
Drew McDermott wrote:
> Hal Niner wrote:
>
>> A theoretical question: suppose I would like to create a Lisp
>> language, named CRA, that is Common Lisp, but statically typed with
>> type inference, pretty much like Haskell and ML-like languages. What
>> particular features of CL I'd have to leave out CRA? Would it hamper
>> the language as we know it?
>
>
> I use a statically typed version of Lisp called Nisp. (Downloadable
> from http://www.cs.yale.edu/homes/dvm, my webpage.) Type declarations
> are written using hyphens (i j - Integer). I am in the process of
> completely rewriting it. For a preview of the result read the "Opt
> Manual" (also available from my webpage), which describes a statically
> typed KR language that looks a lot like Lisp (but has no recursive
> functions).
>
> I love static typing for the following reasons:
>
> (a) It catches many bugs that are otherwise hard to track down. For
> instance, you write 'car' where you meant 'caar'
Jeez, can you use something like CAAR in a statically-typed language?
What is the type returned by CAAR? What is the type passed to it? Jes
wondrin, I'm no expert on this, but I thought that was one of the
hassles with static typing.
, which eventually
> generates an error far from the point where the error occurred.
? i just examine the stack, find the first call that looks silly, debug
its caller. I do agree that getting these ···@& languages to compile my
code is so hard that I am at version 4.0 before it will compile (and
that's a Good Thing sometimes) but on the whole I can get to Correct
other ways that do not have me jumping through hoops set by the compiler
as an indirect way of helping me think.
Reinholf Messner (sp?) worked out that it is better to run up and down
Himalayan peaks largely unroped (roping up for technical sections) and
rely on climbing skill than to rope up and double the climb time by
moving ever so safely one at a time up the mountain. The reason being
most climbers are killed by the weather, and forecasts get exponentially
more unreliable as they are extended. Something like that. So a good
programmer thinking clearly wins against a programmer who dons a strait
jacket when sitting down to code so they do not hurt themselves with
their own code.
A final thought is, why get into types when programming? That is the
wrong level of abstraction. It's kinda like, no matter how cool we want
our languages to be, we still want to think in assembler.
The code should simply be as ignorant as possible of type. COBOL is very
good at this. :)
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Everything is a cell." -- Alan Kay
In the last exciting episode, Kenny Tilton <·······@nyc.rr.com> wrote:
> Jeez, can you use something like CAAR in a statically-typed language?
> What is the type returned by CAAR? What is the type passed to it? Jes
> wondrin, I'm no expert on this, but I thought that was one of the
> hassles with static typing.
The difference between CL and the ML derivatives, in this regard,
tends to be that in the ML languages, lists have a type associated
with them.
Thus, you may have:
# [1 ; 2 ; 3 ; 4];;
- : int list = [1; 2; 3; 4]
# ["a" ; "b" ; "c" ; "d"];;
- : string list = ["a"; "b"; "c"; "d"]
In that case, there are useful inferences to be made about the members
of the list. And you aren't allowed to mix types:
# ["a"; 1; 2.5];;
Characters 6-7:
["a"; 1; 2.5];;
^
This expression has type int but is here used with type string
In ML, in order to have lists similar to those found in Lisp, you have
to define some sort of "union" type that allows some elements to be of
varying types. That certainly makes life more difficult than is the
case in Lisp.
In the case of Lisp, everything is permitted to be a member of a list,
which means you don't get to validate that elements are of the "Right
Type." That being said, there may still be some validation possible
that would indicate that CAR would be 'right' and CAAR 'wrong.' But
CL is certainly a lot looser about it than ML...
--
select 'cbbrowne' || ·@' || 'acm.org';
http://cbbrowne.com/info/functional.html
"The main reason for open-source gets developed is need. If the need
is there, then the software will get written. If it isn't really
needed, then the lack of software is hardly a problem, right?"
-- Almost Brian Hurt's Words <·····@visi.com>
Christopher Browne wrote:
>
> The difference between CL and the ML derivatives, in this regard,
> tends to be that in the ML languages, lists have a type associated
> with them.
>
> ...
>
> In the case of Lisp, everything is permitted to be a member of a list,
> which means you don't get to validate that elements are of the "Right
> Type." That being said, there may still be some validation possible
> that would indicate that CAR would be 'right' and CAAR 'wrong.' But
> CL is certainly a lot looser about it than ML..
In Nisp, if you declare a variable 'l' to be of type (Lst (Lrcd Symbol
Integer)) (which would be the type of an alist associating symbols with
integers), then (car l) is of type (Lrcd Symbol Integer) -- a list of
two elements, a symbol and an integer, and (caar l) is of type Symbol.
Of course, if you declare a list to be of type (Lst Obj) -- list of
arbitrary objects -- then you can't infer anything about the type of
(car l). You can give the system a "hint" if you know something more
specific at a certain point. You might write (be Integer (car l)) to
say that (car l) is known to be an integer.
Please don't confuse "statically typed" with "type-safe." The latter
property means that it's impossible for a program written in the
language to encounter a type error at run time. Lisp is a "dynamically
type-safe" language because it checks types at run time. A "statically
type-safe" language like ML doesn't need to check at run time because if
a program compiles at all then it has no type errors. Nisp is
statically typed, but has all kinds of escape hatches to allow Lisp
programmers to evade the type system when they want to. That is, static
typing is provided to be helpful, not bothersome.
-- Drew McDermott
Kenny Tilton wrote:
>
> Drew McDermott wrote:
> > Hal Niner wrote:
> >
> >> A theoretical question: suppose I would like to create a Lisp
> >> language, named CRA, that is Common Lisp, but statically typed with
> >> type inference, pretty much like Haskell and ML-like languages. What
> >> particular features of CL I'd have to leave out CRA? Would it hamper
> >> the language as we know it?
> >
> >
> > I use a statically typed version of Lisp called Nisp. (Downloadable
> > from http://www.cs.yale.edu/homes/dvm, my webpage.) Type declarations
> > are written using hyphens (i j - Integer). I am in the process of
> > completely rewriting it. For a preview of the result read the "Opt
> > Manual" (also available from my webpage), which describes a statically
> > typed KR language that looks a lot like Lisp (but has no recursive
> > functions).
> >
> > I love static typing for the following reasons:
> >
> > (a) It catches many bugs that are otherwise hard to track down. For
> > instance, you write 'car' where you meant 'caar'
>
> Jeez, can you use something like CAAR in a statically-typed language?
> What is the type returned by CAAR? What is the type passed to it? Jes
> wondrin, I'm no expert on this, but I thought that was one of the
> hassles with static typing.
It would have to be a list of lists, and return any type. But it's
all very well saying that. In Lisp, (caar (read)) is perfectly
legal, and (provided the luser types in a list of lists), will work.
The problem is that the compiler doesn't know in advance the exact
type of the value returned by read. You could annotate this, though:
(caar (the list-of-lists (read))
And you'd need some form of complex types too.
The main problem I have with static typing is that it types the wrong
thing. It gives variables types when values should have types.
Variables are just arbitrary memory locations that could contain
anything. Variables are not necessary, and not all languages have
them.
> Reinholf Messner (sp?) worked out that it is better to run up and down
> Himalayan peaks largely unroped (roping up for technical sections) and
> rely on climbing skill than to rope up and double the climb time by
> moving ever so safely one at a time up the mountain. The reason being
> most climbers are killed by the weather, and forecasts get exponentially
> more unreliable as they are extended. Something like that. So a good
> programmer thinking clearly wins against a programmer who dons a strait
> jacket when sitting down to code so they do not hurt themselves with
> their own code.
You could regard garbage collection as a straitjacket too, but better
that than shooting yourself in the foot with calls to free(). The
problem arises when straitjackets get in the way of good programmers.
Most of the time malloc() and free() are irrelevances the programmer
should not be bothered with.
> kenny tilton
:ugah179
--
"I'm outta here. Python people are much nicer."
-- Erik Naggum (out of context)
From: Joe Marshall
Subject: Re: Common Lisp as a statically typed language
Date:
Message-ID: <fzn8h1tp.fsf@ccs.neu.edu>
Kenny Tilton <·······@nyc.rr.com> writes:
> Reinholf Messner (sp?) worked out that it is better to run up and
> down Himalayan peaks largely unroped (roping up for technical
> sections) and rely on climbing skill than to rope up and double the
> climb time by moving ever so safely one at a time up the mountain.
> The reason being most climbers are killed by the weather, and
> forecasts get exponentially more unreliable as they are extended.
> Something like that.
Ok....
> So a good programmer thinking clearly wins against a programmer who
> dons a strait jacket when sitting down to code so they do not hurt
> themselves with their own code.
This doesn't follow at all. (Unless you are coding while climbing.)
Obviously there is no substitute for clear thinking, but if you have
an inobtrusive safety mechanism, there is no reason not to use it.
I'm no fan of traditional statically typed systems (by this I mean
ones in which I am required to decorate my code with type information
before I'm allowed to run it), but I wouldn't object to a system that
tells me ``Hey, this code you wrote simply won't work because I can
prove that you'd end up trying call CAR on a NUMBER.'' provided I
don't have to take the time to teach it.
The world rejoiced as Kenny Tilton <·······@nyc.rr.com> wrote:
> Reinholf Messner (sp?) worked out that it is better to run up and down
> Himalayan peaks largely unroped (roping up for technical sections) and
> rely on climbing skill than to rope up and double the climb time by
> moving ever so safely one at a time up the mountain. The reason being
> most climbers are killed by the weather, and forecasts get
> exponentially more unreliable as they are extended. Something like
> that. So a good programmer thinking clearly wins against a programmer
> who dons a strait jacket when sitting down to code so they do not hurt
> themselves with their own code.
Interesting. This all implies that it is not always obvious which
risk are the important ones. In an activity as commonly-fatal as
climbing Mount Everest, apparently there are some non-intuitive
effects.
I'll bet that fatigue is also a factor. The more time you spend at
such high altitudes, the more you will be fatigued by lack of oxygen.
Minimizing the risk of death, in this case, may not involve a terribly
low minimum. The "best chances" may involve taking some pretty big
risks...
> A final thought is, why get into types when programming? That is the
> wrong level of abstraction. It's kinda like, no matter how cool we
> want our languages to be, we still want to think in assembler.
Something that's kind of nice about ML is the "polymorphism" thing
where it determines a lot of type mismatches without requiring that
you either:
a) Specify types on everything, or
b) Specify a specific type.
The Python compiler does a fair bit of this sort of inference, too...
> The code should simply be as ignorant as possible of type. COBOL is
> very good at this. :)
Heh. Not! COBOL is pretty pathological in that regard.
The way CL provides unified ways of dealing with sequences of
different types is a nice thing. Having the same operators work on
strings, lists, and sometimes even arrays is a whole lot more
parsimonious than the way Scheme typically requires quite separate
sets of functions...
--
wm(X,Y):-write(X),write(·@'),write(Y). wm('cbbrowne','cbbrowne.com').
http://www.ntlug.org/~cbbrowne/lsf.html
"What is piracy? Piracy is the act of stealing an artist's work without
any intention of paying for it. I'm not talking about Napster-type
software. I'm talking about major label recording contracts."
-- Courtney Love, Salon.com, June 14, 2000
From: Kenny Tilton
Subject: Re: Common Lisp as a statically typed language
Date:
Message-ID: <3ECCD1B4.4070408@nyc.rr.com>
Christopher Browne wrote:
> The world rejoiced as Kenny Tilton <·······@nyc.rr.com> wrote:
>
>>Reinholf Messner (sp?) worked out that it is better to run up and down
>>Himalayan peaks largely unroped (roping up for technical sections) and
>>rely on climbing skill than to rope up and double the climb time by
>>moving ever so safely one at a time up the mountain. The reason being
>>most climbers are killed by the weather, and forecasts get
>>exponentially more unreliable as they are extended. Something like
>>that. So a good programmer thinking clearly wins against a programmer
>>who dons a strait jacket when sitting down to code so they do not hurt
>>themselves with their own code.
>
>
> Interesting. This all implies that it is not always obvious which
> risk are the important ones. In an activity as commonly-fatal as
> climbing Mount Everest, apparently there are some non-intuitive
> effects.
>
> I'll bet that fatigue is also a factor. The more time you spend at
> such high altitudes, the more you will be fatigued by lack of oxygen.
Right. I would add "fatigued by /carrying/ oxygen", except the sherpas
do that. But the climbers also ferry bottles between camps. I should
have mentioned that Messner and company trained hard enough to climb
without oxygen.
I guess they started from a winning proposition: up-and-down in a couple
of days. No seige tactics. No long exposure to altitude. Little gear,
food, etc to hump around. Operate within reliable range of forecasts (no
storms). Less climbing (seigers go up and down between camps
repeatedly). Small team: no politics, no weaker climbers.
Sounds great! Now what do we have to do? Be very good technically. Pick
a great partner. Train incredibly hard. Top equipment. Zero tolerance of
slips while climbing.
Lots of parallels there for Lisp and small teams, the one exception
being that slips are handled /better/ by Lisp, so I just take as long as
I need to sharpen my axe and crampons, reset myself on the ice slope and
just carry on.
>
> Minimizing the risk of death, in this case, may not involve a terribly
> low minimum. The "best chances" may involve taking some pretty big
> risks...
Yeah, it's pretty scary, but they did the arithemtic and decided that in
fact the risk of death their way was very small. Someone else calculated
a tenth of a per cent.
Seige climbing (and the waterfall method of system development) provide
a false sense of safety.
> Something that's kind of nice about ML is the "polymorphism" thing
> where it determines a lot of type mismatches without requiring that
> you either:
Free lunch! woo-hoo!!
>>The code should simply be as ignorant as possible of type. COBOL is
>>very good at this. :)
>
> Heh. Not! COBOL is pretty pathological in that regard.
I was thinking about auto-coversion between "PIC 9(n)" variants, from
text to float to twos-complement to packed-decimal. Lawdy we could have
used that on a project in which the project manager insisted on using
VAX Basic. That and move-corresponding and evaluate and copy-replacing
and....
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Everything is a cell." -- Alan Kay