We have projects, many programmers create a system together. They have
to understand and read each others code. The project is finished and
sometimes the team works on the next project. Some other organisation
takes responsibility for maintenance. After some years very few changes
are done in the code. One person is responsible for some huge code base.
Still some changes have to be done, maybe suddenly. This person has to
dive into the code base, locate the places where he has to do changes,
do them, test and release a new version. There might be a considerable
hurry. Maybe lots of people can't do their job before this program works
again. We have to consider this when we work with programming in an
organisational setting.
This also concerns a single person seemingly working on his own in the
company. Sooner or later he leaves or get sick. If no one can replace
him because he works in an undocumented mess the company might be in big
trouble.
Computers have a problem working with acronyms because they are not
unique. To understand an acronym you have to consider context.
Acronyms create problems when you do refactoring. String search and
replace finds too many occurences.
Short names of variables and functions could possibly be called acronyms
and are often used when you are in a limited scope.
The language as such is a tool of thought. If you have to expand the
acronyms in your mind to understand the program logic, it is better not
to use them. I have a name JVerbDyadicDefine in JWithATwist. Lets say I
write JVDD instead. If the reader has to decrypt it in his head to
understand that it is a dyadic verb definition, the long name is a lot
faster to read because there is no need for this mental operation.
Programs with many acronyms the user has to decrypt in his mind are
practically unreadable because of the limitation of 5 to 7 objects a
human being can simultaneously keep in mind. To decrypt a number of
tacit J sentences and then keep in mind exactly what the resulting
functions called maybe x, y and z do is even more
complicated(understatement). And then if you don't remember the acronyms
of x, y and z you have to decrypt the sentences again and again in your
mind. Or you have to rewrite the code so that it is readable.
Well, and I think when you use an acronym you often have to pick up the
long name in your mind to remember the acronym. And if you don't
remember the long name you don't remember it's acronym.
Maybe we should move into development environments like Eclipse and
Visual Studio? No need to retype long names of variables and functions
at a prompt? Work like most other developers? Even Emacs and Vi is a lot
better than what most of us use for J development? No need for long
arguments with rationalizations of why we work totally different
compared to developers in other programming languages?
/Erling
On 2016-08-11 17:28, Don Guinn wrote:
Long names, though help self document, make reading difficult. This is not
a problem unique to programming. News articles and technical papers use
acronyms to simplify. First they list out the full name then put an acronym
in parentheses after it. Then use the acronym in the rest of the article.
Like this - "National Aeronautics and Space Administration (NASA)" or
"Federal Bureau of Investigation (FBI)". After a time some common acronyms
are used so much that everyone recognizes the acronym and it is no longer
even necessary to give the full name. Just use the acronym.
A similar thing could be done for large programs. At the top comment the
acronym to be used in the program and its full name. For me, after a while,
I recognize the acronym immediately and I don't have to use or type long
names.
On Thu, Aug 11, 2016 at 8:42 AM, Erling Hellenäs <[email protected]>
wrote:
On 2016-08-11 16:23, Tracy Harms wrote:
On Aug 11, 2016 10:09 AM, "Erling Hellenäs" <[email protected]>
wrote:
In most common programing
languages today names of functions
and variables are long. The program
and the environment is often complex.
Long names are needed to describe
complex operations in a complex
environment.
Names can be long in J. There is a cultural norm for using short names in
J, one that can be traced back to algebra and other writing practices that
pre-date computers, but it isn't a language feature. This entire topic
seems disconnected from both your alternative notation and your criticisms
of the J language.
Yes, I said:
"I can see no reason whatsoever to try to make the syntax extremely terse."
Raul said:
"There actually are reasons to use short names - they are faster to
type, they fit in tweets, and they are more manageable in a "let's try
another variation of this again" than the longer names. That said, you
can look at things like OpenGL as a counter example - here, we have
long names and lots of them. But here also we have problems with
people declaring frequently used chunks of it "deprecated" despite how
many frequently used things would break if people actually stopped
supporting the older stuff."
It seems like a deviation from the original subject, yes. I talk about
words in the meaning of J words like verbs, adverbs and conjunctions. Maybe
Raul misunderstood or its he's just generalizing. Or I misunderstood him.
If you want to use long names in J, go ahead and do so.
Yes, you can. I did and showed in the forums. I never saw anyone else do
it.
Tracy Harms
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
