RE: ::scr Touchy Feely?

["Simon Kinahan" <simon@xxxxxxxxxxxxxxxxxxx>]

> Yes, the more I play around with Smalltalk, the more I like the
> syntax; it gets out of the way. But I still get weirded out by the
> 'arithmetic implemented as message passing' approach which means that
> 1 + 3 * 3 doesn't really do what you expected.

It is odd, isn't it ? and there's something inelegant about making
commutative operations asymetric like that. It's nice to be able to do
operator overloading without nasty extra syntax, though.

> From my point of view, the Java syntax (and C++'s syntax before it) is
> a *horrible* syntax to do OO in. Method definitions that appear to
> have more declaration code that code that actually *does* anything
> definitely leave me code, and if your code is well factored that's
> almost certainly what you'll have in a lot of cases.

It's the static nature of the thing that gets in the way. The need to
declare all kinds of meta-information about your code, like what type it is,
what exceptions it throws, who can access it, and so on. The trouble with
dynamic languages, though, is that without all that metadata things like
stripping (see below) are hard. I don't really buy the error-proneness
argument against dynamic languages: if you can get confused about the type
of something, you're already doing something wrong.

What I'd really like is a modern, OO langauge that did type inference (like
Standard ML) were possible, and then used dynamic typing where necessary.

> Oh yes, image files are definitely weird. If you're just running a
> single app though you can usually strip the image file right down to
> something that'll be reasonably small and run headless. But you
> probably already knew that.

Yes. It is an unreliable process, though, because Smalltalk can't really
work out which methods are called during execution from your designated
entry point. If you use #perform: and its friends at all (and who doesn't)
you have to be very careful. For non-trivial applications, I generally found
that stuff you needed would get stripped out, and stuff you didn't need
would get left in, and then you'd have to spend a few days manually dinking
around with the stripper to get it right. Not really what you want to be
doing right before a release. It doesn't really mater any more, 20 meg image
files are nothing, but it did then.

Java actually has the same problem with reflection, and in one respect it is
worse: you can never guarantee precisely what will be on the classpath when
the program is run. Programs that operate over the whole codebase, like
obfuscators, get into trouble with this.

Simon