8 ms·

I've got a bit of the blub paradox going on here so this story is lost on me. Can anyone give me a concrete example of what he's talking about instead of an ab

by tieTYT 13y ago

I've got a bit of the blub paradox going on here so this story is lost on me. Can anyone give me a concrete example of what he's talking about instead of an abstract analogy?

seanmcdirmid 13y ago
In Smalltalk, you can manipulate objects directly rather than just indirectly via code that operates on them. The state of your manipulation is made persistent in smalltalk's image facility. Also, the whole object graph is supposedly better exposed accordingly then what you could get sigh just a plain old debugger. At least I think that is what the author is trying to convey.
- radiowave 13y ago
  It's pretty rare that you'd actually make ad-hoc changes and then rely solely upon persistence to preserve those changes. Ultimately, you'd want to write code to produce the outcome programatically. It's more the case that you play around and do little "what ifs", which helps you crystalize your ideas about what you're trying to implement. 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...
  - yeahbutbut 13y ago
    > Still, using Python to pay the bills isn't so bad... Well, and pdb isn't bad.
    - aaronem 13y ago
      It exists. That's better than the alternative, and if this seems like damning with faint praise, it's because there really isn't anything else good to say on the subject -- the debugging facilities available in any Lisp environment, even Emacs, make those offered by Python (or Perl, or Ruby, or Javascript) look pitiful, and from all I've seen of Smalltalk, it is to Lisp as Lisp is to your interpreted language of choice.
  - aaronem 13y ago
    There's barely any such thing as a debugger, and no such thing as an object graph, and even modifying a function in place is far more complicated than real tools would make it -- but nonetheless, in the sort of browser-based Javascript development I do on an almost daily basis, I sense a faint echo of the je ne sais quoi to which you refer; specifically, iteratively fiddling with a live system until it behaves more like how you want, then baking those changes into the serialized form of it (also called "source code") so that they're incorporated next time the system is instantiated. 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.
- rprospero 13y ago
  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.
fusiongyro 13y ago
The debugger situation with Smalltalk is part of what he's talking about. You're running your application, and some part of your code throws an exception. A window pops up with the stack trace in it. You can inspect all the objects in each frame. "Inspect" in Smalltalk means, see and change the properties, call methods, change the code, clone, see the class hierarchy, etc. You can modify the method that threw the exception right there from the debug window, save it, and resume the method from where it broke. Application proceeds with new code in place and problem solved. 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.
- agentultra 13y ago
  That's roughly how one works in Common Lisp as well (though most implementations don't ship with a graphical environment, so ssh is typical instead of VNC). 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.
  - fusiongyro 13y ago
    Absolutely. There's a deep kinship between them. Prolog can also be used this way, though it doesn't support images, it's a homoiconic language and it's very easy to read and write terms from files.

by tieTYT 13y ago

I've got a bit of the blub paradox going on here so this story is lost on me. Can anyone give me a concrete example of what he's talking about instead of an abstract analogy?

seanmcdirmid 13y ago

In Smalltalk, you can manipulate objects directly rather than just indirectly via code that operates on them. The state of your manipulation is made persistent in smalltalk's image facility. Also, the whole object graph is supposedly better exposed accordingly then what you could get sigh just a plain old debugger. At least I think that is what the author is trying to convey.

radiowave 13y ago
It's pretty rare that you'd actually make ad-hoc changes and then rely solely upon persistence to preserve those changes. Ultimately, you'd want to write code to produce the outcome programatically. It's more the case that you play around and do little "what ifs", which helps you crystalize your ideas about what you're trying to implement. 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...
- yeahbutbut 13y ago
  > Still, using Python to pay the bills isn't so bad... Well, and pdb isn't bad.
  - aaronem 13y ago
    It exists. That's better than the alternative, and if this seems like damning with faint praise, it's because there really isn't anything else good to say on the subject -- the debugging facilities available in any Lisp environment, even Emacs, make those offered by Python (or Perl, or Ruby, or Javascript) look pitiful, and from all I've seen of Smalltalk, it is to Lisp as Lisp is to your interpreted language of choice.
- aaronem 13y ago
  There's barely any such thing as a debugger, and no such thing as an object graph, and even modifying a function in place is far more complicated than real tools would make it -- but nonetheless, in the sort of browser-based Javascript development I do on an almost daily basis, I sense a faint echo of the je ne sais quoi to which you refer; specifically, iteratively fiddling with a live system until it behaves more like how you want, then baking those changes into the serialized form of it (also called "source code") so that they're incorporated next time the system is instantiated. 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.
rprospero 13y ago
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.

fusiongyro 13y ago

The debugger situation with Smalltalk is part of what he's talking about. You're running your application, and some part of your code throws an exception. A window pops up with the stack trace in it. You can inspect all the objects in each frame. "Inspect" in Smalltalk means, see and change the properties, call methods, change the code, clone, see the class hierarchy, etc. You can modify the method that threw the exception right there from the debug window, save it, and resume the method from where it broke. Application proceeds with new code in place and problem solved. 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.

agentultra 13y ago
That's roughly how one works in Common Lisp as well (though most implementations don't ship with a graphical environment, so ssh is typical instead of VNC). 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.
- fusiongyro 13y ago
  Absolutely. There's a deep kinship between them. Prolog can also be used this way, though it doesn't support images, it's a homoiconic language and it's very easy to read and write terms from files.