On Smalltalk

The article is extensive. It doesn't fit the definition of what I'd call a tutorial. It's more like a primer on Smalltalk, talking about definitions, and the concepts in it.

I found the "Final Thoughts" section at the end particularly valuable as it confirms the conclusions I've come to. I was talking with a friend who is a Java programmer about this stuff just recently. He seemed confused about the idea of "it's all about the messaging, not the objects" at first. I guess he displayed the classic confusion with OOP that Alan Kay has often complained about. Despite this he's downloaded Squeak, and indicated he'll take a look at it. So that's progress. :) If nothing else learning Smalltalk will help in learning what OOP was meant to be about, and perhaps through that people will learn better OOD, that is if they don't get "Red Pill" syndrome and decide to stay. :) I'll pass this along to him.

There, how's that?

Good. :)

I have a question. I've been discussing Lovejoy's article with this friend of mine. One of the things I hadn't considered before reading it is that static typing breaks encapsulation, because it introduces an external control on how an object behaves.

A topic that came up for me as I was writing about it is method scoping. Smalltalk doesn't have it. You've said before that it's good there are no such things as protected/private methods. I imagine this would hinder the message-oriented paradigm. I'm sure there are cases however where an object will want to execute some common functionality between its methods, which is only used to manage its internal state, in which case it would need to be private. I have seen methods in the Squeak class library that are categorized as "private", indicating no one should call them. I imagine this is a case of bad class design though.

A thought that came to mind is instead of defining a method for this sort of thing, define a code block and assign it to a class/instance variable, and execute it when needed within your methods. That would have the same effect.

Another thought that came to mind is if you are seeing a need for this, it suggests that you need to factor out a part of your class into another one. Does this sound right?

My opinion on the matter is that the need for private methods indicates a less than optimal class design that needs to factored better, in which case a method category named private is a sufficient apology/warning for saying "it's the best I could do for now and this may change".

It may also indicates a failure on the part of the programmer in thinking he can successfully predict the future and know that all possible future clients won't ever want to call this method. Wanting to make a method private means you're saying no to outside callers, and no to subclassers, both are assertions that you think they're too stupid to use your class correctly.

As a framework/library user myself, I'm against this approach, my freedom shouldn't be restricted because the original developer failed to anticipate my current scenario.

IMHO, static typing is the result of thinking everything can and should be modeled mathematically, where everything is provable while dynamic typing is the simple recognition that the most complex systems we see in the world around us, are biological, dynamically adaptive, and late bound. Many things work quite well despite poor specifications, and somethings by accident.

One side thinks they can design everything statically by specifying how a system should work, the other recognizes that most systems are so complex we can't really understand how everything will interact anyway, so we'd rather grow a system by accumulating features and relying on behavior instead of specification.

If two object behave the same, why should another object care about its specification? Static systems IMHO, just don't grow well.

Re: static typing

First of all, Alan Kay would agree with you that static systems don't grow well, not to mention that most of them are early-bound. Refactoring tools and the web architectures have helped these systems approximate the freedom you get with Smalltalk and Lisp, but they don't make them equal.

What you say confirms something I suspected. I was just discussing Dijkstra with someone earlier today. Dijkstra didn't like OOP (would he have liked MOP?). He believed that all programs should be proven correct mathematically, and if there was a system that could not be proven, it wasn't worth entertaining. I admire some of the stands he took, and certainly having a mathematical discipline about programming is good, but this particular stand he took is pretty narrow-minded. What you say makes sense in this context. If you can plan out a program ahead of time, and prove it mathematically, then there's no reason to think you'll need to change it. Static systems work well for this.

It's been my impression listening to others in the DL community that static typing was invented for performance optimization, not to prevent programming errors, though it has that effect for some cases. This is the reason TDD is useful even with static systems.

Most type systems don't prevent real programming errors, smart programmers do. Everyone seems to forget that, and they keep trying to make languages for dumb programmers to prevent them from doing this or that, but dumb programmers won't produce good programs in any language, and smart programmers don't need help on syntax, the most basic of tasks. Until type systems suck less, dynamic languages will remain more productive for most application programming, especially on the web.