4 ms·

This should really be "Why every developer should learn Smalltalk." Dan Ingalls gave a keynote at jsconf demoing Lively Kernel, a SmallTalk-like, image-based, i

by asolove 15y ago

This should really be "Why every developer should learn Smalltalk." Dan Ingalls gave a keynote at jsconf demoing Lively Kernel, a SmallTalk-like, image-based, in-browser IDE written in JavaScript. His demo received a standing ovation and was the thing I heard talked about most during the social events. We're obviously not far from being able to have SmallTalk-quality interactions with things we build in the browser. Brent Victor's recent talk has spurred a lot of work on more-interactive development environments, some of them in the browser. I would really like an old SmallTalker to spend some time researching and thinking about the old tools they had: which were valuable, which were more trouble then they were worth? What mistakes did they make that they wish they had done differently? It would be an excellent briefing for the next few years of work on the web.

stcredzero 15y ago
(A small note: it's traditional to not capitalize the t in Smalltalk. Old-timers take that as a signal that text was written by a non-dev.) thinking about the old tools they had: which were valuable, which were more trouble then they were worth? A seasoned Smalltalker would have spent more time talking about the Debugger. I was teaching a Smalltalk class once, and this one student who was a quant from a New York financial firm just spontaneously exclaimed: "This debugger is from God!" It was very fast, responsive, and was "well integrated" with the environment. More on that... EDIT: As I took the time to say elsewhere, there really isn't that much "integration." It's more that the environment is so minimalist that it lacks many barriers present in other environments. Just about every single instance of every object has the equivalent of a REPL, and finding a particular instance in the middle of runtime debugging typically takes just a second. Even the "IDE" really isn't one. (And I should know, because I've written a good portion of a commercial Smalltalk browser.) Aside from the refactoring mechanisms, it's a pretty lightweight and basic browser on objects -- it just so happens they're the meta-level. What mistakes did they make that they wish they had done differently? A big mistake: exorbitant per-seat developer licenses, and positioning as the "secret weapon" of the Fortune 500. Another oft-cited one was the Parcplace/Digitalk merger and the ensuing conflicts. Most of the mistakes had to do with community and how the ecosystem did/didn't interact with the rest of the programming world. Technologically, there was a lot of goodness.
- asolove 15y ago
  Thanks for both the small note and the big suggestion. What did the debugger have that made it "well integrated"? In JavaScript, we have fairly good graphical tools in Chrome. One headache is debugging asynchronous code, and a good debugger could track not just the current call stack, but the deeper "reason" why this code is running, including timers, events, xhr callbacks, and let us jump between those levels as opposed to just the function calls.
  - stcredzero 15y ago
    What did the debugger have that made it "well integrated"? It's more what the environment didn't have. Everything, including almost all of the meta-level (and by almost, I think it's just 3 Classes that are treated specially by the VM) was just an ordinary object. Even throwing an exception was just Smalltalk executing as usual. Basically, there were no barriers. (EDIT: An example mentioned elsewhere -- the integration between the Debugger and Unit Tests. It's not rocket science. You just catch an exception and pass an object to the Debugger.) One headache is debugging asynchronous code, and a good debugger could track not just the current call stack, but the deeper "reason" why this code is running, including timers, events, xhr callbacks, and let us jump between those levels as opposed to just the function calls. It wasn't unusual in VisualWorks for us to have multiple call stack open at the same time. (In fact, some people would put code to evaluate in comments, which could be executed in the midst of another debug session.) Timers, events, Semaphores -- these are all just Objects, subject to the same kind of manipulation. This isn't to say there wasn't some pain around concurrency, because there was that. But a competent programmer felt confident about dealing with it, because she/he had such responsive tools and no barriers to what they could do and see.
    - angersock 15y ago
      What sort of issues did you observe with concurrency and Smalltalk?
      - stcredzero 15y ago
sebastianconcpt 15y ago
We are already having them: 1. go here: http://amber-lang.net/ http://amber-lang.net/ 2. click "Open Browser" 3. start having nerdgasms

by asolove 15y ago

stcredzero 15y ago

(A small note: it's traditional to not capitalize the t in Smalltalk. Old-timers take that as a signal that text was written by a non-dev.) thinking about the old tools they had: which were valuable, which were more trouble then they were worth? A seasoned Smalltalker would have spent more time talking about the Debugger. I was teaching a Smalltalk class once, and this one student who was a quant from a New York financial firm just spontaneously exclaimed: "This debugger is from God!" It was very fast, responsive, and was "well integrated" with the environment. More on that... EDIT: As I took the time to say elsewhere, there really isn't that much "integration." It's more that the environment is so minimalist that it lacks many barriers present in other environments. Just about every single instance of every object has the equivalent of a REPL, and finding a particular instance in the middle of runtime debugging typically takes just a second. Even the "IDE" really isn't one. (And I should know, because I've written a good portion of a commercial Smalltalk browser.) Aside from the refactoring mechanisms, it's a pretty lightweight and basic browser on objects -- it just so happens they're the meta-level. What mistakes did they make that they wish they had done differently? A big mistake: exorbitant per-seat developer licenses, and positioning as the "secret weapon" of the Fortune 500. Another oft-cited one was the Parcplace/Digitalk merger and the ensuing conflicts. Most of the mistakes had to do with community and how the ecosystem did/didn't interact with the rest of the programming world. Technologically, there was a lot of goodness.

asolove 15y ago
Thanks for both the small note and the big suggestion. What did the debugger have that made it "well integrated"? In JavaScript, we have fairly good graphical tools in Chrome. One headache is debugging asynchronous code, and a good debugger could track not just the current call stack, but the deeper "reason" why this code is running, including timers, events, xhr callbacks, and let us jump between those levels as opposed to just the function calls.
- stcredzero 15y ago
  What did the debugger have that made it "well integrated"? It's more what the environment didn't have. Everything, including almost all of the meta-level (and by almost, I think it's just 3 Classes that are treated specially by the VM) was just an ordinary object. Even throwing an exception was just Smalltalk executing as usual. Basically, there were no barriers. (EDIT: An example mentioned elsewhere -- the integration between the Debugger and Unit Tests. It's not rocket science. You just catch an exception and pass an object to the Debugger.) One headache is debugging asynchronous code, and a good debugger could track not just the current call stack, but the deeper "reason" why this code is running, including timers, events, xhr callbacks, and let us jump between those levels as opposed to just the function calls. It wasn't unusual in VisualWorks for us to have multiple call stack open at the same time. (In fact, some people would put code to evaluate in comments, which could be executed in the midst of another debug session.) Timers, events, Semaphores -- these are all just Objects, subject to the same kind of manipulation. This isn't to say there wasn't some pain around concurrency, because there was that. But a competent programmer felt confident about dealing with it, because she/he had such responsive tools and no barriers to what they could do and see.
  - angersock 15y ago
    What sort of issues did you observe with concurrency and Smalltalk?
    - stcredzero 15y ago

sebastianconcpt 15y ago

We are already having them: 1. go here: http://amber-lang.net/ http://amber-lang.net/ 2. click "Open Browser" 3. start having nerdgasms