Electronics > Beginners
Exponents
Nominal Animal:
--- Quote from: ebastler on April 10, 2019, 03:15:25 pm ---
--- Quote from: Nominal Animal on April 10, 2019, 02:52:57 pm ---In general, because many programmers aren't that good at math and changing the precedence/associativity rules when your users have gotten used to them would be downright evil, one must assume that software environments do not always parse or compute expressions correctly.
--- End quote ---
You have a point there, but nevertheless it's pretty disappointing. By the same token, you could argue that one should expect some spelling errors in programming languages' keywords -- programmers aren't that good at spelling, and cannot break backwards compatibility once a language has been rolled out. But I have yet to see a language with a "prnit" or "inputt" command. ;)
--- End quote ---
Would color vs. colour suffice?
Kidding aside, typos are different from spelling errors, and spelling errors are in fact quite common in various APIs. Typos are usually caught by other developers (or the developers themselves after a while), but spelling errors do creep in; mostly in library interfaces, since the core languages tend to get reviewed by people who can actually spell before they become too widespread to fix. The first example that comes to mind that I've seen in a library is parallell instead of parallel.
A real example of a syntax mistake is print in Python 2. Although it is a function, it did not require parentheses around its argument. This was corrected in Python 3. (A counterexample is return, which is a statement and not a function, and therefore does not need parentheses around the argument(s).)
That might look like pedantic picking, but the difference does matter at the implementation level a lot in Python. In C, it is actually very important: for example, sizeof(i++) does not increment the value of variable i, because sizeof is an operator that evaluates to the size of its argument without evaluating the argument for side effects (like increments, decrements, or memory accesses). This, and similar issues with optional macros (assert() et cetera), often surprise new programmers, and cause hard to debug problems.
(They are not hard to debug because they're difficult to see, quite the contrary; they are hard to debug because the programmer's intent is not written anywhere, so to see that the intent and the implementation do not match, one has to divine the original programmer's intent. That divination part is the hard part.)
So yeah, you do need to expect some errors/oddities in programming language syntaxes, and library interfaces.
magic:
Well, we have HTTP Referer field. Not sure if it originally was a typo or a deliberate attempt at shaving one byte from each request :-DD
Nominal Animal:
I'd say "referer" was a spelling mistake. (Consider e.g. referee. I'd say it is an easy mistake, something I could make myself.)
As an example of the stranger choices devs have made, is the legendary Boolean implementation with tristate values: True, False, and FILE_NOT_FOUND.
Wimberleytech:
--- Quote ---
GNU Fortran
Program Exponents
print *, -3**4
end program Exponents
-81
--- End quote ---
You are soooo old! Oh dang!
Brumby:
Here is the core of the problem!:
--- Quote from: Nominal Animal on April 10, 2019, 02:52:57 pm ---It would be better if there was a separate operators for negation and subtraction instead.
--- End quote ---
These are two different operations that give the same result in many situations - but even so, I still stand by my earlier statement:
--- Quote from: Brumby on April 09, 2019, 02:37:31 am ---If there IS an issue with the expression, then that lies with the person who prepared it. THAT is, actually, a much more important step than resolving it. If it is not written correctly, then you will not - and can not - get a correct answer.
--- End quote ---
Mathematical expressions are usually a representation of some part of the universe in which we live. As such, there will be only one correct way to write them (commutative laws aside) - so if there is any chance of ambiguity, the simple answer is to use parentheses.
If the person writing the expression does not do this, then they will be reliant on the expression being evaluated according to the rules they observed when drafting it. As we have seen, this has risks - and mathematical expressions are a class of study where this sort of risk has no place.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version