TITLE OF PAPER: How To Argue About Types (Day 3 Keynote)
URL OF PRESENTATION: _URL_of_powerpoint_presentation_
PRESENTED BY: Bruce Eckel
REPRESENTING: Mindview
CONFERENCE: PyCON 2004
DATE: 20040326
LOCATION: Ballroom
--------------------------------------------------------------------------
REAL-TIME NOTES / ANNOTATIONS OF THE PAPER:
{If you've contributed, add your name, e-mail & URL at the bottom}
Bruce is recording the talk, planning to put it on the web later.
Things I Learned at the SD Conference
Braython
Concurrency
cache coherency and memory bariers (or: one more reason why Java threading has always been broken)
JDK 1.5 "new" thread support: "It's pthreads 20 years later"
Active Objects
Braython
Gary Cornell, President of A!Press has created Braython by adding braces to the language - he quipped that now if you really want braces you can get them back now.
Cache Coherency Problem
CPU1 +--------+
CPU2 | memory |
CPU3 +--------+
(conceptual)
CPU1-Cache1 - +-----+
CPU2-Cache2 - | mem |
CPU3-Cache3 - +-----+
( actual )
The evil double checked locking problem
The examples he was working on for his Thinking in Java book were working (i.e. failing) in a dual processor box but he could not reproduce them on a single processor box. This is bad...
The cache in a multi processor box is not "flushed" (he thinks synchronised is a better term -- invalidation is probably better) - the temptation of the cpu to read a local variable is to read it from the cache - the hardware has to be aware that it has to fetch the real value from main memory - a very difficult thing to get correct. Discussion of read and write memory barriers (also known as a "fence".) Only now in JDK 1.5 does the volatile keyword correctly uses barriers
In the new version of Java they have not only fixed the volatile issue and added a library that is more or less a wrapping of pthreads.
Passive Objects
this is an object (box), T == threads, blocked at entry point to methods ('=').
+---------------+ / T
| field = -- T
| field | \ T
| field |
| |
| = -- T
| | \ T
+---------------+
threads content at the entry point to methods
Eckel believes that there are only a few people in the world that really understand threads, since every time he thinks he understands them, he turns out to be wrong.
Active Objects
A picture of a box where the Thread is on the left and there is a memory queue feeding it with thread memory requests all queued up by entering the entry points to the method -- i.e. serialization happens at the message level. (This is derived from Carl Hewitt's pioneering work in Actor languages)
Serialzed on a msg basis
schmid'ts goop referenced [ link below ]
Java is adding futures. (see Python cookbook recipe below , and note that futures were invented by Multilisp in 1985
(A Future is a Twisted Deferred, a promise that a result will be provided at some point in the future, except instead of being polling, as Bruce seemed to indicate Java Futures would be, they are callback based, which means no polling and better performance)
(Twisted also gives you tools to write well with threads, with callInThread and callFromThread, both of which actually use a Queue to prevent issues with deadlocking)
Holub asserts (according to Bruce) is that this solves a lot of problems such as race conditions and may solve deadlocks. The assumption is that it's supported at the compiler level. They are thinking of putting into the next version D language.
The D Language
Available free for Windows and Linux at link below
Native compiled, garbage-collected, often runs significantly faster than c++
Many py-like features, built-in unit tests & design by contract.
Might provide compiler support for Active Objects
Arguing about types
Great for starting fires on the net
Not just entertaining, but enlightening
"The correct type system will guarantee results" usually gets things going
Checked Exceptions
A form of static typeing that exists only in Java
My observation that these seem to be more trouble than they are worth was heretical
He initial thought they were a good idea because his mind was around that in the beginning but as time passed as he looked at the code he had issues - but the real issue was that he started to get to know python. That the execption system was really the point. The exception is raised but the catching of exceptions is really up to the coder (the how and why the exception is caught).
In the experiance of adding tons of scaffolding in java to handle checked exceptions and then doing similiar work in Python he came to the understanding that if he really forgets to check an exception he will just find out about it and that's okay.
Weak vs Weakly Typing
(Weak Typing) Aka 'latent typing'
Stroustrup-Proxy: C++ has strong, static type checking
Smalltalk, Python, etc. Wonk: "C/C++ is weakly typed because it has casts and unions"
Wonk: Nope if a language allows an object to accept any incorrect message, then it's weakly typed. Java also allows casts, but it checks them, both at compile time and run times....
Proxy: so you're saying that if the lang is strong everywhere but has a single trap door, you're going to call the whole thing weak?
Wonk: 'Totally weak, dude'
Lexicon
Static typing: types are checked at compile time
Dynamic typing : types are checked at run time
(what about both)?
Strong typing: You can't succesfully apply an improper operation (send a bad message) to an object
Weakly typed: you can successfully perform an improper operation on an object. May or may not be a common confusion with the following term, but people use it anyway
Saw Andrew (Koenig) give a talk on ML, and had a brief moment of understanding, which then vanished (in reference to Type Inference)
Manifest typing: you must specify the types when you create them
Duck Typing: A term used in Ruby (a reference to Duck Tape, actually Duct Tape, where you can take an object of an existing type and add new methods /to/ an object of an existing type and add new mehtods to that object. I think we can do something like this in Python ....
Duck typing isn't really related to duck tape but that "if it walks like a duck and acts like a duck ..."
A slide w/ multiple dictionary definitions of the word "Latent"
"If you only need something that quacks, don't worry about checking that it's a duck"
- Andrew Dalke
The issue people have is that "but I *want* it to *be* a duck" - that they want to really know if it *is* a duck
"Is the Duck There?"
In latent typing we aren't interested in naming the duck in the first place.
As a spiritual (not religious person), he believes that the duck is there even though there is scant evidence of its existence.
Latent Typing in Python
def speak(anything):
anything.talk()
class Dog:
def talk(self): print "arf!"
def reproduce(self): pass
class Robot:
def talk(self): print "Click!"
def oilChange(self): pass
a = Dog()
b = Robot()
speak(a)
speak(b)
The concept of latent typing is already what Python does inherently - analogous to parametric polymorphism in template coding in C++
The above example easily translates to C++ by using templates (shown an example of the above as a template)
class Dog { public: void talk() { cout << "arf" << endl; };
class Robot { public: void talk() { cout << "click" << endl; };
template < class T > void speak( T spkr ) { spkr.talk(); }
int main() {
Dog d;
Robot r;
speak(d);
speak(r):
}
in C++ the compiler checks the typing at run time
Usually C++ compilers generate voluminous but unhelpful error messages -- perhaps vomit is the correct word for this action.
Java and C# Generics are a different story
A sample was displayed showing how, using Generics, how Java would do the above *but* that in the end he was unable to create code that allowed a robot object to be added to a list of dogs.
In Java or C# you cannot say "I don't care what type it is" - all you can do is treat them all as base objects.
create a base interface and then extend it appropriately
by creating an interface that implements the behaviour but using a void type (base object) you do the work but lose all information that comes along with the object
Fragments of a conversation about latent typing
Based upon numerous web comments
Java Wonk (german accent): for safety as much static checking of types is necessare
Other: isn't the extra type information just that extra information
Java Wonk: you are just complaining about the extra typing - the tools handle that
Other: Code is read more than written - Python allows that and is easy to read
Java Wonk: I don't know python so I don't believe you
Other: failure rate of software projects continues to be high despite use of strongly typed Java.
See weblog posting for complete dialog
The only solution is to out-produce the static typing proponents.
Is Latent typing necessary?
What does it really do?
Latent typing allows you to cut across class hierarchies calling methods that are not part of a common interface
C++ has no ultimate object base class, so the need for latent typing is more immediately obvious
Java use of Aspects is similiar to Python's meta class -- i.e. it's possible to have a disjoint class hierarchy in other languages but with some exceptions
If you argue against the use of latent typing you are also arguing for duplication of code - latent typing allows you to share code across classes.
Is the problem just that latent typing is unfamiliar?
Object for procedural programmers
Aspects, Metaclasses, etc
Those grow on you over time
Also, maintenance overhead from extra code due to lack of latent typing
(20 lines/code per day per programmer figure)
Opposite argument
Probablility vs possibility
C++ is more likely to have a disjoint hierarchies than Java
Perhaps the probability is not that high that it will happen very often in practice
The "happy path"
It's really about testing [ the big point of the talk - part 1 ]
In the end, these are all just different kinds of tests. We can consider them as aspectrum:
Testing by the compiler (static type checking)
Testing by the run-time system (dynamic type checking + more)
Unit testing of your classes
Conformance testing of your program
The only way to guarantee the correctness of you program is to have the full spectrum of all of the above - why depend on one of them. It's not whether but *when* this kind of testing will happen.
Not whether, but when [ the big point of the talk - part 2 ]
Balance the expressiveness and clarity of a language with the place in the spectrum where these tests occur.
Opinion: Programs are prose, and must be readable. Static checking is a good thing if it doesn't impact the clarity and expressiveness of the language. If clarity and expressiveness are impacted, then the checking should be moved to reduce that impact.
In the end, must have run-time tests, other tests, and doesn't make sense to obscure code (via static type checking and more complex code) to get up-front testing.
Determinism
Einstein didn't like the uncertainty principle
"God does not play dice with the universe"
"There must be a hidden variable"
Bell's theorem: proves no hidden variable
Hawking: determinism is higher the closer in spacetime you are to an event, but diminishes further away
"The universe is not really that deterministic"
Fate or Free Will
The Greeks believe in both
perhaps Hawking's approach explains the dichotomy
Provable correctness in programs
My guess: only a fraction of programs
Static type checking is limited, and the further in spacetime you are from compilation, the more the "software uncertainty principle" diminshes that determinism
Only by testing throughout will you get a program that is as correct as you are able to describe it
Therefore you must test throughout the entire time spectrum.
C++ Book, Java book
In the best of all worlds he would drop all languages and only work in Python and D
Q: Duck typing:what your talking about is trying to group several types of classes by properties. Seems to him (Koenig) that is very similar to 'type signatures' from the ML community. Signatures is not a type but what you can use to describe a type. (Comment - related to categories in Objective C)
A: The answer he gave is that Andrew knows far more than he does so he will not try to even answer :)
Q: Based on my experiance with threads would he recommend that they use them all the time
A: Not going to take sarcastic questions. But according to Stroupstrup, threads are a bad idea that we have to live with.
Q: Re: ace/tao: some paper w/ experiment data (include fading in/out of question)
A: In the Art of Unix programming, Eric Raymond has a section titled "threat or menace"
Q: Compare active objects w/ Smalltalk message passing
A: The answer is no because he doesn't know smalltalk that well but someone he overheard says it may be similiar because each active object has its own thread and that it's taking messages off a queue. Only one message is ever being processed at a time and it's run to completion before the next one is. Should also look at Erlang
Q: A java wonk (Jim Huginin) asks: is it not better to have explicit types in the code (like in a library). As documentation, etc.
A: Sure, up to a point. Line in sand somewhere between too decorated code & too implicit.
--------------------------------------------------------------------------
REFERENCES: {as documents / sites are referenced add them below}
The Blog Post: http://mindview.net/WebLog/log-0052
Active objects: http://www.cs.wustl.edu/~schmidt/PDF/Act-Obj.pdf
Actor Languages: http://tinyurl.com/yqtt9
Futures in Python: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/84317
Futures in MultiLisp: http://wombat.doc.ic.ac.uk/foldoc/foldoc.cgi?MultiLisp
D Language: http://www.digitalmars.com
Java wonk vs. Bruce: http://mindview.net/WebLog/log-0052
[about two-thirds down: "Flexibility vs. (Perceived) Safety"]
Erlang: http://www.erlang.org/
--------------------------------------------------------------------------
QUOTES:
"I want no heckling from the Twisted people."
--------------------------------------------------------------------------
CONTRIBUTORS: {add your name, e-mail address and URL below}
Ted Leung, twl@osafoundation.org, http://www.sauria.com/blog
Bob Kuehne, rpk@blue-newt.com, http://www.blue-newt.com
Donovan Preston, dp@divmod.org, http://ulaluma.com/pyx
--------------------------------------------------------------------------
E-MAIL BOUNCEBACK: {add your e-mail address separated by commas }
--------------------------------------------------------------------------
NOTES ON / KEY TO THIS TEMPLATE:
A headline (like a field in a database) will be CAPITALISED
This differentiates from the text that follows
A variable that you can change will be surrounded by _underscores_
Spaces in variables are also replaced with under_scores
This allows people to select the whole variable with a simple double-click
A tool-tip is lower case and surrounded by {curly brackets / parentheses}
These supply helpful contextual information.
--------------------------------------------------------------------------
Copyright shared between all the participants unless otherwise stated...