[Tfug] Language choices

[Stephen Hooper]

<snip>

> Right.  And that could have been done with a more general mechanism.
> You have underlying mutexes already, and we did something rather like
> the snippet above for years in C++.  Our term for it was  Resource
> Aquisition
> is Initializatoin (from Cope, I think: RAI).  It worked in C++ for reasons
> it
> would not work in Java -- every local object was destructed at the end of
> the file.  That meant that creating an object before a chunk of code was
> effectively the same as wrapping that code with the constructor and
> destructor of the object.  It was a general mechanism, and it worked
> well.   I'm not saying Java can/does work that way, but that Java needed
> an equally useful (and hopefull more intentional) general mechanism.
>

<snip>

>
> In the above case, the "synchronized" would not be a keyword but
> an object or class. The Synchronized class would use semaphors,
> the Transaction class would use transactions, the mmap would
> use memory mapping, etc.  It would be in the library, not the
> language.
>

Ok... and why aren't you free to write such a library in Java?

> Aren't you going to get in trouble if two
> > threads instantiate synchronized at the same time?
>
>
> Nope. Never did in C++ either.

Well if you are using a semaphore, then I wouldn't expect you to.

>
> Even with your
> > much beloved closures?
>
>
> Nope.

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

<snip>

>
> Because threads would be objects also, and they would receive
> closure parameters. You would tell them to run concurrently.
> BTW: Python isn't ideal here. You end up either deriving from a
> thread class or else passing a function pointer (named, real function)
> to a thread instance. But it works very well, if the syntax is not all
> that I'd like.

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

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.

>
> I also doubt that "transactions" have to be part of the grammar.
>
>
> I would hope not. They should use the same wrapping mechanism
> that synchronized should use, which of course does not exist.
>
> Are we talking right past each other?  I see what you say, but I don't
> know how to express the thing I'm talking about.

Yes, I think we may be.

>
> Whether you or I like closures or not is immaterial.  The point is that
> they allow a much smaller and simpler grammar partly because having
> closures  makes more general mechanism possible.  Having more
> general mechanism makes the library more consistent and powerful
> and makes the language  much more simple (in terms of fewer keywords,
> operators, etc).

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 :)

So you know... I personally, am rather indifferent to them.  If I see
them coming I will say hello, but I  am not going to walk across the
street to greet them.

>
> The reason smalltalk only has 5 keywords is that it supports closures.
> closures add only these symbols: [, ], |  It's a very small price to pay
> to keep the grammar that small and simple.  In ruby it adds {, }, | and
> the alternatives do...end.
>

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

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

> I think that I'm not going to make this point in english text.  I think you
> will have to get into a language with closures to see it.

I have done Perl programming, and LISP-ish/Scheme-ish programming, and
Javascript programming all of which I think have closures, and I am
still afraid I don't understand your point.

What exactly is it about closures that is forcing  "synchronized" as
part of the the language, rather than as a class?  As I was trying to
say before, I thought that was more inherent to the actual JVM.