5 ms·

This is where my Blub programmer life bites me. I don't understand what you mean by "manipulate objects directly". I can't figure out the right abstraction le

This is where my Blub programmer life bites me. I don't understand what you mean by "manipulate objects directly". I can't figure out the right abstraction level to put it at. 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.

gnaritas 13y ago
> Clearly, if inspect that object and change the name member, Bob from accounting's name doesn't suddenly change to Gary. 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 ]]. Hugely helpful when prototyping to be able to simply avoid the persistence issue.
- rprospero 13y ago
  First off, thank you for your through reply > > 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.
  - coliveira 13y ago
    You are thinking about the separation between source files and the running system, but there is no such thing as a separate source file in Smalltalk. You can generate them if you wish, but it is not necessary. The code, in fact, is just a representation of the real system, which is contained in an image file. 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.
pjmlp 13y ago
It is as if your application is always running inside the debugger. You can change anything at any time and those changes are made persistent. This is one reason why images are prunned for deployment.
- loup-vaillant 13y ago
  Pruned? How do we do that? I mean, how do you distinguish the changes you want to deploy from the changes you want to drop?
  - overgard 13y ago
    Basically it already knows the system/ide classes and pulls them out, and does some code analysis to remove unused bits of code and so on. It's an interactive process, but it's generally pretty smart.
  - gnaritas 13y ago
    Image pruning is really not a good way to do it, it's much better to take a clean base image and load your code into it as part of the deploy process. Pruning a development image is a very old fashioned way to create a production image.
    - pjmlp 13y ago
      That way you cannot prevent regular users to access Smalltalk classes they shouldn't be touching at all. You can only avoid pruning for server side applications.
      - gnaritas 13y ago
        Fair point, but server side apps are really where most Smalltalk is these days.
aaronem 13y ago
What you're missing is that, in Smalltalk, the representation on which you're acting is indistinguishable from the object; in your example, when you change the name member, Bob from Accounting's name does suddenly change to Gary; not only do future accesses of the name member on that object return "Gary", but, for example, if you have an HR management frontend open on Bob when you make the change in the inspector, you'll instantly see the effect there as well. 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.
- rprospero 13y ago
  I understand that changing the name member of the Bob object to Gary will cause it to be Gary in every subsequent member access. Perhaps I've grown spoiled in my old age, but I'd be shocked at any system which didn't have this property. However, if I called out "Hey Gary!" down the hall, would he respond? Would his driver's license still read Bob? 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.

gnaritas 13y ago

> Clearly, if inspect that object and change the name member, Bob from accounting's name doesn't suddenly change to Gary. 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 ]]. Hugely helpful when prototyping to be able to simply avoid the persistence issue.

rprospero 13y ago
First off, thank you for your through reply > > 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.
- coliveira 13y ago
  You are thinking about the separation between source files and the running system, but there is no such thing as a separate source file in Smalltalk. You can generate them if you wish, but it is not necessary. The code, in fact, is just a representation of the real system, which is contained in an image file. 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.

pjmlp 13y ago

It is as if your application is always running inside the debugger. You can change anything at any time and those changes are made persistent. This is one reason why images are prunned for deployment.

loup-vaillant 13y ago
Pruned? How do we do that? I mean, how do you distinguish the changes you want to deploy from the changes you want to drop?
- overgard 13y ago
  Basically it already knows the system/ide classes and pulls them out, and does some code analysis to remove unused bits of code and so on. It's an interactive process, but it's generally pretty smart.
- gnaritas 13y ago
  Image pruning is really not a good way to do it, it's much better to take a clean base image and load your code into it as part of the deploy process. Pruning a development image is a very old fashioned way to create a production image.
  - pjmlp 13y ago
    That way you cannot prevent regular users to access Smalltalk classes they shouldn't be touching at all. You can only avoid pruning for server side applications.
    - gnaritas 13y ago
      Fair point, but server side apps are really where most Smalltalk is these days.

aaronem 13y ago

What you're missing is that, in Smalltalk, the representation on which you're acting is indistinguishable from the object; in your example, when you change the name member, Bob from Accounting's name does suddenly change to Gary; not only do future accesses of the name member on that object return "Gary", but, for example, if you have an HR management frontend open on Bob when you make the change in the inspector, you'll instantly see the effect there as well. 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.

rprospero 13y ago
I understand that changing the name member of the Bob object to Gary will cause it to be Gary in every subsequent member access. Perhaps I've grown spoiled in my old age, but I'd be shocked at any system which didn't have this property. However, if I called out "Hey Gary!" down the hall, would he respond? Would his driver's license still read Bob? 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.