The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: peter@rulingia.com (Peter Jeremy)
Subject: [TUHS] long lived programs
Date: Sat, 7 Apr 2018 07:52:40 +1000	[thread overview]
Message-ID: <20180406215240.GA57101@server.rulingia.com> (raw)
In-Reply-To: <20180406055756.A6927156E510@mail.bitblocks.com>

On 2018-Apr-05 22:57:49 -0700, Bakul Shah <bakul at bitblocks.com> wrote:
>Getting back to programming languages, I am not sure case
>distinction really helps. Many of the earlier languages such
>as Algol, PL/I, APL, Pascal, Fortran, Cobol, Lisp didn't have
>it and I don't think it was solely due to an attempt to pack
>more chars in a word.

Early APL implementations do have cases - they use underscored capitals
as a second case (rather like early Unix would use A and \A).  In the
case of APL, I suspect the limiting factor was the number of characters
on a golfball.  Internally, it required 8-bit characters to represent
all the symbols.

>Capitalization can improve legibility in
>written languages but the meaning of a word often doesn't
>change in spite of case change. In modern PLs the meaning can
>be entirely different, and even the category (DO vs do) and I
>am not sure that increases legibility.

Cases (particularly capitalisation) can add meaning - German and English
both use capitalisation as hints (I'm not sure about other languages).
Many programming languages have defacto conventions that use case to
indicate the category of a name (eg constants and macros are all upper
case in C) and Go uses capitalisation to control visibility.

The problem of "DO" vs "do" is no different to "xl" vs "x1" vs "xI" or
"DO" vs "D0" - they are distinct to the compiler but can be confusing to
the reader and are probably better handled via style conventions than
trying to mandate that the compiler makes them equivalent.

>Not to mention the
>camelCaseHorror. Much prefer hyphenated-words

Hyphenated variable names don't work in many programming languages
because "-" is an operator.  The use of camelCase vs underscores tends
to be a language convention.  Whe

Using "case-insensitive, case-preserving" helps in some cases but I
suspect at least some of that is because that is mostly how English
works and therefore English speakers will naturally read "THIS" and
"this" as equivalent.  Someone whose native language is not a latin
script is likely to find having "THIS" and "this" being the same is
quite confusing and an English speaker probably won't instinctively
see "jqvkwrri" and "JQVKWRRI" as identical.  (BTW, DNS is an example
of a case-insensitive, case-preserving service).

-- 
Peter Jeremy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180407/340e7861/attachment.sig>


  reply	other threads:[~2018-04-06 21:52 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-05 21:03 Norman Wilson
2018-04-05 21:23 ` Clem Cole
2018-04-05 21:38   ` Bakul Shah
2018-04-06  2:03     ` Random832
2018-04-06  4:27       ` Warner Losh
2018-04-06  4:31         ` Jon Steinhart
2018-04-06  4:58         ` Steve Nickolas
2018-04-06  5:02           ` Jon Steinhart
2018-04-06  4:29       ` Steve Johnson
2018-04-06  5:57       ` Bakul Shah
2018-04-06 21:52         ` Peter Jeremy [this message]
2018-04-05 22:46   ` Arthur Krewat
2018-04-05 23:23   ` Paul Winalski
2018-04-05 23:33     ` Arthur Krewat
2018-04-06  0:05       ` Toby Thain
2018-04-06  4:51 ` Dave Horsfall
2018-04-06 15:00 ` Tony Finch
2018-04-07 20:41 ` Paul Winalski
  -- strict thread matches above, loose matches on Subject: below --
2018-04-06 22:33 Doug McIlroy
2018-04-07  1:01 ` Paul Winalski
2018-04-07  1:09   ` Larry McVoy
2018-03-23 18:27 [TUHS] long lived programs (was Re: RIP John Backus Bakul Shah
2018-03-23 20:50 ` [TUHS] long lived programs Steve Johnson
2018-03-23 21:07   ` Clem Cole
2018-03-23 15:51 Ron Natalie
2018-03-23 15:57 ` Clem Cole
2018-03-23 16:25   ` Lars Brinkhoff
2018-03-23 16:59     ` Lawrence Stewart
2018-03-23 17:31       ` Steve Nickolas
2018-03-23 16:32   ` Ron Natalie

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180406215240.GA57101@server.rulingia.com \
    --to=peter@rulingia.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).