I’m very excited to see a headless focus on Pharo.
The image model and tooling is all really interesting, but I think that a big challenge is reproducability, especially when it comes to production systems and multiple colaborators. In a sense, it’s not just development but also operations, with aggregated state.
Hopefully working on headless VMs and things like that will also help with figuring out nicer flows for people used to more traditional development environments. The images have a lot of great development and debugging tools, just hard to square with actually running an application in a server-like environment
I am curious about one thing. The image model of small talk, which is considered one of its strengths is similar to the notebook state in Jupyter notebooks right? How does smalltalk get away from all the associated disadvantages?
What am I missing when people talk about image based development?
The main thing I think you’re missing is that the actual Smalltalk development experience looks nothing like the experience of using Jupyter.
First, Smalltalk, unlike every other language I’m aware of, and unlike Jupyter notebooks, is not written as files. Instead, you work entirely in a tool called the browser, where you can see a list of classes, those classes’ definitions, and a list of all methods within a class. The order in which these classes and methods were defined is irrelevant and invisible. This alone eliminates a huge swath of the notebook complaints.
Second, with few exceptions, the version of objects you’re seeing is always live; while you might have a Workspace (REPL) open with a test and output, that’s visibly very distinct from an Inspector, which shows you the current state of any given variable. The Browser likewise only shows you the current definitions of a class or method. (Previous versions are usually available through what you can think of as a very powerful undo tool.) You thus don’t end up with the current v. previous value skew issues with notebooks.
Notebooks are suffering because they’re trying to bring a kind of Smalltalky experience to a world where code is written linearly in an editor. I agree, that’s tough, and that’s really the underlying issue that the post you linked is hitting. Smalltalk (and Common Lisp environments) instead focus on saying that, if you’re gonna have an image-style situation, you need tooling that focuses on the dynamic nature of the preserved data.
[Edit: all that said, by the way, I think you can make a case that some specifics of how Smalltalk’s image works in relation to its dev environment are a bit off. One way to fix that is the direction Self went with Morphic, where truly everything is live, and direct object manipulation rules the day. The other direction you can go is what Common Lisp and Factor do, which is to say that the image contains code, but not data—in other words, making images more like Java .jars/.NET assemblies/Python .pyc files. The purist in me prefers Self’s approach, the practical part of me prefers Factor/Common Lisp’s.]
I am not sure I understand. Say I have an object A that contains another object B constructed in a particular way as a member. Now, if I edit the constructor of the object B, so that the variables inside B are initialized slightly differently, would it reflect on the already constructed object inside A?
Not in that specific case, no. For other things (e.g., changing variable names, class shape, changing a method definition, etc.), the answer is yes. The best way to think of it: the Smalltalk image is a database, and like most databases, if you change the schema or a stored procedure, that takes effect immediately, but existing data would need to be backfilled or changed. This is exactly the thing I was flagging on why Common Lisp and Factor do not do this: their images are code only, no data. (Or Self, for which the answer to your question is, at least in some cases, actually yes.)
This is different than the main thing highlighted in the article, though. There, the concern wasn’t as much about state existing at all, as much as the fact that the presentation made it look as if the output accurately reflected the input, which wasn’t guaranteed. Thus, in a notebook,
In[123]: x = 5
Out[123]: 5
is potentially not accurately reflecting the real value of x, whereas in Smalltalk, if you went behind the scenes and changed x to, say, 10, then any Inspector on x would also change immediately to 10.
I understood the rest of the post, but I do not get it when you say that in Common Lisp (and Factor), image is code only, and not data. How is that different from storing everything in a file?
Eh, I probably confused things. The images for Factor and Lisp are just compiled code, effectively, albeit stored in a high-level format that’s designed to make debugging a running app a lot easier. That’s why I said they’re equivalent to Java .class files or the like. I was more mentioning that because the word “images” means something very different in Smalltalk/Self v. Common Lisp/Factor-like systems.
So, what does it mean when Factor says it has an image based model? Is it simply saying that it is compiled?
Going back to the original question; My experience is with R, where the image is frequently not a boon, unless one is very careful not to reuse variable names during data cleaning. And the linearity of notebooks isn’t a factor when you work in the command line. R does let you see the current definitions of everything but that is not as helpful as it first seemed to be. Hence my question.
One problem I could see with image files is servicing them; how do you patch several image files, or worse, deal with divergences in each due to patching of behaviour?
Oh man, seeing that screenshot of Jenkins’ pipeline graph in the slides made my week. Knowing that we’ve contributed to the future of Smalltalk, even in the tiniest way imaginable, is pretty bloody great.
I’m very excited to see a headless focus on Pharo.
The image model and tooling is all really interesting, but I think that a big challenge is reproducability, especially when it comes to production systems and multiple colaborators. In a sense, it’s not just development but also operations, with aggregated state.
Hopefully working on headless VMs and things like that will also help with figuring out nicer flows for people used to more traditional development environments. The images have a lot of great development and debugging tools, just hard to square with actually running an application in a server-like environment
I am curious about one thing. The image model of small talk, which is considered one of its strengths is similar to the notebook state in Jupyter notebooks right? How does smalltalk get away from all the associated disadvantages?
What am I missing when people talk about image based development?
The main thing I think you’re missing is that the actual Smalltalk development experience looks nothing like the experience of using Jupyter.
First, Smalltalk, unlike every other language I’m aware of, and unlike Jupyter notebooks, is not written as files. Instead, you work entirely in a tool called the browser, where you can see a list of classes, those classes’ definitions, and a list of all methods within a class. The order in which these classes and methods were defined is irrelevant and invisible. This alone eliminates a huge swath of the notebook complaints.
Second, with few exceptions, the version of objects you’re seeing is always live; while you might have a Workspace (REPL) open with a test and output, that’s visibly very distinct from an Inspector, which shows you the current state of any given variable. The Browser likewise only shows you the current definitions of a class or method. (Previous versions are usually available through what you can think of as a very powerful undo tool.) You thus don’t end up with the current v. previous value skew issues with notebooks.
Notebooks are suffering because they’re trying to bring a kind of Smalltalky experience to a world where code is written linearly in an editor. I agree, that’s tough, and that’s really the underlying issue that the post you linked is hitting. Smalltalk (and Common Lisp environments) instead focus on saying that, if you’re gonna have an image-style situation, you need tooling that focuses on the dynamic nature of the preserved data.
[Edit: all that said, by the way, I think you can make a case that some specifics of how Smalltalk’s image works in relation to its dev environment are a bit off. One way to fix that is the direction Self went with Morphic, where truly everything is live, and direct object manipulation rules the day. The other direction you can go is what Common Lisp and Factor do, which is to say that the image contains code, but not data—in other words, making images more like Java
.jars/.NET assemblies/Python.pycfiles. The purist in me prefers Self’s approach, the practical part of me prefers Factor/Common Lisp’s.]Thank you for your response.
I am not sure I understand. Say I have an object A that contains another object B constructed in a particular way as a member. Now, if I edit the constructor of the object B, so that the variables inside B are initialized slightly differently, would it reflect on the already constructed object inside A?
Not in that specific case, no. For other things (e.g., changing variable names, class shape, changing a method definition, etc.), the answer is yes. The best way to think of it: the Smalltalk image is a database, and like most databases, if you change the schema or a stored procedure, that takes effect immediately, but existing data would need to be backfilled or changed. This is exactly the thing I was flagging on why Common Lisp and Factor do not do this: their images are code only, no data. (Or Self, for which the answer to your question is, at least in some cases, actually yes.)
This is different than the main thing highlighted in the article, though. There, the concern wasn’t as much about state existing at all, as much as the fact that the presentation made it look as if the output accurately reflected the input, which wasn’t guaranteed. Thus, in a notebook,
is potentially not accurately reflecting the real value of
x, whereas in Smalltalk, if you went behind the scenes and changedxto, say,10, then any Inspector onxwould also change immediately to10.Thanks again for the detailed response!
I understood the rest of the post, but I do not get it when you say that in Common Lisp (and Factor), image is code only, and not data. How is that different from storing everything in a file?
Eh, I probably confused things. The images for Factor and Lisp are just compiled code, effectively, albeit stored in a high-level format that’s designed to make debugging a running app a lot easier. That’s why I said they’re equivalent to Java
.classfiles or the like. I was more mentioning that because the word “images” means something very different in Smalltalk/Self v. Common Lisp/Factor-like systems.So, what does it mean when Factor says it has an image based model? Is it simply saying that it is compiled?
Going back to the original question; My experience is with R, where the image is frequently not a boon, unless one is very careful not to reuse variable names during data cleaning. And the linearity of notebooks isn’t a factor when you work in the command line. R does let you see the current definitions of everything but that is not as helpful as it first seemed to be. Hence my question.
Interesting! So if I define a class, instantiate it, change a method definition, and call that method on the class, the new definition is called?
That would indeed be much more useful than a
notebook-like approach.That’s completely correct, and also applies to certain other refactorings on the class (e.g., renaming instance variables or the like).
One problem I could see with image files is servicing them; how do you patch several image files, or worse, deal with divergences in each due to patching of behaviour?
Oh man, seeing that screenshot of Jenkins’ pipeline graph in the slides made my week. Knowing that we’ve contributed to the future of Smalltalk, even in the tiniest way imaginable, is pretty bloody great.