[Tfug] Language choices

[Tim Ottinger]

I'm clearly struggling.  I don't know enough java or enough smalltalk to
bridge the gap.
I'm at the very edge of what I know about both, so there we are.  But there
is something
cool here, and I'm unable to get across the cool bit. I'm frustrated, and
sorry for that.


> 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).
>
> What exactly are powerful, general mechanisms?


That the language (AFAIK) is really based on only a few ideas, and you can
do almost anything with it.  Those ideas are objects, messages, and
closures, and that from those we can express almost anything imaginable and
typically more simply than you can do the same things in other languages

So power == expressive power for me.  Read just about any smalltalk text, or
the examples in the GoF book and you'll see how little effort (few lines of
code, few symbols, few language specifics) go into building examples for all
those patterns.  If that doesn't speak to you, that's fine, but I can't do
any better.


So far you have mostly
> addressed the simplicity of language syntax.  But the design
> considerations of programming languages are numerous, and syntax is only
> one aspect.  Performance, memory management, ease-of-use/productivity,
> the various programming paradigms ( imperative, functional, declarative,
> distribute/parallel, object-oriented, aspect-oriented, etc., etc. ) ...
> the list goes on.


Right, and those are unrelated to the point I want to make.  Other than the
OO bit, maybe.


You are comparing apples and oranges.  A programming language is an
> entirely different beast than a system API.  While I agree with you that
> the Win32 API is piece of crap, I see very little use in comparing it to
> Smalltalk.


I'm unable to make this point.  I stop.


> 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.
>
> Say what?


That looks completely coherent to me.



> 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.
>
> Please explain how a monitor is in any way related to a closure?


A closure would be the right syntax for building monitors around code.
They're not the same thing, and one is not better than the other, but the
syntax making it happen  should probably be something like:

synchronize(x) {
    protected code
}

where synchronize is NOT a keyword, but a class that uses a mutex.
and { protected code} is not a special mechanism for the 'synchronize'
keyword, but a closure.

The reason isn't to make monitors easier, but to make it possible for
programmers to make any "synchronize"-like mechanism for whatever reason
instead of having only one instance of the "kind of thing that synchronized
represents" which involves "a specialized parenthesis expression in the
grammar} sealed in a grammar where I cannot make any additions or duplicate
the mechanism.

So I want my monitor to be a class in the library that takes a closure
rather than grammar, so that the mechanisms that "synchonized" uses for
implementation in the hypothetical language are available for me to use to
may synchronize-like things.

transaction() {
   transaction code
}

or  whatever.

> 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.
>
> You want to simplify the grammar to make the grammar simpler. That's a
> bit circular isn't it?  And, once again, what makes a language more
> "powerful"?  ( See above )


I like to consider it "no loose ends"  :-D

But also I want the grammar to be simpler so that the language HAS to
expose the mechanisms it would otherwise have built into the interpreter
or compiler will have to be exposed for me to capitalize on.

It would not be enough to strip stuff out of the grammar leaving the
programmer
impoverished.  The designer also has to build mechanisms (closures, etc)
into
the grammar to make it possible for programmers to do the things that the
language designer might otherwise have done in the compiler/interp/grammar.

I don't know how to illustrate that. It's a principle, a concept.

> Now lets see how well I've described it.
>
> You can do better. ;-)


I could quit, too.