THE GOOD:
1. pickle
2. simplicity and uniformity
3. big library (bigger would be even better)
THE BAD:
1. f(x,y,z) sucks. f x y z would be much easier to type (see Haskell)
90% of the code is function applictions. Why not make it convenient?
2. Statements vs Expressions business is very dumb. Try writing
a = if x :
y
else: z
3. no multimethods (why? Guido did not know Lisp, so he did not know
about them) You now have to suffer from visitor patterns, etc. like
lowly Java monkeys.
4. splintering of the language: you have the inefficient main language,
and you have a different dialect being developed that needs type
declarations. Why not allow type declarations in the main language
instead as an option (Lisp does it)
5. Why do you need "def" ? In Haskell, you'd write
square x = x * x
6. Requiring "return" is also dumb (see #5)
7. Syntax and semantics of "lambda" should be identical to
function definitions (for simplicity and uniformity)
8. Can you undefine a function, value, class or unimport a module?
(If the answer is no to any of these questions, Python is simply
not interactive enough)
9. Syntax for arrays is also bad [a (b c d) e f] would be better
than [a, b(c,d), e, f]
420
P.S. If someone can forward this to python-dev, you can probably save some
people a lot of soul-searching
Jul 18 '05
467  21128 
Pascal Costanza <co******@web.de> writes: Dirk Thierbach wrote:
testxyz obj = (concretemethod obj == 42)
Does the code compile as long as concretemethod doesn't exist?
No. Does your test pass as long as conretemthod doesn't exist? It
doesn't, for the same reason.
As long as I am writing only tests, I don't care. When I am in the
mood of writing tests, I want to write as many tests as possible,
without having to think about whether my code is acceptable for the
static type checker or not.
Uh...the type system will let you *write* what you want, it will just
stop you from *running* those tests. Which are obviously going to
fail anyway. Okay, so perhaps you for some reason needs to write the
tests for nonexistent code, and then run something else that you keep
in the same file. You then need to add
concretemethod = undefined
which just goes to show you how useless static typing is.
-kzm
--
If I haven't seen further, it is by standing in the footprints of giants
"Joachim Durchholz" <jo***************@web.de> wrote in message news:bn**********@news.oberberg.net...
A test suite can never catch all permutations of data that may occur (on
a modern processor, you can't even check the increment-by-one operation
with that, the universe will end before the CPU has counted even half of
the full range).
Just to be pedantic, there are some circumstances where this is
possible. For example, it is quite possible to construct a test suite
that will exhaustively test the boolean "or" operator. There are
exactly four test cases, so that's not too bad.
It's worth mentioning this because it points out what you
have to do for a unit test suite to provide the degree of
coverage that any theorem-proving based system does:
you have to check the entire set of inputs for the function.
Sometimes I run into unit test boosters who feel that
they're provably correct when they have a test case
for every code path. But you'd have every code path
tested with just one test case for the "or" example,
whereas you need fully 4 test cases before you're
provably correct.
Hmmm. Should my test suite for "or" include
passing it strings and ints and checking to be
sure it gives an exception?
Marshall
"Pascal Costanza" <co******@web.de> wrote in message news:bn**********@f1node01.rhrz.uni-bonn.de...
In a statically typed language, when I write a test case that calls a
specific method, I need to write at least one class that implements at
least that method, otherwise the code won't compile.
In a dynamically typed language I can concentrate on writing the test
cases first and don't need to write dummy code to make some arbitrary
static checker happy.
This is a non-issue. In both cases, you need the implementing code
if you want to be able to run the testcase, and you don't need the
implementing code if you don't.
Marshall
Adrian Hey <ah**@NoSpicedHam.iee.org> writes: Kenny Tilton wrote: Ralph Becket wrote:
STATICALLY TYPED: the compiler carries out a proof that no value of the
wrong type will ever be passed to a function expecting a different type,
anywhere in the program.
Big deal.
Yes it is a very big deal.
While Mr. Martin probably should get out more, I must admit that I
have a nagging feeling about typing and object orientation. Somebody
else correlated typing with imperativity, and I suspect dynamic typing
is a better match for OO than static typing. But I'm probably making
the common error of comparing with the rather pedestrian type systems
of C++ and Java, perhaps O'Haskell and OCaml have systems that work
better?
-kzm
--
If I haven't seen further, it is by standing in the footprints of giants
Marshall Spight wrote: In a decent dynamically typed language, you have proper name space
management, so that a method cannot ever be defined for a class only by
accident.
How can a method be defined "by accident?" I can't figure out what
you're trying to say.
class C {
void m();
}
class D {
void m();
}
....
void doSomething (Object o) {
if (o instanceof C) {
((D)o).m();
}
}
"Oops, by accident method m is also defined in D, although I wanted to
call method m in C."
Doesn't happen in languages with proper name space management. (The
problem is that Java gives you only the illusion of well-behaved
namespaces.)
Pascal
P.S, before anyone repeats the same issue again: Yes, Java has a badly
designed static type system. The example was not a very good one in the
first place. Doesn't matter wrt to my essential message though.
--
Pascal Costanza University of Bonn
mailto:co******@web.de Institute of Computer Science III http://www.pascalcostanza.de Römerstr. 164, D-53117 Bonn (Germany)
ke********@ii.uib.no wrote: Pascal Costanza <co******@web.de> writes:
Dirk Thierbach wrote:
testxyz obj = (concretemethod obj == 42)
Does the code compile as long as concretemethod doesn't exist?
No. Does your test pass as long as conretemthod doesn't exist? It
doesn't, for the same reason.
As long as I am writing only tests, I don't care. When I am in the
mood of writing tests, I want to write as many tests as possible,
without having to think about whether my code is acceptable for the
static type checker or not.
Uh...the type system will let you *write* what you want, it will just
stop you from *running* those tests. Which are obviously going to
fail anyway. Okay, so perhaps you for some reason needs to write the
tests for nonexistent code, and then run something else that you keep
in the same file.
+ not "for some reason". Writing tests for nonexistent code is in fact
one of the key ideas of extreme programming.
+ No, I don't want to run code that happens to be in the same file. My
development environment can already do some very useful things with the
test code even if it isn't statically type-checkable yet.
Pascal
--
Pascal Costanza University of Bonn
mailto:co******@web.de Institute of Computer Science III http://www.pascalcostanza.de Römerstr. 164, D-53117 Bonn (Germany)
"Marshall Spight" <ms*****@dnai.com> wrote in message news:<Ol********************@rwcrnsc51.ops.asp.att .net>... "Scott McIntire" <mc******************@comcast.net> wrote in message news:MoEkb.821534$YN5.832338@sccrnsc01... It seems to me that the Agency would have fared better if they just used
Lisp - which has bignums - and relied more on regression suites and less on
the belief that static type checking systems would save the day.
I find that an odd conclusion. Given that the cost of bugs is so high
(especially in the cited case) I don't see a good reason for discarding
*anything* that leads to better correctness. Yes, bignums is a good
idea: overflow bugs in this day and age are as bad as C-style buffer
overruns. Why work with a language that allows them when there
are languages that don't?
As I understand it, the Operand Error that caused the grief was a
hardware trap in the 68k FPU. Seems that this trap would have been
programmed to do the same thing regardless of the language used.
Also, I wouldn't call this an overflow "bug." The code was written to
assume (based on proofs) that any overflow indicated a hardware
failure, and to take the designed action for hardware failure. It
would have been trivial for the programmers to prevent the overflow or
handle it in another way. Instead, they made a deliberate decision
that the default exception handling was exactly the right response for
overflow on this variable.
Mike
Marshall Spight wrote: "Pascal Costanza" <co******@web.de> wrote in message news:bn**********@f1node01.rhrz.uni-bonn.de...
In a statically typed language, when I write a test case that calls a
specific method, I need to write at least one class that implements at
least that method, otherwise the code won't compile.
In a dynamically typed language I can concentrate on writing the test
cases first and don't need to write dummy code to make some arbitrary
static checker happy.
This is a non-issue. In both cases, you need the implementing code
if you want to be able to run the testcase, and you don't need the
implementing code if you don't.
No, in a dynamically typed language, I don't need the implementation to
be able to run the testcase.
Among other things:
- the test cases can serve as a kind of todo-list. I run the testsuite,
and it gives me an exception. This shows what portion of code I can work
on next.
- when a test case gives me an exception, I can inspect the runtime
environment and analyze how far the test case got, what it already
successfully did, what is missing, and maybe even why it is missing.
With a statically typed language, I wouldn't be able to get that far.
Furthermore, when I am still in the exceptional situation, I can change
variable settings, define a function on the fly, return some value from
a yet undefined method by hand to see if it can make the rest of the
code work, and so on.
Pascal
--
Pascal Costanza University of Bonn
mailto:co******@web.de Institute of Computer Science III http://www.pascalcostanza.de Römerstr. 164, D-53117 Bonn (Germany)
"Marshall Spight" <ms*****@dnai.com> wrote in message news:<Ol********************@rwcrnsc51.ops.asp.att .net>... "Scott McIntire" <mc******************@comcast.net> wrote in message news:MoEkb.821534$YN5.832338@sccrnsc01... It seems to me that the Agency would have fared better if they just used
Lisp - which has bignums - and relied more on regression suites and less on
the belief that static type checking systems would save the day.
I find that an odd conclusion. Given that the cost of bugs is so high
(especially in the cited case) I don't see a good reason for discarding
*anything* that leads to better correctness. Yes, bignums is a good
idea: overflow bugs in this day and age are as bad as C-style buffer
overruns. Why work with a language that allows them when there
are languages that don't?
As I understand it, the Operand Error that caused the grief was a
hardware trap in the 68k FPU. Seems that this trap would have been
programmed to do the same thing regardless of the language used.
Also, I wouldn't call this an overflow "bug." The code was written to
assume (based on proofs) that any overflow indicated a hardware
failure, and to take the designed action for hardware failure. It
would have been trivial for the programmers to prevent the overflow or
handle it in another way. Instead, they made a deliberate decision
that the default exception handling was exactly the right response for
overflow on this variable.
Mike
(Google is gagging right now, so appologies for any multiple posts)
"Pascal Costanza" <co******@web.de> wrote in message news:bn**********@f1node01.rhrz.uni-bonn.de... For one thing, type declarations *cannot* become out-of-date (as
comments can and often do) because a discrepancy between type
declaration and definition will be immidiately flagged by the compiler.
They same holds for assertions as soon as they are run by the test suite.
That is not true unless your test suite is bit-wise exhaustive.
Assertions cannot become out-of-date. If an assertion doesn't hold
anymore, it will be flagged by the test suite.
This is only correct if all assertions receive coverage from the
test suite, which requires significant discipline, manual testcase
writing, and recurring manual verification, and even then,
it is only true at runtime. And assertions only verify what
you manually specify.
The benefits of a type system require significantly less manual
work, and find errors at compile time. Also, they verify that
type errors provable do not occur anywhere in the program,
vs. just where you manually specify.
Marshall
"Pascal Costanza" <co******@web.de> wrote in message news:bn**********@f1node01.rhrz.uni-bonn.de... ... there exist programs that work but
that cannot be statically typechecked. These programs objectively exist.
By definition, I cannot express them in a statically typed language.
I agree these programs exist.
It would be really interesting to see a small but useful example
of a program that will not pass a statically typed language.
It seems to me that how easy it is to generate such programs
will be an interesting metric.
Anyone? (Sorry, I'm a static typing guy, so my brain is
warped away from such programs. :-)
Marshall
Marshall Spight wrote: "Pascal Costanza" <co******@web.de> wrote in message news:bn**********@f1node01.rhrz.uni-bonn.de...
... there exist programs that work but
that cannot be statically typechecked. These programs objectively exist.
By definition, I cannot express them in a statically typed language.
I agree these programs exist.
It would be really interesting to see a small but useful example
of a program that will not pass a statically typed language.
It seems to me that how easy it is to generate such programs
will be an interesting metric.
Anyone? (Sorry, I'm a static typing guy, so my brain is
warped away from such programs. :-)
Have you ever used a program that has required you to enter a number?
The check whether you have really typed a number is a dynamic check, right?
Pascal
--
Pascal Costanza University of Bonn
mailto:co******@web.de Institute of Computer Science III http://www.pascalcostanza.de Römerstr. 164, D-53117 Bonn (Germany)
"Kenny Tilton" <kt*****@nyc.rr.com> wrote in message news:Zn*******************@twister.nyc.rr.com...
Lights out for static typing.
That kind of statement reminds me a lot of the people
who were saying in 1985 that CISC computing was
dead.
Anyway, I've argued elsewhere with Uncle Bob about
the issues raised in the quoted blog, and one thing
that came out of those arguments was that much of
what he was talking about was true for C++ vs.
Python, but not true for C++ vs. Java. In particular,
it's not clear to me that what he's referring to is
anything besides just rapid turnaround in getting
from a file edit to a running program. Java and
Python are both good about that, with Python
probably having the edge, but C++ can take a
*long* time to compile.
I'll probably get flamed for that statement, eh?
Marshall
"Paul F. Dietz" <di***@dls.net> wrote in message news:Kr********************@dls.net...
(7) Developing reliable software also requires extensive testing to
detect bugs other than type errors, and
(8) These tests will usually detect most of the bugs that static
type checking would have detected.
Whether and to what degree (8) is true is the big open
question in this debate. Does anyone have any objective
metrics? Anyone know how to get them?
This strikes me as a very hard thing to quantify.
Marshall
Pascal Costanza <co******@web.de> once said: Marshall Spight wrote: I agree these programs exist.
It would be really interesting to see a small but useful example
of a program that will not pass a statically typed language.
It seems to me that how easy it is to generate such programs
will be an interesting metric.
Anyone? (Sorry, I'm a static typing guy, so my brain is
warped away from such programs. :-)
Have you ever used a program that has required you to enter a number?
The check whether you have really typed a number is a dynamic check, right?
Yes, but this doesn't imply we can't write a statically-typed program to
handle the situation...
I can imagine Haskell code like
y = do x <- myread "34"
return x * 2
z = do x <- myread "foo"
return x * 2
where
myread :: String -> Maybe a
y, z :: Maybe Int
and "y" ends up with the value "Just 68" whereas "z" is "Nothing".
--
Brian M. McNamara lo****@acm.org : I am a parsing fool!
** Reduce - Reuse - Recycle ** : (Where's my medication? ;) )
Brian McNamara! wrote: Pascal Costanza <co******@web.de> once said:
Marshall Spight wrote:
I agree these programs exist.
It would be really interesting to see a small but useful example
of a program that will not pass a statically typed language.
It seems to me that how easy it is to generate such programs
will be an interesting metric.
Anyone? (Sorry, I'm a static typing guy, so my brain is
warped away from such programs. :-)
Have you ever used a program that has required you to enter a number?
The check whether you have really typed a number is a dynamic check, right?
Yes, but this doesn't imply we can't write a statically-typed program to
handle the situation...
I can imagine Haskell code like
y = do x <- myread "34"
return x * 2
z = do x <- myread "foo"
return x * 2
where
myread :: String -> Maybe a
y, z :: Maybe Int
and "y" ends up with the value "Just 68" whereas "z" is "Nothing".
The code you have given above doesn't give the user any feedback, right?
Do you really think that this is useful?
Pascal
--
Pascal Costanza University of Bonn
mailto:co******@web.de Institute of Computer Science III http://www.pascalcostanza.de Römerstr. 164, D-53117 Bonn (Germany)
Pascal Costanza <co******@web.de> wrote: As long as I am writing only tests, I don't care. When I am in the mood
of writing tests, I want to write as many tests as possible, without
having to think about whether my code is acceptable for the static type
checker or not.
Then just do it. Write as many tests as you care; when you're ready,
compile them and run the type checker.
Where's the problem? One thing that is certainly missing for Haskell or
OCaml is a good IDE that supports as many styles of programming
as possible, but even with the primitive command line versions at the
moment you can do what you want in this case.
And anyway, this would be a question of the IDE, not of static typing.
The type system might test too many cases.
I have never experienced that, because every expression that is valid
code will have a proper type.
Can you think of an example (not in C++ or Java etc.) where the type
system may check too many cases?
Here is one:
(defun f (x)
(unless (< x 200)
(cerror "Type another number"
"You have typed a wrong number")
(f (read)))
(* x 2))
Look up
http://www.lispworks.com/reference/H...ror.htm#cerror
before complaining.
Done. But I still miss the point. OTOH, Lisp certainly doesn't check
types, so I don't see how a Lisp program can be an example of the
type system checking too many cases. OTOH, this example is tied to
a specific Lisp debugger feature. I think it would be better to give
an example in a statically typed language.
I could probably rewrite the code with an approximation to cerror
(with the restriction that non-local control structures don't
translate one to one), but even then I don't see why the type system
would test too many cases for this example.
- Dirk
"Pascal Costanza" <co******@web.de> wrote in message news:bn**********@f1node01.rhrz.uni-bonn.de... Marshall Spight wrote:In a statically typed language, when I write a test case that calls a
specific method, I need to write at least one class that implements at
least that method, otherwise the code won't compile.
In a dynamically typed language I can concentrate on writing the test
cases first and don't need to write dummy code to make some arbitrary
static checker happy.
This is a non-issue. In both cases, you need the implementing code
if you want to be able to run the testcase, and you don't need the
implementing code if you don't.
No, in a dynamically typed language, I don't need the implementation to
be able to run the testcase.
You need it to be able to run the testcase and have it succeed.
If you just want to fail with undefined method, that's exactly
the same as the compile error.
Among other things:
- the test cases can serve as a kind of todo-list. I run the testsuite,
and it gives me an exception. This shows what portion of code I can work
on next.
The compile errors also serve as a kind of todo list. I run the compiler,
and it gives me an error. This shows what portion of the code
I have to write next.
- when a test case gives me an exception, I can inspect the runtime
environment and analyze how far the test case got, what it already
successfully did, what is missing, and maybe even why it is missing.
With a statically typed language, I wouldn't be able to get that far.
Okay, so if you want to write testcases for two methods without
writing either, you have to stub in *both* methods and write
one before you can execute the testcases for one successfully.
You'd have to do this eventually anyway; the static compiler
will impose the requirement that you write stubs for the second
one before you execute the first. So I'd admit that the statically
typed language would put a tiny ordering on trivial tasks that
wouldn't otherwise be there.
(Aren't you supposed to write the method right after you
write the testcases, though?)
All those other things you've mentioned are also possible
for statically typed languages as well. (Inspect the runtime
environment, analyze how far, etc.)
Furthermore, when I am still in the exceptional situation, I can change
variable settings, define a function on the fly, return some value from
a yet undefined method by hand to see if it can make the rest of the
code work, and so on.
I'll acknowledge dynamic languages have an advantage in interactive
execution, which may be considerable.
Marshall
"Pascal Costanza" <co******@web.de> wrote in message news:bn**********@f1node01.rhrz.uni-bonn.de... Marshall Spight wrote: "Pascal Costanza" <co******@web.de> wrote in message news:bn**********@f1node01.rhrz.uni-bonn.de...
... there exist programs that work but
that cannot be statically typechecked. These programs objectively exist.
By definition, I cannot express them in a statically typed language.
I agree these programs exist.
It would be really interesting to see a small but useful example
of a program that will not pass a statically typed language.
It seems to me that how easy it is to generate such programs
will be an interesting metric.
Anyone? (Sorry, I'm a static typing guy, so my brain is
warped away from such programs. :-)
Have you ever used a program that has required you to enter a number?
The check whether you have really typed a number is a dynamic check, right?
This is not an example of what I requested. I can easily write
a statically typed program that inputs a string, and converts
it to a number, possibly failing if the string does not parse to a number.
I was asking for a small, useful program that *cannot* be written
in a statically compiled language (i.e., that cannot statically
be proven type-correct.) I'd be very interested to see such
a thing.
Marshall
Dirk Thierbach wrote: Pascal Costanza <co******@web.de> wrote:
As long as I am writing only tests, I don't care. When I am in the mood
of writing tests, I want to write as many tests as possible, without
having to think about whether my code is acceptable for the static type
checker or not.
Then just do it. Write as many tests as you care; when you're ready,
compile them and run the type checker.
Where's the problem? One thing that is certainly missing for Haskell or
OCaml is a good IDE that supports as many styles of programming
as possible, but even with the primitive command line versions at the
moment you can do what you want in this case.
And anyway, this would be a question of the IDE, not of static typing.
A flexible and useful IDE must treat static type checking as a separate
tool. It needs to be able to do useful things with code that isn't
correct yet. Modern IDES even give you parameter lists, etc., when the
code isn't actually completely parsable.
And that's all I wanted from the very beginning - static typing as an
additional tool, not as one that I don't have any other choice than use
by default.
The type system might test too many cases.
I have never experienced that, because every expression that is valid
code will have a proper type.
Can you think of an example (not in C++ or Java etc.) where the type
system may check too many cases?
Here is one:
(defun f (x)
(unless (< x 200)
(cerror "Type another number"
"You have typed a wrong number")
(f (read)))
(* x 2))
Look up
http://www.lispworks.com/reference/H...ror.htm#cerror
before complaining.
Done. But I still miss the point. OTOH, Lisp certainly doesn't check
types, so I don't see how a Lisp program can be an example of the
type system checking too many cases. OTOH, this example is tied to
a specific Lisp debugger feature. I think it would be better to give
an example in a statically typed language.
No, it's not better to give an example in a different language. The
whole point of my argument is that the code above cannot be statically
type-checked. And the feature presented is extremely helpful, even in
end user applications.
I could probably rewrite the code with an approximation to cerror
(with the restriction that non-local control structures don't
translate one to one), but even then I don't see why the type system
would test too many cases for this example.
I don't want an "approximation of cerror". I want cerror!
Pascal
--
Pascal Costanza University of Bonn
mailto:co******@web.de Institute of Computer Science III http://www.pascalcostanza.de Römerstr. 164, D-53117 Bonn (Germany)
Marshall Spight wrote: (Aren't you supposed to write the method right after you
write the testcases, though?)
No. Furthermore, when I am still in the exceptional situation, I can change
variable settings, define a function on the fly, return some value from
a yet undefined method by hand to see if it can make the rest of the
code work, and so on.
I'll acknowledge dynamic languages have an advantage in interactive
execution, which may be considerable.
Thank you.
Pascal
--
Pascal Costanza University of Bonn
mailto:co******@web.de Institute of Computer Science III http://www.pascalcostanza.de Römerstr. 164, D-53117 Bonn (Germany)
"Pascal Costanza" <co******@web.de> wrote in message news:bn**********@f1node01.rhrz.uni-bonn.de...
And that's all I wanted from the very beginning - static typing as an
additional tool, not as one that I don't have any other choice than use
by default.
I can get behind that idea! It strikes me as being better
than what one has now with either statically typed
languages or dynamically typed languages.
Marshall
Marshall Spight wrote: It would be really interesting to see a small but useful example
of a program that will not pass a statically typed language.
It seems to me that how easy it is to generate such programs
will be an interesting metric.
Anyone? (Sorry, I'm a static typing guy, so my brain is
warped away from such programs. :-)
Have you ever used a program that has required you to enter a number?
The check whether you have really typed a number is a dynamic check, right?
This is not an example of what I requested. I can easily write
a statically typed program that inputs a string, and converts
it to a number, possibly failing if the string does not parse to a number.
....and what does it do when it fails?
I was asking for a small, useful program that *cannot* be written
in a statically compiled language (i.e., that cannot statically
be proven type-correct.) I'd be very interested to see such
a thing.
I have given this example in another post. Please bear in mind that
expressive power is not the same thing as Turing equivalence.
I have given an example of a program that behaves well and cannot be
statically typechecked. I don't need any more evidence than that for my
point. If you ask for more then you haven't gotten my point.
Pascal
--
Pascal Costanza University of Bonn
mailto:co******@web.de Institute of Computer Science III http://www.pascalcostanza.de Römerstr. 164, D-53117 Bonn (Germany)
Dirk Thierbach <dt********@gmx.de> writes: Yep. It turns out that you take away lots of bogus programs, and the
sane programs that are taken away are in most cases at least questionable
(they will be mostly of the sort: There is a type error in some execution
branch, but this branch will never be reached), and can usually be
expressed as equivalent programs that will pass.
I don't understand why you think that most of them will be `dead code'.
I don't understand why a smart type checker would complain about dead
code.
"Pascal Costanza" <co******@web.de> wrote in message news:bn**********@f1node01.rhrz.uni-bonn.de...
class C {
void m();
}
class D {
void m();
}
...
void doSomething (Object o) {
if (o instanceof C) {
((D)o).m();
}
}
"Oops, by accident method m is also defined in D, although I wanted to
call method m in C."
Doesn't happen in languages with proper name space management. (The
problem is that Java gives you only the illusion of well-behaved
namespaces.)
The above code in Java would fail at runtime. What do you think it
ought to do? What would it do in Python? How is this superior to
what Java does? Do you consider this a real-world example?
Does the fact that you didn't respond to the other items
in my post mean you are no longer holding the position that
"explicitly cast[ing] objects" "is one of the sources for potential bugs
that you don't have in a decent dynamically typed language."
Marshall
"Marshall Spight" <ms*****@dnai.com> writes: It would be really interesting to see a small but useful example
of a program that will not pass a statically typed language.
It seems to me that how easy it is to generate such programs
will be an interesting metric.
Would this count?
(defun noisy-apply (f arglist)
(format t "I am now about to apply ~s to ~s" f arglist)
(apply f arglist))
"Pascal Costanza" <co******@web.de> wrote in message news:bn**********@f1node01.rhrz.uni-bonn.de... Marshall Spight wrote:
It would be really interesting to see a small but useful example
of a program that will not pass a statically typed language.
It seems to me that how easy it is to generate such programs
will be an interesting metric.
Anyone? (Sorry, I'm a static typing guy, so my brain is
warped away from such programs. :-)
Have you ever used a program that has required you to enter a number?
The check whether you have really typed a number is a dynamic check, right?
This is not an example of what I requested. I can easily write
a statically typed program that inputs a string, and converts
it to a number, possibly failing if the string does not parse to a number.
...and what does it do when it fails?
What it does when it fails is irrelevant to my request
for someone to come up with a small, useful program
that cannot be written in a statically typed language,
since the program you describe can easily be written
in any statically typed language I'm aware of.
I'm perfectly aware of the fact that statically typed languages
have some runtime checks. This is a feature that static
and dynamic languages have in common, so I don't
see what you might be trying to get at.
I was asking for a small, useful program that *cannot* be written
in a statically compiled language (i.e., that cannot statically
be proven type-correct.) I'd be very interested to see such
a thing.
I have given this example in another post.
I'm very sorry, but I didn't see it. Could you help me find it?
Please bear in mind that
expressive power is not the same thing as Turing equivalence.
No prob.
I have given an example of a program that behaves well and cannot be
statically typechecked. I don't need any more evidence than that for my
point. If you ask for more then you haven't gotten my point.
I'm not asking for more; I'm asking to see the program you're referring to.
Also, I was under the impression that this subthread is about
*my* point, which was a request for a small, useful program
that cannot be written in a statically typed language.
Marshall
In article <bn**********@f1node01.rhrz.uni-bonn.de>, Pascal Costanza
<co******@web.de> wrote: Marshall Spight wrote: "Pascal Costanza" <co******@web.de> wrote in message
news:bn**********@f1node01.rhrz.uni-bonn.de...In a statically typed language, when I write a test case that calls a
specific method, I need to write at least one class that implements at
least that method, otherwise the code won't compile.
In a dynamically typed language I can concentrate on writing the test
cases first and don't need to write dummy code to make some arbitrary
static checker happy.
This is a non-issue. In both cases, you need the implementing code
if you want to be able to run the testcase, and you don't need the
implementing code if you don't.
No, in a dynamically typed language, I don't need the implementation to
be able to run the testcase.
Among other things:
- the test cases can serve as a kind of todo-list. I run the testsuite,
and it gives me an exception. This shows what portion of code I can work
on next.
- when a test case gives me an exception, I can inspect the runtime
environment and analyze how far the test case got, what it already
successfully did, what is missing, and maybe even why it is missing.
With a statically typed language, I wouldn't be able to get that far.
To be fair, you can do both of those things in statically typed langauges
too, except that you get the error at compile time rather than run time.
Furthermore, when I am still in the exceptional situation, I can change
variable settings, define a function on the fly, return some value from
a yet undefined method by hand to see if it can make the rest of the
code work, and so on.
This is a good point.
E.
Pascal Costanza <co******@web.de> once said: Brian McNamara! wrote: I can imagine Haskell code like
y = do x <- myread "34"
return x * 2
z = do x <- myread "foo"
return x * 2
where
myread :: String -> Maybe a
y, z :: Maybe Int
and "y" ends up with the value "Just 68" whereas "z" is "Nothing".
The code you have given above doesn't give the user any feedback, right?
Do you really think that this is useful?
It is certainly useful if the strings are coming from a file read over
the network by a batch process that runs nightly on a machine sitting in
a closet.
But I suppose you really want this example (defun f (x)
(unless (< x 200)
(cerror "Type another number"
"You have typed a wrong number")
(f (read)))
(* x 2))
statically typed, huh? Ok, I'll try. If I come up short, I expect it's
because I'm fluent in neither Haskell nor Lisp, not because it can't be
done.
readInt :: IO Maybe Int
cerror :: String -> String -> IO Maybe a -> IO Maybe a
cerror optmsg errmsg v =
do print errmsg
print ("1: " ++ optmsg)
print "2: Fail"
mx <- readInt
r <- if (maybe False (=1) mx)
then v
else return Nothing
return r
f :: Int -> IO Maybe Int
f x = do x' <- if x < 200
then cerror "Type another number"
"You have typed a wrong number"
(do mx <- readInt
do x <- mx
return f x)
else return (return (x * 2))
return x'
I think that maybe works. Perhaps someone who really knows Haskell and
has a Haskell compiler can check it and/or tidy it up a little if
necessary.
--
Brian M. McNamara lo****@acm.org : I am a parsing fool!
** Reduce - Reuse - Recycle ** : (Where's my medication? ;) )
Dirk Thierbach <dt********@gmx.de> writes: OTOH, Lisp certainly doesn't check types,
Ho hum. I realize that this is probably not what you meant, but given
the existence of usenet archives, I have to oppose this statement
anyway ;-)
Lisp implementations are not /required/ to check types at compile time
(they are at run time, when they encounter a CHECK-TYPE form), but
that doesn't neccessarily mean they don't.
Even if the CL type system isn't as friendly for such things as the
ones of Ocaml or Haskell may be (try proving whether a value is of
type (satisfies (lambda (x) (= x (get-universal-time))))[1] for a
start), some implementations really do honor you optional type
declarations, and even do some significant type inferencing. They
won't just abort compilation if they think you program could be
improved type-wise, but they will issue a warning, which is just as
good IMHO.
OTOH, this example is tied to a specific Lisp debugger feature.
The Lisp debugger is a standardized part of the language, just like
the type system is.
[1] Yes, yes, you'll have to create a named function for that lambda
expression in reality scince SATISFIES doesn't actually accept
lambdas for some reason, but you get the point.
Pascal Costanza <co******@web.de> wrote: Mastering a programming language is a very long process.
So you see that with different tools, you cannot do
it in exactly the same way as with the old tools, and immediately you
start complaining that the new tools have "less expressive power",
just because you don't see that you have to use them in a different
way. The "I can do lot of things with macros in Lisp that are
impossible to do in other languages" claim seems to have a similar
background.
No, you definitely can do a lot of things with macros in Lisp that are
impossible to do in other languages. There are papers that show this
convincingly. Try
ftp://publications.ai.mit.edu/ai-pub...df/AIM-453.pdf for a
start. Then continue, for example, with some articles on Paul Graham's
website, or download and read his book "On Lisp".
That's a great paper; however, see Steele's later work: http://citeseer.nj.nec.com/steele94building.html
John
Pascal Costanza <co******@web.de> wrote: Dirk Thierbach wrote:
Yep. It turns out that you take away lots of bogus programs, and the
sane programs that are taken away are in most cases at least questionable
(they will be mostly of the sort: There is a type error in some execution
branch, but this branch will never be reached)
No. Maybe you believe me when I quote Ralf Hinze, one of the designers
of Haskell:
"However, type systems are always conservative: they must necessarily
reject programs that behave well at run time."
I don't see any contradiction. It's true that type systems must necessarily
reject programs that behave well at run time, nobody is disputing that.
These are the programs that were "taken away". Now why does a type
system reject a program? Because there's a type mismatch in some branch
if the program. Why is the program still well behaved? Very probably
because this branch never gets executed, or it only executes with
values where the type mismatch for some reason doesn't matter. There
may be other reasons, but at the moment I cannot think of any.
I don't have statistically evidence, but it would be easy to
enumerate all terms of a simple language (say, simply typed lambda
calculus with a few constants and ground types) up to a certain length,
and then pick out those that are not well typed but still well behaved.
My guess is that most will be of the type
(if true then 42 else "abc") + 1
It may not be decidable whether such a condition in an if-statement
is always true, but in this case I would consider such a program also
pretty bogus :-)
If you have an example that is not if this type, I would be interested
to see it.
Could you _please_ just accept that statement? That's all I am
asking for!
I have no trouble accepting that statement. As I have said, nobody is
disputing it. What I don't accept is your conclusion that because
one has to reject certain programs, one looses "expressive power".
- Dirk
Pascal Costanza <co******@web.de> wrote: Brian McNamara! wrote:
Have you ever used a program that has required you to enter a
number? The check whether you have really typed a number is a
dynamic check, right?
This dynamic check doesn't necessarily translate to a type check.
Not everything boils down to types just because you're using "numbers".
As Brian has shown, you can use a type that says "maybe it is a
number, maybe it isn't". And that is statically safe, even if we
cannot decide at compile-time if it will be a number of not.
Yes, but this doesn't imply we can't write a statically-typed program to
handle the situation...
The code you have given above doesn't give the user any feedback, right?
Do you really think that this is useful?
There's no problem with adding feedback, other than you have now to
package up the whole thing into the IO monad, because you have side
effects. The important point is the "Maybe" type. With a function like
multiread :: IO (Maybe Int)
you can write code as in
f = do z <- multiread
let y = do x <- z
return (x * 2)
return y
The outer "do" handles the IO monad, the inner "do" will ignore the
calculation if there is no value available. Here's a (very quickly
written, and very bad; I am sure it can be done with more elegance)
implementation of multiread:
myread :: String -> IO (Maybe Int) -> IO (Maybe Int)
myread "" _ = return Nothing
myread s failcont = result (reads s) where
result [(x, "")] = return (Just x)
result _ = failcont
multiread :: IO (Maybe Int)
multiread = do
s <- getLine
myread s (print "Reenter number, or press Enter to abort" >> multiread)
- Dirk
Dirk Thierbach <dt********@gmx.de> writes: I don't see any contradiction. It's true that type systems must necessarily
reject programs that behave well at run time, nobody is disputing that.
These are the programs that were "taken away". Now why does a type
system reject a program? Because there's a type mismatch in some branch
if the program.
*or* because the type system was unable to prove that there *isn't* a
type mismatch in *all* branches. pr***********@comcast.net wrote: I don't understand why you think that most of them will be `dead code'.
Because otherwise the code will be executed, and this will result
in a crash -- there must be a reason why the type checker complains.
I don't understand why a smart type checker would complain about dead
code.
Because in general, it is not decidable if some part of the code will
be executed or not (halting problem).
- Dirk
Pascal Costanza <co******@web.de> wrote: A flexible and useful IDE must treat static type checking as a separate
tool. It needs to be able to do useful things with code that isn't
correct yet.
I don't agree with the "must", but type checking is a seperate phase
in the compiler. It should be possible to make an IDE that treats
it that way. But I doubt that particular point is high on the priority
list of any potential programmer of an IDE.
And that's all I wanted from the very beginning - static typing as an
additional tool, not as one that I don't have any other choice than use
by default.
And that's fine, but it is not an issue of static typing.
>The type system might test too many cases.
No, it's not better to give an example in a different language. The
whole point of my argument is that the code above cannot be statically
type-checked.
You can look now at two examples of code like this that can be
statically type-checked.
And I had the impression that you wanted to explain why a "type system
might test too many cases". I still don't understand this argument. I
don't see any "case" that the type system will test in the above
program, let alone "too many".
I could probably rewrite the code with an approximation to cerror
(with the restriction that non-local control structures don't
translate one to one), but even then I don't see why the type system
would test too many cases for this example.
I don't want an "approximation of cerror". I want cerror!
Then use Lisp and cerror. Nobody forces you to use anything else. The
problem is again that you want to do it only in exactly the same way
as you are used to doing it. You don't see how to do it in another
language, and then you say "it cannot be done". And that's just wrong.
So can we settle on "you like to do it your way, but it is possible
to do everything you want in a statically typed language if
you're a little bit more flexible"? (That means of course that if
you refuse to be a bit more flexible, it cannot be done in exactly
the same way -- after all, they are different languages.)
As long as you say "this cannot be done" you'll get answers showing
you that it can indeed be done, only in a way that is a little bit
different. Then you say "yes, but that's not how I want it. You're
trying to force to use me something I don't want!".
It gets a bit silly after some iterations. Let's stop it.
- Dirk
"Pascal Costanza" <co******@web.de> wrote: But you completely ignore the fact that it also adds expressive power at
another end! For one thing, by allowing you to encode certain invariants
in the types that you cannot express in another way. Furthermore, by
giving more knowledge to the compiler and hence allow the language to
automatize certain tedious things.
I think you are confusing things here. It gets much clearer when you
separate compilation/interpretation from type checking, and see a static
type checker as a distinct tool.
The invariants that you write, or that are inferred by the type checker,
are expressions in a domain-specific language for static program
analysis. You can only increase the expressive power of that
domain-specific language by adding a more elaborate static type system.
You cannot increase the expressive power of the language that it reasons
about.
Sorry, but that reply of yours somewhat indicates that you haven't really
used modern type systems seriously.
All decent type systems allow you to define your own types. You can express
any domain-specific abstraction you want in types. Hence the type language
gives you additional expressive power wrt the problem domain.
An increase of expressive power of the static type checker decreases the
expressive power of the target language, and vice versa.
That's a contradiction, because the type system is part of the "target"
language. You cannot separate them, because the type system is more then
just a static analysis phase - you can program it.
As a sidenote, here is where Lisp comes into the game: Since Lisp
programs can easily reason about other Lisp programs, because there is
no distinction between programs and data in Lisp, it should be pretty
straightforward to write a static type checker for Lisp programs, and
include them in your toolset.
It is not, because Lisp hasn't been designed with types in mind. It is
pretty much folklore that retrofitting a type system onto an arbitrary
language will not work properly. For example, Lisp makes no distinction
between tuples and lists, which is crucial for type inference.
It should also be relatively straightforward to make this a relatively
flexible type checker for which you can increase/decrease the level of
required conformance to the (a?) type system.
This would mean that you could have the benefits of both worlds: when
you need static type checking, you can add it. You can even enforce it
in a project, if the requirements are strict in this regard in a certain
setting. If the requirements are not so strict, you can relax the static
type soundness requirements, or maybe even go back to dynamic type
checking.
I don't believe in soft typing, since it cannot give you the same guarantees
as strong typing. If you want to mix static and dynamic typing, having
static typing as the default and *explicit* escapes to dynamic typing is the
only sensible route, IMNSHO. Otherwise, all the invariants and guarantees
typing gives you are lost. Overloading is one obvious example
that increases expressive power in certain ways and crucially relies on
static typing.
Overloading relies on static typing? This is news to me. What do you mean?
If you want to have extensible overloading then static types are the only
way I know for resolving it. Witness Haskell for example. It has a very
powerful overloading mechanism (for which the term 'overloading' actually is
an understatement). It could not possibly work without static typing, which
is obvious from the fact that Haskell does not even have an untyped
semantics. So there is no inclusion, the "expressiveness" relation is unordered wrt
static vs dynamic typing.
No, I don't think so.
Erasing type information from a program that uses type abstraction to
guarantee certain post conditions will invalidate those post conditions. So
you get a program with a different meaning. It expresses something
different, so the types it contained obviously had some expressive power.
Erasing type information from a program that uses overloading simply makes
it ambiguous, i.e. takes away any meaning at all. So the types definitely
expressed something relevant.
- Andreas
ke********@ii.uib.no wrote: While Mr. Martin probably should get out more, I must admit that I
have a nagging feeling about typing and object orientation. Somebody
else correlated typing with imperativity, and I suspect dynamic typing
is a better match for OO than static typing. But I'm probably making
the common error of comparing with the rather pedestrian type systems
of C++ and Java, perhaps O'Haskell and OCaml have systems that work
better?
I have a my own pet theories to explain the current exitement about
dynamically typed languages. Here they are..
1- Most of this buzz comes from OO folk, many of whom will only have
(bad) experience of static typing from C/C++/Java.
2- Development of static type systems (and type inferencers/checkers)
which are strong enough to offer cast iron *guarantees* but at the
same time are flexible enough to allow useful programs involves
some tricky theory that few really understand (I won't pretend I do).
But some language developers don't want to get to bogged down with
all that difficult and boring theory stuff for however many months
or years it takes. They want to make their language cooler than the
competition right now, so have to rely exclusively on the expensive
run time checks they call "dynamic typing".
3- Given that once this design decision (hack) has been made it is
irreversible for all practical purposes, enthusiasts/advocates of
these languages need to "make a virtue of necessesity" by advertising
all the advantages that dynamic typing brings (allegedly) and
spreading FUD about all the things you can't do with statically typed
languages (allegedly). It is likely they will cite C++ in their
evidence. :-)
Regards
--
Adrian Hey
Dirk Thierbach <dt********@gmx.de> writes: pr***********@comcast.net wrote: I don't understand why you think that most of them will be `dead code'.
Because otherwise the code will be executed, and this will result
in a crash -- there must be a reason why the type checker complains.
Allow me to rephrase: I don't understand why you think *most* of them
will be dead code. Aren't there other cases where the type checker
would complain?
I don't understand why a smart type checker would complain about dead
code.
Because in general, it is not decidable if some part of the code will
be executed or not (halting problem).
- Dirk
"Andreas Rossberg" <ro******@ps.uni-sb.de> writes: Sorry, but that reply of yours somewhat indicates that you haven't really
used modern type systems seriously.
All decent type systems allow you to define your own types. You can express
any domain-specific abstraction you want in types. Hence the type language
gives you additional expressive power wrt the problem domain.
Cool! So I can declare `Euclidean rings' as a type an ensure that I
never pass a non-Euclidean ring to a function?
On Fri, 24 Oct 2003 18:18:25 -0700, prunesquallor wrote: "Andreas Rossberg" <ro******@ps.uni-sb.de> writes:
Sorry, but that reply of yours somewhat indicates that you haven't
really used modern type systems seriously.
All decent type systems allow you to define your own types. You can
express any domain-specific abstraction you want in types. Hence the
type language gives you additional expressive power wrt the problem
domain.
Cool! So I can declare `Euclidean rings' as a type an ensure that I
never pass a non-Euclidean ring to a function?
In Ada, you can
--
Jay O'Connor http://www.deskofsolomon.com
- Online organizational software for teachers
On Fri, 24 Oct 2003 19:29:56 -0700, Jay O'Connor wrote: On Fri, 24 Oct 2003 18:18:25 -0700, prunesquallor wrote:
"Andreas Rossberg" <ro******@ps.uni-sb.de> writes:
Sorry, but that reply of yours somewhat indicates that you haven't
really used modern type systems seriously.
All decent type systems allow you to define your own types. You can
express any domain-specific abstraction you want in types. Hence the
type language gives you additional expressive power wrt the problem
domain.
Cool! So I can declare `Euclidean rings' as a type an ensure that I
never pass a non-Euclidean ring to a function?
In Ada, you can
Ooops...
--
Jay O'Connor http://www.deskofsolomon.com
- Online organizational software for teachers
Jay O'Connor <jo******@cybermesa.com> writes: On Fri, 24 Oct 2003 19:29:56 -0700, Jay O'Connor wrote:
On Fri, 24 Oct 2003 18:18:25 -0700, prunesquallor wrote:
"Andreas Rossberg" <ro******@ps.uni-sb.de> writes:
Sorry, but that reply of yours somewhat indicates that you haven't
really used modern type systems seriously.
All decent type systems allow you to define your own types. You can
express any domain-specific abstraction you want in types. Hence the
type language gives you additional expressive power wrt the problem
domain.
Cool! So I can declare `Euclidean rings' as a type an ensure that I
never pass a non-Euclidean ring to a function?
In Ada, you can
Ooops...
Yeah, my innocent sounding question often hide some nasty pitfalls.
"Adrian Hey" <ah**@NoSpicedHam.iee.org> wrote in message news:bn*******************@news.demon.co.uk...
I have a my own pet theories to explain the current exitement about
dynamically typed languages. Here they are..
Nice analysis. I particularly liked:
But some language developers don't want to get to bogged down with
all that difficult and boring theory stuff for however many months
or years it takes.
Your ideas are probably biased, but your biases match mine, so
there you are.
Marshall
Marshall Spight wrote: "Pascal Costanza" <co******@web.de> wrote in message news:bn**********@f1node01.rhrz.uni-bonn.de...
class C {
void m();
}
class D {
void m();
}
...
void doSomething (Object o) {
if (o instanceof C) {
((D)o).m();
}
}
"Oops, by accident method m is also defined in D, although I wanted to
call method m in C."
Doesn't happen in languages with proper name space management. (The
problem is that Java gives you only the illusion of well-behaved
namespaces.)
The above code in Java would fail at runtime. What do you think it
ought to do? What would it do in Python? How is this superior to
what Java does? Do you consider this a real-world example?
You should be able to choose unique names in the first place. The
problem Java has here is that there is no safe way to avoid that in
general. There is a risk of name clashes here.
There is some information about one way to properly deal with namespaces
at
http://www.cs.northwestern.edu/acade.../packages.html
There are also other approaches. For example, there exist several module
systems for Scheme. (I don't know a lot about them, though.)
I don't know how Python handles potential name conflicts.
Does the fact that you didn't respond to the other items
in my post mean you are no longer holding the position that
"explicitly cast[ing] objects" "is one of the sources for potential bugs
that you don't have in a decent dynamically typed language."
No.
Pascal
Dirk Thierbach wrote: Pascal Costanza <co******@web.de> wrote:
A flexible and useful IDE must treat static type checking as a separate
tool. It needs to be able to do useful things with code that isn't
correct yet.
I don't agree with the "must", but type checking is a seperate phase
in the compiler. It should be possible to make an IDE that treats
it that way. But I doubt that particular point is high on the priority
list of any potential programmer of an IDE.
No, it's only high on the priority list of actual programmers of IDEs.
For example, you could check what Eclipse has to offer for Java in that
regard.
And that's all I wanted from the very beginning - static typing as an
additional tool, not as one that I don't have any other choice than use
by default.
And that's fine, but it is not an issue of static typing.
>>The type system might test too many cases.No, it's not better to give an example in a different language. The
whole point of my argument is that the code above cannot be statically
type-checked.
You can look now at two examples of code like this that can be
statically type-checked.
I am not convinced, but let's play that game for a while: OK, we have
three programs that have the same behavior, and they especially all
behave well. Only two of them can be statically type checked.
This completes my proof that static type systems reduce expressive power.
And I had the impression that you wanted to explain why a "type system
might test too many cases". I still don't understand this argument. I
don't see any "case" that the type system will test in the above
program, let alone "too many".
I could probably rewrite the code with an approximation to cerror
(with the restriction that non-local control structures don't
translate one to one), but even then I don't see why the type system
would test too many cases for this example.
I don't want an "approximation of cerror". I want cerror!
Then use Lisp and cerror. Nobody forces you to use anything else. The
problem is again that you want to do it only in exactly the same way
as you are used to doing it. You don't see how to do it in another
language, and then you say "it cannot be done". And that's just wrong.
I don't say it cannot be done. Don't put words into my mouth.
In this case, you actually need to write additional code to simulate
dynamic checks in a statically typed language that a dynamically typed
language gives you for free. I am sorry, but I don't see any advantage
in such an approach.
So can we settle on "you like to do it your way, but it is possible
to do everything you want in a statically typed language if
you're a little bit more flexible"? (That means of course that if
you refuse to be a bit more flexible, it cannot be done in exactly
the same way -- after all, they are different languages.)
Well, in my book the computer should adapt to what I want, and not the
other way around.
As long as you say "this cannot be done" you'll get answers showing
you that it can indeed be done, only in a way that is a little bit
different. Then you say "yes, but that's not how I want it. You're
trying to force to use me something I don't want!".
No, I haven't said it cannot be done. I have talked about expressive
power, and that's something different.
It gets a bit silly after some iterations.
Indeed.
Pascal
Andreas Rossberg wrote: An increase of expressive power of the static type checker decreases the
expressive power of the target language, and vice versa.
That's a contradiction, because the type system is part of the "target"
language. You cannot separate them, because the type system is more then
just a static analysis phase - you can program it.
For christ's sake, the only interesting question here is: do statically
typed languages increase or decrease the set of programs that behave
well at runtime?
Pascal
Pascal Costanza <co******@web.de> wrote: - when a test case gives me an exception, I can inspect the runtime
environment and analyze how far the test case got, what it already
successfully did, what is missing, and maybe even why it is missing.
With a statically typed language, I wouldn't be able to get that far.
Furthermore, when I am still in the exceptional situation, I can change
variable settings, define a function on the fly, return some value from
a yet undefined method by hand to see if it can make the rest of the
code work, and so on.
That's because you're in an interpreted environemt, not because you're
using a dynamically typed language. Interpreters for statically typed
languages allow the same.
John
Quoth Adrian Hey <ah**@NoSpicedHam.iee.org>:
| ke********@ii.uib.no wrote:
|> While Mr. Martin probably should get out more, I must admit that I
|> have a nagging feeling about typing and object orientation. Somebody
|> else correlated typing with imperativity, and I suspect dynamic typing
|> is a better match for OO than static typing. But I'm probably making
|> the common error of comparing with the rather pedestrian type systems
|> of C++ and Java, perhaps O'Haskell and OCaml have systems that work
|> better?
|
| I have a my own pet theories to explain the current exitement about
| dynamically typed languages. Here they are..
|
| 1- Most of this buzz comes from OO folk, many of whom will only have
| (bad) experience of static typing from C/C++/Java.
That is true for sure with at least some of them.
While your other two theories were interesting, I think most of
it is essentially psychological. I am quite sure that some people
react to static typing with a deep personal resentment. Static
typing is discipline. It would be interesting to see how it flies
in different cultural contexts, say US vs. Japan.
But the value in not blaming it all on C++ et al. is that it gives
us some reasons to think about whether Haskell et al. are really
doing all they can to make static typing work for everyone. Like,
ERROR "hello.hs":8 - Unresolved top-level overloading
*** Binding : main
*** Outstanding context : Show b
Not to get into the details here, but is someone who takes our
hint here and checks out Haskell really headed for a terrific
demonstration of how modern static typing is an easy and fun way
to increase programming productivity? It really is at least a
little harder than we would like to understand type errors like
this, let's admit. A significant factor in the success of languages
like Python is that their shallow learning curve allows the typical
beginner (someone who has used another language) to write a useful
program after literally a few minutes of study of the language.
People like that, they don't like frustration. Psychological thing,
as I said, but possibly something that FPLs could work on.
As for O'Haskell and Objective CAML ... I find O'Haskell really
interesting, but in my view it isn't particularly about OOP
programming in any conventional sense. Objective CAML is, but
someone else will have to tell us how well it works as an OOPL.
Donn Cave, do**@drizzle.com
"Pascal Costanza" <co******@web.de> wrote in message news:bn**********@newsreader2.netcologne.de... Marshall Spight wrote:
The above code in Java would fail at runtime. What do you think it
ought to do? What would it do in Python? How is this superior to
what Java does? Do you consider this a real-world example?
You should be able to choose unique names in the first place. The
problem Java has here is that there is no safe way to avoid that in
general. There is a risk of name clashes here.
Grrr. You didn't answer any of my questions. (Except the one
about Python, for which you said you didn't know.) Or maybe
your response is meant to be an answer to one or more of
them, only I can't tell which or how.
I'm having a hard time following you. Also, you seem to be
shifting what you're talking about quite frequently, which
makes me suspicious.
At this stage I've entirely lost track of the thread. Ah, well. Does the fact that you didn't respond to the other items
in my post mean you are no longer holding the position that ...
No.
I didn't think so. :-)
Marshall This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Xah Lee |
last post by:
http://python.org/doc/2.4.1/lib/module-re.html
http://python.org/doc/2.4.1/lib/node114.html
---------
QUOTE
The module defines several functions, constants, and an exception. Some
of the...
|
by: Juha S. |
last post by:
Hi,
I'm writing a small text editor type application with Python 2.5 and
Tkinter. I'm using the Tk text widget for input and output, and the
problem is that when I try to save its contents to a...
|
by: Berco Beute |
last post by:
I wonder what it would take to implement Python in JavaScript so it
can run on those fancy new JavaScript VM's such as Chrome's V8 or
Firefox' tracemonkey. Much the same as Python implementations...
|
by: Luke Kenneth Casson Leighton |
last post by:
On Sep 3, 10:02 pm, bearophileH...@lycos.com wrote:
1200 lines of code for the compiler, and about... 800 for a basic
suite of builtin types (Dict, List, set, string).
...
|
by: taylorcarr |
last post by:
A Canon printer is a smart device known for being advanced, efficient, and reliable. It is designed for home, office, and hybrid workspace use and can also be used for a variety of purposes. However,...
|
by: ryjfgjl |
last post by:
If we have dozens or hundreds of excel to import into the database, if we use the excel import function provided by database editors such as navicat, it will be extremely tedious and time-consuming...
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
| |
