4 ms·

The article explains how you can be productive. It's mostly in the "live coding/debugging" environment, which dramatically shortens the edit-test-debug cycle. T

• groovy2shoes 10y ago
  > Beauty is in the eye of the beholder I think this is what it comes down to in the end. I don't find anything about it beautiful, from the aesthetics to the workflow to the isolation from the rest of the system. But I'm coming to realize thanks to the massive response to my comment why someone else might find any or all of those things beautiful, so thank you for that. I find it interesting that you compare it favorably against Eclipse, considering that Eclipse is a direct descendant of IBM's VisualAge Smalltalk environment. Would you mind going into more detail why it is that the Squeak or Pharo environment is better for you than Eclipse? > In practice, you don't need the full power of Vim or Emacs in a programming environment where you're ever only dealing with small methods and where everything is laid out neatly in the System or Class Browser. I love Vim, but I don't miss it here. I disagree, and I think that dealing with a well-organized codebase composed of cohesive modules each containing an array of small methods (or equivalent) is an area (though far from the only one) where Emacs and Vim shine, especially when making use of multiple buffers, windows, netrw/dired-mode, wildmode/wildmenu, something like ctags/etags, registers, marks, ... the list goes on and on. I have a feeling that if you're not missing Vim or Emacs when using the Squeak/Pharo environment, you likely weren't making full use of Vim's or Emacs's power (which is excusable, given the learning curve of the those tools). When I say that I've been using Vim for over 10 years, the implication is not that I've just been getting used to it for 10 years, it's that I've been constantly learning it for 10 years, and even now not a month goes by where I'm not able to more fully utilize its power than before. The only environment I've found that's more powerful/productive for me than Vim has been SLIME with Emacs (I've recently found out about SLIMV and am looking forward to giving it a try, though I tend to have an aversion to using plugins in Vim). In the end, though, I think what it comes down to is the different emphasis on the environments. Whereas Vim and Emacs emphasize navigating and manipulating text, Squeak and Pharo emphasize navigating and manipulating a live environment. I personally loath that style of development because I'm lacking tools to track changes to the product and tools to reproduce the product from a fresh image. But if that style of development has been beneficial for you, then of course a tool like Vim or Emacs isn't going to cut it. To each their own, I suppose.
  • nilram 10y ago
    (Note, I’m not the poster your responding to.) > considering that Eclipse is a direct descendant of IBM's VisualAge Smalltalk environment. I was an active Smalltalker and Java developer in that timeframe and I used both Java and Smalltalk environments. IBM’s titles were "VisualAge for Smalltalk" (VAST) and "VisualAge for Java" (VA Java). They were both built on top of Smalltalk. . In fact, or at least my recollection, the VA Java environment had basically the same code browsers and tools available as the VAST environment, and the word on the street was that building on top of the Smalltalk environment allowed IBM to meet their time-to-market objectives for the Java product. So I have to disagree with the idea that Eclipse is a direct descendant of VisualAge for Smalltalk. The same company was involved, but at best they’re siblings, and really, bastard siblings at that. Eclipse was a "rewrite" of the environment in verb only; it was a new environment in it’s own right and the tools didn’t allow for exploring and debugging existing code, or trying out new code, as well as VA Java did. > I personally loath that style of development because I'm lacking tools to track changes to the product and tools to reproduce the product from a fresh image. Both VisualAge for Smalltalk and Digitalk/V (the first of many subsequent re-writes that avoided Xerox’s licensing fees of Smalltalk-80) could commit "change sets" to an external code repository. Loading those changes to a fresh image would allow reproducing a product predictably, perhaps addressing your objection. I can speak definitively only for the Digitalk/V case, but the resulting image would include the dev tools and for the application, the VM would ensure that only the application code was executed. There was subsequent development (after a merger of Digitalk and it’s competitor, ParcPlace) that would allow creating an application in the more traditional sense, but that was never released. It was rumored that Dolphin Smalltalk had that capability, but that, too, never saw the light of day (as far as I'm aware).
    • groovy2shoes 10y ago
      Thank you for the history lesson. I find this stuff very interesting, but it can be hard to find reliable information except by talking to people who know (I mean, you don't get that kind of detail from typical articles on the Web). That pretty much means we have to piece together a lot of this history by talking to people, which seems strange to me in this day and age given how easily we can record and preserve such information.