[Tfug] Language choices

[Tim Ottinger]

Ahhhh... Closer and closer.


> The smallness a grammar doesn't really make a language simple.  Don't
> you think it has much more to do with vocabulary?

First off, I think that a language that is based entirely on a very small
number of powerful, general mechanisms is much easier to use than one with
more grammar and keywords to learn.  Every special-purpose mechanism in a
language is sort of like an apology for not having a better idea.  IOW:
There shouldn't be special-case grammar in a language (IMHO).

Smalltalk I like to discuss because it's based on only two or three very
general mechanism. I like software designs that have only two or three
unifying abstractions rather than designs that don't have ay unifying
abstractions, where every function is a "special case".  MFC and he M$ API
are examples of the latter - pretty much everything you do is a special case
you have to memorize. I apply patterns like a mad banshee but memorize very
poorly, and that may flavor my perceptions.



On 11/8/06, Stephen Hooper <stephen.hooper at gmail.com> wrote:
>
> <snip>
> Ok... and why aren't you free to write such a library in Java?


I don't have a way to make one.  I don't have guaranteed destruction (a
generalized mechanism) nor do I have closures to wrap arbitrary blocks of
code in start/stop mechanisms.  It would not be the same if I have to use
template method (a class with a run() method) or if I require the user to
call start and stop methods around a block of code.

A rule for library design is that you always require the least possible of
your users. Neither of these do that, but closures do.  The way that
'synchronized' works is very much like a closure, except that it is a
special case and not something you can build.

Show me how to make a new keyword that works like synchronized does in Java,
please.

In Java (again as I recall), threads are objects.  You instantiate a
> Thread, pass it a runnable class, and that class will run in the
> thread.  This is pretty much the same as I remember C pthreads being
> (without the whole class thing).


Yes, and I don't like it. It's too much overhead, too many named objects
that can't close the current scope -- you have to rearrange too much code
when you write a routine where the middle 10 lines of 40 should be run
multi-threaded.   You should be able to just stick in a word and a set of
braces around the 10, but you can't.  You can't even write a nested function
that closes the local variables like you can in python.  You have to create
a separate object/method and pass it everything that it needs to know.
That's more syntax and effort, and I don't like it.

I don't understand why a closure plays a part, except that you are
> passing it the in-thread code in yet a different way.


Yes.  And think about how convenient and powerful the different way is, and
how having it means less syntax in the entire language.



>
> > Nope.
>
> And in this context, what are you using closures for?


I am passing the code that I want wrapped up as a closure, but Python
doesn't have closures (nested functions only, which is close). Instead I
have to write a function and name it, and maybe create a class to stick it
in, and that has more overhead and bookkeeping and syntax than:
    synchronize: [ some block ]

I can get the same effect wherever semaphores are, but clearly without the
same order-of-magnitude simplicity.  Everything I have to do is a bit
harder.   I don't know Java, so if there is a way to do that in the middle
of a function, then I will be happer.  If that way involves a lot of syntax
and the use of 'new' then I'm not going to like it nearly as much.


I don't think you just /like/ closures: I think you curl up with them
> on the sofa at night with a cup of hot chocolate, and watch long
> romantic movies together :)


Mostly I dream of having them all the time.  Kinda more a fan-boy
relationship with a supermodel than a close, intimate relationship.  I tend
to be stuck in languages where there are no closures (Java/C++/C#/Python)
rather than in languages where they're simple and free (smalltalk/ruby).


> My point is that it should not be part of a language, and that  we've had
> to
> > do it in langages with far too much grammar because we didn't have
> > closures -- hence the "far reaching" bit about closures.
>
> The problem with this thought is it seems to me to be borrowing from
> Peter to pay Paul...
>
> Let's say we have a case where we need to demonstrate possession of
> objects by objects.  We could do this in two ways:  increase the
> vocabulary (as in Latin), or increase the grammar (as in English).
>
> Do I understand you want to increase the vocabulary, to simplify the
> grammar?  It may work better in some cases to decrease the vocabulary,
> and increase the grammar.



Ah, yes!  I exactly want to increase the vocabulary to simplify grammar!
My reason is twofold: it makes the grammar simpler and makes the language
more powerful.  This works because programming is the act of adding
vocabulary to a grammar.

That means that anything done in the grammar is off-topic, but anything in
the vocabulary can be duplicated, changed, extended, parodied, etc.
Anything not written into the grammar is something you can examine and join
into.  Anything in the grammar is sealed off.

You've exactly captured my point!!

Now lets see how well I've described it.

:-D