RE: Functional Paradigm popularity and Maths (Was: XML as a transition to s-expr)

["David Simmons" <address@hidden>]

> -----Original Message-----
> From: Anton van Straaten [mailto:anton@appsolutions.com]
> Sent: Wednesday, December 19, 2001 4:01 PM
> To: David Simmons
> Cc: ll1-discuss@ai.mit.edu
> Subject: RE: Functional Paradigm popularity and Maths (Was: XML as a
> transition to s-expr)
> 
> David Simmons wrote:
> > Where the process of mentally parsing them (when nested) is easier
with
> > additional degrees of experience in abstract thinking of this very
form.
> > I.e., read some lisp/scheme, it gets easier. Read it all the time,
it
> > "seems" really easy and natural (especially with a good pretty
printer).
> 
> I have to point out that a very similar thing applies to Smalltalk - I
say
> that from personal experience.  For Smalltalk, your statement might
need
> to
> be rephrased along the lines of "the process of mentally parsing
messages
> (when chained)..."

I entirely agree with you. In my opinion, Smalltalk has largely suffered
from the fact that it is "different" syntactically from the mainstream.
Keyword (only) messages and cascading are two areas that have hindered
it. 

Lack of declarative forms for classes, etc are another area [it depends
entirely too much on the assumption of an intrinsic IDE that will hide
various "eval" and forget expressions].

It is one of the reasons why I extended and evolved Smalltalk from the
outset of my work on the first commercial implementation version of QKS
Smalltalk in 1991.

It has been a driving force in the design and implementation of
SmallScript as new language based on a superset of classic Smalltalk.

    expr foo: arg1.

    expr foo(arg1).
 
    expr.foo(arg1).    

    a member1 member2
    a.member1.member2

Cascading is not ever required, but it is a convenience. I just wish
that the cascading operator was not a ";" semi-colon. That choice of
character conflicts with the now very established and mainstream
language use to indicate the (delimiter/terminal) end of a
statement/expression. 

It doesn't matter that Smalltalk usage/design precedes the popular
adoption of ";" as a terminal/delimiter. The reality is the "popular"
usage makes reading Smalltalk code with such ";" cascades in it, quite
difficult if you see them as terminals. 

Whereas, Smalltalk syntax is based on English punctuation, so a "." is
the terminal, and a ";" is a clause separator.  

    // C
    a = foo(expr);

    "" SmallScript [with requisite Smalltalk compatibility]
    a := foo(expr).  

Cascade (for those who read this and wonder what we are talking about):

    // C
    a fn1;
    a fn2;
    result = a fn3;

    "" SmallScript [with requisite Smalltalk compatibility]
    result := a fn1; fn2; fn3.

Given my Smalltalk superset requirement, I don't have any good answer
for eliminating the ";" from SmallScript. But, it does not have to be
exposed in most code. So generally you would only encounter it when
using browsers to look over the implementation sources to
frameworks/modules. At which point you are well past the cascade issue. 

Because, in Smalltalk at least, the investment in learning the language
is at best a few days (excluding deeper block semantics); where the real
investment is in learning and becoming familiar with the frameworks.
Noting that it is really frameworks that fundamentally lock developers
(skill/experience sets) and applications (source code) into a given
language and platform.

> Despite being a big fan of Smalltalk's semantic model - I implemented
a
> language extension product in '91 which had a metaclass model based on
> Smalltalk's - I never felt comfortable with Smalltalk's syntax.  I've
> programmed in or played with dozens of other languages, and very few
have
> put me off in the same way (APL and OCaml come to mind).  I'm sure,
had I
> forced myself to use Smalltalk, that I could have gotten used to it.
But
> these mental blocks can take real effort to overcome, and as proof of
that,
> I offer your resistance to parentheses... ;)
> 
> The real point, I think, and this is aimed in general at some of the
> broader
> discussion taking place here, is that most if not all of these
preferences
> are just that: preferences, subjective and personal.  The issue with
Lisp
> is
> that the prefix/parenthesis model is unfamiliar to most people.
They're
> taught other things in math at school, and by their calculators, even
> before
> they get to programming languages.  That doesn't mean those things are
the
> most natural - I'm sure the Romans were convinced that numbers like
> MCMLXXV
> were perfectly natural.  (The newsgroup flames when the switch to
decimal
> notation occurred would have been something to see!)
> 
> It's easy to imagine teaching prefix notation to a young child,
though:
> "if
> you want to add 2 and 3, what do you write?":
> 
> 	add 2 3
> 
> The parentheses are a short step from there.  

Sure. But why do I need them?

The form without parenthesis is perfectly understandable as a self
contained expression. 

*unless* I intend to nest them, a simple terminal character would
suffice to separate/delimit multiple discrete expressions. 

     add 2 3;  
  OR
     add 4 5.
  OR
     2 add 3;
  OR 
     2+3.

Such a terminal/delimiter pattern matches the way most human languages
are written. Where English/latin languages use ".", and many popular
programming languages use ";".

Oh, but wait, that is an entirely different mode of thinking than what
lisp mode is going to lead me into (require of me).

So, ah, yes, because I am going to nest more of these constructs I do
need a grouping construct like parenthesis. At which point I am now
finding myself needing to think in terms of nested (list) structures.

Which was my original point.

>(But switch that around to
> "2
> add: 3", and the result is clearly incomprehensible ;)
> 

I don't quite follow this latter comment.

    add 2 3
    2 add 3
    3 add 2
    2 3 add

are all sensibly parsable constructs as a human being. It also happens
that addition is (numerically) a commutative operation so ordering
doesn't matter here. Of course if these were collections and we wrote
"c1 add c2" that would generally not hold true for "c2 add c1".

So, while I think I understand the broader point, I think this is not a
good example for illustrating it. Furthermore, I think the use of
mathematical examples to explore some of these questions leads one to
inappropriate conclusions because it artificially scopes the problem
domain.

Try this:

    filestream append 'Hello'.
    filestream flush.
    filestream close.

Might be a better example to illustrate these ideas.

    "" Which with that weird cascade is:
    filestream append('Hello'); flush; close.

-- Dave S. [SmallScript LLC]

SmallScript for the AOS & .NET Platforms
David.Simmons@SmallScript.com | http://www.smallscript.org> 

> > Where, in Smalltalk, the concept of ubiquitous and consistent
> > "thing/object" semantics are directly exposed as the language.
> 
> I think this is valid, and it's a big reason why many functional
languages
> support an object capability.  I'm of the opinion that languages will
> evolve
> to have increasingly functional cores, largely because of the leverage
> that
> provides to language developers, but that languages aimed at
> non-mathematical everyday programmers will have front ends that
exhibit
> all
> the usual geegaws and warts that help make people comfortable and
> productive.  This might place some limits on, for example, how
strictly
> typed the cores can be, but that may just be part of the cost of
> ergonomics
> in languages - like a Cadillac having a greater drag factor than a
Formula
> I
> car.
> 
> Anton