On 17 January 2012 20:16, Andreas Wacknitz <[email protected]> wrote: > > Am 17.01.2012 um 13:26 schrieb Frank Shearar: > >> On 17 January 2012 03:20, blake <[email protected]> wrote: >>> On Mon, Jan 16, 2012 at 2:43 PM, Frank Shearar <[email protected]> >>> wrote: >>> >>> >>> Frank, >>> >>> I agree with what you said EXCEPT that I don't see the NIH mentality in >>> Smalltalk. What I do see, and have seen a lot of over the years, is people >>> coming in and banging on Smalltalk's differences without taking the time to >>> learn the whys and wherefores. I don't think it's knee-jerk defense so much >>> as a creeping sense that the person complaining maybe isn't in the best >>> position to do so. (And I say this as someone who's been on several sides of >>> the argument.) >> >> I'm aware of the reasons why the NIH arises, and I'm sure that's part >> of why the reaction arises in many other communities. I reserve the >> right to say "ahem, take the time to actually read what the person's >> asking for, because they might actually have good ideas". >> >> And, in particular, Gerry raises concerns _this very list_ has raised. >> Living permanently in the image is _bad_, which is why we're moving to >> Metacello for everything so we can _construct_ an image. Look at > There is a big difference between rescuing artifacts outside the image for > distribution, reuse and storage > and working outside the image. I would like to be able to remotely debug > Smalltalk but not for the price of giving up what we already have. > For me there is a big advantage to have the "living objects world". There > might be alternatives to the image > concept in order to have it. But Eclipse, NetBeans, Emacs, vi and Visual > Studio don't provide anything better. > Each these IDE's are in itself bigger and more complex than Pharo. > These IDE's provide tools to deal with big muds of dead code - quite the > opposite of a "living objects world".
Emacs + SLIME = image-based, interactive development. As image-based as you'd like, at least. Eclipse + Cusp = image-based development: you're connecting to a running Common Lisp image, which you can snapshot and restore any time you like (just like choosing to work in a built image or in a persistent one). IDE and "living world" are orthogonal concerns. frank frank
