In my experience, the organizational problem gets handled through redundancy.
This, of course, comes in direct conflict with budget issues, so there is always some tension there. Also, personalities come into play, which often leads to bad decisions (which can be good, since that tends to highlight issues needing attention). Anyways, I do not doubt the need for well documented interfaces, and well understood behavior (for mechanical systems). But, of course, the better the technical people do their jobs, the more you get managers who say stuff like "make it like it was" or similar things. Anyways, organizations are all just people and you have to learn to deal with them (which sometimes means taking responsibility for something frightening all on yourself, and then (a) trying to get it fixed and (b) trying to make sure that the social wheels keep turning like they should have been. If you've a broad experience base, you are probably better at this kind of thing (and, being a jack of all trades, worse at most things). ... So the trick is to design and build things so that they can be replaced, and then sell other people on this idea (and, also, that right now there are better things to spend time on). Or, that is my opinion... If you are working with a lot of programmers, the trick becomes getting them focussed on useful issues and on getting things to the point where they are good enough (or mostly so), and then trying to think ahead to where the problems are coming from. The exact approach here, will tend to be different in different organizations (and that is a good thing). And this is why you get push back on generic statements about best practices. And this also relates to why there are so many standards to choose from. And, this relates to a variety of other issues. I will say this: when I try to use Eclipse, I spend more time trying to figure out which things to pick from which part of the system than I spend re-studying J vocabulary (when I program in J). I am also far less productive in Eclipse than in J. But that doesn't matter, because sometimes taking that one line of J code and putting it into Eclipse is a good idea, even though it takes so much time asking around and figuring out which wizard I need to use and which thing I need to download, because - despite the whole malware problem - it's still easier to give java to someone else to execute than it is to give J to someone else to execute. (Or, I think it is... my last attempt failed, so maybe this has changed...). Thanks, -- Raul On Fri, Aug 12, 2016 at 4:35 AM, Erling Hellenäs <[email protected]> wrote: > 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 ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
