[Tfug] Language choices

[Tim Ottinger]

I only know so much, but I offer what I do know.  I guess that's the kind of
giving, ignorant guy I am.


On Mon, 30 Oct 2006 04:43:06, Chris Niswander <cn.tfug.account at bitboost.com>
wrote:
>
>
> Warning: This message provides NO useful information about M L or R E X X!
>
> At 08:47 PM 10/29/2006 -0600, you wrote:
> Oh, I think you could compose an informal proof that the syntax
>     nodes.each { |node| puts node }
>                  ^
> is actually more correct (maybe even clearer!) than
> >> >nodes.each { }node| puts node }
>
> >;-)


Indeed.  I didn't see that extra } in there.  Thanks for the correction.



I'm no Ruby expert, but it looks to me like:
>
> 1. The word "block" has long been used in other languages (e.g. C)
>    to mean something somewhat different from Ruby-style blocks.
>    For example,
>        while (i)
>          {                             // this is a 4-line ...
>            icky = scratchy(i);         // C-style "block"
>            i = squamous(icky.yuck());  // it doesn't take parameters
> really
> ...
>          }                             // it's not a function def ...



 Closure would be a better, older term, perhaps?


2. Talking about "blocks" as if Ruby-style blocks
>    were the first and only type that ever existed
>    invites confusion and/or statements that are *arguably* false or
> misleading,
>    IMHO.  Maybe a different term should be used, such as "Ruby-style
> blocks"?


Closure, then.

But remember that blocks/closures have been discussed in smalltalk for many
years before anybody ever considered starting the oak project, let alone the
java
we know these days.  Smalltalk was in the early-to-mid 70s, whereas Java
started
as "oak" in 1991 (only 15 years ago).  Also, smalltalk was the language for
which
the term "object-oriented" was coined (by Alan Kay, the author of
smalltalk).  It
was later retrofitted to some languages that influenced him like Simula.

Java wasn't the first, nor the best, object-oriented languages. I'm only a
little
familiar with java but I've not seen anything innovative in it yet.
'Course, I'm
not doing web apps or guis, so maybe there's something cool in those libs.
And eclipse is kinda cool.

3. It looks like Ruby supports a syntax in which a 'block'
>    has the exact same syntax as an anonymous function's definition,
>    except that a single keyword is left off the front, and the
>    syntax of either is very similar to a non-anonymous function's
> definition,
>    and any of these is fairly terse.


"Anonymous function" is too long to type, of course.  Closure sounds best.
And reminds me of ladies foundation garments, which is a pleasant
association.

http://gafter.blogspot.com/2006/08/closures-for-java.html

4. I think the observation (by Ruby's designer?) that blocks and anonymous
>    function definitions are really the same kind of thing, and can be
> written
>    with exactly the same (reasonably terse and clear) syntax, is a nice
>    discovered orthogonality that must provide some benefits.


It is an old and proven idea, from smalltalk closures.

   I doubt I'm the only person who has ever written a loop body,
>    elaborated it, and then said, "It might be kind of good
>    to turn this loop body [a block] into a function so I can
>    (re)use it elsewhere (without splitting it into multiple copies)."


Or better yet, if you've written a container class and hated the idea that
you have to expose so much of it to make iteration work (or else do
something
ugly like a friend class).

It's such a more useful general mechanism, that I do have trouble
confusing "correct" for "useful".  I think it's "better" for very
ottinger-ish
definitions of "better".

   This happened to me a day or two ago, but I was writing in Python,
>    where as in most languages the conversion takes somewhat more work
>    (more typing after the cut and paste) so I haven't gotten around to it.
>    :-)


Lambda is not as nice, and Python does the same kind of thing as C#
with iterator/generator syntax.  It integrates iteration to the language in
a decent way, but it's in the language system.

However you can simulate the closure experience somewhat with nested
functions.   This is typically done when you're creating python decorators.
The inner function encloses (closes around) the local variables:

     def with_exception_reporting(function):
           def inner_function(*args, **kwargs):
                 try:
                     return function(*args, **kwargs)
                 except Exception, obj:
                      print "Yikes, we got " + str(obj)
                      raise

    @with_exception_reporting
    def divide(numerator, denominator):
         return numerator/denominator

If we had more high-level functions (functions taking function params)
we would begin to realize that we don't need comps and generators
nearly as much as we think we do.


   But from your explanation I don't really have a specific feel for other
>    benefits, just a very vague suspicion that there might be more benefits
>    than I know of. :-)


Closures can, indeed, do many things well.  Think "functor", "delegate",
"event",
and "strategy".  And "template method" sometimes.  Actually, having blocks
greatly
reduces the number of things you need the language to do for you, including
"if" and "case".


   Do you happen to know of a good explanation with more details, to which
>    you could link?  So far I've found some iffy/partial explanations
> elsewhere. :-)


http://www.gnu.org/software/smalltalk/gst-manual/gst_34.html explains some
of the
smalltalk closure usage.

Fowler offers this: http://www.martinfowler.com/bliki/Closure.html



5. Also, I found a code example
>        [1,2,3].delete_if{|x| x == 1}       # => [2,3]
>    and I'm thinking, does Ruby really have a specific loop operator (well,
>    I guess really a specific method of the standard libraries' collection
> classes)
>    for deleting some items from a list based on a conditional?
>    What kind of crazy language standard would expect people to
>    memorize stuff that specific instead of writing it on the fly as
> needed?


Does it really? No.  It doesn't have any loop operators. After you're done
calling me
a liar, realize that delete_if is not an operator.  It is not part of the
grammar of the
language in any way, shape, or form.

Delete_if is a member function.  It's a member function of the list class,
of which [1,2,3]
is an instance.  The function takes one parameter, which is a closure. When
you have
closures, you don't need iteration built into the language.  It keeps the
language very
small and simple.

So any container may write a generic iterator, and then add methods that
pass blocks
into the generic iterator.  It's kind of mind-blowing.

   I can't help but think that rather than memorize such specific operators,
>    I might rather write something like Python-style list comprehensions,
> e.g.
>        [x for x in [1,2,3] if x != 1] # written in a few seconds, worked
> 1st time.
>    although, frankly, I thought Python list comprehension syntax was a bit
>    unobvious when I first encountered it, and I still suspect that a
> better
> syntax
>    could (should?) be designed.


I like list comps and generator comps, but I think that the smalltalk/ruby
way is "better"

Well, the [x for x in y] is a language construct, whereas the other is a
member
function.  Think about that difference for a while. It is enlightening.

   (Please note: I do *not* intend to suggest that Python-style list
>     comprehensions as-is somehow provide a universal substitute for Ruby
> blocks.)
>
> 6. Care to kindly correct or elaborate any of this?


Inline, above.

It amazes me how much language syntax the closure mechanism obviates.
Switch/case is just a dictionary with some value-based key and a closure
for a value.   Iterating a tree is just a matter of passing a closure to a
general
function that iterates.

Then there's the whole "higher-order function" thing.

It's a whole world of coolness.  I'm only so aware of it so far, but find it

to be a more simple world-view than writing all of these other ideas into
the BNF.  Y'know?

So even though I do almost everything for work in some C++-based-language
these days (Java and C# keep dragging me into their worlds)  and all my fun
stuff in Python, I think that Ruby/smalltalk have the better way wrt
closures
keeping the language syntax absurdly small and simple.