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...