[Tfug] Language choices

[Tim Ottinger]

On 11/7/06, Robert Hunter <hunter at tfug.org> wrote:
>
> Tim, interesting ideas, once again.


Tks. They're not mine, though.  All borrowed and old.

>
> > This is the thing about
> >     x<1 IfTrue: [ do something ]
> >           ifFalse: [do something ]
> > that I find appealing.  You don't have to add "if..else..then..elseif"
> to
> > your syntax. The only syntax we have here is:
> >     object message
> >     object message: parameter
>
> Personally, I don't find anything innovative about burying conditional
> execution semantics for the purpose of streamlining the language syntax.


Not "buried".  I don't understand your statement.   Maybe I'm not
communicating very well on either the read- or write-side of the
connections.  Apologies.


> "Wierd" and "funny" are subjective descriptions.  If you have been
> programming in a given language for a period of time, you tend to used to
> it.


Indeed, there's an old saying that everything is "intuitive" once you've
memorized it. :-)  Oddly, when I learn new languages, the old familiar ones
start looking clunky and weird.  Maybe I'm unlearning too much.  Maybe I'm
learning better things.  I don't know.  But python and now ruby and that
little smalltalk think has more profoundly changed my thinking than TDD or
Agile or C++ or anything else I've learned.

>
> > The idea that everything (expressions and variables) are all objects,
> and
> > all programming is sending messages with objects parameters is very
> > simple, and far-reaching in power.
>
> Can you explain why?  Try to avoid subjective analysis, such as "it
> sucks", "or it is cool."  That doesn't communicate anything other than
> your personal taste.


I thought I had. Now I'm bummed.  Maybe I don't know what I need to say to
show it.  I've tried to say it in all the ways that have appealed to me so
far.  Here's another shot.

The whole nature of OO is that a program is a bunch of objects signaling
other objects. In fact, that's almost Alan Kay's definition.  When smalltalk
(which I know only by reading about) chooses to do everything using just
this paradigm, it created a very powerful language which has affected
everything that came after it.  It has been very far-reaching.

>From wikipedia: "Smalltalk syntax is rather minimalist, based on only a
handful of declarations and reserved words. In fact, only five keywords are
reserved in Smalltalk: *true*, *false*, *nil*, *self* and *super*. The only
built-in language constructs are message sends, assignment, method return
and literal syntax for some objects. The remainder of the language,
including control structures for conditional evaluation and iteration, is
implemented on top of those by the standard Smalltalk class library. (For
performance reasons implementations may recognize and treat as special some
of those messages; however, this is only an optimization, not hardwired into
the language syntax)."

By using the simple mechanism of "objects receiving messages" as the primary
(only?) language mechanism, smalltalk achieved a very small and simple
syntax. All mechanisms are these simple, generalized mechanisms.  There's no
exception or exemption for "synchronized" or "for" or "if".  The BNF grammar
never really needed to get bigger.  It fits on a single page, maybe a single
screen without too much eyestrain, and it can do everything that more
complex languages can do in fewer, shorter lines.

It's open to extension because it's all just objects receiving messages, and
messages can pass blocks. Likewise, a friend of mine has taken over
maintenance and evolution of "rspec" in ruby.  You should look at the
examples and see how expressive a grammar has grown out of simple, general
mechanisms: http://rspec.rubyforge.org/examples.html   Note that "specify"
and "context" are not keywords.  Everything here is blocks and messages.
The "do".."end" in ruby are block/closure boundaries. It will probably look
weird for a minute or two, before it starts looking darned simple.  After a
while the subjective "weird" goes away.

There's a little of smalltalk grammar discussion at
http://www.smalltalk.org/articles/article_20040914_a1.html  and more at
http://experts.about.com/e/s/sm/smalltalk.htm

Basically, you have no limitations and almost no grammar to get in your
way.  Python has a more conventional way of doing things, but is growing
increasingly "functional" in its style. By not having closures, python is a
larger language.  It has too much specific syntax now for my taste. If it
gets closures, that won't be the case any more.  Ruby sticks pretty close to
smalltalk in practice, but has some madness from perl. Perl is the
antithesis of the smalltalk way.  And think, if Python syntax starts looking
a little clunky how must I feel about C++, C#, and Java.  They look like
armor-plated dog poo.

In particular, I think that the way Java added "synchronized"  as a
> > special keyword in the language instead of a general mechanism for
> > wrapping  blocks or closures is sick and wrong.
>
> The "synchronized" thing in Java is for dealing with concurrency.  It has
> nothing to do with closures.



Exactly what I hate about it.   I think that there should be no special
mechanism in the grammar for doing that.  Instead, there would be a general
mechanism for wrapping any arbitrary group of statements, and "synchronized"
would be a specific instance.  Of course, that would be doable if there were
closures and they were used to advantage.  Instead we get grammar warts.

transaction {
    gc disabled {
       synchronized on: x {
           arbitrary commands
           for however many lines
        }
        more stuff()
    }
    commands
    with GC
    and stuff.
 }

But no. Transactions probably have to be another specific addition to the
grammar. Sigh. I know that if I wrote my programs they way they write their
grammars, my coworkers would make me refactor it.  And might pick on me.


> >
> > Of course, a few years ago I wouldn't know any better. :-/\



Imagine where you will be in a few more years ;-)


:-)