[Tfug] Language choices

Stephen Hooper stephen.hooper at gmail.com
Thu Nov 9 11:22:15 MST 2006


On 11/9/06, Tim Ottinger <tottinge at gmail.com> wrote:
> 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.
>

I think you have described it very well, and coherently explained some
of the questions I had, but I find though, that I must disagree with
your main premise: that smaller grammars make easier languages.

The great thing about grammar, is that you can be completely ignorant
of 99% of it, and still produce a communicable thought. As proof
positive of this, I offer myself as an example.

Despite all the attempts my English teachers over the years made to
introduce me to all the nuances of grammar, I am much ashamed to admit
that I cannot pick out from any given complex sentence where the
subject (and the object are).  That may sound stupid, but really, on
sentences like this one, where the hell are they?

I also have no useful clue about where I can use commas, and for what
can I use commas.

Still, I like to think I write in English :)

Java, Python, etc. are nice meaty languages.  The learning process I
had to put into them wasn't so much related to where I could, or
couldn't put semicolons, but to understanding the pieces that made
them.

Java as a language is relatively simple when compared to all the
standard classes, coffee names, etc. that one first encounters when
using it.  What the hell is a bean?  Can I use it, eat it, or grok it?

So as far as your "synchronized" example goes... I never really
worried about it.  Much the same way that I normally don't worry about
95% of the keywords in C at any given point in time...

Does that make the language easier, or harder?  I would say it makes
it NULL, or Buddhistically speaking "mu".




More information about the tfug mailing list