SmalltalkForExtremeProgrammers

Many of us learned object-orientation through C++, Java or some other stiffly-typed, file-based language. It's taken lots of us years to overcome the worst excesses of those languages. Although we can't completely undo the damage of learning OO through compromised languages, it would be nice to have a workshop that gives developers already familiar with Java or C++ a taste of a better way to work.

(For example here's a few specific examples of brain damage that many people struggle to overcome: static, final, "int" vs "Integer", "...'populate' the widgets", "join entity", "foreach", and so on...)

Cool things that might be interesting to developers:

• Model View Presenter/ Model View Controller (not populating the widgets)
• Block Closures (not foreach/iterators)
• A dynamic environment where you can dynamically introduce new classes and change them (No need to drop a temporary java file to compile a new class...)
• Change sets and the image concept - rather than data files and DLL/classpath hell.

Given the overtly weird look Smalltalk has (from a curly bracketed perspective), it'd probably be enough just to do something small and simple.

Inside every curly bracketed person there's a small, square bracketed person trying to get out ;-)

--DafyddRees

Good idea, maybe we could invite JosephPelrine to help present. --RachelDavies

I'd love to help out if needed. JosephPelrine

Or even AndyBower? if he'd be interested. --DafyddRees

This is a great idea. It's hard to over-emphasise the benefits to be gained as a programmer (a programmer at all, never mind an OO programmer) from learning Smalltalk. For an agile programmer it's simply imperative: so much of the stuff that the mainstream agile community has learned over the last few years is merely (merely!) the way that Smalltalk programming has always been done. It would take an act of deliberate perversion to develop a Smalltalk system in a non-agile way.

For the professional OO programmer, the need to know Smalltalk is like the need of a native English speaker to know Shakespeare and the KJV. If you don't, you simply can have no idea what the intellectual tools you're using are capable of, nor can you properly understand most of what those tools are used to do, nor how they came to be the way they are.

Note that the "overtly weird look" of Smalltalk is as much a red herring as are the complaints about Lisp's parentheses; once you understand what the language is about, the syntax vanishes. Smalltalk looks very weird when written down, true, but why would you ever want to look at Smalltalk code other than in a pretty-printing browser? Trying to understand Smalltalk by looking at printed code is like trying to understand butterflies by looking at their corpses pinned to a board. --KeithB

This would be good and Joseph (with the smallscript stuff) or Andy (with Dolphin's COM integration) should certainly be involved because one of the biggest headaches with smalltalk (For me anyway) is playing nicely with the rest of the non-smalltalk world. I think the attraction of the ScriptingRouteToAgileness is that you can start small and get a lot of leverage by pulling in existing stuff you already understand. With smalltalk (For me anyway) you have to climb a lot of learning curves and understand a lot of new stuff before getting something to impress your boss. --TomAyerst

Perhaps a LispForExtremeProgrammers? (or SchemeForExtremeProgrammers?) too?

Join the ObjectLiberationFront, fight for objects be free to decide what to do themselves; free objects from the oppression of manifest, static type systems. IvanM