Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
What is the correct plural form of the portmanteau mutex. Is it mutexes or mutices?
From a purely linguistics point of view, the correct usage is mutexes because the word mutex is not Latin in origin. Prescriptivists would wail in anguish if mutices were to enter regular usage.
The -ices usage (e.g., the plurals of index and vertex) is falling out of favor. Indexes and vertexes are both correct usage, for example.
Let their common usage decide...
GoogleFight
Everyone knows that the correct answer is Mutii.
Mutexes. It's correct in a de facto manner--- the vast majority of people (in my experience, certainly) call them mutexes, not mutices, and English is a language that's defined by use. :)
As mutex is short for "mutual exclusion", I would only imagine that "mutual exclusions" would become mutexes. Mutices would be confusing. Better to be unambiguous.
As a side note: it's not a portmanteau, or it would be a mutsion.
There's no official correct form because 'mutex' hasn't gained wide enough circulation to enter any of the major English dictionaries. Thus, the most correct term is whatever is used most by people. And I think that Google hits are a pretty good indicator of (relative) usage frequency, as great_lama has pointed out.
Other English nouns that end in -ex or -ix:
Affix
Annex
Apex
Appendix
Cervix
Circumflex
Complex
Cortex
Crucifix
Duplex
Helix
Ibex
Index
Infix
Latex
Matrix
Phoenix
Prefix
Postfix
Reflex
Remix
Suffix
Vertex
Vortex
And lots more less common words. If you look up these in the dictionary, you'll find that most of them have both plurals shown as acceptable. Several have only the -exes/-ixes form, but few or none (depending on the dictionary you use) have only the -ices form.
In conclusion, I believe mutexes to be the correct plural form of mutex.
Either/or. I've seen both (though mutexes is considerably more common).
Mutex is not in any real dictionary I know of, so there's no "official answer."
Index can be pluralized to indexes or indices, though, so it makes sense that mutex could follow suit.
Since the word apex can be pluralized as either apexes or apices, I'd say you can pronounce it either mutexes or mutices. Whatever suits you.
I think that the hysterical raisins (in this case the fact that "mutex" is a portmanteau) should not be given too much weight in resolving such issues.
Perhaps it would be more useful to consider similar words and their usage; reflex -> reflexes for example.
Or, use the simplest choice: most pluralizations in english use -s/-es (depending on whether last letter is a perceived vowel); in this case -es.
I guess I can't see any reason to use the alternative, except as some sort of tribute to Latin, once thought to be the noblest of all languages. :)
Maybe it is like sheep? Singular and plural?
Related
According to this comment from the general question Is it possible to create a quine in every turing-complete language? it seems like it is said that it's possible.
However I didn't find any Ook! Quine on the internet.
Do you think that it's really possible?
And if yes will we be able to find it?
It wouldn't even be very difficult. You would want to code it in brainfuck and then translate, and the internal representation for each command should be a pair of numbers (probably from 0-2) to represent the punctuation of each half-command. You could borrow much of the structure from Erik Bosman's brainfuck quine.
Updated: here. https://gist.github.com/danielcristofani/1fe53487df1f7afcb5b91c06d95184b2
This is ~40 commands taken directly from Erik Bosman's quine, another ~120 freshly written commands of rather clunky output code to handle Ook!'s verbosity, and then the data segment to represent all that.
As I read STM32 example code I see a fair number of variables that begin with uw. Ex:
static __IO uint32_t uwLsiFreq = 0;
__IO uint32_t uwCaptureNumber = 0;
__IO uint32_t uwPeriodValue = 0;
__IO uint32_t uwMeasurementDone = 0;
Everything has a meaning or a story behind it. What does uw mean here?
Example Source: STM32Cube_FW_F2_V1.7.0/Projects/STM32F207ZG-Nucleo/Examples/IWDG/IWDG_Example/Src/main.c.
Download link --> click "Get Software" button next to "STM32CubeF2".
Alright, I'd like to post my own, more complete answer. Thanks to #njuffa for pointing out in a comment below my questions that "Probably: uw stands for 'unsigned word' in some sort of Hungarian notation," thanks to #PeterJ_01 for pointing out that the CEO of Stack Overflow has some opinions on the matter, and thanks to #Sigve Kolbeinson for pointing out in a comment under PeterJ_01's answer that the CEO of Stack Overflow's name is Joel Spolsky (as found in the link), he actually doesn't hate Hungarian notation, but rather is just upset a limited and corrupted form of it [Systems Hungarian] got traction for a while, and for giving us the actual link to the article so we can learn more and read the article ourselves.
1. Here's my conclusion to answer my question:
uw at the beginning of many STM32 example variables certainly must logically mean "unsigned word," where a "word" is 32 bits in this case. Knowing this adds a lot of clarity as I read the code, and removes some confusion about the names, so I'm glad to know this.
In this case, this is a type of Systems Hungarian usage, which is frequently discouraged for languages which have explicit types, such as C and C++, since it's redundant and adds little value. Contrast this to Apps Hungarian, which I describe below, which Joel Spolsky (CEO of Stack Overflow) strongly promotes as a way to help make "wrong code look wrong."
2. Here's some additional insight (primarily about Hungarian Notation) I learned along the way from #Sigve and #njuffa via their comments and the links they provided:
You might just call this section "what exactly is Hungarian notation in computer programming?"
Hungarian notation exists (I didn't know about it before), and refers to the concept of adding a few extra characters at the beginning of each variable and/or function name to provide additional information about the variable or function, such as its purpose, its type, or its return type.
Inadvertently this answered my question about FreeRTOS naming conventions too. Now I know! They use [primarily Systems] Hungarian notation as well. Here's some links. Note that in the first link you'll see a list of all of the Hungarian notation usages in FreeRTOS. This notation is almost entirely Systems Hungarian notation, but arguably uses a little bit of Apps Hungarian notation too when they specify the name of the file in which functions and macros are defined right inside the function or macro name.
FreeRTOS Hungarian Notation
what is v and x means in freeRTOS task creating or used in it?
https://www.freertos.org/FreeRTOS-Coding-Standard-and-Style-Guide.html#NamingConventions
Hungarian notation has two main forms: Systems Hungarian and Apps Hungarian. See their differences here.
Systems Hungarian is essentially a corruption of the original intent of "Hungarian" notation that came about when it's creator, Charles Simonyi's, mistakenly used the word "type" instead of "kind" in his description of it (source). Charle's original intent was to encode additional information into variable names that isn't inherent in the programming language itself. However, Systems Hungarian notation says basically to store the variable's type into the variable name. Ex: unsigned long myVar now becomes unsigned long ulMyVar. Most people seem to argue this is either of limited use or completely worthless. Joel Spolksy is not a proponent of this form of Hungarian notation, as indicated in his article, but he is strongly for Apps Hungarian style. Other opinions can be found in the "Notable opinions" section of the Wikipedia article here.
Apps Hungarian describes the concept of storing additional information into the front of a variable name which can NOT otherwise be easily deduced, such as using us to mean "unsafe string" and s to mean "safe string". Many people either feel more neutral towards this method, or like it and promote it. Both Joel Spolsky (CEO of Stack Overflow) and Steve McConnel think it's a good idea and promote its usage.
Note, here's a useful excerpt from Joel's article:
Somebody, somewhere, read Simonyi’s paper, where he used the word “type,” and thought he meant type, like class, like in a type system, like the type checking that the compiler does. He did not. He explained very carefully exactly what he meant by the word “type,” but it didn’t help. The damage was done.
Apps Hungarian had very useful, meaningful prefixes like “ix” to mean an index into an array, “c” to mean a count, “d” to mean the difference between two numbers (for example “dx” meant “width”), and so forth.
Systems Hungarian had far less useful prefixes like “l” for long and “ul” for “unsigned long” and “dw” for double word, which is, actually, uh, an unsigned long. In Systems Hungarian, the only thing that the prefix told you was the actual data type of the variable.
This was a subtle but complete misunderstanding of Simonyi’s intention and practice...
(emphasis added)
It means unsigned word in this naming convention. Almost not used now. But some people love it as it shows them what type the variable is. Another ones hate arguing that it is one of the worst programming habits (including the creator of the Stack Overflow ).
IMO it does not matter
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 2 years ago.
Improve this question
NetBeans 7.4 beta is currently available for public download, and it introduces a weird warning rule by default:
Method length is 16 lines (10 allowed)
My question is: Is this an accepted code convention rule, that can be proven somehow, somewhere ? NetBeans support/devs say it's not a bug, but don't give a statement why they only allow 10 lines, and where exactly this rule has its origin.
You can change the maximum method/function length warning behavior in NetBeans options (it's under Tools->Options->Editor, in the Hints tab, under "Too Many Lines" section in the checkboxes list).
There you can set the maximum number of lines, how you would like to be warned, etc.
I believe that the rule was introduced by NetBeans developers because when working in teams, the automated tools that QAs use to "inspect" code flag long method declarations/functions bodies. Unfortunately, the use of automated tools by "code analysts" is on the rise, whilst their understanding of the reasons behind that are still limited. I do not say that your functions should be hundreds of lines long - that's just plain wrong, but a hard-coded number as a coding law - come on!
The "10 lines rule" has to do with enforcing test-driven development. The theory is that any method that has more than ten lines can be better broken down into units that are testable. it holds up in theory, but in practice a warning like this is more annoying than helpful.
I think there is not a convention about that, and it's very hard to make small functions in particular working in big projects.
I feel that the problem in NetBeans (or the rule) is counting lines with just one bracket or documentation.
This article gives him opinion about write functions with 5-15 lines.
I always disable this warning, as well as the warning about too many nested blocks. I understand the idea around not having large methods but a LOT of the time it's just not practical, and as someone else mentioned if you keep splitting your code into arbitrary functions just to appease the IDE you end up with spaghetti code jumping all over the place, refactoring becomes a huge problem later on as well.
Same as the line length limit warning, maybe a line 50 characters long made you scroll sideways in 1985, but today we have larger monitors (in color now as well!). I've seen people mutilate a line of code by shortening variable names so that it fits within the limit, turning a perfectly readable line of code into an indecipherable mess just so it fits within the limit.
Personally I think those three rules together have caused more garbage spaghetti code than helped create readable / testable code.
I think there is no such rule. I always thought a good convention would be no more lines of code in a class than one can read without scrolling. 10 lines seems not very much for me but in general it's for overview purposes and easier testing..
Can the existing Marpa parser be used to improve parsing of Perl 5 (e.g., replace all or chunks of existing Perl interpreter's parser)?
I am asking on a theoretical level, e.g. ignoring practical considerations such as "if it can, it would cost 10,000 man hours of work".
If not, what are the specific issues preventing the use of Marpa? (again, preferably theoretical ones).
For background of why this is interesting, Jeffrey Kegler (Marpa's author) has posted a somewhat famous article "Perl Cannot Be Parsed: A Formal Proof" on PerlMonks in 2008, which was influenced by his then-current work on Marpa.
Thanks for asking. The perlmonks post and my current parsing work address two different if related questions. Question 1: Is Perl parsing, in its full generality, decidable by a Turing machine? Question 2: Can Marpa, as a practical matter, parse Perl 5?
You might compare the two questions: "Is the behavior of every C program decidable?" and "Can machine X run programs compiled in C?" The answers are, respectively, "no" and "yes for all practical purposes and reasonable choices of X". So my perlmonks post (updated here) is about the theoretical question of whether the syntax of Perl programs in, in its full generality, decidable. Note that the decidability of Perl parsing in that context has nothing to do with Marpa, recursive descent, bison, etc. -- it's about Turing machines.
Question 2 is "Can Marpa drive a practical Perl 5 parser?" The current Perl 5 parser is LALR, with a separate lexer and lots of procedural assistance. Marpa is more powerful than LALR, allows a separate lexer, and offers much more help to procedural code than LALR does. I addressed the speed question in a recent blog post: "Is Earley parsing fast enough?" What I've just said is very telegraphic -- but I hope it will do to outline how I'd justify my "yes" answer to Question 2.
No deep architectural problem stands in the way of a Marpa-driven Perl 5 parser. At this point, it's really a question of comfort level.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
It is well known that different people have different aptitudes regarding various programming paradigms (e.g. some people have trouble learning non-procedural, especially functional languages. Some people have trouble understanding pointers - see Joel Spolsky's blog for musings on that. Some people have trouble grasping recursion).
I was recently reading about a study that looked at how the grammar of someone's native language affected their speed of learning math. Can't find that article now but a quick googling found this reference.
That led me to wondering whether someone's native culture or first language might affect their aptitude towards various programming paradigms. I'm more curious about positive influences - e.g. some trait that make it easier/faster for someone to learn a particular paradigm, for example native language grammar being very recursion-oriented.
To be clear, I'm looking for how culture/language grammare may affect the difference between aptitude of the same person towards various paradigms as opposed to how it affects overall aptitude towards programming between different persons.
Important: the only answers I'm interested in are either references to scientific studies, or personal observations from someone intimately familiar with a particular culture/language, including from their own experience.
E.g. I'm not interested in your opinion of how Chinese being your first language affects anything unless you speak Chinese or worked with extremely large set of Chinese-native programmers extensively.
I'm OK with your guesstimates not based on scientific studies, but please be sure to supply your reasoning about plausible causes of your observation.
I'm not interested in culture-bashing (any such commends will be deleted or flagged for deletion).
I'm also not particularly interested in culture-building - we all know Linus is from Finland and Tetris was written in Russia and Larry Wall is an American. Any culture/nation can produce a brilliant mind in any discipline. I'm interested in averages.
Disclaimer: I was a Cultural Anthropologist before I got into programming, so you know I'm going to be on a high horse, here.
Obviously, a person's history will have an impact on their aptitude for any particular task, but I think this has less to do with the structure or grammar of a person's language than it does with the particular material conditions of the culture in which that language is spoken.
For example, a pair of Anthropologists in the 60's went to various African communities and tested people's susceptibility to various optical illusions. Here is a classic one:
In this illusion, the bottom line looks longer, because the angled lines connecting it make it appear to be off in the distance.
These Anthropologists found that in many African cultures, the illusion doesn't work at all - people consider the lines to be the same length. By refining their study, they found that the only people who were susceptible to the illusion were people who had grown up in an urban environment. They hypothesized that the illusion did not work on people from remote jungle environments, because these people had little or no experience with right angles and seeing things at very long distances.
My point with this is that even if you successfully found a correlation between programmers' native languages and their abilities with certain aspects of programming, you couldn't be sure that the correlation wasn't spurious. For example, you might think that Asians tend to be bad drivers, and you might even be able to demonstrate this statistically. If you then concluded, however, that "bad driving" is some sort of fundamental characteristic of Asian-ness, you would be ignoring the fact that Asians are more likely to be from Asia, and thus to have had much less experience driving cars (or even being in cars) while growing up than Westerners (and especially Americans) have had.
With programming, we might think that a particular language inhibits programming ability, and not take note of the fact that the society in which that language is spoken has much less access to computers, and thus people growing up with that language appear to have less programming aptitude or ability to understand certain programming concepts.
In short, I wouldn't give much credence to the idea that language inhibits anyone's ability to understand anything in particular. The human mind is much too flexible and adaptable for that to be true.
This seems analogous to the Sapir-Whorf Hypothesis - that the facilities of a language affect the ease which which one can cogitate about certain subjects, or in the words of the Wikipedia article:
"The linguistic relativity principle (also known as the Sapir-Whorf Hypothesis) is the idea that the varying cultural concepts and categories inherent in different languages affect the cognitive classification of the experienced world in such a way that speakers of different languages think and behave differently because of it."
( http://en.wikipedia.org/wiki/Linguistic_relativity )
While there appears to be little definitive information here, the discussions appear to be relevant to the question, and perhaps worthy of further exploration.
Just a few random thoughts. I think the influence is generally very weak and can most of the time be neglected but they do exist and sometimes they can make us feel them.
In Chinese grammar, for example, we don't quite distinguish between plural and singular forms, but I wouldn't think we Chinese have any noticeable difficulty understanding the concepts of scalar and array in Perl. The reason might be this: although we generally don't need particular suffixes or changes in form to indicate whether something is singular or plural, we do have the concepts of plural and singular and we mostly depend upon the context to tell them apart. Grammar-wise, the context in Chinese may possibly be way more important than that in those languages belonging to indo-european family. We omit a lot of things sometimes when they have already been mentioned and sometimes when we just presume that these things can be implicitly well understood by the listener. In either case, we don't need those indefinite and definite articles (a, an, the) or those relative pronouns like, that, which and who, to indicate whether they're being mentioned for the first time or yet another time again. Maybe that's partially why I feel very comfortable with Perl's default variable "$". print; chomp; split; all act upon $, which has never ever been mentioned. But this is quite subjective.
I think the Chinese language is more characterized by implicitness and fuzziness than Indo-european languages. For example, We never ever pay attention to subject verb agreement and we never ever do verbal conjugation to denote tenses. This could mean that the Chinese are inclined use a not quite so logical mode of thinking. One of my teachers onced used an example to try to generalize (or maybe over-generalize)the difference between Chinese non-logical mode of thinking and American logical mode of thinking.
If the American version of quarrelling should be this:
“I can lick you.”
“No, you can’t.”
“Yes, I can.”
“No, you can’t.”
“I can.”
“you can’t.”
“Can!”
“Can’t!”
The Chinese version (translated in English) would be something like this:
I can lick you.
How dare you!
What if I dare?
Then you try.
Try? Hm, you wait and see.
Wait and see? I’m not afraid.
Not afraid? OK. You don’t run away.
Who runs away? Come on and lick
Well, I agree that there may be some differences between Chinese way of thinking and that of other countries but the example looks like a stereotype because the Chinese may easily switch to the use of the American version. Back to the question, I think the language and culture may indeed influence a programmer's learning process in one way or another but this influence is defninitely not decidingly noticeable. Maybe because of the culture you're exposed to makes you feel a little bit uncomfortable to get used to some notions in some programming language, recursion or whatever, but time will solve it.
I was recently reading about a study that looked at how the grammar of someone's native language affected their speed of learning math. ... Important: the only answers I'm interested in are either references to scientific studies, or personal observations from someone intimately familiar with a particular culture/language, including from their own experience.
I learned a lot of maths before I started programming (enough to count as "intimately familiar"), and IMO programming is relatively easy: more tangible.
Sometimes I've wondered whether it's beneficial to know more than one human language: if you only know one language, then you might think of the words "cat" and "dog" as being values, i.e. synonymous with cat and dog objects; but if you're fluent in more than one language, then "cat" and "dog" become pointers: because for example the French words "chat" and "chien" are referring/pointing to the same objects as "cat" and "dog", and so clearly there's a distinction between the word and the object.
It's disappointing that you post the question without linking to the article which inspired it. I thought of "reverse polish notation" and wondered whether that was at all the kind of differences in "grammar" that were considered in the original study.
The reference you cite seems to rest on the assumption that making it easier helps with learning. In my understanding, there is a countereffect: without enough challange, you're not learning enough.
There are theories/studies (anyone with a link?) that development of language created crucial pressure on expanding the cerebral cortex and thus "made us human". (in very darwinistic terms: more grey matter ==> better language capabilities ==> better teamwork ==> better survival as a group). So language complexity can't be all bad for learning.
(My only qualification is being an eager follower of The Frontal Cortex blog, so take this with a grain of salt.)
In german we have a strange ordering of numbers: 10^0 and 10^1 positions are switched, but others are normal, (e.g. 25 is 'five and twenty', 125 is 'one hundred five and twenty'). It's been claimed that this makes learning numbers harder, and thus german should adopt a more intuitive ordering.
I guess that it helps a lot with doing additions in your head - at least if you stay below 100 or 200 - You can first add the 10^0 position and already say it / write it down while taking any carry into account for the 10^1 position.
(That doesn't continue for 10^2, I guess that would be done in writing by the majority anyway)
Also: abstractions. There are languages where numbers aren't abstracted from objects, "two coconuts" and "two sabretooth tigers" don't share a common "two" word / concept. Such a language would probably be very bad for developing math skills. Here the abstraction (separating number and object) in language is important.
Generally, I'd say the language has a strong effect on shaping a developing mind, and I see no reason why this should not extend to culture.
Of course it's still open what would be the "right kind of complexity" - for what, and how particular language features affect general improvement vs. establishment of an elite (i.e. "sharpening the skills of the gifted, while hampering the rest").
Interesting Question, no doubt - looking forward to other replies.