Interesting talk. Smalltalk (like Lisp) has indeed a very simple (i.e. minimal) syntax. But that doesn't necessarily mean that it is also simple to write and read code, or to implement an efficient compiler. E.g. blocks - as great as they are - make inlining very difficult; it eventually took 30 years to implement a VM with decent performance (see <a href="http://software.rochus-keller.ch/are-we-fast-yet_crystal_lua_node_som_pharo_i386_results_2020-12-29.pdf" rel="nofollow">http://software.rochus-keller.ch/are-we-fast-yet_crystal_lua...</a> for the results of <a href="https://github.com/rochus-keller/Som/">https://github.com/rochus-keller/Som/</a> and <a href="https://github.com/rochus-keller/Smalltalk/">https://github.com/rochus-keller/Smalltalk/</a> compared to Cog/OpenSmalltalk). Another language explicitly designed for simplicity is e.g. Oberon, which is statically typed and easier to implement with decent performance.<p>In my experience, at the end of the day, it's more the familiarity with a language that makes it seem "simple". And there is a trade-off between "simplicity" of the language and "simplicity" of the solution; if the language is too minimal, the solution quickly becomes confusing instead, and vice versa.
Seeing an article about Smalltalk with Hernan presenting so up in HN is nice.<p>I worked with Hernan a while ago. We worked in a financial system with very cool things: an OO database, a workflow system that can work locally or remotely transparently, a good model for units and dates, tons of custom tools in the IDE (something that is only possible with Smalltalk IDEs) that allowed us to automate unit test generation, versioning, and database migrations. The last time I saw that level of productivity in any IDE was then.<p>However, Smalltalk is not perfect, and when I see these presentations, I cannot stop thinking that a more balanced discussion is needed.<p>The presentation shows how Smalltalk blocks are uniform with the if/then/while syntax. But that's only part of the history. To support blocks that way, the compiler optimizes those cases and inlines the block unless you do something else. So, while assigning the block to a variable looks the same, it's not executed similarly. That's the beauty of hiding the implementation details. But, sometimes, those details bite you. Most St programmers avoid creating custom "ifThen:else" messages because, in most VMs, that will break.<p>In other words, like any design decision, the simplicity of the "object message" syntax has trade-offs, too. The performance trade-off is fixed by having exceptional cases hidden from most programmers. The other trade-off is the need to always dispatch to a receiver. Compared to Lisp or other functional languages, the need for a receiver dramatically impacts how you design and structure your program. Many things that you can resolve with a polymorphic function need to spread across classes in St. And that introduces the problem of sharing the implementation: class hierarchies, traits, or composition. Resolving those problems with a simple function is refreshing and falls under the statement at the beginning of the talk: the programming language affects how you think about the problem. When I look at the code I wrote back then in Smalltalk or Java, I cannot stop thinking about how the restriction of using classes and methods adds unnecessary complexity.
Story time. When I was a young developer in a database company, my cubicle was next to a section where a team sat. The team consisted 30 to 40 people working on a secret project. Whenever I asked them what they were working on, they said it’s a secret next gen technology. They spoke in secret code and big terms. The only thing I knew was they were using Smalltalk as the language as they weren’t shy in speaking beamingly about it. They work on these powerful workstations with large monitors, a luxury at the time, as the Smalltalk dev studio required them. I thought these were god developers, working with advanced technologies in a covet skunk project.<p>The project went on for couple years. Nobody knew what they were doing, not their goals, their product plan, their features, nor their designs. The only thing we knew was they were using Smalltalk.<p>The high-up forced them to give a demo eventually. The talk was good, on Smalltalk, on OO, and on the landscape of the technologies. When the demo started, it showed a half finished login dialog box but nothing else. They said something about unable to package the code and do a release. Understandably software releases were a big bang process back then. But what about prior releases? Nothing. They didn’t have any finished builds. The talk continued.<p>The project got canceled couple months later.
Worth watching even if you skip to the last couple of minutes, where he tests a Game of Life scenario in a way that is not comparable to anything I've seen done with any other programming language.<p>This power that Smalltalk systems have where the code runs in a GUI that is also the editor/debugger/etc has deeply fascinated me recently.<p>At the same time it makes me kind of sad, because it feels like we're all stuck writing code with a hand tied to our back. Almost makes me think that there's a happy alternative coding universe where the Smalltalk way is the default way, and a couple of weirdos are using separate IDEs/editors and restart their program on every change, or think they're smart if they're running something as primitive as a REPL.<p>The reason why I'm not just diving in and never looking back is that it seems like such a big investment, and that I'm so comfy with my (very) extended Neovim setup. And I'd like to be able to create applications that run without shipping the entire Smalltalk VM. And I'd like to actually understand a tool that I'd have to dive into that deeply, and I think I'll never have the time to truly understand all of the VM, the classes, etc.<p>Maybe instead, I should just create my own language that contains its own code editor. Seems like almost the same time investment, but maybe more satisfying?<p>Sigh...<p>Anyway, here is some other related interesting material:<p>- Bret Victor - Inventing on Principle (Always funny to hear the crowd go nuts when he does the live game editing time thingy.)<p>- Pretty much any Alan Kay video.<p>- Dan Ingalls his "Lively Kernel", which seems to me like it's pretty much the same as a Smalltalk system, but where you code in JavaScript, and it runs in the browser.
I was excited in Smalltalk around 1999, during my Master Thesis. The sad story is Java Hotspot had more technology than ParcplaceDigitalk(Cincom) and kept growing.
I love Smalltalk but Java won, even when it was closed sources.
Try Squeak (or Cuius): it is beautiful,but sadly it has little traction.
I wonder if someone has considered building a modern variant of Smalltalk on top of elixir/erlang.<p>You’d get virtualization, multi threading, scalability, etc.<p>And consider git, DevOps, CI/CD and off we go?
I remember clear as water to this day the feeling when I was a teenager doing C/C++ that it was with Smalltalk the first time I experienced the power of creating software that doesn't give you bad surprises for unknown reasons.
Does anyone have any advice on how to become an auteur software engineer? I've tried visual programming, functional programming, and several others, and they are just so much more enjoyable and powerful (in a specific sense akin to productive) than mainstream languages like Python, C++, etc. But I'm relatively exhausted by having platforms dictated to me by the middle of the bell curve and, frankly, people not experienced. Even as something as simple.and pragmatic as F# or Elixir seems to make people step back from you, as if you're cursed, much less something like Smalltalk. At this point in my career, I have given up and am just going to use Python and C++ like everyone wants you to. It's been a big enough hurdle yo probe that Incan write in Python and C++ despite having used a plethora of languages.<p>So, how do you use these powerful platforms banished to personal projects? How does one get into a position such that you can dictate the platforms used? Is there anyone who has done this?<p>It's an unfortunate case of people having the interesting applications having a very tunnel visioned view of what could be with software.