Smalltalk: Swimming with the fish
simberon.blogspot.nl
simberon.blogspot.nl
(I’m mostly speaking out of my experience with VisualWorks, a commercial Smalltalk implementation, but other implementations are similar.)
I would greatly recommend everyone to give Smalltalk a try. The IDEs are pretty ugly and cumbersome, but don’t let that put you off. Get a feeling of the minimalism of the programming language and the pure form of object orientation. Dig through the code of the standard library — it’s quite easy — and check out the implementations of TrueClass, FalseClass, BlockClosure etc.
Unfortunately, many parts of the Smalltalk IDEs are horribly outdated and make Smalltalk a very poor choice of environment to use for production code.
Smalltalk lives in its own little world, and the tools that you’d normally use during day-to-day development are integrated in the IDE, and there is virtually no possibility of using external tools. The text editors are pretty bad, and you can’t use vim or emacs or Sublime Text. The Smalltalk VCSes are particularly horrible. For version control, you need to use systems such as Monticello or Store, both of which make me cringe just thinking about them again.
I also feel that Smalltalk coders get locked in into their environment. Many Smalltalkers that I have met are quite unfamiliar with what is happening in the outside world. Most of them have never heard of git, for example (and quite a few did not know what Subversion was). When an interesting technology enters the Smalltalk world, people seem to rush to reimplement it in Smalltalk (yes, there is STON — Smalltalk Object Notation).
These were the main reasons why I quit my Smalltalk job. A sad decision, but one that was unavoidable in the long run.
Smalltalk is a nice language and has IDEs with some very nice features that I would love to see in other environments, but it is also severely lagging behind in many other areas. I would like the Smalltalk community to be more aware of what is happening outside and build bridges. Without that mindset, I feel Smalltalk will simply fade out completely.
Source: I used to be a professional Smalltalker for almost three years.
Source: professional Smalltalker for about four years (fifteen years ago)
My opinion is the opposite: I find the IDE in Pharo to be simple and very elegant, far more human-friendly than any I've seen in 'mainstream' languages. And this version of Smalltalk is under heavy development, with a push towards even greater cohesion. This small corner of computing is seething with hot, cutting-edge activity.
> The text editors are pretty bad
Well, you ought to know that Smalltalk is focused on relatively small snippets of code, held together in consistent OO structures. There's hardly any point in fancy text-editing features when your methods are generally 8-12 lines long!
This! And also, in Pharo 3.0 there's being a huge push towards better text editing, although I've never ever needed more than what Pharo 1.0 did already provide...
You don't work with text in Smalltalk.
Any amount of text is still text, and Emacs excels at text editing.
I really hope this project pans out, because I would love to be able to program in Smalltalk for practical purposes.
(In fact, even the thought of being able to write a single application in both Lisp (Clojure) and Smalltalk (Redline) is making me giddy. We're still a long ways from this dream, but perhaps it'll be possible one day.)
My complaint is that neither of these things is coming back in a relevant way.
Perhaps the biggest shift in software engineering in the last decade or two is the fact that no one writes entire systems anymore. We've moved to a system of (somewhat!) interchangeable parts. If your thoughtfully constructed, delicately handcrafted utopia doesn't play well with tools the user is used to and libraries the user needs, no one will use it in the real world.
Smalltalk, though a wonderful entire system in the 80's, hasn't kept up with computing progress. Most of its best features made it into other languages (Ruby and Obj-C are the premier examples), languages which aren't so opinionated about what OS you run, what IDE you're using, what language adjacent programs are written in, etc.
Much like Lisp Machines, the rest is left to rot, and incite wistful blog posts by old hands. And pretty much everyone else ships code in other languages.
However, the main point is that back then you haven't got HN, Reddit and the blogs of today.
As such not many geeks were fortunate enough to know and understand those systems, as consequence you have a legion of developers that cannot understand the beauty of those systems.
That's unfortunate. If we kept at it, we could have discovered much simpler ways of doing things than the current accumulation of leaky abstractions over leaky abstractions in a rather disintegrated environment. We can do better: http://www.vpri.org/pdf/tr2011004_steps11.pdf
Where is this directed? It sounds like a criticism of Lisp, Forth, Self, etc, but please correct. The fact that the ignorant masses flocked to C and Unix doesn't grant them one _iota_ of merit. C isn't even a good low-level language. And look at the most popular platform of them all - the web browser, if you want a good laugh.
When a young programmer asks me for advice about the next language to learn is, my advice is to go for the language that feels most alien. C++ won't enlighten a Java programmer significantly. Forth will.
> I even learned Java before giving C++ a try
- null terminated strings
- plain vectors
- manual management of resources (memory, files, db connections, locks...)
- C style casts
- pre-processor instead of using inline/const/templates
- the C subset of C++ it is also not 100% compatible with C, there are a few cases with different semantics
- since C99, new language constructs are added via macros, instead of keywords
- no use of namespaces
- lack of safety of parameters that can be changed (pointer vs reference parameters)
The best way to learn C++ is to read books like "Modern C++ Design", "Programming -- Principles and Practice Using C++" and the recently published "Tour of C++".
"Modern C++ Design" is really intended for advanced C++ programmers only. I don't feel it gives a very good impression of the language to new developers - there are so many awful hacks in that book.
It's the sort of thing that you should hold off on until you have the experience with the language necessary to be wise about when such techniques are appropriate.
But, again, there may be other languages more worthy of your effort.
I only leaned Java before touching C++ again because of my peculiar introduction to OOP and because I discarded the language after considering it an inelegant kludge, but, compared to Smalltalk, what language isn't?
And, finally, I decided to swallow my pride and learn C++ because I wanted to be part of the Brazilian electronic voting system projecy. Now, every ballot runs some C++ code I wrote.
If the company is that cool, give it a shot.
Perhaps systems like Smalltalk still have something to teach us?
Isn't Light Table essentially an effort to re-create the Smalltalk environment for modern languages?
I think one could make the case that Android shares many design decisions with a "Smalltalk machine". And the same actually goes for iOS, as objective-c is basically Smalltalk bolted on to c.
And then there is javascript that's modelled after Self -- so by extention chrome OS is also similar to a "Smalltalk machine".
Now why all these systems end up with some bastardized crappy programming languages rather than just using Smalltalk -- that I don't know.
The exception might be the one-laptop-per-child project.
So, I think it's wrong to say "it's not coming back" -- even java (for set-top boxes and smart devices) was an attempt at "bringing it back".
If anything, it seems these systems keep being reinvented.
Because Worse is Better[1]. For example Internet and the Web is a bastardized version of Xanadu Project[2]. HTML is a bastardized version of XML or XHTML. Worse is here now, when Better gets here, it's not Better anymore, only marginally more useful. That or it turns out the benefits Better has aren't that important or are highly impractical.
Javascript was probably born out of Not Invented Here. Worse Is Better only contributed the curly braces from C, and the continued use of the first widely known scripting engine.
If The Right Thing is already there, Worse Is Better simply doesn't win without exterior help. Worse is better only because it's first. And even so…
> when Better gets here, it's not Better anymore, only marginally more useful.
I would say perceived as marginally more useful in the short term. This is a point where Worse easily looks Better, but whether it is is more debatable.
Worse is Better is omnipresent. Linux vs Minix vs BeOS vs Windows is example of Linux despite being bad relatively, simply winning out (on servers) due to its developer base and losing to Windows that despite numerous faults/warts won the desktop market by a large margin.
When I said Right Thing being here, I didn't mean existence, but presence. Right thing may exist in heads of few masters that know it super well, but them being unable or unwilling to spread it dooms the Right Thing. A Worse Thing that spreads far and wide will win and has always won.
Xanadu vs Internet
Linux vs BeOS
MacOS vs Windows
Lisp/Smalltalk vs C
You're being unfair: you compare a Javascript interpreter against a Smalltalk environment. Obviously, If I were in a rush, I would start with a simple interpreter first.
Realistically, if you don't really care about performance (I doubt Brendan Eich did at the time), implementing a JavaScript interpreter is neither easier nor harder than implementing a Lisp or Smalltalk or Self interpreter. I maintain that ease of implementation simply was not an influential factor either way.
Therefore, Javascript was invented for other reasons. My best guess is, Brendan Eich wanted his language to be non-intimidating to C, C++, and Java users. Apparently, it worked.
Oh. That is a typical "Worse is Better".
Okay, I retract. "Worse is Better" is an excellent explanation for Javascript. There are just other kinds of short term benefits persisting through time than the mere ease of implementation.
As for actually implementing a smaltalk interpreter, it can now be done in 300 lines: http://www.youtube.com/watch?v=EGeN2IC7N0Q (I believe he used Maru http://piumarta.com/software/maru/ ) With current techniques, a language specialist can implement Smalltalk in a day.
I'm not that strong, though. It could take me from a week to a month, depending on how much I need to learn. (Parsing the syntax is easy, but I'm less sure about the semantics.)
No, HTML was an SGML language (XHTML is of course an XML language). HTML5 is more of an "HTML"-like language...
SGML, if anything, is more powerful than XML -- but XML is a great effort to simplify SGML while maintaining most of the power.
For other SGML languages than HTML, look for docbook (which now also exist in an XML dress).
Saying Smalltalk hasn't kept up with computing progress is an old argument that doesn't make sense anymore.
No. A few of them have, usually in needlessly restricted and nigh-broken forms (Ruby's blocks are a pale and pitiful shadow of Smalltalk's). I've yet to see message cascading or conditions outside of lisps and smalltalk.
While I really like Smalltalk, for some reason it does not work for me as a web development platform (and the web is my platform), or maybe I just don't grasp it.
I tried Seaside (http://www.seaside.st/) but the URLs it generates are not acceptable (unfortunately) and I find their component system quite complex. I hope someday I will find way to use the techniques behind Smalltalk (live environment, object model) in a browser or web environment. Maybe Amber will develop into something I can work with. I really hope so. Any suggestions anyone?
I love the idea of Smalltalk, but it also never stuck for me. I think I just prefer to learn from books than through milling around in the image. All the great minds in Smalltalk seem to be self-driven autodidacts. I'm not.
I'm pretty good at Haskell and Prolog though, so I think it works out in the end. I'm also not good at Lisp or Forth. :)
Although Iliad is not about generating clean URLs (it can, though), but more about being small and understandable, plus having Ajax for free and being pragmatic.
http://www.usingenglish.com/reference/idioms/swim+with+the+f...
"[He] sleep[s] with the fishes" is the canonical form of the idiom, whose presence in the common vernacular originates with its use in Puzo's "The Godfather"; in my entire life as a native US English speaker, I have never once heard "swim with the fishes" used with anything remotely resembling the same meaning. (It doesn't even make sense! Dead things don't swim; they can't, because they're dead.)
At least I think that is what the author is trying to convey.
The trouble is that just explaining the mechanics of it doesn't really capture the experience, and if you talk about the experience on its own, you end up talking about, er, fishes. Which is to say that it's an almost useless analogy, but one that I don't know how to better.
Still, using Python to pay the bills isn't so bad...
Well, and pdb isn't bad.
Granted, I have only the most trivial experience with Smalltalk; I'm pretty sure at least some of the concepts I have in mind here are entirely meaningless in that context, but I wonder if it would be fair nonetheless to consider the modern browser Javascript environment, for example Firefox with Firebug and a proper REPL instead of the single-line console, as potentially possessing at least some of the flexibility a Smalltalker considers de rigeur.
On the other hand, if you wanted to build, for example, an object-graph generator in pure Javascript, I don't think you could do so, at least not one worth having; unless I'm very much mistaken, Javascript's reflection facilities don't suffice to allow one thing to notice when another thing changes, unless the latter thing explicitly notifies the former of the change. So you'd have what would be essentially static analysis on running code; you could recursively walk properties from the global object on down, following references where necessary, but it'd be dog-slow in modern JS implementations; worse, there'd be no way to keep it synchronized with the actual state of the objects to which it refers, short of rewalking everything to spot the changes, which would be ugly in theory and unusable in practice. So it's probably also accurate to say that the modern browser Javascript environment offers no immediate prospect of attaining anything remotely resembling the facilities a Smalltalker considers de rigeur.
Which is a shame, because what I've seen of Smalltalk has been impressive in the extreme, especially by contrast to the tools whose use I can actually justify in my professional life.
For instance, let's say I have an Employee object that throws an exception. Clearly, if inspect that object and change the name member, Bob from accounting's name doesn't suddenly change to Gary. So I'm not acting directly on the object, but a representation of the object.
However, then it just sounds like Smalltalk lets me play with a set of bits in memory that represent the Bob object. Most debuggers I've worked with already allow me to do that in some fashion. Yet, this is always touted as one of the great, unique features of Smalltalk. There must be something that I'm missing, but I can't see what.
You can change anything at any time and those changes are made persistent.
This is one reason why images are prunned for deployment.
You can only avoid pruning for server side applications.
Yes it does.
> So I'm not acting directly on the object, but a representation of the object.
No, that is the object. Now, if it's backed by a relational database what you're saying might be true, but then you just change the name and then tell the object to save.
You're thinking too data centric as if only persistent objects exist, so let me explain. Smalltalk is image based, you're working in the live runtime, not on files that later become the live runtime.
Forget the debugger, it has nothing to do with the debugger. I can open up a workspace and say "SomeClass allInstances", highlight the statement, press a key to inspect it and up pops a list of all instances of that class in a window. I can then click any instance in that list and inspect it and get a window for that object where I can see and modify the state of that object. That object could be a session object for a user on the website at that moment, or it could be the application itself, or any other object in the system.
In most languages using the debugger is the only time you get to play with the running program, in Smalltalk there is only the running program and you're in it all the time. I can highlight a method name, hit one key, and be taken to the source for any method in the system including those that give me that ability; I could change code that breaks the IDE that I'm working in if I wanted. I could inspect the running IDE and change the color of the window tile while I'm using it. I can do all of this from the IDE or workspace without ever invoking a debugger.
Here's a very simple way to grok it, it's just like SQL in the sense that a database is a running image and you can query user table or even system tables that control how the server itself functions. If you change a view, clients of that view see the change instantly; you don't have to restart the database to see your code changes because you are working on the running server, not a text file that when ran becomes the server.
Smalltalk is the same, you write code in the running image and changes are seen immediately by clients using that server. This is the same as a Lisp hacker connecting Emacs to a running Lisp instance, say the one that hosts this site, and making changes while people are using the site.
Smalltalk is optimized for code navigation like no other environment I've ever seen. When I work in Ruby or frankly any other language, I have to pull up the documentation for the String class to see what methods it supports; I've never had to do that in Smalltalk, I just go to the String class and look at what methods it supports directly assuming I don't see what I'm looking for in the intellisense. If I want to extend it, I add a method to it right there, but categorize it with my package so it's part of my project and not part of String for the purposes of source control.
If I want to see how a string works, I can simply highlight a string in a workspace and inspect that instance of it in a window, and then play with it, sending messages to it to see how it reacts, or if it errors, or whatever. Pretty much anywhere in the system you can simply highlight some code and press a key to evaluate it allowing you to hack things together by trial and error much much faster than if all you have is a REPL or worse only the debugger.
A Smalltalk workspace is pretty much exactly like working in a SQL workspace; write some code, highlight it, run it, see what happens. But in Smalltalk, you're not limited to a result window, you might have a transcript up, but you also might have 10 inspectors open on all the objects you're playing with in a workspace so you can see them and watch their state change while you're playing with the code.
A Smalltalk image is a running object database, not a transactional one, you don't generally want to use it for persistence, however, you can and this is fantastic when prototyping. You can write the entire UI using the image as the database and put off the persistence decision until your app is shaken out and you know what you really want to do. I can just hang an OrderedCollection off my class and use it as the database. I could then query it like so:
Customer db select: [:e | e name = 'Joe'
and: [ e age > 3 ]].
> > Clearly, if inspect that object and change the name member, Bob from accounting's name doesn't suddenly change to Gary.
> Yes it does.
Okay. either I wasn't clear in my analogy or I'm actually further away from understanding Smalltalk than I thought. Let me put it a different way: If I open the Bob object in the inspector and set the "deceased" member to "true", will Bob claw his way out of his casket?
A lot of my confusion about whether it's the object or the representation of the object comes from this level. I tried to learn Smalltalk a few years ago. We started off with some GUI work and the teacher was quite adamant that we understand that the button on the screen was the object and not just a visual representation of the object.
If I'm understand what you've written properly, then the Smalltalk language isn't nearly as important as the Smalltalk environment. For a comparison point, during my day job, I write a large amount of Python in Emacs. This code is for an application that runs in a REPL. Emacs gives the the ability to highlight code and run it. I can call the "help" function on an object to see its documentation or the "dir" function to view all its members and methods. I can load code at run time and patch new members onto classes or objects.
Of course, that's the classic Blub programmer paragraph. At the very least, Smalltalk sounds like a nice environment and I'm jealous of having multiple, independent object inspectors. I'm also sure that the Smalltalk documentation is better written than what I usually get from "help". Still, I suspect that I'm missing something. Especially if I'm still wrong about what it means to work directly on an object.
For example, when you want to modify an object in Smalltalk, the system generates a representation of it - with methods and instance variables - and you modify the representation with the system text editor. Then you ask to system to apply the changes to the object. When the changes are applied, that is it, no source files are needed anymore. The system continues to live like this. When your "programming session" is over, you save the whole image, and starts it again on the next day. No compilation of whole system is ever performed. It is said that some objects in a standard Smalltalk image have been alive for several years... they are only saved and used, never recompiled or modified.
No prob.
> If I open the Bob object in the inspector and set the "deceased" member to "true", will Bob claw his way out of his casket?
Oh, I see what you meant, no of course not as the Bob object itself is a representation of the real world Bob, however if you did that your system and all of its clients would immediately think Bob was deceased.
> A lot of my confusion about whether it's the object or the representation of the object comes from this level.
I think you might be confusing classes with objects; objects are instances of a class and thus only exist at runtime, which is all the time in Smalltalk (and Lisp) and at debug time for other languages.
The representation you work on is the class, in most languages the class is a source file you edit that at runtime can have instances of itself created. In Smalltalk, the class itself is just another object in the system, you create subclasses and instances by sending messages to it; there are no source files. You don't work on source files, you work on live objects, the IDE doesn't edit files, it edits method objects from the classes in the running system. You can reflect, inspect, and browse the live running class system just like the IDE does.
> If I'm understand what you've written properly, then the Smalltalk language isn't nearly as important as the Smalltalk environment.
Correct, but don't let that make you think the language isn't important as well. Smalltalk the language is amazing in a similar fashion to how Lisp is amazing; the syntax is incredibly flexible and simple.
The proof of this is that Smalltalk control structures, your if/then/else/switch/while/for/etc are not part of the language itself (discounting VM optimizations), they are simply implemented in the standard library using objects, polymorphism, and lots of higher order functions.
Just as Lisp macro's enable Lispers to add native control structures because Lisp itself uses the same mechanism, Smalltalk's simple lambda syntax [ code ] or [:arg | arg isX ] and special method naming syntax enable Smalltalk'ers to add native control structures because Smalltalk the language uses the same mechanism.
For example, you can't add your own "if" to Ruby that looks and works just like the built in "if", but you could in Smalltalk because that's how it was done in the first place. It's all library, classes and objects (functions in Lisp) and everything is built on top of that. Very few languages work this way, most have special keywords for control structures and you can't add to them.
> For a comparison point, during my day job, I write a large amount of Python in Emacs.
Great, also a great little language. Ah... but you're using Emacs, if you aren't aware that's just a Lisp image exactly the same thing as a Smalltalk image. You know exactly what working in an image is like, you do it daily.
> This code is for an application that runs in a REPL. Emacs gives the the ability to highlight code and run it.
Yup, Emacs is an image.
> I can call the "help" function on an object
On an object, or do you mean on a class in a file. Vastly different things. Object and class are not interchangeable words to use in this context.
> to see its documentation or the "dir" function to view all its members and methods.
I think you're talking about classes, not objects. And does this also include all source for the standard library as well, not just your application?
> I can load code at run time and patch new members onto classes or objects.
Yup, Python like Smalltalk is a very flexible dynamic language, but it didn't come out till a decade later and still isn't as flexible.
> Of course, that's the classic Blub programmer paragraph.
Yup, but at least you're aware of that, so you've un-blubbed IMHO.
> At the very least, Smalltalk sounds like a nice environment and I'm jealous of having multiple, independent object inspectors.
And multiple IDE's and multiple workspaces, windows all over the place.
> I'm also sure that the Smalltalk documentation is better written than what I usually get from "help".
Actually, honestly, you'll find very little documentation to speak of for most Smalltalk code; Smalltalker's tend to just read the source, it's there, it's simple, the average method length in a typical image last time I looked was about 7-10 lines of code, and you can just create instances of anything on the fly and play with them to see how they work, or find existing running instances and play with them.
> Still, I suspect that I'm missing something. Especially if I'm still wrong about what it means to work directly on an object.
Yup, but I think you'll understand by the time you read this line based on your Emacs use alone.
If all your experience and knowledge is born of Unix and the web, you don't really have available the necessary concepts to think about how a Smalltalk, or even a Lisp, actually works -- I know this because all of my experience and knowledge were born of Unix and the web, until recently, when I took it into my head to learn Lisp and also to gain at least a passing familiarity with Smalltalk. The difference is amazing -- in the preface of the UNIX-HATERS Handbook, written mostly by veterans of the Lisp years at SAIL, our modern computing environment is described thusly, by Ken Pier of Xerox PARC:
"I liken starting one's computing career with Unix, say as an undergraduate, to being born in East Africa. It is intolerably hot, your body is covered with lice and flies, you are malnourished and you suffer from numerous curable diseases. But, as far as young East Africans can tell, this is simply the natural condition and they live within it. By the time they find out differently, it is too late. They already think that the writing of shell scripts is a natural act."
Which I thought was hyperbole, too, until I spent some time discovering what sort of environment Pier and the SAIL folk took for granted. I don't unreservedly recommend the experiment; I earn my living in Pier's "East Africa", and sometimes I think I'd be better off if I didn't know how bad I have it. But I can certainly say that if you haven't tried it for yourself, you don't begin to know what you're missing.
The last time that I tried to learn Smalltalk, it was drilled into me that Smalltalk works directly with objects and not just their representations. For instance, the collection of black pixels on the screen was the Mouse object itself and not just a manifestation of a Mouse object somewhere in memory. A large amount of my confusion has possibly come from those lessons.
I agree that Lisp is an enlightening experience. I spent two years using Scheme as my primary programming language at work. Then again, I may just be stuck as a Blub programmer. I spent a year focused on Common Lisp, but never found any use for SLIME, despite using Emacs exclusively.
Yes and no, respectively.
Perhaps a heavily contrived example might help: Consider a system in which there is exactly one representation of an object member's value, which is stored in that object; when you call an accessor method, what you actually get is a reference, which is instantiated with an observer attached that listens for a notional "change" event, fired whenever the referred value is modified, and whose event handler updates whatever context exists around the reference, regardless of its nature, so that the displayed value matches that newly assigned to the object member.
...and now perhaps you can see why people familiar with Smalltalk think so highly of it; what in, for example, Javascript, would require an enormous amount of manual infrastructure and completely fail to generalize, in Smalltalk happens entirely transparently. It's not so much that you don't have to think about it; it's that there's nothing there to think about.
> I spent a year focused on Common Lisp, but never found any use for SLIME, despite using Emacs exclusively.
And now you've lost me. How can this possibly be the case? What was your Lisp workflow like? I mean, I can understand not getting the appeal of Lisp if you're just talking to the REPL and not working in an actual Lisp environment of the sort you get with Emacs Lisp or SLIME, but I have trouble understanding how anyone could work with those tools for a year without recognizing their potential.
Look, a cosmetic bug in this window. Right click on it, click Inspect. Looks like one of the properties has the wrong value. Edit the property from the inspector, fix the problem. The application was running the whole time and now is fixed.
An impressive thing you can do with Fuel is serialize and deserialize the exception with all state. Somebody blows up your web application. You wrote a bit of code to catch unhandled exceptions and export them with Fuel. You download the binary to your local computer and deserialize it in your live Smalltalk image. You see the debugger window pop up and can examine all the state when the error happened as if it popped up locally. See, examine, change the code, all of it live the whole time. (I don't know if this is done in practice much, but it's pretty normal to run a headless Smalltalk image and connect to it over VNC when you need to debug something).
To sum up, everything is live all the time in Smalltalk, and you can interactively change all the actual running instances, both code and data, at any time without interrupting anything.
It's really much more pleasant than shipping text files and interpreters all over the place and sorting through logfiles and tracebacks when things go south.
These notebook interfaces are REPLs, but they're a little more user friendly in the sense that you can edit history in place instead of doing a history completion and then evaluating an additional line.
Has anybody had any experience with these notebook interfaces as well as the smalltalk environment and can give a rundown of the differences?
I have no clue what it means to live amongst your objects and touch and feel and turn and taste them. That article didn't really explain what that means, but I'll take him at his word.
Crap article.
"Unfortunately, no one can be told what the Matrix is. You have to see it for yourself."
"After this, there is no turning back. You take the blue pill - the story ends, you wake up in your bed and believe whatever you want to believe. You take the red pill - you stay in Wonderland and I show you how deep the rabbit-hole goes."
Try the red pill... (And think of turtles rather than rabbits!)
In a live environment it is easy to make experimentations because you can get very quick feedbacks, and there is no need to switch between modes like development to execution or execution to development. Catching and fixing certain bugs is also easier as I showed before.
I think there is a need for this kind of development, that's why people try implementing code hotswapping and class reloading capabilities in various programming environemnts. But still most of them are just limited workarounds compared to smalltalk where live coding works fine for decades.