The precedence rules are terrifying. I get it, but:
> 3/6*4 is 2 while 3 / 6*4 is 1/8 since the spacing turns the / into a division operator. Use parentheses or spaces to disambiguate: 3/(6*4) or 3 /6*4.
having to be up-front as a warning feels like a sign that your approach to precedence is fundamentally broken and you should require parentheses.
(Also the idea that 1/8 and 1 / 8 are different things feels bonkers to me in general, but maybe that's just taste.)
Sound like a typical Rob Pike design. Idiosyncratic, not that user friendly, and mostly "works for me" affair (considering things like the Sam editor and parts of Golang).
Rubbishing someones character for a design choice is just too extreme. Sounds like you have something personal against Rob Pike rather than anything constructive to add
This approach to precedence comes straight from Iverson and APL itself. Iverson originally started out designing a more uniform mathematical notation. It developed into a programming language secondary to that. Note that J, K, and others in this family all duplicate this choice largely. And there's mainstream languages that have chosen the middle ground of allowing basic precedence for + - * / expressions but require explicit grouping otherwise.
It's not a particularly outlandish idea.
So attributing it to Rob Pike's personality traits is just off the mark. It's ok to be critical but it should be specific and informed, not just bashing someone character as a whole, and if you're gonna take it that far, you'd probably better at least know what you're actually talking about.
And note I've been critical of Rob's choices and behavior surrounding Go's date/time on a particular issue, so note this isn't empty hero worship on my part.
>So attributing it to Rob Pike's personality traits is just off the mark
That's fine, since I didn't speak about Pike's "personality traits", but to his architecure/design tendencies.
And I didn't attribute this design to him. I know of APL, and even if I didn't the influence is right there in the TFA title. I compared it to his designs ("sounds like a typical Rob Pike design"), i.e. he adopted it because he does have these design tendencies, and so this was to his taste.
>not just bashing someone character as a whole
Where exactly are you getting that from? As if I've called him a "bad person" or something?
You can't just cherrypick examples and say this is typical.
Even worse, you (GP) can't say this is typical without providing any examples when the most obviously relevant analogy (precendence in Go) does not support your statement.
You are misunderstanding his point even though masklinn explained it. It's not about the specific point of operator precedence. It is about designing something that has internally sound logic but is very unexpected by a typical new user. And he provided the example of time package patterns in Go which imho fits very well. Yea it makes sense but I'm sure there are hordes of users that think "why doesn't this work like in virtually every other language?".
It's probably good to not take the "typical" too literally and more as a "Rob Pike has done a few designs in the past that have this quality".
It's not about the particular intepreter or specific precedence design, it's about the tendecies described: what kind of stuff he often appears to like and/or produce.
Now, you might disagree with that, but at least disagree with what I tried to say, not what I didn't mean :)
The -option I'd say yes. Although this is vintage UNIX style behavior, in 2009, when Golang emerged, it should have picked GNU-style. No reason except idiosyncrasy or nostalgia to go with single dash.
For method capitalization, I'd say no, as this is the case in any other popular languages too (C# to name but one).
The capitalisation itself isn’t idiosyncratic (though it seems uncommon in the unix world), however that having a semantic impact is rather rare.
Not completely unique (e.g. variables v symbols in erlang, concrete type v generic placeholder in haskell) but really rare, and usually the capitalisation isn’t a switchable thing, it’s a very fixed meaning.
Fully agreed. I stopped considering this practical in any way when I read
> 3*4+5 is 27
I'm sorry but if your calculator does not follow standard mathematical rules for operator precedence then I'm out. But the space issue takes it to another level.
I also get it, it derives from APL which is right to left and all operators have same precedence but it's just so far from practically usable for normal people... there's a reason noone uses APL today. And sure it's just a plaything but seems weird to even create apps for iPhone, iPad and Android and a logo for it.
Quick, what should be the order of precedence among (binary!) flip, transp, rot, rho, and iota?
APL / Ivy have so many operators a conventional precedence order would likely be completely impossible to remember or work with.
(One option I’d consider viable in general would be to define associativity and perhaps compatible groups like {+, -} or {*, /} but force explicit parentheses when operators from different groups are used, but that wouldn’t feel like a calculator.)
I’d rather actually we used postfix notation as that not ambiguous at all. I would like a modern “dc” written in Go if I’m honest. With engineering units, BCD decimal arithmetic, blackjack and hookers.
Actually if there was a postfix notation spreadsheet with that capability it would be an interesting tool.
APL was the first language I learned in school and I was thrown by the precedence of the mathematical operators, but once the other operators were put in play, it was an incredibly simple rule -- and rarely did I or other APL developers have bugs relating to order of operation.
I then moved to C++ and was gobsmacked the the precedence rules and was forced to use parentheses to get things right. I have seen hundreds of bugs produced by programmers that tried to be clever and avoid parens relying on their faulty memory of the precedence priorities.
Just look at the C++ Operator Precedence table listed at the following URL. It's wild!
One thing I really like about kdb+/q is the fact that it has strict right-to-left execution/precedence. While I know it's a standard, I don't want to deal with bodmas, or whatever it is. Having right to left makes it clear and unambiguous how it will execute. Saying that, it does also encourage huge one line abominations. Everything in moderation i guess...
Yeah, there's a legendary twitter thread that removed all doubt for me. Thousands of teachers, professors, and engineers all confidently asserting that their version of PEDMAS is the correct and unambiguous one.
Stuff like this is very difficult to change, because the conventions both global and fundamental... but we also shouldn't pretend like history happens to always chose the perfect convention. It's more a matter of we've just learned to live with the warts.
I wonder if programming languages having precedence rules at all is an atavism from the 70s when it was an interesting problem for parsing. Adding parentheses makes things clearer in 99% of the cases.
Programing languages require precedence rules because mathematicians decided that having a screwball precedence would make their notation more concise, over the hundreds of years of being used and taught these notations have become the expected form of math, and programing languages(all of which tend to be math heavy) usually will try to follow the expected rules.
Honestly as an interested amateur I think that much of the notation used in math is one of the weakest parts of the discipline. there are two things that I think would aid the notation greatly.
1. Most complex equations have a lot of moving parts within them, however the notation has no way of indicating what these parts are for and why they are there, you better hope that the author has taken to time to document their equation properly.
2. the terrible symbology. you have heard the joke about the two hard things in computer science. it turns out that programmers are usually fairly good at naming things, the mathematicians are the true dark masters at names. if you have an item in your equation that represents the confidence of a rating they will not name it confidence_rating, no, they will name it σ(a small sigma), good luck searching(or even typing) that.
Now I get why it was done, they tended to a notation that was as concise as possible, this makes it much faster to manipulate parts when you are working on something. however I feel this has the opposite effect when trying to teach it to others.
As its designers explain: A bare a * b + c is an invalid expression. You must explicitly write either (a * b) + c or a * (b + c).
Why doesn't WUFFS have precedence? Because it's focused intensely on solving its specific problem, Wrangling Untrusted File Formats Safely. Having solved the buffer problem (you can't write buffer[oops_too_big] type mistakes in WUFFS, they will not compile) and the integer overflow problem (likewise, it doesn't compile) they wanted to also solve that problem where the programmer thought there were making one calculation, but due to precedence rules they were actually making a different calculation.
Well yeah, having precedence rules makes the notation more concise and can save you from typing lots and lots of brackets. And I don't think multiplication/division having higher precedence than addition/subtraction (and, by extension, AND having higher precedence than OR) is all that "screwball" - and even if it were, if you paid attention in elementary school, you already know it, so programming languages can rely on it. Of course, the moment they start getting "creative" with precedence, those exceptions turn into massive footguns...
> I wonder if programming languages having precedence rules at all is an atavism from the 70s
It's not an "atavism from the 70s", it's a mirror of mathematical conventions, as well as a syntactic convenience.
Language designers have tried to do away with precedence all along by having uniform evaluation (e.g. smalltalk, as well as APL and all its descendents hence Ivy, probably), removing infixes (lisp, forth, assemblies), or requiring explicit prioritisation (I think I saw that a while back though I don't remember the language).
> Adding parentheses makes things clearer in 99% of the cases.
It also adds a significant amount of noise for 99% of the cases, for no value since any schoolchild past 12 or so has integrated the precedence rules.
> It also adds a significant amount of noise for 99% of the cases, for no value since any schoolchild past 12 or so has integrated the precedence rules.
As all the viral "Only 25% of people got this right" stuff that pops up from time to time proves: No they haven't.
Also since we're rarely writing equations composed entirely of single digit numeric literals and are using reasonable variable names, the percentage of characters overhead and therefore noisiness of using brackets is much less than in the short examples being thrown around.
If memory serves well, normal operator precedence was already present in the first FORTRAN, which was proposed in 1953.
And APL's priority system is: there is no priority. Everything is evaluated right to left. Pike's Ivy is no exception. 3/4 differing from 3 / 4 is a lexical convention: 3/4 is a rational number.
The latter example is more noisy, you do learn precedence in high school yet the latter example is also more clear because it is the most accurate way of conveying intent.
> 3/6*4 is 2 while 3 / 6*4 is 1/8 since the spacing turns the / into a division operator. Use parentheses or spaces to disambiguate: 3/(6*4) or 3 /6*4.
having to be up-front as a warning feels like a sign that your approach to precedence is fundamentally broken and you should require parentheses. (Also the idea that 1/8 and 1 / 8 are different things feels bonkers to me in general, but maybe that's just taste.)