*for this sprite only* blocks

solely.

I vote for functionl programming wherever possible. So, no for this one.

About v1.add(v2) versus add(v1,v2): I don't think there's a right answer to this. In the case of addition, which is commutative, the symmetric notation makes more sense to me, but if we were talking about subtraction I'd see more of a case for v1.sub(v2).

(Of course these days in Snap! you can just say v1+v2, but you are asking a general question so let's talk about multiplying vectors, which isn't just a termwise scalar multiplication, so that option is ruled out.)

I think each programmer's aesthetic sense about these things depends on how they grew up. I'm a Lisp child, so having a global procedure that takes the two vectors as inputs feels really natural to me. Jens and Bernat are Smalltalk children, so the v1.foo(v2) notation feels natural to them, except that really they'd say v1 foo v2, which doesn't look quite so kludgy.

Never mind vectors for a moment and imagine you're implementing the underlying + on scalars. Well, in a computer there are these two different kinds of numbers, integers and reals, so in Smalltalk notation you have to implement integer.+(real) separately from real.+(integer), and it gets quadratically hairier if you also have exact rationals and complex numbers as primitive data types in your language. For abstractions built on top of the primitive arithmetic operations, you can take advantage of polymorphism and just have one method for all numbers, but down at the bottom level it gets messier. So I think that's a weakness of the Smalltalk approach in which everything is a method of one object, vs. generic functions. On the other hand...

This is the great strength of Smalltalk. Everything is an object, so if you imagine asking something like 3.value() the answer would be the same 3 object you started with -- this would be the identity function. All those other languages that call themselves object oriented are half-hearted about it, with user-visible non-object data types, so you end up with kludges such as wrapper classes and case-sensitive type names (integer vs. Integer).

It's not a silly question; it's a great question. But sometimes seemingly simple questions have really complicated answers. Is light a wave or a particle?