Re: The task is to invent names for things
On 29/10/2021 07.07, Stefan Ram wrote: > The name should not be "optimized" for a certain use case > (as for the use in an if expression) only. "We", "have", > and "any" carry little information. A name should pack as > much information as possible in as least characters as > possible. So, for me, it'd be something like: Although, does that not imply that "pack[ing]...information" is primary, and "least characters..." secondary? How else to define "readability" (wrt 'names')? > if word_count: Yes, but this does open the door to the 'gotchas' of truthiness, ie there ain't no such thing as a free lunch/"silver bullet". Whereas, names such as: is_valid words help to imply a boolean and a collection, resp. (cf the micro-softy way of imposing the language-technicalities over naming-readability, eg bValid Thereafter, to counter the idea of not having too many names, there may be an argument for setting-up one's data to be able to code: if is_valid: while word_count: # pop word from words and do something... so now we have a data-set which includes: words: a collection, eg arriving to us from some input word: one item from words, isolated for processing word_count: a convenient expression of len( words ) is_valid: an indicator that the words received are ready for our process (not that I 'like' "is_valid" but need a specific context to improve that) The "is_" prefix appeals to me because it is so English-like (dare I say COBOL-like?) that readability is in no doubt. At the same time, whilst it could be considered and 'extra' name/extra-effort, it adds precision to the logic. YMMV! Indeed some may wish to argue that the data-set includes unnecessary verbiage, and that this in-and-of-itself might contribute to cognitive-overload... import this >> So, the obvious solution is to ask the language, like Python, to allow >> variables that are synonyms. > > Programs already have too many names in them. > There is no need to add even more, especially > when they are equivalent, and the average human can > only hold 7 ± 2 objects (like names) in his short- > term memory. +1 aka "cognitive overload" @Martin's term is "naming paralysis", which fits as a component of "analysis paralysis", cf 'let's get on with it'! (which summed-up how I felt abstracting and refactoring a function this morning - dithering and vacillating like I couldn't decide between chocolate cake or chocolate pudding...) Which point, when referred to synonym variables, gives the optimal answer: "both" (cake and pudding!) When you think about it, passing values to functions, ie an argument becomes a parameter, that can be considered a form of synonym. (and (before someone disappears off on another unintended tangent) some circumstances where it is not!) >> really good names often end up being really long names > > If they are really long, they are not really good, > /except/ when they have a really large scope. > > Names for a small scope can and should be short, > names for a large scope may be longer. Interesting! Surely as something becomes more specific, there is more meaning and/or greater precision to be embedded within the name. Thus: operator assignment_operator walrus_operator > Some very short names have traditional meanings > and are ok when used as such: > > for i in range( 10 ): For historical (?hysterical) reasons I find myself agreeing with this. (in FORTRAN any variable beginning with the letters "I" through "N" was regarded as an integer - all others being real/floating-point - thus, it is a familiar idiom. That said, this form of for-loop is reminiscent of other languages which use "pointers" to access data-collections, etc, and keep track of where to logic is within the process using "counters" - none of which are necessary in pythonic for-loops. Accordingly, there is an argument for using: for ptr in range( 10 ): for ctr in range( 10 ): (or even the complete word, if that is the functionality required) The above allowing for the fact that I have my own 'set' of 'standard abbreviations' which are idiomatic and readable to me (!). One of which is: for ndx in range( 10 ): This abbreviation originated in the days when variable-names had to be short. So, one tactic was to remove vowels*. Once again, more readable (to me) than "i", but possibly less-than idiomatic to others... That said, watching a video from EuroPython 2021, I was amused to see: for idx in range( 10 ): and doubly-amused when I experimented with the idea as-presented and 'copied' the code by 'translating' his "idx" into the English "index", and whilst typing into my own REPL, cogno-translated the thought into my own "ndx" expression. Now, I don't know if the EuroPython author uses "idx" because that relates somehow to his home-language. However, if we analyse such abbreviations, their writing is a personal exercise. Whereas, measuring/assessing "readability" involve neither
Re: The task is to invent names for things
On Thu, 28 Oct 2021 00:38:17 +, Eli the Bearded wrote: > In comp.lang.python, Peter J. Holzer wrote: > ^^ > > Those all work. But if you are writing a new web framework and you name > your method to log stuff to a remote server "Britney" because you were > listening the singer, that's not perfectly fine, even you want to make > "Oops, I did it again" jokes about your logged errors. Although Oops would be aq pretty reasonable name for a logger or error handler... > > > Elijah -- > naming is hard, unless it's easy -- After a number of decimal places, nobody gives a damn. -- https://mail.python.org/mailman/listinfo/python-list
Re: The task is to invent names for things
On Thu, 28 Oct 2021 00:41:41 +0200, Peter J. Holzer wrote: > On 2021-10-27 12:41:56 +0200, Karsten Hilbert wrote: >> Am Tue, Oct 26, 2021 at 11:36:33PM + schrieb Stefan Ram: >> > xyzzy = lambda x: 2 * x >> > . Sometimes, this can even lead to "naming paralysis", where one >> > thinks excessively long about a good name. To avoid this naming >> > paralysis, one can start out with a mediocre name. In the course of >> > time, often a better name will come to one's mind. >> >> In that situation, is it preferable to choose a nonsensical name over a >> mediocre one ? > > I don't know. A mediocre name conveys at least some information, and > that seems to be better than none. On the other hand it might be just > enough to lead the reader astray which wouldn't happen with a > non-sensical name. > > But since perfect names are hard to find, using nonsensical instead of > mediocre names would mean choosing nonsensical names most of the time. > So I'll stick with mediocre names if in doubt. > > hp Although if a mediocre name is chosen there is less impetus on the programmer to change it, "its not great but it'll do" where as a nonsense name sticks out like a saw thumb until it is corrected. I am firmly undecided -- Riches cover a multitude of woes. -- Menander -- https://mail.python.org/mailman/listinfo/python-list
RE: The task is to invent names for things
Stefan, I choose not to get involved in a discussion about arbitrary naming rules as many languages and programmers have their own ideas and preferences and rules. My examples were EXAMPLES and the actual names are irrelevant. Feel free not to use them and I assure you I have no plans to either. My POINT was that people choose names as being descriptive in many ways, often unique to themselves or to their organizations. A name that may be considered quite useful and explanatory in one context is not in another. Specifically, names chosen using American English may mean little if looked at by programmers elsewhere or if they are chosen with a sense of humor or the like, may not make sense to those who are not in on the ideas involved. Naming a variable PINK (in any combination of upper or lower case you feel like may make you think it fits when using it to count Breast Cancer patients but many will have no idea why you chose that. I strenuously disagree with many things you quote as being obviously true. Nonsense! Programs need whatever number of variables they need. There is no reason you must reuse the same variable of "i" or "index" for every loop nor why it must be different every time. Nor must names lengths be determined by the length of scopes. You are quoting, presumably, from some document outlining what a corporation or University or such are doing to try to get a consistency across their programmers. Fine, I have seen multiple CONTRADICTORY such declarations and it is often a matter of taste. In some languages I use periods in longer variable names and in others I use underscores and many times I use camelCase, Hungarian notation and others. The compiler and interpreter generally do NOT care. To bring this back to python, does it have any serious rules or informal ones as compared to others? I have seen places that suggest constants be all CAPS and Classes should be capitalized and regular variables never capitalized and endless variations on such themes. I have seen places they suggest adding parts to names such as the units so you have xxxDollars versus xxxFeet or where they want each variable to contain a similar suffix (or prefix) specifying the type of the object such as int or char or objectXY as one way to make things clearer or help prevent errors. There are MANY schools of thought and I suggest no one right way. My thought was that no matter what methodology for naming you have, it may not work quite well if the same variable is used in contexts ranging from does it currently exist, how much does it hold, is it "true" as in non-empty, or the value it has when switched to another form of measurement. It is common often to encapsulate something into an object and then use instance variables or functions to address it different ways. So an object called incomedata might be used as incomedata.count in one context and incomedata.nonempty() in another. That is not the same as my talking about synonyms. And note many languages allow you to create somewhat dynamic synonyms such as a view of a subset of something like an array using another variable and allowing it to represent the current state of the main data structure or even change selected parts. It is not at all a foreign concept to have multiple names point to the same things. Often, it helps make the code clearer. -Original Message- From: Python-list On Behalf Of Stefan Ram Sent: Thursday, October 28, 2021 2:07 PM To: python-list@python.org Subject: Re: The task is to invent names for things Supersedes: [corrected two typos] "Avi Gross" writes: >if (WeHaveAny) |Function names should be lowercase, with words separated by underscores |as necessary to improve readability. |Variable names follow the same convention as function names. PEP 8 (2019) The name should not be "optimized" for a certain use case (as for the use in an if expression) only. "We", "have", and "any" carry little information. A name should pack as much information as possible in as least characters as possible. So, for me, it'd be something like: if word_count: . >So, the obvious solution is to ask the language, like Python, to allow >variables that are synonyms. Programs already have too many names in them. There is no need to add even more, especially when they are equivalent, and the average human can only hold 7 ± 2 objects (like names) in his short- term memory. >really good names often end up being really long names If they are really long, they are not really good, /except/ when they have a really large scope. Names for a small scope can and should be short, names for a large scope may be longer. Some very short names have traditional meanings and are ok when used as such: for i in range( 10 ): . And, as a "golden rule" for refactoring, I'd say: Whe
Re: The task is to invent names for things
IMHO, I prefer really weird names. For example if I'm not sure how to name a class that I'm coding, I name it like XXXYYY (literally). Really ugly. This is a way to avoid the so called "naming paralysis". Once I finish coding the class I look back and it should be easy to see "what it does" and from there, the correct name. If the "what it does" results in multiple things I refactor it, splitting it into two or more pieces and name each separately. Some people prefer using more generic names like "Manager", "Helper", "Service" but those names are problematic. Yes, they fit in any place but that's the problem. If I'm coding a class and I name it as "FooHelper", I may not realize later that the class is doing too many things (unrelated things), because "it is a helper". The thing gets wrong with the time; I bet that most of us saw a "Helper" class with thousands of lines (~5000 lines was my record) that just grows over time. On Wed, Oct 27, 2021 at 12:41:56PM +0200, Karsten Hilbert wrote: Am Tue, Oct 26, 2021 at 11:36:33PM + schrieb Stefan Ram: xyzzy = lambda x: 2 * x . Sometimes, this can even lead to "naming paralysis", where one thinks excessively long about a good name. To avoid this naming paralysis, one can start out with a mediocre name. In the course of time, often a better name will come to one's mind. In that situation, is it preferable to choose a nonsensical name over a mediocre one ? Karsten -- GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B -- https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
RE: Re: The task is to invent names for things
Names can be taken too far as the same variable may have different connotations in one place than another. Say I am counting how many of something and incrementing variable HowMany as I go along and initialized to zero. Then I want to test if I have any and instead of: if (HowMany > 0) I decide to be cute and depend on the truthiness of HowMany like: if (HowMany) The latter is a tad hard to parse for some people and if it had been named WeHaveAny then the code would sort of make sense: if (WeHaveAny) Somewhere else in the code some other names might make sense and make the program easier to read. So, the obvious solution is to ask the language, like Python, to allow variables that are synonyms. In languages with pointers, this can often be done fairly easily. In some languages with some optimizations, it can be dangerous as some copies of this kind can later be changed to an actual copy when the underlying data changes. So, since at the moment you might not be able to do this: HowMany = 0 alias HowMany WeHaveAny Then if this feature matters to you, you could cautiously write code that declares a second variable and copies either the current value of the first or a Boolean true/false. I am sure many of us (meaning me) have often named a variable and later reconsidered once we saw the role it plays in various parts of the program and had to go back and change everything. As other have noted, it is not a trivial task and really good names often end up being really long names which are also a pain especially when other really long names start with the same characters. Compilers don't care but humans reading the code may give up! Worse, many times the code consists of longer combinations and trying to keep within reasonable (printable) line lengths gets hard. MyHumoungousDictionaryContainingElectionResults[SomeCountyInSomeStateOfTheUS ] = MyHumoungousDictionaryContainingElectionResults[SomeCountyInSomeStateOfTheUS ] + TheOfficialCertifiedVoteCountOfThisRegion -Original Message- From: Python-list On Behalf Of Karsten Hilbert Sent: Thursday, October 28, 2021 2:50 AM Cc: python-list@python.org Subject: Aw: Re: The task is to invent names for things > > I don't know. A mediocre name conveys at least some information, and > > that seems to be better than none. On the other hand it might be > > just enough to lead the reader astray which wouldn't happen with a > > non-sensical name. I was thinking that a nonsensical name might lead readers to go beyond the name when trying to understand code, and would prompt me to improve upon the name upon reading my own code (and having acquired, likely, a better understanding of the concept that's to be named). Karsten -- https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
Aw: Re: The task is to invent names for things
> Karsten Hilbert writes: > >ite is the -te form (in some uses like a gerundium) of aru > >(to go, to walk) > > This form, "行って", is written with two "t", as "itte", > in many transcriptions to convey the gemination (っ) of > the "t". There is, however, "ite", "居て", the -te form of > "居る" ("iru" - "to be"), which usually is transcribed "ite". I stand corrected, thanks. Not the first time that ite/itte slipped :-/ At any rate, it, eh, is rather malleable to word play. Karsten -- https://mail.python.org/mailman/listinfo/python-list
Aw: Re: The task is to invent names for things
> > I don't know. A mediocre name conveys at least some information, and > > that seems to be better than none. On the other hand it might be just > > enough to lead the reader astray which wouldn't happen with a > > non-sensical name. I was thinking that a nonsensical name might lead readers to go beyond the name when trying to understand code, and would prompt me to improve upon the name upon reading my own code (and having acquired, likely, a better understanding of the concept that's to be named). Karsten -- https://mail.python.org/mailman/listinfo/python-list
Re: The task is to invent names for things
On Thu, Oct 28, 2021 at 11:55 AM Eli the Bearded <*@eli.users.panix.com> wrote: > The choice of a non-sensical is perfectly fine _when_ it's a major > component. Kafka, Python, Java, Rust. Those are all non-sensically named, > in that the name doesn't fit what it is, by pun, initials, or reference. > Someone just liked the name and applied it to thing being build. The > designer of Kafka liked the author. Guido liked Monty Python. Java is > named for coffee. Rust is named for a fungus. > > Those all work. But if you are writing a new web framework and you name > your method to log stuff to a remote server "Britney" because you were > listening the singer, that's not perfectly fine, even you want to make > "Oops, I did it again" jokes about your logged errors. > More generally: You can pick any name you like if the identity of your creation is, well, entirely your creation. What does "Python" mean in terms of programming languages? It means exactly what Guido and the subsequent developers made of it. What's LPC? Originally, "Lars Pensjo C". But it became "this language", if that makes sense. I'm known as "Rosuav". What does that word mean? It means me. Nothing more and nothing less. But when you need the name to evoke some other meaning, you need to be as close as possible to that meaning. Obviously that's never going to be perfect, but the closer you can come, the more useful the name will be. The purest example would be "X meets Y" names, like a Python interface to libcurl called pycurl. Nobody has any doubts or disagreements about what that name means! ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: The task is to invent names for things
In comp.lang.python, Peter J. Holzer wrote: ^^ > On 2021-10-27 12:41:56 +0200, Karsten Hilbert wrote: >> In that situation, is it preferable to choose a nonsensical >> name over a mediocre one ? > I don't know. A mediocre name conveys at least some information, and > that seems to be better than none. On the other hand it might be just > enough to lead the reader astray which wouldn't happen with a > non-sensical name. C is named as a pun on the earlier B, which was derived from BCPL, the Barely Complete Programming Language. Unix is a pun on Multix, Linux a personalization of Unix. sed is a portmanteaux of "stream editor". AWK is named for the authors' initials. Perl started out as an initialism (Practical Extraction and Report Language, I think), which the manpage used to lead with. Ruby is named as a play on Perl, it's a different four letter gem, and Ruby has obvious Perl influence. But "Python"? What's Python named for? Hint, it's a pretty "non-sensical name" for a computer language. > But since perfect names are hard to find, using nonsensical instead of > mediocre names would mean choosing nonsensical names most of the time. > So I'll stick with mediocre names if in doubt. The choice of a non-sensical is perfectly fine _when_ it's a major component. Kafka, Python, Java, Rust. Those are all non-sensically named, in that the name doesn't fit what it is, by pun, initials, or reference. Someone just liked the name and applied it to thing being build. The designer of Kafka liked the author. Guido liked Monty Python. Java is named for coffee. Rust is named for a fungus. Those all work. But if you are writing a new web framework and you name your method to log stuff to a remote server "Britney" because you were listening the singer, that's not perfectly fine, even you want to make "Oops, I did it again" jokes about your logged errors. Where naming has a great importance to understanding, it needs to be done carefully. Mediocre names work, but can be confusing. For the remote logging example, there's probably not a lot of difficulty with mediocre. If you're doing something with a multiple of things, do you call it a "pod", "cluster", "group", "set", etc? You can pick one but then when you have multiples of multiples, you'll want to pick another and if you do it wrong it will confuse people. A Kubernetes "cluster" will run replica "sets" of "pods" (each of which have one or more "containers", but "containers" is a word that predates Kubernetes). If your framework runs "sets" of "clusters" that reversal of heirarchy ends up being more likely to confuse. Or look at the mess that AWS has for Elasticache Redis: you can have a "cluster" that provides redundancy in case something fails. Or you can run in "cluster mode" which shards the data across multiple independent nodes. If you want redundancy in "cluster mode" you can can have groups of replicas. Redis no replication or sharding: Node Redis non-cluster mode cluster: Node Replica-Node1 ... Redis cluster mode cluster no replicaion: Shard-1-Primary-Node Shard-2-Primary-Node ... Redis cluster mode cluster with replicas: Shard-1-Primary-Node Shard-1-Replica-Node-1 ... Shard-2-Primary-Node Shard-2-Replica-Node-1 ... ... Maybe this is Redis's fault or maybe it's AWS's, I don't know the history of these names, I've only used it on AWS. But whoever did the naming did a "mediocre" job to come up with something that's called a "Redis cluster-mode enabled cluster". https://aws.amazon.com/blogs/database/work-with-cluster-mode-on-amazon-elasticache-for-redis/ Elijah -- naming is hard, unless it's easy -- https://mail.python.org/mailman/listinfo/python-list
Re: The task is to invent names for things
On 2021-10-27 12:41:56 +0200, Karsten Hilbert wrote: > Am Tue, Oct 26, 2021 at 11:36:33PM + schrieb Stefan Ram: > > xyzzy = lambda x: 2 * x > > . Sometimes, this can even lead to "naming paralysis", where > > one thinks excessively long about a good name. To avoid this > > naming paralysis, one can start out with a mediocre name. In > > the course of time, often a better name will come to one's mind. > > In that situation, is it preferable to choose a nonsensical > name over a mediocre one ? I don't know. A mediocre name conveys at least some information, and that seems to be better than none. On the other hand it might be just enough to lead the reader astray which wouldn't happen with a non-sensical name. But since perfect names are hard to find, using nonsensical instead of mediocre names would mean choosing nonsensical names most of the time. So I'll stick with mediocre names if in doubt. hp -- _ | Peter J. Holzer| Story must make more sense than reality. |_|_) || | | | h...@hjp.at |-- Charles Stross, "Creative writing __/ | http://www.hjp.at/ | challenge!" signature.asc Description: PGP signature -- https://mail.python.org/mailman/listinfo/python-list
Re: The task is to invent names for things
On 27/10/2021 23.41, Karsten Hilbert wrote: > Am Tue, Oct 26, 2021 at 11:36:33PM + schrieb Stefan Ram: > >> xyzzy = lambda x: 2 * x >> >> . Sometimes, this can even lead to "naming paralysis", where >> one thinks excessively long about a good name. To avoid this >> naming paralysis, one can start out with a mediocre name. In >> the course of time, often a better name will come to one's mind. > > In that situation, is it preferable to choose a nonsensical > name over a mediocre one ? I've often debated this with myself - it's related to adding: """Docstring.""" immediately after typing a class/function/method definition - because my head is too full of the code to be written - and those linters can be clamorously insistent! Thus, isn't the answer "yes!". Cognitive over-load is the issue: We can only hold so many thoughts in-mind at a given point in time. (the size of "many" being up for debate, highly variable between individuals, and between the same person at different times or under different conditions - see also "in the zone") With today's powerful IDEs, in particular Find-and-Replace-All functions (noted that PyCharm has a Refactor facility which includes such, and with code-aware 'intelligence' cf 'blind' string-matching), it really is easier to go with a 'first thought name' and the promise of re-visiting the choice later. When 'later' arrives, eg when the value is being utilised differently (an earlier comment in this thread), there is a natural/QA process to (re-)think the name according to its different aspects over time. That said... there is a risk that you (OK, "I") don't re-visit the choice and "asdf" (easy for US-keyboard users) 'slips through' to Code Review. Oops! You do Code Review don't you? An opposing thought might be that if you have sat-down and sketched-out a design - a high-level 'how' you are going to deliver the requirements, many 'names' will be 'set' during that process - I think an integral component of Domain-Driven Design (DDD) philosophy. An eminently-sensible piece of advice underlying such thinking is that the spec/requirement should be written in the user's terms (those of the "domain"). Thus, the easiest (and accuracy/consistency promoting) path, is to maintain the use of that terminology/names all the way through from spec to code. Above also reduces my cognitive load - an appealing characteristic for such a lazy "bear of little brain"... -- Regards, =dn -- https://mail.python.org/mailman/listinfo/python-list
Re: The task is to invent names for things
On Thu, Oct 28, 2021 at 7:54 AM Karsten Hilbert wrote: > > Am Wed, Oct 27, 2021 at 10:00:16PM +1100 schrieb Chris Angelico: > > > > Am Wed, Oct 27, 2021 at 10:20:19AM +1100 schrieb Chris Angelico: > > > > > > > Many operations in computing are fully reversible. After you do > > > > something, you can undo it. After you assign, you can unassign. And > > > > after you ite, you can unite! > > > > > > I wonder whether Japanese programmers would agree. > > > > Not sure. My knowledge of Japanese is extremely scanty. Can you elaborate? > > ite is the -te form (in some uses like a gerundium) of aru > (to go, to walk) > > so, to un-go, revert-the-having-gone-ness, I genuinely wonder ... > > On the other hand, Japanese is full of wondrous word-play at > levels undreamt of by us ASCIInarians. > Ah ha, neat :) Thank you. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: The task is to invent names for things
Am Wed, Oct 27, 2021 at 12:41:56PM +0200 schrieb Karsten Hilbert: > Am Tue, Oct 26, 2021 at 11:36:33PM + schrieb Stefan Ram: > > > xyzzy = lambda x: 2 * x > > > > . Sometimes, this can even lead to "naming paralysis", where > > one thinks excessively long about a good name. To avoid this > > naming paralysis, one can start out with a mediocre name. In > > the course of time, often a better name will come to one's mind. > > In that situation, is it preferable to choose a nonsensical > name over a mediocre one ? That one was a genuine question, BTW, not a snark remark. Karsten -- GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B -- https://mail.python.org/mailman/listinfo/python-list
Re: The task is to invent names for things
Am Wed, Oct 27, 2021 at 10:00:16PM +1100 schrieb Chris Angelico: > > Am Wed, Oct 27, 2021 at 10:20:19AM +1100 schrieb Chris Angelico: > > > > > Many operations in computing are fully reversible. After you do > > > something, you can undo it. After you assign, you can unassign. And > > > after you ite, you can unite! > > > > I wonder whether Japanese programmers would agree. > > Not sure. My knowledge of Japanese is extremely scanty. Can you elaborate? ite is the -te form (in some uses like a gerundium) of aru (to go, to walk) so, to un-go, revert-the-having-gone-ness, I genuinely wonder ... On the other hand, Japanese is full of wondrous word-play at levels undreamt of by us ASCIInarians. Karsten -- GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B -- https://mail.python.org/mailman/listinfo/python-list
Re: The task is to invent names for things
On 2021-10-27 22:00:16 +1100, Chris Angelico wrote: > On Wed, Oct 27, 2021 at 9:41 PM Karsten Hilbert > wrote: > > Am Wed, Oct 27, 2021 at 10:20:19AM +1100 schrieb Chris Angelico: > > > Many operations in computing are fully reversible. After you do > > > something, you can undo it. After you assign, you can unassign. And > > > after you ite, you can unite! > > > > I wonder whether Japanese programmers would agree. > > Not sure. My knowledge of Japanese is extremely scanty. Can you elaborate? Don't know about Japanese but it works in Latin (FSVO "works"). hp -- _ | Peter J. Holzer| Story must make more sense than reality. |_|_) || | | | h...@hjp.at |-- Charles Stross, "Creative writing __/ | http://www.hjp.at/ | challenge!" signature.asc Description: PGP signature -- https://mail.python.org/mailman/listinfo/python-list
Re: The task is to invent names for things
On Wed, Oct 27, 2021 at 9:41 PM Karsten Hilbert wrote: > > Am Wed, Oct 27, 2021 at 10:20:19AM +1100 schrieb Chris Angelico: > > > Many operations in computing are fully reversible. After you do > > something, you can undo it. After you assign, you can unassign. And > > after you ite, you can unite! > > I wonder whether Japanese programmers would agree. > Not sure. My knowledge of Japanese is extremely scanty. Can you elaborate? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: The task is to invent names for things
Am Tue, Oct 26, 2021 at 11:36:33PM + schrieb Stefan Ram: > xyzzy = lambda x: 2 * x > > . Sometimes, this can even lead to "naming paralysis", where > one thinks excessively long about a good name. To avoid this > naming paralysis, one can start out with a mediocre name. In > the course of time, often a better name will come to one's mind. In that situation, is it preferable to choose a nonsensical name over a mediocre one ? Karsten -- GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B -- https://mail.python.org/mailman/listinfo/python-list
Re: The task is to invent names for things
Am Wed, Oct 27, 2021 at 10:20:19AM +1100 schrieb Chris Angelico: > Many operations in computing are fully reversible. After you do > something, you can undo it. After you assign, you can unassign. And > after you ite, you can unite! I wonder whether Japanese programmers would agree. Karsten -- GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B -- https://mail.python.org/mailman/listinfo/python-list
Re: The task is to invent names for things
On 27/10/2021 12.29, Stefan Ram wrote: > dn writes: >> On 27/10/2021 11.16, Stefan Ram wrote: >>> The Mental Game of Python - Raymond Hettinger (PyBay 2019) >>> | "The computer gives us words that do ### things. > ... >> Alternately, if your question was to identify the mumbled word, it is >> (seemed to me to be) "does". > > Thanks! > > Yes, my question was about the word at the place of the > "###". It does not even seem mumbled to me, but pronounced > with certainty and intention. That's why it makes me wonder. > As if there was a term "does things". That is a colloquialism: - my computer does things - my program[me] does stuff The "stuff" is something of a euphemism. In our profession, I would suggest it is used to avoid detail, eg as a 'signal' to a non-IT person that a more detailed answer would likely bore, or 'go over your head'. In PM-circles we identify the beginning and end of a project - the rest of the project plan 'stuff', is known as 'the miracle that happens in the middle'. Want more detail? Do we have more detail? What do I know? If a dog owner said: "my dog does things" it would again be a euphemism, but in this case employed to avoid saying something distasteful, ie that the puppy is not (yet) house-trained. That said, I suspect if you tried to use it in an English (language/literature) essay, the teacher/prof would take exception to such informality, and demand a 'better' noun! Believe it or not, my second trainee-discussion of the day included a question similarly-worded: 'why does the computer/interpreter/run-time do these things?'. Rather than 'literature', I taught this guy one of my favorite excursions into the world of poetry (the specific type of poetic stuff is "doggerel"): I really hate this dumb* machine, I wish that they would sell it. It never does quite what I want, but only what I tell it! * you might regard this word as a euphemism for another Upon which note, and your observation that I am no English-major, it's probably time we went to do things... -- Regards =dn -- https://mail.python.org/mailman/listinfo/python-list
Re: The task is to invent names for things
On Wed, Oct 27, 2021 at 10:16 AM dn via Python-list wrote: > Programmers of the world unite! > You have nothing to lose but your 0 > - or your 1 Many operations in computing are fully reversible. After you do something, you can undo it. After you assign, you can unassign. And after you ite, you can unite! ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: The task is to invent names for things
On 27/10/2021 11.21, Stefan Ram wrote: > r...@zedat.fu-berlin.de (Stefan Ram) writes: >> The Mental Game of Python - Raymond Hettinger (PyBay 2019) >> |What daddy does is make new words to make computers easier to use." > > BTW: It now also reminds me of: > > |What I Do > | > |I build paradigms. > |I work on complex ideas and make up words for them. > |It is the only way. > | > Ted Nelson (1937-) in 1998 or earlier > > , which might precede Raymonds talk. Indeed, this is how we 'invent' jargon - a short-cut to enable subject-specialists (SMEs) to inter-communicate succinctly or more accurately. What really gets me into 'grumpy old man' mode, is the predilection for our TV folk to imitate their foreign peers, or to use their own jargon/slang in a public forum. Over the decades of my career I've listened (as politely as possible) to so many (so, so, many) ordinary-folk complaining that we computer-guys talk gobbledegook, and need to down-shift and explain things in ordinary language. Sometimes this is valid - there is no point in talking to my neighbors about "ternary operators" and certainly "walrus" would create complete misunderstanding. However, a public broadcaster to think it acceptable to use such (of their) terms as "presser" (Press Briefing, or is it Press Release?), only goes to show that IT people (without specific training in (public) communication) aren't 'that bad' after all! Programmers of the world unite! You have nothing to lose but your 0 - or your 1 -- Regards, =dn -- https://mail.python.org/mailman/listinfo/python-list
Re: The task is to invent names for things
On 27/10/2021 11.16, Stefan Ram wrote: > dn writes: >> Some time ago I watched a video of a Raymond Hettinger talk. In it he >> recounted answering his son's question of 'what do you do, Dad?' > > The Mental Game of Python - Raymond Hettinger (PyBay 2019) > > Around minute 21, Raymond says: > > |I often, doo, uh, try to describe, uh, computer programming, > |uh, to kids. > | > |How many of you can tell, uh, uh, a child what a, uh, a > |software engineer does? > | > |At least one man, uh, uh, can. - One man who has. > | > |Here's my explanation: > | "The computer gives us words that do ### things. > | What daddy does is make new words to make computers easier to use." > > . An awesome explanation! > > But please help me to understand the word marked "###" above! That was quick. Thank you! (and yes, I had "Bay Piggies" in my head, but after starting to re-watch that video, moved-on because the agenda didn't seem to match) OTOH it is not exactly as I remember (which may say more about me!). Perhaps he re-used the story elsewhere - I shall investigate further... Meantime, the tape will reinforce a 'learning-opportunity' for a certain trainee and his 'algebraic habit'... Your question: Firstly, Raymond often needs to "er" in order to let his mind catch-up with his words. A lot of us do this, not because we've forgotten what to say, but because we're also listening, in QA-mode as it were, and sometimes question our choice of words - ah, back to names/words again! In this case, I'll suggest that he was already struggling with the subject of the sentence - is he talking about 'a programmer' talking to a child, or his own situation in-conversation with his son? Secondly, there is the issue of singular/plural forms - especially when formulating the sentence's object - or final clause. Thus, do I use the singular "does" because "computer" is singular, or should it be the plural "do" because "words" is plural? His first choice was grammatically-correct. Think of the pause as running pytest prior to further execution... Alternately, if your question was to identify the mumbled word, it is (seemed to me to be) "does". Thanks again! -- Regards, =dn -- https://mail.python.org/mailman/listinfo/python-list
The task is to invent names for things
Some time ago I watched a video of a Raymond Hettinger talk. In it he recounted answering his son's question of 'what do you do, Dad?' by suggesting that programmers spend much?most of their time thinking of names - and good names are better than "n = name", etc. This theme developed throughout the talk. Have searched, but been unable to re-locate this video. Do you recall the talk? Please advise its URL... -- Regards, =dn -- https://mail.python.org/mailman/listinfo/python-list