[Tfug] Language choices

[Bexley Hall]

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"

> > 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).

> >   <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 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.

> 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.

> 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).

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).

--don




 
____________________________________________________________________________________
Sponsored Link

Degrees online in as fast as 1 Yr - MBA, Bachelor's, Master's, Associate
Click now to apply http://yahoo.degrees.info