Re: ANN: Introducing AdaBase - Thick database bindings for Ada

[Georg Bauhaus <bauhaus@futureapps.invalid>]

On 21.05.16 09:01, jrmarino wrote:

> I seriously doubt anyone beyond beginner would have the slighly issue understanding the code or understanding the purpose of the variables or types based on the names.  I'll give you the style could be more uniform, and I'll give you I had no idea of the level of anal-retentiveness about things, but I will not concede that the quality or readability of the actual code is affected.  It seems this situation is the equivalent of moving Rafael Nadal's water bottles out of their perfect alignment before he serves -- something that shouldn't make a bit of differences but is crippling to somebody with OCD. :)

Some less subjective issues to consider.

- Pattern recognition: a human's capability to recognize some
arrangement of visible items is so well developed that deviations
of any kind can lead to rejection even when differences are
minor. Worse, even when rejection actually means a failure to
recognize that the thing seen is just right, structurally. In a sense:
false negatives resulting from minor pattern deviations.

- Expectations: anyone beyond beginner might have grown expectations
that he or she will find met by much software. Using any programming
language. These typically create some group pressure on authors to
(somewhat) conform in order for their work to be more welcome, pompous
and condescending as this might be. The mechanism works, statistically.
Solution below.

- Crowd addressed: All of C#, Swift, Java, Scala, Haskell, ...
use letter case and underscores in ways that make software "usual",
stylistically, even when grammatically it does not matter:
a piece of software typically needs to be "properly dressed"
to make a first impression. You know how important first impressions
are. Write an Objective-C class using Ada underscores, or
K&R C style for method names, and you're out for these reasons.
Even when the compiled structure is in line with the structure
of the system for which is was written.

- Precedent (+/-): There were two Ada bindings for OS/2. One did use
IBM's names, the other tore them apart using Ada underscores and turned
IBM's two-letter prefixes into package names, IIRC. Apparently,
some readers found it difficult to (pattern-)recognize the original
names after Ada-ification.  Which brings me to:

- Existing names: Typical database stuff names that are already known
by readers. So, whenever two things in are written in different
programming languages' names (e.g., original, binding) to denote the
same thing, then the names should perhaps be the very same, including
letter case (in a thin binding).


A tutorial example using RM style could render the issue less
controversial, and less in need of body-part psychological reference.
(Is a public Ada interface style and private body style is
useful as a means to match any author's working habits? It seems to
work outside Ada.)

I like fully spelled names in public interfaces, also types in
preference to names, particularly to composite names. Just had to
type and type again those varied names used for Base 64 Encoding
functions, while using three programming languages. Python's
incarnation ends the package name with "64", and starts method
names with "b64", "b32", and so on. Logical? Yes. Usable?
Not near the end of a workday. For me, monotonous uniformity of
naming makes focusing job matters easier.


-- 
"HOTDOGS ARE NOT BOOKMARKS"
Springfield Elementary teaching staff