> Yeah, it's the usual condescending "If you don't see the stupendousness of our approach, it's because you're not enlightened yet!" that we also get from Lisp and Haskell types. Spare us.

Alternatively, it's the recognition that the switching costs to unfamiliar technology are non-zero.

> If I don't do it your way, could you please stop assuming that it's because I don't know any better? It may be because I actually do know better.

It may be, but there is a pretty huge in between space where you don't know any better.

I think you'll find people will believe that if you put in enough "escape effort" to pull yourself out of the habit. If you don't, you can't really know, which makes it condescending for you to assert you know better.

So there's this big space where neither party is in a position to judge, but the advocates want you to try. Somehow, that always seems to get internalized as, "they think they know better". They don't. They've found it to be a big win for them and other people, and they have an educated guess that therefore it'll be better for you, even if it initially doesn't seem like it. That's really not unreasonable.

> So there's this big space where neither party is in a position to judge, but the advocates want you to try. Somehow, that always seems to get internalized as, "they think they know better". They don't. They've found it to be a big win for them and other people, and they have an educated guess that therefore it'll be better for you, even if it initially doesn't seem like it. That's really not unreasonable.

That's fine. There's a totally reasonable case to be made for that, for Smalltalk, Haskell, and Lisp (at least). The advocates just need to express it in a way that doesn't come across as "I'm enlightened; you're ignorant. Once you're enlightened, you'll do it my way." That's counter-productive. It turns people off rather than encouraging them to try it and see.

> The advocates just need to express it in a way that doesn't come across as "I'm enlightened; you're ignorant. Once you're enlightened, you'll do it my way."

But I think if you look at what they say, it really is as much the responsibility of the listener whether it is interpreted that way. Even the above quote, which I'm sure someone didn't say to you, can be interpreted as, "don't knock it until you've tried it".

I don't think that's what the article is saying at all. It says that when you've done things the same way for most or all of your professional life, as I have (30 years programming in FORTRAN, C/C++/C#/Objective-C, Java, Python using text editors, textual compilers, command line tools of all sorts, Eclipse, Visual Studio), you become so used to it, you become so good and efficient at it, that it seems like the only or best way to develop software. You find yourself in a comfort zone. This was my experience; I was your typical code jockey.

However, even after 30 years, I still had a tiny feeling inside of me that there was a better way to do things, one that was easier on my brain. All I had to do was "let go." Let go of my preconceptions. Open my mind to other possibilities. Recognize that my past experience was based on crude methods from decades ago (circa 1980) that have been optimized and refined to their current stratospheric levels.

When I first tried Smalltalk, it took a little while to change my mindset and adapt. Now, I see why it is such a super-productive tool. It directly aids the natural, cognitive flow of developing an application concept. There is less stress on my brain (whether I'm aware of that stress or not – most people are not). The result is that I can write an application in a fraction of the time that it would've taken me in Java or C#. And it's more fun, to boot!

If we could pit the world's best Java programmer against the world's best Smalltalk programmer in a cage match to see who finishes a moderate-size application first, I know who I'd bet on. I wasn't exaggerating when I said "a fraction of the time."

You have no idea how refreshing it is to only keep a minimalist language in your head. Thanks to the simplicity and elegance of the syntax, code is easier to write than in Java, and much, much easier to read. It takes more cognitive effort to read C++ or Java or Haskell or Clojure. How can anyone take issue with this??

People are always saying how much more expressive this language is over that one because of some much-touted language feature(s). Aside from anecdotal tales, I've never seen scientific evidence that language features overall have a great impact on how algorithms are implemented. Sure, some languages are exceptional in narrow problem domains, but for general-purpose programming across multiple domains, I've never seen much difference among the dozen languages I've used. Certainly, Smalltalk is not constrained in this respect for most use cases.

So, no, you're not ignorant. You just haven't tried to break out of your comfort zone for whatever personal reasons you may have. If the suggestion that you're human offends you, then you need to dial back your sensitivity because all I'm doing is calling it as I see it.

Denial is not a river in Africa.

It's impossible to just read about Smalltalk and poke around a bit, and think one knows. The language itself is a tiny part of things, and one needs to really get immersed in the environment to really appreciate things.

Maybe you know better, the author could have put things better. But I am sure a lot of people don't know, I know I was one of them. Even after a long time Smalltalker gave an enthusiastic (to put it mildly) 2 hour demo. Now I've become the rabidly enthusiastic one, but most people think I am passionate about historical programming languages.

What other environment can you trivially do this: - can't find a method, but know what you want: provide sample inputs and an output, and (at least Pharo and Squeak Smalltalk) will find you all methods that produce the output. - trouble visualizing relationships while debugging? Script some code in a few minutes that become part of your debugger to see what is going on. - really code live - there is "hot swapping", but it's something bolted onto a rigid foundation, and eventually fails. In Smalltalk, it's a foundational element.

Though the author could have put things differently, it can be difficult when so much that is mainstream feels so primitive, with layer upon layer of cruft bolted on. Programming in Smalltalk is uninterrupted bliss, then I go to work and use tools that have roots that predate Smalltalk, but Smalltalk is talked about as the "old" curiosity.

Excuse the rant - Smalltalk makes me feel like I am using a polished and refined set of tools, and then day to day I run around with crude stone tools, the "modern" way. I think the author feels the same way.

"It may be because I actually do know better."

And what is it that you know better? It would be difficult to defend current software development practice as being ideal or supremely productive. However, I can see other non-technical reasons for sticking with what you know. For example, your business organization may not be willing to overhaul its IT operations in order to support Smalltalk. There would be financial costs. There would be hiring issues (from what talent pool would you draw from?). There would be lack of managerial experience in running a Smalltalk project. There would be interoperability issues with existing applications. And so on.

But from the purely technical standpoint, you have to know that the way things are cannot be ideal. There will always be easier and more productive ways to write software. The trick is to find out what those ways are.