Static Vs. Dynamic Again

Joda say: 'Fear leads to static typing, static typing leads to casting, casting leads to suffering.'

1. Stefan used to believe X.
2. Now Stefan says he was wrong to believe X.
3. Now Stefan says he believes Y.

Does Stefan's testimony provide the information we need to judge whether X or Y is correct? Or is it just that Stefan's current belief coincides with our truthiness.
(Stefan was responding to 'A "fair and balanced" look at the static vs. dynamic typing schism')

Joda "static typing leads to casting"
Haskell, OCaml...

Static typing really only becomes important when you engage in higher order programming. Does Smalltalk even have first class functions/methods? (A quick search implies no.) Can you write "compose" in Smalltalk. Even if you can, does any Smalltalker use it?

Comment by James Robertson

In Smalltalk, methods are objects, just like everything else. BlockClosures (commonly called blocks), are first class functions. I'm not sure what you think static typing has to do with any of that...

1) Stefan had a hypothesis.

2) Stefan rejected his hypothesis because it did not match his experimental results.

3) Stefan formed a new hypothesis.

I suppose I should go and read the articles now :)

Mr. Robertson wrote:

>BlockClosures (commonly called blocks), are first class functions.

Apparently that's debatable. The very first article from the above search says...

Scheme has first class functions and second-class objects/methods (lexical closures trap environments and functions) while Smalltalk has first class objects and second-class functions (blocks) and methods.

>I'm not sure what you think static typing has to do with any of that...

Let's try it in syllogism form...

1. Static typing is only necessary when you use higer-order functions.
2. 1. Smalltalk doesn't have higher order functions.
   2. -or- Smalltalk doesn't make it easy to use higher order functions, so no one does.
3. Therefore, Smalltalk doesn't need what static typing provides.

Or, it might be the case that no Smalltalker uses higher order functions because without static typing, it is too error prone to make it worthwhile.

Mike I suppose I should go and read the articles now :)
Yes ;-)

Smalltalk-80 did not define blocks to be closures. That is a later evolution of Smalltalk.

Anon "Apparently that's debatable. The very first article from the above search says..."
And in the preceding sentences: "although one can override method lookup ... while control structures can in principle can be defined as methods"
Which is to say, meta-programming for Smalltalk methods is not first class, and many implementations reify specific methods which in effect become keywords.

Smalltalk blocks (anonymous functions) can be assigned to variables, passed as arguments, created as the program runs... and iirc returned as the result of some other Smalltalk block.

Every Smalltalker uses higher-order functions!
Let's take an obvious example map :: (a->b) [a] -> [b]
The corresponding Smalltalk method is the Collection method collect: Evaluate aBlock with each of the values of the receiver as the argument. Collect the resulting values into a collection that is like the receiver. Answer the new collection."

Anon Can you write "compose" in Smalltalk. Even if you can, does any Smalltalker use it?
Smalltalk is not a functional programming language - it is an obsessively object oriented programming language.

Comment by Alan Knight

The commenting here seems to increasingly rarely actually answer any questions. So, I'll try. Smalltalk certainly does have higher order functions. It's very easy to use them, people do it constantly. The Dave Thomas (Bedarra, not Pragmatic) article quoted isn't really a helpful resource, I don't think, for someone trying to understand Smalltalk's basic concepts in the matter, and the choice of excerpts makes it worse. It's a short article advocating something that would need a good deal of background to understand in context. By message-oriented, I would say it means something more like Erlang.

For example, in the quote "although one can override method lookup ...". Overriding method lookup here means changing the method lookup algorithm. I'd call that more meta-higher order functions. While CLOS, for example, is more flexible in that respect, the ability to change the way inheritance works hardly seems necessary for higher-order functions. I don't know, perhaps it's when you're defining many of your own metaclasses, each with their own different method lookup strategy that static typing becomes particularly valuable. I'd certainly like to see the algorithms involved.

The part that says "while control structures can in principle be defined as methods" makes it sound like it rarely happens, when the original simply says that two or three methods are typically hard-coded for performance. This limits you in that you cannot redefine the meaning of the if statement easily. However, Smalltalkers very very commonly define their own control structures, and it's extremely useful, at both the trivial level (Cursor showWhile:) and the more meta level (Seaside and its continuation-based web pages).

If "compose" does what I think it does, that is, take two functions and make one function that evaluates the first on the result of evaluating the second, then in Smalltalk, it would look something like the following (apologies for the formatting). For methods you wouldn't do that, because methods aren't functions, so you need to know who the receiver is.

BlockClosure compose: aBlock

^[:arg | self value: (aBlock value: arg)].

The function doesn't exist as such, so I doubt people would use it all that often. It doesn't really fit the idiom.

For a 10,000 foot comparison of Smalltalk vs. statically typed functional languages, from someone with limited familiarity with the latter, for what it's worth, I'd say they're mirror images. Smalltalk has state everywhere, is eager, its standalone functions (blocks) are slightly odd, and manipulating methods is possible, but weaker (although it's harder than just manipulating functions). It attempts to deal with the issue of state by encapsulating it in small boxes, using inheritance and polymorphism to make it transparent. Polymorphism is entirely based on the "first argument"/"receiver", so is simple and preserves encpasulation, but has limited power. Smalltalk is willing to pay the cost of method dispatch, but not that of being functional. Statically typed functional languages try to deal with state by getting rid of it. Functions are primary. Encapsulation, inheritance and polymorphism essentially aren't there. In so far as there's polymorphism, it revolves around function argument matching, so it's very non-encapsulated, but more powerful. They're willing to pay the cost of being lazily functional, but not that of dynamic dispatch. Functions are consistent, and more easily manipulated, but objects are definitely lower-class (if CLOS/Scheme objects are to be considered second-class, then I'd say they're third-class in Haskell, and sometimes they're more like clever justifications of why you wouldn't really want objects anyway). It would be interesting to try and synthesize the two approaches, but I don't think it would be easy.

You're on the way to answering Smalltalk v. Haskell?

Encapsulation, inheritance and polymorphism essentially aren't there
Polymorphism isn't there? That doesn't seem right.
Isn't map a polymorphic function? map :: (a->b) [a] -> [b]

Comment by Alan Knight

Oh, right, I had thought that the Smalltalk/Haskell comparison question was also under the comment stream for this post. Polymorphism isn't a great term, since it means so many different things. Map has parametric polymorphism. I was talking more about what I guess I'll call Smalltalk-type polymorphism, meaning that based on the receiver of a message, the invocation of the same function by name does different things. Functional languages do that too, but as I said in the original comment, the selection mechanism has the opposite emphasis. That is, the function has many implementations (is there a "function extension" mechanism for new modules to add implementations?) and the implementation is chosen based on pattern-matching the arguments.

what I guess I'll call Smalltalk-type polymorphism
In other words, a mix of subtype/inclusion polymorphism and adhoc polymorphism (overloading).

interesting to try and synthesize the two approaches
We should mention Dylan and Nice and Scala