::scr Touchy Feely?

[Piers Cawley]

"Simon Kinahan" <simon@flatnet.demon.co.uk> writes:

>> 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.

Oh yes. One of the things that's nice about Smalltalk is the pervasive
use of point objects; I have the vague feeling that they get used so
much because they're so easy to construct using a binary operator. 

I'm really hoping that Perl 6's custom operator stuff is going to stay
simple to use. 

>> 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.

Oh ghod yes. I really, really, really don't like static
languages. There's so much bullshit and repetition. It's a large part
of the reason I've done so much work on Pixie, with an eye to doing
object persistence that won't *require* scads of meta data. (Though
the goal is to design it so that you can supply meta data, once you've
got your object model nailed down enough that said meta data will be
useful, a la Common Lisp's DECLAIM stuff.)


> 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.

Who knows, maybe Perl 6 will allow this sort of thing. It'd be nice if
it did, but I'm *so* not holding my breath.

>> 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.

You are in a maze of little twisty classpaths, all different.

-- 
Piers

   "It is a truth universally acknowledged that a language in
    possession of a rich syntax must be in need of a rewrite."
         -- Jane Austen?