Smalltalk simplicity and consistency vs. other languages (2022) [video]

Simplicity, Syntax, and Trade-offs

• Smalltalk’s syntax is extremely minimal and uniform, but commenters stress this doesn’t automatically make code easier to read/write or compilers easy to optimize.
• Blocks and message-passing unify control structures with normal method calls, but require special compiler cases (e.g., inlining ifTrue: / whileTrue:) to avoid major slowdowns.
• The “everything is a message to a receiver” model pushes design toward distributing behavior across class hierarchies/traits, which some see as elegant and others as adding complexity vs simple functions in other languages.
• Familiarity strongly influences what feels “simple”; a language that is too minimal can complicate solutions.

Performance and VM Optimization

• There is lively debate over why Smalltalk VMs historically lag high-performance JS engines.
• One side attributes it partly to language/VM design (e.g., blocks, dynamic dispatch) being harder to JIT well, comparing Smalltalk’s trajectory to Python’s.
• Others argue performance differences are mostly about investment: JS has large, well-funded teams; OpenSmalltalk is volunteer-driven. Using Squeak/Pharo as a performance benchmark is called misleading.
• Examples are cited of high-performance Smalltalk-like systems (Self, Strongtalk, Truffle/Graal-based SOM variants, TruffleSqueak) that can match or beat JS on some benchmarks, challenging “Smalltalk is slow” claims.
• For Python, the underlying reasons for optimization difficulty are described as unclear; CPython’s tight coupling to C extensions is mentioned but not resolved.

Live Programming Environments

• Many are fascinated by Smalltalk’s image-based, live environment where code, GUI, debugger, and tools are all integrated and always running.
• This is contrasted with mainstream workflows that require rebuilding/restarting, seen as a step backward.
• Emacs and Lisp/Interlisp systems are mentioned as spiritually similar (extensible, live, image-based history) but not identical in experience; Smalltalk is seen as more coherent, Emacs more “kludgy.”
• Downsides: modern Smalltalk environments can be heavy (e.g., 1GB+ RAM) and awkward to deploy because shipping the VM/image is required.

Practicality, Tooling, and Project Experience

• Anecdotes describe impressive productivity and tooling in Smalltalk systems (OO databases, workflow engines, IDE-embedded automation).
• Counter-anecdote: a large secret Smalltalk project that produced almost nothing demoable; language wasn’t the only issue, but secrecy, lack of vetting, and historical SCM/configuration difficulties in Smalltalk played a role.
• Concerns raised about modern Smalltalk practicality: perceived lack of batteries-included libraries, weak or absent multithreading in common FOSS implementations, and clunky UIs (tiny editors, mouse-centric workflows).
• Others note earlier commercial Smalltalks were “batteries included” for their era; what’s practical varies by decade.

Language Philosophy and Career Reality

• Some participants feel mainstream languages (Python, C++, Java) are far less pleasant or expressive than Smalltalk, Lisp, F#, Elixir, etc., but are forced to use them for career reasons.
• Advice given:
  • Prototype in your preferred language and demonstrate dramatic productivity/value to influence stack choices.
  • Be prepared to teach coworkers if you introduce a niche language.
  • Alternatively, embrace popular tools but apply ideas from “better” languages in design style and abstractions.
• There’s tension between loving tools vs focusing on problem-solving:
  • One camp says tool aesthetics are a distraction; effectiveness is what matters.
  • Another argues high-quality tools “dissolve” problems and that mastery of tools is crucial.
  • Some suggest a middle ground: don’t be romantically attached to tools, but don’t ignore their impact either.

Comparisons to Other Languages and Systems

• Smalltalk is repeatedly compared to:
  • Lisp and older Lisp machines/Interlisp systems (images, GC, interactive development).
  • JS, Python, Ruby, and dynamic dispatch models; dictionary-based method lookup is seen as both powerful and a performance drag.
  • Tcl and GNU Smalltalk as scripting options; GNU Smalltalk is characterized as more “Smalltalk-flavored scripting” than full Smalltalk environment, with questionable maintenance status.
• “Homoiconicity” is debated:
  • Some claim Smalltalk is homoiconic like Lisp; others argue that in compiled Lisps and modern environments, the classic “code as data with same representation” notion doesn’t really apply.

Learning, Minimal Setups, and Experiments

• People request more “live coding” Smalltalk videos; links are shared to Pharo tutorials, game/live-editing talks, and introductory Smalltalk demos.
• Glamorous Toolkit (on Pharo) is highlighted as a modern “moldable development” environment where the documentation itself is live, editable code.
• Some want ultra-minimal Squeak setups (no graphics/sound, REPL-only on small devices like Raspberry Pi Zero); this is described as non-trivial, with no simple, documented path in the thread.
• Ideas are floated for:
  • A Smalltalk-like system on the Erlang/Elixir BEAM VM to gain concurrency and distribution.
  • Using JS VMs as deployment targets for Smalltalk (e.g., squeak.js).
  • Considering Objective-C (inspired by Smalltalk) as a more practical dynamic alternative today; this is mentioned but not substantially discussed.