Why I still program Outline in Smalltalk •Introduction, Background •What do Programmers Need? Musings on Software Development •Some History •What Is Smalltalk? Stephen Travis Pope • Language, Libraries, Tools, Methodology [email protected] Relationship to Other Languages, IDEs, etc. UCSB MAT Colloquium • January 14, 2012 •Why I Still Use Smalltalk http://HeavenEverywhere.com/WISPiST.pdf •A Call to Revolutionary Action

1 2

Summary (spoiler alert) NeXT ad from 1992

3 4 My Background What I Develop (& biases) Complex projects (music, AI, high-level tools) Training: EE, CS, Music • • Media-rich (A/V) •HW Development Projects • • Analog Synths, Eventide •DB-rich (large volumes, complex queries) • Vienna, Salzburg jobs •Wide-area distributed Programming • Cross-platform • Low-level, lots of tool-building, then LISP • • Visits to MIT and SAIL in 1976/77 •Performance-critical (compute-bound) • UNIX & C starting in 1976 •Back-end servers and front-end GUIs Graphics starting in 1979 • • C/C++, Python, MATLAB, SuperCollider, SQL • IRCAM, [email protected]

5 6

MODE, 1990-92 Context: 1983 Culture

“Girls just want to have fun” “Puttin’ on the Ritz”

7 8 Context: 1983 Context Computing

STP & CB in 1984 (photos by CR)

9 10

What do Programmers Need? What do Programmers Need? •Software Development Processes • Edit code • Compile, link •Software development tools! • Run, debug • Test • Document • Share, manage multi-programmer teams • Package, deliver • Maintain, upgrade

11 12 What do Programmers Need? Requirements Analysis •Great Overviews of the 1980s • Why Pascal is Not My Favorite Programming Language (BWK, 1981) ‣ Requirements for an Experimental Programming Environment (LPD, 1982) • The Organization of Expert Systems (1982) • An OO Approach to Multimedia Databases (1986) • Programmer as Reader (AG, 1986) • Requirements for an Experimentation Environment for Composers (STP, 1988)

13 14

Req_Exp_Prog_Env (lang)

* Req_Exp_ * *

* Prog_Env * *

* *

* *

* *

15 16 Req_Exp_Prog_Env (L2) Req_Exp_Prog_Env (Tools)

* * * *

*

*

* *

*

17 18

Req_Exp_Prog_Env (Libs) Req_Exp_Prog_Env

* * *

*

* *

19 20 Programmer as Reader •Rules of Reuse: 1: If you can’t find it, you can’t reuse it •Insight: Software engineers spend more time 2: If you don’t trust it, you won’t reuse it reading than writing; therefore code reading •Ease of learning via high-level concepts tools are really important. • As in real life •Later insight: Code rewriting, refactoring, ... •Encourage good design & coding style by use •“Reading and writing are partners” of templates • Should use same/similar tools •Design of Smalltalk Browsers • E.g., not emacs and google • Find, test, reuse

21 22

Summary On-going Debates Language Issues Smart people have thought long and hard • • Uniform vs hybrid OO (is everything an object?) about how to improve programmer ‣ • Kinds of sharing of state and behavior productivity and code quality • Classes vs prototypes • Language issues • Single/multiple inheritance (composition, traits) • Library issues • Interfaces, protocols, abstract classes Development tool issues • Type declarations (vs type inferencing) • Performance/reusability/LoE trade-offs Operating system and environment • • Preferred syntax (many variants) Support for OOP & rapid prototyping and ‣ • ‣ Coding style and enforcement incremental refinement (refactoring, agileP) •Library/Tool/Environment issues?

23 24 Programming Languages A Brief History •Maximal (complex, •Minimal (simple, multi-paradigm, single paradigm) kitchen sink) •Scheme LISP •ALGOL •PASCAL •CS landmarks leading up to 1983 •PL/1 •Smalltalk •CommonLISP •Lua •ADA •MathLangs •C++ •APL, FP, Prolog, ... •Scripting (?)

25 26

1970s SMALLTALK-72 INSTRUCTION MANUAL ADELE GOLDBERG AND ALAN KAY, EDITORS History

1968: Englebart’s “Mother of all Demos” • DynaBook 1972: Kay’s “A Personal Computer for • \ Children of All Ages” \ \ •1976: Kay & Goldberg’s “Personal Dynamic Media” \ •1970s Xerox/MIT Hardware Development • Xerox Alto, MIT LISP Machines •Unix OS (open-source, licensed) 27 28 Interim Dynabook

29 30

OOP History IDE History •1960s •Smalltalk • Simula-67 (Augment/NLS, Sketchpad, ...) •LISP •1970s (uniform languages) • MIT Smalltalk-72, -76, -80 (i.e., V3) • • Xerox • FlavorsLISP • InterLISP-D & LOOPS •Others • Actor • Mesa/Cedar (PARC) •1980s (hybrid languages) • Maestro (PET) 1975 • Objective-C, C++ (1983) • UCSD Pascal, 1978 • ObjectPascal (1985) • TurboPascal (Borland), 1981 • Eiffel, ADA •Barstow, Shrobe & Sandewall, 1984 31 32 UCSD So, like, what is Smalltalk? Pascal •“The Smalltalk Programming System” •Language •(Class) Libraries •(Integrated) Development Environment •Delivery Mechanism •Methodology •Book series •Operating system? •Look-and-feel? PARC Learning Research Group 33 34 Smalltalk History

NoteTaker

35 36 Early 1981 Smalltalk PR Smalltalk’s Design Principles 1977 •(See Byte, 8/81) •Reuse of Personal Mastery (OO Models) •Language • Available to developer and user alike • Model of Communicating (Concurrent) Objects • Objects, Storage Mgmnt, Messages/Methods • Organization • Modularity, Classification • Polymorphism, Factoring, Leverage (reuse)

37 38

Smalltalk’s Design Principles Smalltalk-as-OS

•User Interface •Operating system: “A collection of the objects • “Language in which most of the communication is that didn’t fit into the language, i.e., there visual” shouldn’t be one” (Dan I) • Reactive Principle (all objects have GUIs) •OS components in the library • All windows, tools and apps are objects • Storage mgmnt, File system, Networking, Threads, • Any text can be executed (no shell) Scheduler, Display handling, User I/O •System • ST can run without/instead of an OS “When Smalltalk was little, she thought she • Everything is open (lots of rope, but there are nets • -- code DB and crash recovery) was an operating system.”

39 40 Smalltalk Language •Truly minimal syntax • One best way to write any given expression • Keyword syntax (rather than algebraic syntax) • Very few reserved words, no adjectives •Everything is an object •Objects only interact by message-passing •Instance and class messages •Control structures are messages (extensible) •Objects and classes are reflective • isKindOf:, understands:, allInstances Complete BNF of Smalltalk - Learning, coding, compiling

41 42

Everything is an object? Is this really so important? •Really? •Java argument (types vs classes) •Yes! •No stand-alone functions •Class creation (msg to superclass[es]) •No passive data structures •Control structures (aBool ifTrue: []) •“Evolutionary rather than revolutionary” •Low-level arithmetic (3 + 4) •Promotes Exception-handling ([] on: anExc handle: []) • Learning, finding • Reuse Debugging print (Transcript show: aValue) • • • Extensibility •Files, Sockets, Threads, Error conditions • Code management •Compiler, Browser, ... •Example: aList := aString asPath: sepChar

43 44 Keyword Syntax Control Structures •(As opposed to algebraic syntax) •Blocks, Booleans and Intervals are objects •To get an item out of an array Smalltalk: cl := [ :x :y | x + y ]. ‣ item := anArray at: 1 C++ 0x: auto cl = [&] (int x, int y) { return x + y; }; •To assign into an array •If/then/else ‣ anArray at: 1 put: anObject z > 0 ifTrue: [ “do this block” ] To construct a new Rectangle ifFalse: [ “otherwise, do this block” ] • For loops ‣ aRectangle := Rectangle left: 0 right: 4 top: 0 bottom: 4 • ‣ aRectangle := Rectangle left: 0 top: 0 width: 4 height: 4 1 to: 5 do: [ :num | • Always alternate keyword/argument Transcript show: (num * num) printString; cr] Also: do/while, switch, catch/throw, ... • Never have a list of arguments without keyword • • No operator precedence rules - 3 + 4 * 2 = 14 ! • Extensible control structures (!)

45 46

Smalltalk Libraries Smalltalk Libraries

•Single root class (Object) •Protocol of Object •All classes can be extended (!) • Messages understood by all objects •Heavy use of polymorphism •Important high-level abstractions Mostly single inheritance • Magnitudes (number, point, date, character) • Collections (array, string, set, dictionary) Use composition and forwarding by default • • • Streams (file, socket, producer, server) Other sharing mechanisms (species, MI, generic • • Model, View, Controller classes behaviors, traits, interfaces, passing blocks, etc.) • Graphics classes • “Core” = ~1000 classes; VW 7.9 = ~3300 classes • Event classes

47 48 Class Hierarchies Special Features •Infinite-precision math •Metanumerics •Many graphical models •Several flavors of schedulers •ChangeSets, Namespaces, Packages •OO design patterns • Adaptor, Visitor, Singleton, Observer, Factory, Prototype, Composite, Decorator, Facade, Proxy, ...

49 50

Events Magnitudes & and Sequenceable Collections Views

51 52 The Smalltalk Pluggable GUI Look and Feel •Graphics rendering •BitBLT, SPIM, OpenGL •Window Manager •Was the OS •Can use host OS windows •MVC Classes •Widgets, wrappers, Look&Feel •Multi-screen, multi-desktop, multi-user GUIs •Standard tools (B-I-E) 53 54

Smalltalk IDE Code Browsers •Browsers •Uniform access to all system source code in • Browse collections of objects (e.g., classes) a hypertext browser with full-text search • Organization of set •Unit of change (compilation) is a method • Operations on inner nodes & leaf nodes •Many kinds •Inspectors • Package, Namespace, Hierarchy, Refactoring • Low-level access to an object’s properties • Cross-referencing (reflection & code DB) • May violate encapsulation •Code editing aids •Editors • Formatter, spelling, auto-complete, explainer • Customized inspector • Templates for classes, methods, documentation • May add custom GUI (V/C) •Standard system browser layout

55 56 System Browser (GST) Class Object

57 58

Browsers Browsers

Implementors

Variable references

Senders

Finding things

59 60 Navigator Browser Code History

61 62

C++ Browser (in ST) Object Browsers

63 64 Inspectors Editors

The “soldering iron” - may violate encapsulation

65 66

Debuggers Debugger •Basically a method-list browser where the method list is the stack of some thread Stack •Adds inspectors on the receiver object, method arguments and temporary objects Method •Allows full browser-style cross-referencing •Supports fix&continue - you can recompile a method in the middle of the stack and continue from there Receiver Args, temps

67 68 Debugging a View’s Display Method

SUnit Suite Profiling, Testing, etc.

69 70

Code Management Package & CASE Management •Supporting multi- person teams Web repository Packages on disk •Projects and changes • Change list tool •Namespaces •Configurations •Package managers •ENVY

71 72 Other Smalltalk & Multimedia Outliner IDE Tools •Graphics • Several back-ends • Display-list frameworks •Sound • Hardware synthesis • Software synthesis •Music • MIDI, OSC, Csound, SuperC •Simulation, VR Control Panels • ARK, Croquet, Cobalt

73 74

Early MM in Smalltalk DoubleTalk

Kyma MuO eToys

75 76 Squeak World Squeak World

77 78

Delivery Mechanism Performance •Smalltalk code compiles to virtual machine •Smalltalk “Virtual Image” language (like Java, python, ruby, .NET, ...) Store all objects, classes, methods to a binary file • “It is the virtual machine implementor’s job to Like LISP, APL, MATLAB, JAR files • • cheat and not get caught.” • Includes current tools and threads •Source databases and change tracking •VM techniques • Dynamic translation & native code caches •Packaging apps for delivery • Polymorphic in-line caches (type inferencing) • Package & configuration managers • Massive inlining • Strippers & whittlers •Easy connection to C (DLLCC, SWIG, Slang)

79 80 Smalltalk and OOA/D The Risks (of open systems) •OO Design Patterns •Breaking the system • Most existed in ST before the GoF book • Very easy Early OOA/D methods • Processor := nil, True := false • • Break compiler OBA, CRC Cards • • Tools for recovery (change lists, method versioning) •UML and formal OO Methods •VI bloat Notations • • Strippers, whittlers Processes • Incompatible changes Domain-specific languages • • • Merging tools XP, Agile methods • • Up-front control as in Envy

81 82

Other Topics Modern Smalltalks •Extensibility •VisualWorks •Customizable Apps DLLCC, SWIG, Slang • Squeak •eToys Portability • • Pharo •Croquet True “WORA” • • Other free •Scratch Concurrent VMs • MuO • Other commercial • •Polycephaly • •Kyma ST on other VMs •Descendents •Qwaq • Self •Java, Ruby, .NET, JS • •Cobalt Strongtalk •Amber, Bistro, Fancy • •Newspeak

83 84 Why it Smalltalk Today “failed” •Microcontrollers to mainframes •GUI or headless •With or without OS Web Apps with SeaSide and Swazoo PC Week, 1990 • ParserGenerators for other languages Perceived compute expense (required HW) • • Many frameworks for multimedia apps Mediocre performance on non-Xerox 1980s • • Interoperability between dialects HW (no tags, SW bitBLT, OS, small RAM) • Interoperability with C libraries •“Everything you know is wrong” •

85 86

Programming Today Development Environment Comparison •Syntax, Semantics •Object Model •Libraries •IDE •Development/delivery scheme Relatives I Deserve • Better than a • C-family C+ ! • “Scripting” Languages • Hybrid Languages

87 88 C-Family C Variants •C++ (C-with-classes) Class like a struct • Wired Many early versions • • Gradual transition of prior skills 4 languages in 1: CPP, C, C++, • • • Relevant? templates (KY) • Scale to low-level code •Objective-C • Relevant? • Hybrid of C & Smalltalk • High performance (promised) • Higher-level dynamic model • Great libraries • STL •Java • JUCE (!) • C++- (no MI or operator overloading) • Boost (blessing or curse?) • “What a shame they didn’t steal the whole thing” • Ubiquitous

89 90

C Variants C++ 0x (11) •Tired • Low-level • No GC • Most operations use types • Not uniformly OO • int type vs Integer class in Java • Big problems with libraries • C++/stl, ObjC/NS, Java (unstable) • Ridiculously complex syntax (gcc parser) • No native linkers (C++ mangled names) • Old edit/compile/run cycle (some f&c) • Code lives in files • Weak style guidelines (better in Java)

91 92 XCode JUCE GUIs

93 94

IntroJucer Cartwright’s DrJava

95 96 Modern Scripting Languages Python •Wired •Wired • Simple syntax, easy to learn • Simple • Supported on most platforms (what version/libs) • Many libraries (reuse?) • Lots of available libraries (compatibility?) • Widely supported •Tired •Tired • Issues with reuse (finding, reusing) • Syntax (hinders power programmers) • Google is not a coding tool • Not OO (most libs are procedural) • Not uniform OO • Poor performance (simple VM, several options) • “Syntactical sugar” • Too many libraries • Questionable performance • No tools (emacs, spyder, low-level debugger) • Really poor tools, low-level debuggers • “Curse of version 3”

97 98 Spyder Ruby •(See above) •Wired • Simple • Smalltalk-like (blocks as objects) • Web App libraries (RoR) •Tired • Complicated (sweet) syntax • Not uniformly OO • No tools (low-level debugger)

99 100 JetBrains for RoR Julia •Wired • Simple • Very fast JIT VM • MATLab-like math libraries •Tired • Aimed at “technical computing” • Not OO • Linux/Mac only • Few tools (low-level debugger) (coming soon)

101 102

JuliaStudio Block Diagram Compilers •Max/MSP, QuartzComposer, AudioWeaver •Wired • Easy to learn (for simple tasks) • Good performance •Tired • Questionable OO • Issues with reuse • Issues with scalability • Extensible in C (if at all) • Morphs all look the same • Compare to Scratch

103 104 Other Contenders Language-independent IDEs Special-purpose languages • Examples MATLAB/octave • • XCode, VisualStudio, Eclipse, NetBeans SuperCollider • • All are file-based Processing, Wiring • • Integrate with SVN, Mercurial, git, etc. • JavaScript & HTML5 • •Many other recent (scripting) languages •None have code queries (who sends this?) • New LISPs, FP-languages, CSP, logic, etc. •Weak debuggers (fix&continue) • Few are uniformly OO •Programmer as reader • Even fewer address the library & tool issues • Finding, testing, reusing •Better IDEs for (web) scripting languages • Refining, refactoring • Lively/JavaScript, DART •Smalltalk IDE for julia, python or dart?

105 106

So, why do I still If you took it away... program in Smalltalk? •Julia •JavaScript + Lively Kernel •Realtor’s answer: • Dan Ingalls • Productivity, productivity, productivity •NewSpeak • Productivity, reliability, malleability • Strongtalk background, “Self in Squeak” •CS Answer • Translates to Dart (!) (same people, Bracha & Bak) • Development cost •Dart • Reliability, maintainability • “Better JS” (C++-+), complex, ambiguous • Portability (!) • Optional typing (strongtalk, NewSpeak) • Stability (!) • Translates to JS VM • MM libraries • Weak libraries, single-inheritance • Powerful, open-source tools • Pretty good IDE (xref)

107 108 The Lively Kernel Dart

109 110 Newspeak A Call to Action

What features should we all demand of our software development tools?

111 112 A Call to Action A Call to Action •Language demands: •Language demands: • Uniform OO model • Keyword messages • Everything is an object, including: #s, classes, threads, • Avoid f(a, b, c, d, e) closures, Booleans, message-sends, error conditions, ... • e.g., aGraphicsContext copyArea: aShape from: • Class messages (not just for constructors!) aGraphicsContext sourceOffsetX: srcOffsetX y: srcOffsetY • Many ways of sharing: SI/MI, traits, interfaces destinationOffsetX: destOffsetX y: destOffsetY Simple (unambiguous) syntax (1-page BNF) • Extensible (OO) control structures • Including branching, iteration, catch/throw, switch, ... Go easy on the adjectives, reserved words and • • • Flexible exception-handling punctuation • Support for concurrency (would be nice) • Straight-forward to express other paradigms • Explicit style guidelines (obeyed by libraries) (grammars, rules, logic, ...) in the same syntax • Get it right (V3) before you have an installed base!

113 114

A Call to Action A Call to Action Library demands: • Library demands: Consistent, comprehensive & small class libraries • • MVC classes - widgets and app models • Built for programmer-as-reader (doc, examples) • High-level widgets, document model, browser • Same design, naming and formatting style throughout • OO design patterns • Multimedia support (incl. scheduler) • Graphical models • Standard and new • Sound/music models Small set of high-level abstractions • • Others (gesture) E.g., Magnitude, Collection, Stream, Event, DisplayList • • (R/OO)DB support, O/R mapping, NoSQL/JSON Powerful mid-level abstractions • • Proxies and distributed systems • E.g., Number, SequenceableCollection, BufferedStream • • Minimal concrete classes (opt. constructor-only) • Parser-generator and compiler framework • E.g., Float, Array, FileStream, Chord • Compiler available at run-time

115 116 A Call to Action A Call to Action •IDE demands (coding): •IDE demands: • Code lives in hypertext document DB • Inspector framework for operating on objects Debuggers look like code browsers Programmer-as-reader code browsers with full-text • • Fix&continue source code debuggers search, cross-ref, explainers, formatting, spell • Workspace (VI) development/delivery checker, auto-complete, ... • • Dynamic object network in RAM • Maintain method history & diffs • Object DB queries (allInstances) • Easy roll-back of changes • Tools are open-source and extensible • Unit of change is a single method • Easy to customize browsers • Support for multi-person team programming • Easy to build new inspectors & editors • Tools work; tools scale

117 118

Thank you! Q & A Conclusions

•Object-Oriented is not Enough!

•The computer revolution ... - hasn’t happened yet.

119 120