[Tfug] Language choices

[Stephen Hooper]

On 11/7/06, Bexley Hall <bexley401 at yahoo.com> wrote:
> Hi, Stephen,
>
> > >   APL actually isn't terribly bad when it comes to
> > > punctuation.  The problem is you need an APL
> > > typeball to use it!  :-/  If you replaced the
> > > symbols with ASCII tokens, it wouldn't be bad
> > > at all.  (though crappy for my needs!)
> >
> > Is your complaint with non alphabetic characters?
>
> My gripe is about "languages" that use punctuation
> that isn't normally "spoken".  E.g., it is *natural*
> to say:  "A equals B times 3 minus 5"
> So, the +-*/= etc. carry no cost (in terms of
> conveying their presence to the listener).
> OTOH, the parens around, e.g., (3-5) are not
> obvious from that textual rendering.   And, if
> you are NOT computer literate and don't realize
> the significance of them, their omission can
> result in a miscommunication.
>
> For example, when I am "proofing" PCB layouts
> (best done as a two member team), I need to make
> sure the other person understands the characteristics
> of the components that are being used.  So, when he
> calls out that a certain trace (signal) runs to
> "C15", I need to know that the fact that he has
> *simply* said "C15" implies that C15 is an NPO
> device.  OTOH, had C15 been polarized, I would have
> expected him to say "the high side of C15", etc.
>
> > In that case, you could argue the same thing about
> > any language:
>
> Sure, but I'm assuming USASCII as the character set
> and western european "languages"
>

So assume you substitute each APL char, with one unused ASCII char.
You are going to end up with punctuation...  more than tweny-six.

> > > But, it is amusing to compare the amount of
> > >cruft in, e.g. Perl or Java, vs. "older"
> > > languages...
> > >
> > > ASM (VAX -- including macro capabilities)
> > >   a=b a=. a+b a-b a*b a/b
> > > label:
> > > .directive
> > > @pointer
> > > (address) (address)+ -(address)
> > > @(rn)+
> > > (rn)[rm]
> > > <expression>
> > > $macro
> > > ?parameter
> > > a,b
> > > ; comment
> > > #constant
> > > /string/ "string"
> > > ^Bbinary  etc.
> >
> > Yeah... but machine doesn't have any punctuation.
> > Put a different way, you are way off in orange
> > land, trying to find apples :)
>
> But, expressing *algorithms* in this mechanism
> (language) is the problem.  Not whether or not
> the machine actually "recognizes" that graphology.
>
> > >   (Dartmouth) BASIC
> > >   -a +a
> > > a+b a-b a*b a/b a^b a,b
> > > a=b a>b a>=b a<b a<=b a<>b
> > > stringtype$
> > > "string"
> > > function()
> > > array(b)
> > > (expression)
> > > PRINT;
> >
> > I think you are now not arguing non-alphabetic (or
> > punctuation characters), as you have parentheses,
> > minus sign, etc. listed twice.
>
> I was trying to think of *how* punctuation was used
> when tabulating it all.  Note that if a particular
> symbol is used in lots of different contexts, then
> it proves to be even more "litter".  E.g., LISP
> has very little punctuation.  But, its extensive use
> of parens ("silent" punctuation) makes it a bitch.
>
> > >   C++
> > > 'a' "a" '\a' \0a (significant leading zero)
> > \xDEADBEEF
>
> Grrrr... HTML interpreting my backslashes wrong. :<
>
> > > case:  statement;
> > > /* comment */   // comment
> > > function()
> > > function(...)
> > > (expression)
> > > a[b]  "a_string"[b]  ("read" differently than
> a[b])
> > > #define
> > > { block }
> > > plus all the overloading allowed (which increases
> > > instances of symbols)
> >
> > So now we are into symbols?    I thought you wanted
> > something with the least amount of "punctuation"
> > characters so that it could be read to
> > you over the phone.
>
> Would you prefer I call them "graphemes"?  :>

> My point was, if you can overload the "+" operator
> (addition, string concatenation, union of sets, etc.)
> then it tends to appear more often in "programs".
> Just like '=' appears so frequently in C programs
> because it is part of so many "legal" operators
> (=, ==, +=, >=, !=, >>=, etc.)  Likewise, parens
> used in functions, array declarations, expressions,
> etc. (in some languages).

Yeah... but that just speaks to the mean, not the count ... am I wrong?

>
> > >   <shrug>  When you look at BASIC, FORTRAN, PL/1,
> > > etc. they really *do* look a lot "cleaner" in
> > > this regard, eh?
> >
> > If by cleaner you mean that they will have less
> > punctuation per line, then yes, I guess they might.
>
> That actually isn't a "given".  I was amazed when I
> was writing little code snippets at how "few" symbols
> can still turn up with a very high frequency!  (e.g.,
> lisp)

I was guessing... it does get back to the mean, and the count doesn't it?

>
> > I would also argue that if you are just looking at
> > punctuation characters that will be present in any
> > given code listing you will find that there is
> > pretty much the same number in most languages.
>
> I think it depends on the capabilities of the language
> (my original point).  E.g., things that aren't object
> oriented have no punctuation associated with those
> semantics.
>

Yeah, but if you use those semantics appropriately a program will
actually end up having fewer lines than what you would otherwise have
to do in a non-fluff language... otherwise why write anything but
structured languages, or languages with hashes (or languages with more
than one variable, etc.)...

> > It is true that you may end up cramming more on a
> > line in Perl for example than in BASIC.
>
> A problem with C, C++, Java, Perl, etc. is they have
> a sh*tload of operators that are redundant.  E.g.,
> damn near all of the OPERATOR= operators are just
> syntactic sugar.  They save a few keystrokes and
> don't really increase comprehension or provide
> new functionality.
>

Well... I disagree with the first part, but can accept your argument
about the second part.

> > For example, do this in BASIC:
>
> [snip]
>
> But my stated goal was "a lightweight scripting
> language".  :>  If you look at the tablet press
> examples, I think you'll see that those sorts
> of things don't require all that "fluff".
>
> And, that extra, unused features are a liability, not
> an asset (since they allow the user to unwittingly
> write something that he doesn't mean).  E.g.,
>
> if (station = 27)
>   then reject_tablet();
>
> would cost a company a LOT of money -- since the
> conditional would be TRUE always.  So, a language
> (C) that treats '=' and '==' differently invites
> these kinds of screwups (once a tablet is rejected,
> it can't be salvaged -- like digging through the
> trash).
>

It would be pretty stupid to ask the "programmer" to program on a
"live" machine then wouldn't it?

Otherwise put, "Our quest for the programmer proof language continues!"

> I think the problem is getting out of the "computer"
> mindset and into the "user" mindset.  Given that
> the user may be in many different application
> domains (for my needs).
>

No... I think the problem is that you are pretending that it is harder to read:

*=+.!@#$%^&*(){}"\''\""

than

((()()(((())()))(()))

Seriously, strip out all the non-punctuation characters in a  program
written in one of your non-fluff languages, and then strip out all the
non-punctuation in a program that you think is written in a fluff
language.

Is one really that much better for a user?  What are the counts?  I
would say that after six, seven punctuation marks people will begin to
make mistakes in the reading of the language.

That is assuming they understand the punctuation, skewing  lines, etc.
 If they don't, then I think you may be lucky if they can read you a
complete programatic statement without hating you for saying, "that
doesn't make sense" after every line they have read.

And to speak to that, and the above thought about the pills being in
the trash...

No offense meant to your users, but there is a reason that we aren't
all programmers.  If you are asking them to be programmers, then the
first thing they should understand is that with great power, comes
great responsibility.