`not`, `and`, `or` as logical operator keyword

https://github.com/JuliaLang/julia/issues/5238

I guess many people want to use not, and, or as logical operator keyword. I prefer

if A and not B
    foo()
end

rather than

if A && !B
    foo()
end

because above one is more easy to read and similar to native english. Why julia chooses below exclusively?

1 Like

There is an extensive discussion in that linked issue about the reasons why

1 Like

might also be relevant here.

4 Likes

I wouldn’t prefer it, as I like &&,||,! more than words (perhaps because of C,C++,… history of mine). But as an option I would not be against it.

(I am triggered whenever I read something which starts with “many people want” or “many of us would prefer”)

Heh, one could use Unicode to implement
∧ ∨ ¬ ⊕ ⊻ ⊼ ⊽

although I don’t think that helps readability.

1 Like

Sure, there are people wouldn’t prefer words. But interesting, i don’t like those symbols by the same reason. In my history, C++ → R → python → fortran → julia (I’m in data/math/statistics). I was surprised about that even fortran implemented .OR., .AND., .NOT. and i feel comfortable with fortran more than C++. :joy: I’m used to write R code specifically, it’s OK, but i love that 3 words and, or, and not.

I admit that sometime && and || are more suitable to julia, eg. broadcasting. If i have to write .&& or .and, then i’ll choose .&& of course. I think it’s just about preference. I want both, and && &&.

But thank you! I have a question, do they short-circuit evaluate?

This things are more or less issues of taste.
For programming language I prefer stringency instead of options. What I mean is, in most general terms, I would prefer a single possible way to do something instead of multiple (but equal) ways.
This is again a matter of taste.

For me multiple options aren’t helping me to finish the task. It’s easier for me to remember a single way of doing it.

For Julia in particular I am currently a bit skeptical, but it’s not yet good justified so I didn’t open a discussion on it, because there are often so many options to do something (more complex than AND or OR, but not as complex as whole algorithms) but some of these options are less performant than others, which is not easy to see from the code. Yet the code is so trivial that it seems to be extrem to do performance measurements on these options. See for example this discussion: Finding DataFrame rows with `missing` values in specific columns?

If this is going into a separate off topic discussion moderators can split here.

Yes.

I like this idea.