 |
|
||
|
|
(OOPSLA 2003) Wednesday |
Past OOPSLA trip reports can be found at Trip Reports I've Written in the past
Back to Tuesday
Note on Nov 5th 2003 this paged was moved to a Wiki so you can edit it there. Please read it over there, this copy is here for historical reasons. http://wiki.cs.uiuc.edu/CampSmalltalk/OOPSLA+2003+Trip+report+Wednesday.
This morning we had the pleasure of having David Ungar talk. I'll say up front that David talks really fast and his slides contains long words, much material, and much to think about so I have missed some of his slides.
First David gave a little bit of personal history, 1969 programming in APL
First Unix hacker in Missouri 1975
Invented Self at Stanford, then at SUN
Seven Paradoxes of OOPLD
Thanks for showing up
What is this conference about, it's about how to build software, better ways to build software
A computer without software is just a lump
Problem the brick wall the programming language between you and the computer
Are you satisfied with your programming language?
I'm not it could be better
Problem
Paradoxes defeat the language designer.
Seven of them, but for time reasons we will only cover the first three.
Better for computer -> worse for people
More concepts -> less general code
Better types -> worse... {see couldn't get all the words in teachtext}
The other four can be discussed over beer.
{Yes, he did have them all up, who remembers what they were}
Language is for:
One person writing/reading
People communicating.
...
Video
Design for computers
Versus designed for people.
Last year Bill Gates talked,
this year you have me.
{Oops a problem with sound for his video in KeyNote, wonder if it was a software problem, muting, or hardware, jack unplugged. We mess a bit with the sound folks then off to the video}
Video
{I think of Babylon 5? characters mocking the differences between DOS and the Mac}
Commands typed in, with mistakes
Mac versus PC
Was about DOS versus Mac OS 6
Which won?
DOS won, but now the interface looks like the Mac.
My MIT interview, the interviewing professor stated. {I think in firm tones}
A VM is just an interpreter of a program and language spec.
Well no it's not!
Job is to give you good error message, if cannot then run program without surprises
Ah? Well that cut things short, I did get a job offer, but didn't take it.
Language must be both Humanistic & Mechanistic
Humanistic, Easy to express your self, adapt to style, deal with ambiguity all the time
Computers have mechanistic aspect domains
Example of a Stack program.
Computer is objective, one viewpoint
People are subjective
Moving swiftly between viewpoints is how people solve problems (quickly)
So we fudge
indentation hints for gross block structure (computer doesn't care)
Use of white space
Fonts color etc. All this gloss is for human.
Note how Java syntax is for compiler.
5 lines for stack program {in SELF} versus many for Java
Programming languages for machines/people
But computers have won.
Science and Sanity by Alfred Korzybski
Science 1933
Abstracting
Selective response to total situation
processing evaluating stimuli
Example: Ordering food from a waiter
Lots of things there, but you focus on few things.
Consciousness of abstraction and immutability
assume a set implemented as a simple array
question does includes(dog) alter the set
NO
Well now if we implement move last item found to front so it can find dog faster
question does includes(dog) alter the set
Yes!
changes bits, changes internal state, changes performance
NO
doesn't change external viewpoint {which is right?}
question was does it change mutability.
immutability is an abstraction
it has no existence outside our minds
as an abstraction it represents a choice about what matters ...
Popular languages lack consciousness of abstraction
C++ const member functions
has mutable for escape
Weird to have an immutable class but mutable instance var.
Java final fields
field "bits" constant but reference could mutate.
...
Reject "is" of identity
So
17 == 17
factorial(10) == factorial(10)
But factorial(100) == factorial(100) is not true
Defining == in terms of bits fails for immutable objects such as large Integer, because even identity is a point of view.
For the sake of sanity forego is-of-identity
instead of x is a stack
say x.put(), x.pop() behave as a stack should
...
Consciousness of abstraction
even identity is an abstraction.
Quantum Psychology
Robert Anton Wilson's
Builds on Science and Sanity but is more readable
...
Blind spot illusion {But black dot on paper, move paper to retina blind spot, then spot disappears}
System bets that paper is white, even where it cannot see it
Mind does the bet.
Implication for languages
Debugging is hard because we can be misled.
Java example {Code sample goes here}
Virtual overloading and dispatch optimization pick wrong (I think) method to use.
{I think it picked the method that the Java VM developer decided, not the one that David would have decided}
George Lakoff
Women, Fire, and Dangerous Things
What categories reveal about the mind
Categories spy on un-conscious habits of thought.
..
Must leave behind
Meaning as based on truth and referenced
Grammar as a matter of put form...
Examples a picture of a cat
A cat
not a mammal, or a gray tabby.
Most basic part of this idea is that we pick the middle
Implications for languages:
super starts at bottom, inner starts at top, Java,C++ types start at top
What about starting in middle
{Talking way too fast}
About Containers
State based on container metaphor
X <- 17 we think of putting 17 in the X container
Sets adding, removing.
Implications for Languages
Functional side-effect-free languages, no side-effect bugs, easier analysis
But natural metaphor for many problems include state
One resolution function-type programming in imperative language
Challenge for future languages
Block structure
Containment tree of scoping found in many languages:
Pascal, C++, Beta, Java
What if references not tree structures -> Look at aliases in Unix file system for escape
Containment & Meaning
Where is the program's meaning?
For the computer
program, compiler, libraries, OS
for the human
??? {Did not get that}
Classical Categories
Categories based on shared characteristics
bird -< wings, flight, feathers
consequences-> members with same characteristics equally good.
Symmetry Contradicted
Direct rating: 1-7 how good an example of x of a y
eg a robin is a bird, a chicken is a bird
reaction time to answer more representative examples have shorter times
production of example
not explained by theory
{People feel a robin is a better representation of a bird than a chicken, Yet both birds}
Asymmetric Generalization
representative member
non-representative member
disease->robin->duck better yes rating, if robin gets disease then duck will
disease->duck->robin weaker yes, if duck gets disease, then robin *might
{Talking too fast now}
Self:
My favorite prototype OOPL
Objects cloned from other objects
Object inherit from other objects
No classes, no types
Pros:
simple model: object, slot, parent method
powerful dynamic inheritance, virtual "classes"
more reuse: no "instance -of", can override "instance variables"
Cons:
must step outside language for abstract objects, inheritance of structure,, no static check of type or privacy.
Summary
Meaning not abstract but result of embodiment
People think middle out, not top-down or bottom-up
People think with prototypes, not classes
Next one
More concepts = less general code
APL Story
APL - Array Programming Language
Kenneth E. Iverson
A programming Language, 1962
Interpretive language versus compiled
Workspace of data and functions
Available at high school, several hours every Friday we were one of three computers in country that got to use it.
Some example of syntax.
{which don't produce well in primitive text editors}
In first year college I got a computer science project
Write simple stack based PC and Emulator
By this time I have found out I could use APL for free at night at college
Standard solution by my many classmates was to code in PL/1 via punch cards, thousands of lines, with ugly batch oriented turn around.
My APL solution was about 20 lines, all done interactively.
So I turn it in and I think I'm lazy, can't bare to think about the long queues for batch turnaround
{I think he was implying that he thought the professor was grading on time taken, vs novel solution}
Instructor gives me an "A" that has warped my life ever since. {Lots of Laughter}
So why was I able to do this?
Now they could have written the PL/I program to read in assembler, make PL/1 code then compile it.
So what?
Pl/1 (
Program != Data
APL (smalltalk,lisp,self)
program == data
Basic assumptions in language blind us.
Maybe your 1000 line programs could be solved in 20 in some other language
Poorer is richer
simplicity -> uniformity -> malleability
if there is only one way then
everything is built out of the same stuff and can mix-and-match
so unify, unify, unify
My favorite thing to unity is state and behavior.
Tangent:
classes and bits view of OO
object belongs to a class
class says which variables the object has and even where they are
can ask an object about it's class
what's real? The Bits!!!
This view leads to peeking inside objects
Learning Smalltalk
Black-box object view
An object is like Rutherford's atom, cannot look inside
Send a message, with perhaps another object, get an object back
so we shoot particles at it, and observe the effects.
So state <-> behavior
Was result computed or is it state? We can't tell
Example of Polar Points
point is x/y
polar point is degrees and radius
Yet we can use x/y but that's a message send
unifying state & behavior
promote resuse
encapsulate implementation decisions
empowers inheritance
Self Video {Link to the video please, folks afterwards noted it was excellent and the entire video is worth seeing}
Randy Smith
Simple object model gives us flexibility
Poorer is Richer
Simpler is better
Richer is Poorer?!?
Language with large set of finer-grained concepts can lead to over-specification
More explicit, less room for ambiguity
{Missed some}
Many OOPL designers keep adding "features"
Benefits
Programmer can choose features from language.
But featuritis is a slow killer
Overhead of learning, of reading unfamiliar features, choosing what to say, of debugging behavior
Layering resolves dilemma
put small number of concepts at bottom
add more concepts above
examples
link lists aren't built in the language, just built with objects
Beta
Better types = worse types
Let programmer be explicit
Let computer check
Errors can have mysterious consequences
Not as critical with Smalltalk, Java, etc
But types mostly
Lead to restricted environments
Cannot test anything till everything type-checks
Not user extensible
Inhibit reuses
Maybe Beta has the right compromise
Hidden cost of static types
Wasted time fixing spelling errors
Forces you to think at wrong level
Leads to brittle programs
Smalltalk experiences: find errors faster without them
Less turnaround time not just a convenience
Foster agility
{leads to better-designed programs
fixes for readability as opposed to correctness, mind these aren't done}
fix and continue: aarg!!
The very term shows how we have been hijacked
In Ungars world programmers swims in a sea of live objects
Type paradox
Ancient weak computers lead to invention of types
Idea that declaring everything statically is good
Type hype-ism incurs subtle cots.
Lose of reuse, high cognitive burden on programmer
Loose simplicity
Prefer static factory methods to constructors.
Factory methods have descriptive names.
Can have more than one way of constructing.
Lack of consciousness of abstraction.
Even the act of creation is an abstraction.
Too many concepts.
Richer is poorer.
Constructor concepts ties conceptual object creation to physical object creation.
Class type concepts allows overly specific signatures.
Better types are worse
Enforce singleton with private constructor"
Java provides default constructor
So must constructor to turn off construction
What went wrong?
People versus computers
People think in prototypes, not classes
Singletons
More concepts = less general
"must override hash when you override equals" -> Smalltalk {A coding rule, that when ignored causes subtle bugs at a later date}
Why doesn't the type system catch this?
Very hard to mechanically reason about program behavior with intuitive consequences
"clone incompatible with final fields"
complexity = O(2 number of concepts)
Conclusions
OO programming paradoxes
What's good for people != good for computers
Be conscious of abstraction
Be wary of Aristotelian system
Value of prototype-orientation
Understanding of paradoxes critical for good language design
Question: why lang C++, Java predominate
Ungar: why do people smoke tobacco
Daniel
Thinking from the middle out via strong base classes with default behavior.
fascinating question.
{Didn't get to hear the answer someone wanted to talk to me, there were a few other
questions but a cold managed to subdue my typing/listening abilities}
After this there was time in Camp to well think and talk about future plans.
Then off to another presentation you've not heard much about.
So onward to Thursday