Steve Holden [EMAIL PROTECTED],..eb.com wrote:
The trouble there, though, is that although COBOL was comprehensible (to
a degree) relatively few people have the rigor of thought necessary to
construct, or even understand, an algorithm of any kind.
This is true - and in my experience the
Diez B. Roggisch [EMAIL PROTECTED] writes:
Come on, this is real-time embedded software,
Since when did we restrict ourselves to such an environment? I was under the
impression that this thread is about the merits and capabilities of static
type-checking?
One branch of the discussion brought
Paul Rubin wrote:
Steve Holden [EMAIL PROTECTED] writes:
The issue I have with correctness proofs (at least as they were
presented in the 1980s - for all I know the claims may have become
more realistic now) is that the proof of correctness can only relate
to some highly-formal specification
On Jul 20, 6:28 pm, Paul Rubin http://[EMAIL PROTECTED] wrote:
As the Intel FDIV bug
incident reminds us, even billions of test inputs are not enough to
show that the routine does the right thing for EVERY input.
When I remember correctly the FDIV bug was due to a wrongly filled
lookup table
Kay Schluehr [EMAIL PROTECTED] writes:
When I remember correctly the FDIV bug was due to a wrongly filled
lookup table and occurred only for certain bitpattern in the divisor.
I'm not sure how a formal proof on the structure of the algorithm
could help here? Intel repaired the table i.e. the
Paul Rubin wrote:
Kay Schluehr [EMAIL PROTECTED] writes:
When I remember correctly the FDIV bug was due to a wrongly filled
lookup table and occurred only for certain bitpattern in the divisor.
I'm not sure how a formal proof on the structure of the algorithm
could help here? Intel repaired the
On Jul 20, 6:45 am, John Nagle [EMAIL PROTECTED] wrote:
Juergen Erhard wrote:
On proving programs correct... from my CS study days I distinctly
remember thinking sure, you can prove it correct, but you cannot do
actual useful stuff with it. We might have come a long way since
then (late
Paul Rubin schrieb:
Diez B. Roggisch [EMAIL PROTECTED] writes:
For example, SPARK does not support dynamic allocation of memory so
things such as pointers and heap variables are not supported.
Right, Spark uses a profile intended for embedded systems, so
no unpredictable gc delays etc.
Kay Schluehr [EMAIL PROTECTED] writes:
Sure. But knowing that memory is limited doesn't buy you much because
you achieve an existential proof at best: you can show that the
program must run out of memory but you have to run the program to know
where this happens for arbitrary input values.
Diez B. Roggisch [EMAIL PROTECTED] writes:
What does that buy you - where is I'm crashed becaus I ran out of
memory trying to evade the seventh mig better than sorry, you will
be shot down because I'm not capable of processing more enemie
fighters - but hey, at least I'm still here to tell
John Nagle wrote:
Juergen Erhard wrote:
On proving programs correct... from my CS study days I distinctly
remember thinking sure, you can prove it correct, but you cannot do
actual useful stuff with it. We might have come a long way since
then (late 80s :P), but I don't hold out much hope
Paul Rubin wrote:
Diez B. Roggisch [EMAIL PROTECTED] writes:
What does that buy you - where is I'm crashed becaus I ran out of
memory trying to evade the seventh mig better than sorry, you will
be shot down because I'm not capable of processing more enemie
fighters - but hey, at least I'm
Steve Holden [EMAIL PROTECTED] writes:
The issue I have with correctness proofs (at least as they were
presented in the 1980s - for all I know the claims may have become
more realistic now) is that the proof of correctness can only relate
to some highly-formal specification so complex that
Paul Rubin wrote:
Kay Schluehr [EMAIL PROTECTED] writes:
Sure. But knowing that memory is limited doesn't buy you much because
you achieve an existential proof at best: you can show that the
program must run out of memory but you have to run the program to know
where this happens for arbitrary
On Thu, Jul 12, 2007 at 11:26:22AM -0700, Paul Rubin wrote:
Guy Steele used to describe functional programming -- the evaluation
of lambda-calculus without side effects -- as separation of Church
and state, a highly desirable situation ;-).
(For non-FP nerds, the above is a pun referring
Juergen Erhard wrote:
On proving programs correct... from my CS study days I distinctly
remember thinking sure, you can prove it correct, but you cannot do
actual useful stuff with it. We might have come a long way since
then (late 80s :P), but I don't hold out much hope (especially since
Diez B. Roggisch [EMAIL PROTECTED] writes:
For example, SPARK does not support dynamic allocation of memory so
things such as pointers and heap variables are not supported.
Right, Spark uses a profile intended for embedded systems, so
no unpredictable gc delays etc.
Which is not to say that
Ben Finney [EMAIL PROTECTED] writes:
This seems to make the dangerous assumption that the programmer has
the correct program in mind, and needs only to transfer it correctly
to the computer.
Well, I hope the programmer can at least state some clear
specficiations that a correct program should
Lenard Lindstrom [EMAIL PROTECTED] wrote:
Pascal has no break, continue or return. Eiffel doesn't even have a
goto. In such imperative languages boolean variables are used a lot.
Thanks did not know this.
from StringIO import StringIO
lines = StringIO(one\ntwo\nthree\nfour\n)
Hendrik van Rooyen wrote:
Lenard Lindstrom [EMAIL PROTECTED] wrote:
Pascal has no break, continue or return. Eiffel doesn't even have a
goto. In such imperative languages boolean variables are used a lot.
Thanks did not know this.
from StringIO import StringIO
lines =
Donn Cave [EMAIL PROTECTED] wrote:
In its day, goto was of course very well loved.
Does anybody know for sure if it is in fact possible to
design a language completely free from conditional jumps?
At the lower level, I don't think you can get away with
conditional calls - hence the jumps with
Ben Finney [EMAIL PROTECTED] writes:
This is interesting. Do you have any references we can read about this
assertion -- specifically, that GOTO was not well loved (I assume
by the programming community at large) even by around 1966?
Dijkstra's famous 1968 GOTO considered harmful letter
John Nagle [EMAIL PROTECTED] writes:
Donn Cave wrote:
In its day, goto was of course very well loved.
No, it wasn't. By 1966 or so, GOTO was starting to look like a
bad idea. It was a huge hassle for debugging.
This is interesting. Do you have any references we can read about this
John Nagle schrieb:
Chris Mellon wrote:
You can't prove a program to be correct, in the sense that it's proven
to do what it's supposed to do and only what it's supposed to do.
Actually, you can prove quite a bit about programs with the right
tools.
For example, proving that a program
On 2007-07-13, Hendrik van Rooyen [EMAIL PROTECTED] wrote:
Donn Cave [EMAIL PROTECTED] wrote:
In its day, goto was of course very well loved.
Does anybody know for sure if it is in fact possible to
design a language completely free from conditional jumps?
I think you have to be more clear on
On Fri, 13 Jul 2007 08:37:00 +0200, Hendrik van Rooyen wrote:
Donn Cave [EMAIL PROTECTED] wrote:
In its day, goto was of course very well loved.
Does anybody know for sure if it is in fact possible to
design a language completely free from conditional jumps?
GOTO is unconditional. I
In article [EMAIL PROTECTED],
Paul Rubin http://[EMAIL PROTECTED] wrote:
Ben Finney [EMAIL PROTECTED] writes:
This is interesting. Do you have any references we can read about this
assertion -- specifically, that GOTO was not well loved (I assume
by the programming community at large)
Hendrik van Rooyen wrote:
Donn Cave [EMAIL PROTECTED] wrote:
In its day, goto was of course very well loved.
Does anybody know for sure if it is in fact possible to
design a language completely free from conditional jumps?
At the lower level, I don't think you can get away with
[EMAIL PROTECTED] (Alex Martelli) writes:
If what you wonder about, and the theory mentioned by Clemmer and
detailed by the AQF, are both true, then this may help explain why some
programmers are fiercely innovative why other, equally intelligent ones,
prefer to stick with some plodding,
Donn Cave [EMAIL PROTECTED] writes:
I've wondered if programmers might differ a lot in how much they
dread errors, or how they react to different kinds of errors.
For example, do you feel a pang of remorse when your program
dies with a traceback - I mean, what a horrible way to die?
I'm
Paul Rubin http://[EMAIL PROTECTED] writes:
The idea of designing languages with more and more support for
ensuring program correctness is to put the established, repetitive
processes into the computer where it belongs, freeing the programmer
to be innovative while still providing high
John Nagle [EMAIL PROTECTED] wrote:
I've worked in big mainframe shops, where an operating system
crash caused everything to suddenly freeze, red lights came on all
over the building, and a klaxon sounded. I've worked for aerospace
companies, where one speaks of defects, not bugs, and
In article [EMAIL PROTECTED],
Steve Holden [EMAIL PROTECTED] wrote:
Donn Cave wrote:
Someday we will look at variables like we look at goto.
How very functional. I believe some people naturally think in terms of
state transformations and some in terms of functional evaluation. I am
In article [EMAIL PROTECTED],
Ben Finney [EMAIL PROTECTED] wrote:
Paul Rubin http://[EMAIL PROTECTED] writes:
The idea of designing languages with more and more support for
ensuring program correctness is to put the established, repetitive
processes into the computer where it belongs,
Donn Cave [EMAIL PROTECTED] writes:
Don't worry - there will be a state transformation monad for you!
Nature or nurture? it would be interesting to see some identical twin
studies on novice programmers. Since few of us were exposed first
to strictly functional programming, though, you have
On 7/12/07, Donn Cave [EMAIL PROTECTED] wrote:
In article [EMAIL PROTECTED],
Ben Finney [EMAIL PROTECTED] wrote:
Paul Rubin http://[EMAIL PROTECTED] writes:
The idea of designing languages with more and more support for
ensuring program correctness is to put the established,
Chris Mellon [EMAIL PROTECTED] writes:
You can't prove a program to be correct, in the sense that it's proven
to do what it's supposed to do and only what it's supposed to do. You
can prove type-correctness, and the debate is really over the extent
that a type-correct program is also
Chris Mellon wrote:
You can't prove a program to be correct, in the sense that it's proven
to do what it's supposed to do and only what it's supposed to do.
Actually, you can prove quite a bit about programs with the right tools.
For example, proving that a program cannot subscript out of
Donn Cave wrote:
In its day, goto was of course very well loved.
No, it wasn't. By 1966 or so, GOTO was starting to look
like a bad idea. It was a huge hassle for debugging.
It took another decade to get the iteration constructs
approximately right (FORTRAN was too restrictive,
In article [EMAIL PROTECTED],
Chris Mellon [EMAIL PROTECTED] wrote:
I don't think it's the syntax that keeps people from checking for
errors. It's more a difference of error handling philosophy - in
Python, if you can't do something sensible with an error you just
pretend it can't happen
In article [EMAIL PROTECTED],
Steve Holden [EMAIL PROTECTED] wrote:
Paul Rubin wrote:
Steven D'Aprano [EMAIL PROTECTED] writes:
As far as I can see, the only difference is that the list comp variable
isn't explicitly created with a statement of the form name = value. Why
is that a
Donn Cave wrote:
I've wondered if programmers might differ a lot in how much they
dread errors, or how they react to different kinds of errors.
For example, do you feel a pang of remorse when your program
dies with a traceback - I mean, what a horrible way to die?
Do you resent the compiler's
Donn Cave wrote:
In article [EMAIL PROTECTED],
Steve Holden [EMAIL PROTECTED] wrote:
Paul Rubin wrote:
Steven D'Aprano [EMAIL PROTECTED] writes:
As far as I can see, the only difference is that the list comp variable
isn't explicitly created with a statement of the form name = value. Why
Donn Cave [EMAIL PROTECTED] wrote:
I've wondered if programmers might differ a lot in how much they
dread errors, or how they react to different kinds of errors.
That's quite possible. I'm reminded of a by-now commonplace theory,
well summarized at
Paul Rubin schrieb:
Diez B. Roggisch [EMAIL PROTECTED] writes:
Which implies that even in ADA, runtime type errors are in fact
expected - else there would be no handler for such a case.
Well, yes, runtime errors occur - in statically typed languages as
well. That's essentially the
Diez B. Roggisch [EMAIL PROTECTED] writes:
Sure. But which class of programs are decidable? There's lot's of
research going on with model checking and the like. But AFAIK, the
consensus is that the very moment you allow recursive types, the
type-checking is either incomplete, or possibly
Paul Rubin a écrit :
Bruno Desthuilliers [EMAIL PROTECTED] writes:
If the assertion is wrong, the compiler signals an error. In
that sense it's like a unit test; it makes sure the function does what
the user expects.
It still boils down to the same problem : possibly valid types are
rejected
Paul Rubin wrote:
Diez B. Roggisch [EMAIL PROTECTED] writes:
Which implies that even in ADA, runtime type errors are in fact
expected - else there would be no handler for such a case.
Well, yes, runtime errors occur - in statically typed languages as
well. That's essentially the
Paul Rubin wrote:
Diez B. Roggisch [EMAIL PROTECTED] writes:
Which implies that even in ADA, runtime type errors are in fact
expected - else there would be no handler for such a case.
Well, yes, runtime errors occur - in statically typed languages as
well. That's essentially the
Paul Rubin a écrit :
Bruno Desthuilliers [EMAIL PROTECTED] writes:
Some users in fact recommend writing an explicit type signature for
every Haskell function, which functions sort of like a unit test.
Stop here. explicit type signature == declarative static typing !=
unit test.
The
On 07 Jul 2007 23:27:08 -0700, Paul Rubin
http://phr.cx@nospam.invalid wrote:
Hamilton, William [EMAIL PROTECTED] writes:
Why on earth would anyone prefer taking a failure in the field over
having a static type check make that particular failure impossible?
Because static typechecking
Bruno Desthuilliers [EMAIL PROTECTED] writes:
If the assertion is wrong, the compiler signals an error. In
that sense it's like a unit test; it makes sure the function does what
the user expects.
It still boils down to the same problem : possibly valid types are
rejected based on a
Steve Holden [EMAIL PROTECTED] writes:
Python even leaks the index variable of list comprehensions (I've
mostly stopped using them because of this), though that's a
recognized wart and is due to be fixed.
Wow, you really take non-pollution of the namespace seriously. I agree
it's a wart,
Hamilton, William [EMAIL PROTECTED] writes:
Why on earth would anyone prefer taking a failure in the field over
having a static type check make that particular failure impossible?
Because static typechecking won't make that particular failure
impossible, but instead just change it from a
Paul Rubin wrote:
Steve Holden [EMAIL PROTECTED] writes:
Python even leaks the index variable of list comprehensions (I've
mostly stopped using them because of this), though that's a
recognized wart and is due to be fixed.
Wow, you really take non-pollution of the namespace seriously. I
On Jun 20, 8:53 pm, Stephen R Laniel [EMAIL PROTECTED] wrote:
Reading [1], I wonder: why isn't the compiler making better
use of (purely optional) type labeling? Why not make a compiler
directive so that
a) it will check the types of all my arguments and return
values,
If that is what
On Sun, 08 Jul 2007 08:49:26 -0400, Steve Holden wrote:
Paul Rubin wrote:
Steve Holden [EMAIL PROTECTED] writes:
Python even leaks the index variable of list comprehensions (I've
mostly stopped using them because of this), though that's a
recognized wart and is due to be fixed.
Wow, you
Steven D'Aprano [EMAIL PROTECTED] writes:
As far as I can see, the only difference is that the list comp variable
isn't explicitly created with a statement of the form name = value. Why
is that a problem?
I don't know that listcomp vars are worse problem than other vars;
however there is an
Paul Rubin wrote:
Steven D'Aprano [EMAIL PROTECTED] writes:
As far as I can see, the only difference is that the list comp variable
isn't explicitly created with a statement of the form name = value. Why
is that a problem?
I don't know that listcomp vars are worse problem than other vars;
Steve Holden [EMAIL PROTECTED] writes:
Maybe we just have different styles, and I naturally tend to write in
smaller scopes than you do.
It's easy to make errors even in very small scopes.
--
http://mail.python.org/mailman/listinfo/python-list
Diez B. Roggisch [EMAIL PROTECTED] writes:
Which implies that even in ADA, runtime type errors are in fact
expected - else there would be no handler for such a case.
Well, yes, runtime errors occur - in statically typed languages as
well. That's essentially the halting-problem.
Well, no,
Bruno Desthuilliers [EMAIL PROTECTED] writes:
Some users in fact recommend writing an explicit type signature for
every Haskell function, which functions sort of like a unit test.
Stop here. explicit type signature == declarative static typing !=
unit test.
The user-written signature is
Bruno Desthuilliers skrev:
Paul Rubin a écrit :
Bruno Desthuilliers [EMAIL PROTECTED] writes:
Haskell - as other languages using type-inference like OCaml - are in
a different category. Yes, I know, don't say it, they are statically
typed - but it's mostly structural typing, not declarative
Paul Rubin wrote:
John Nagle [EMAIL PROTECTED] writes:
This has been tried. Original KR C had non-enforced static typing.
All struct pointers were equivalent. It wasn't pretty.
It takes strict programmer discipline to make non-enforced static
typing work. I've seen it work in an
From: Paul Rubin
greg [EMAIL PROTECTED] writes:
E.g. your program might pass its test and run properly for years
before some weird piece of input data causes some regexp to not
quite
work.
Then you get a bug report, you fix it, and you add a test
for it so that particular bug
In article [EMAIL PROTECTED],
Paul Boddie [EMAIL PROTECTED] wrote:
However, it's interesting to consider the work that sometimes needs to
go in to specify data structures in some languages - thinking of ML
and friends, as opposed to Java and friends. The campaign for optional
static typing
On Jul 5, 3:24 pm, Donn Cave [EMAIL PROTECTED] wrote:
In article [EMAIL PROTECTED],
Paul Boddie [EMAIL PROTECTED] wrote:
However, it's interesting to consider the work that sometimes needs to
go in to specify data structures in some languages - thinking of ML
and friends, as opposed to
greg [EMAIL PROTECTED] writes:
E.g. your program might pass its test and run properly for years
before some weird piece of input data causes some regexp to not quite
work.
Then you get a bug report, you fix it, and you add a test
for it so that particular bug can't happen again.
Why on
Paul Rubin a écrit :
greg [EMAIL PROTECTED] writes:
E.g. your program might pass its test and run properly for years
before some weird piece of input data causes some regexp to not quite
work.
Then you get a bug report, you fix it, and you add a test
for it so that particular bug can't
greg [EMAIL PROTECTED] wrote:
Paul Rubin wrote:
E.g. your program might pass its test and run properly for years
before some weird piece of input data causes some regexp to not quite
work.
Then you get a bug report, you fix it, and you add a test
for it so that particular bug can't
Roy Smith [EMAIL PROTECTED] wrote:
greg [EMAIL PROTECTED] wrote:
Paul Rubin wrote:
E.g. your program might pass its test and run properly for years
before some weird piece of input data causes some regexp to not quite
work.
Then you get a bug report, you fix it, and you add a
Bruno Desthuilliers [EMAIL PROTECTED] writes:
Because static type checks impose a lot of arbitrary restrictions,
boilerplate code etc, which tends to make code more complicated than
it needs to be, which is a good way of introducing bugs that wouldn't
have existed without static type checks.
Paul Rubin wrote:
Bruno Desthuilliers [EMAIL PROTECTED] writes:
Because static type checks impose a lot of arbitrary restrictions,
boilerplate code etc, which tends to make code more complicated than
it needs to be, which is a good way of introducing bugs that wouldn't
have existed
Paul Boddie wrote:
Paul Rubin wrote:
The campaign for optional
static typing in Python rapidly became bogged down in this matter,
fearing that any resulting specification for type information might
not be the right combination of flexible and powerful to fit in with
the rest of the
John Nagle [EMAIL PROTECTED] writes:
This has been tried. Original KR C had non-enforced static typing.
All struct pointers were equivalent. It wasn't pretty.
It takes strict programmer discipline to make non-enforced static
typing work. I've seen it work in an aerospace
Paul Rubin a écrit :
Bruno Desthuilliers [EMAIL PROTECTED] writes:
Because static type checks impose a lot of arbitrary restrictions,
boilerplate code etc, which tends to make code more complicated than
it needs to be, which is a good way of introducing bugs that wouldn't
have existed without
Bruno Desthuilliers [EMAIL PROTECTED] writes:
Haskell - as other languages using type-inference like OCaml - are in
a different category. Yes, I know, don't say it, they are statically
typed - but it's mostly structural typing, not declarative
typing. Which makes them much more usable IMHO.
Paul Rubin a écrit :
Bruno Desthuilliers [EMAIL PROTECTED] writes:
Haskell - as other languages using type-inference like OCaml - are in
a different category. Yes, I know, don't say it, they are statically
typed - but it's mostly structural typing, not declarative
typing. Which makes them much
On 6/22/07, Eduardo EdCrypt O. Padoan [EMAIL PROTECTED] wrote:
Remember that pure CPython has no different compile time and
runtiime. But Psyco and ShedSkin could use the annotations the way
they want.
.
def compile(source: something compilable,
filename: where the compilable
On 7/4/07, BJörn Lindqvist [EMAIL PROTECTED] wrote:
On 6/22/07, Eduardo EdCrypt O. Padoan [EMAIL PROTECTED] wrote:
Remember that pure CPython has no different compile time and
runtiime. But Psyco and ShedSkin could use the annotations the way
they want.
.
def compile(source:
Roy Smith wrote:
greg [EMAIL PROTECTED] wrote:
Then you get a bug report, you fix it, and you add a test
for it so that particular bug can't happen again.
The TDD zealots would tell you you've got the order wrong. Instead of
fix, then write a test, it should be write a failing test,
In article [EMAIL PROTECTED],
John Nagle [EMAIL PROTECTED] wrote:
Non-enforced static typing requires a quality assurance group that
reads code and checks coding standards.
In other words, it's enforced, but it's enforced by QA people instead of
the compiler.
--
Eduardo EdCrypt O. Padoan wrote:
On 6/30/07, Bruno Desthuilliers
[EMAIL PROTECTED] wrote:
Eduardo EdCrypt O. Padoan a écrit :
Remember that pure CPython has no different compile time and
runtiime.
Oh yes ? So what's the compiler doing, and what are those .pyc files ?
(hint: read the
Alex Martelli wrote:
Donn Cave [EMAIL PROTECTED] wrote:
In article [EMAIL PROTECTED],
[EMAIL PROTECTED] (Alex Martelli) wrote:
Dynamic typing is recommended, they conclude, when programs must be
as flexible as possible. I recommend reading the Agile Manifesto to
understand why maximal
[EMAIL PROTECTED] (Alex Martelli) writes:
I do have (some of:-) that experience, and am reasonably at ease in
Haskell (except when it comes to coding monads, which I confess I still
have trouble wrapping my head around).
I recently found the article
[EMAIL PROTECTED] (Alex Martelli) wrote:
Eckel's and Martin's well-known essays on why good testing can replace
strict static type checking:
http://www.mindview.net/WebLog/log-0025
http://www.artima.com/weblogs/viewpost.jsp?thread=4639
I've read the first before. I just re-read it. There
Paul Rubin wrote:
E.g. your program might pass its test and run properly for years
before some weird piece of input data causes some regexp to not quite
work.
Then you get a bug report, you fix it, and you add a test
for it so that particular bug can't happen again.
Once I got the
function
In article [EMAIL PROTECTED],
[EMAIL PROTECTED] (Alex Martelli) wrote:
Dynamic typing is recommended, they conclude, when programs must be
as flexible as possible. I recommend reading the Agile Manifesto to
understand why maximal flexibility is crucial in most real-world
application
Donn Cave wrote:
In article [EMAIL PROTECTED],
[EMAIL PROTECTED] (Alex Martelli) wrote:
Dynamic typing is recommended, they conclude, when programs must be
as flexible as possible. I recommend reading the Agile Manifesto to
understand why maximal flexibility is crucial in most
Donn Cave [EMAIL PROTECTED] wrote:
In article [EMAIL PROTECTED],
[EMAIL PROTECTED] (Alex Martelli) wrote:
Dynamic typing is recommended, they conclude, when programs must be
as flexible as possible. I recommend reading the Agile Manifesto to
understand why maximal flexibility is
Because of the different flight path, a data conversion from a 64-bit
floating point to 16-bit signed integer value caused a hardware
exception (more specifically, an arithmetic overflow, as the floating
point number had a value too large to be represented by a 16-bit signed
integer).
Bruno Desthuilliers [EMAIL PROTECTED] writes:
[A type system is a] tractable syntactic method for proving the
absence of certain program behaviors by classifying phrases
according to the kinds of values they compute. (Pierce 2002).
Is this supposed to contradict my assertion
Paul Rubin a écrit :
Bruno Desthuilliers [EMAIL PROTECTED] writes:
[A type system is a] tractable syntactic method for proving the
absence of certain program behaviors by classifying phrases
according to the kinds of values they compute. (Pierce 2002).
Is this supposed to
On 6/30/07, Bruno Desthuilliers [EMAIL PROTECTED] wrote:
Eduardo EdCrypt O. Padoan a écrit :
Remember that pure CPython has no different compile time and
runtiime.
Oh yes ? So what's the compiler doing, and what are those .pyc files ?
(hint: read the doc)
Sorry, I surely know that Python
Bruno Desthuilliers [EMAIL PROTECTED] wrote:
...
I still maintain that the primary *practical* reason behind static
typing is to provide optimization clues for the compiler. You can (or at
It's definitely a helpful aspect, yes -- given that compilers able to
infer types are still not very
Alex Martelli a écrit :
Bruno Desthuilliers [EMAIL PROTECTED] wrote:
...
I still maintain that the primary *practical* reason behind static
typing is to provide optimization clues for the compiler. You can (or at
It's definitely a helpful aspect, yes -- given that compilers able to
wrt/ proofs of correctness, I'll just point to the spectacular failure
of Ariane, which was caused by a *runtime* type error in a system
programmed in ADA - one of the languages with the most psychorigid
declarative static type systems.
That's simply not true. The problem hadn't to do
Diez B. Roggisch a écrit :
wrt/ proofs of correctness, I'll just point to the spectacular failure
of Ariane, which was caused by a *runtime* type error in a system
programmed in ADA - one of the languages with the most psychorigid
declarative static type systems.
That's simply not
On Jun 30, 8:30 pm, Bruno Desthuilliers
[EMAIL PROTECTED] wrote:
Paul Rubin a écrit :
Bruno Desthuilliers [EMAIL PROTECTED] writes:
[A type system is a] tractable syntactic method for proving the
absence of certain program behaviors by classifying phrases
according to the kinds
Bruno Desthuilliers [EMAIL PROTECTED] wrote:
...
Hmmm... For a dinausor, C seems well alive. Can you remind me which
So do chickens.
I'm afraid I didn't get the joke... Are you saying that C is a rather,
well, primitive language ?
The joke's just based on the fact that (based on
1 - 100 of 166 matches
Mail list logo
