> a Smalltalk environment is basically a blob of tightly coupled classes that all call and delegate to one another, up and down the abstraction chain, and when

> a Smalltalk environment is basically a blob of tightly coupled classes that all call and delegate to one another, up and down the abstraction chain, and when you want to load the application you just snarf all those classes into memory, all at once. I really like the idea of Smalltalk images (which can also be used by some Lisps, and Factor IIRC) since we can tweak and fix values directly, rather than trying to orchestrate a way for the fixed value to be used the next time we restart it. On the other hand, I really like functional programming ideas like immutability (which naively would stop us fixing/tweaking things) and referential transparency (where an expression and its result are interchangable; if we switch out the result, it's no longer interchangable with the expression we wrote). I also like version control, reproducible builds, etc. which seem to be trickier with images. An interesting research area, I suppose :) > So now you've introduced more code, more concepts, and more complexity to do something like send a fucking email which is conceptually simple on paper (and you have a library to handle actually sending the email). I completely agree w.r.t. the insanity of people decoupling all of their classes from each other (my old boss got infected by that idea, it was painful). Still, the particular example of sending an email is a legitimate case of external interaction: whilst it's fine to, for example, create as many Customer/Request/whatever objects as we like during unit tests (since they're internal implementation details) we don't want those tests to be sending actual emails. So if I were writing this, I would have the email-sending-mechanism as a parameter, where we can pass a real email sender when running on production and a dummy argument-swallowing black hole during tests. Note that the interface for an email sender is simply a function (from EmailDetails or whatever, to void). > Congratulations. Welcome to software-architecture NASA. One thing I've found about architecture astronauts is that they obsess over "reusability", yet insist on creating all their own stuff from scratch, rather than reusing what's already provided by the language. For example, from this article: public interface CommunicationMethod { void send(CustomerServiceAnnouncement announcement); } The author has just re-invented the idea of a function! Yet (as Rich Hickey famously said), by inventing a new class they've made themselves incompatible/unusable by all the existing code, infrastructure and tooling that works for functions(/closures/whatever).