←back to thread

“I'm basically giving myself a permanent vacation from being BDFL”

(mail.python.org)
2024 points randlet | 6 comments | 12 Jul 18 15:22 UTC | HN request time: 0.335s | source | bottom
Show context
js2 ◴[12 Jul 18 16:15 UTC] No.17516019[source]▶
Background ("PEP 572 and decision-making in Python"):

https://lwn.net/Articles/757713/

replies(2): >>17516132 #>>17516693 #
jcelerier ◴[12 Jul 18 16:26 UTC] No.17516132[source]▶
> The problem with the C-style of assignments is that it leads to this classic error: if(x = 0) {...}

yeah, if you code on 20 years old compilers with no warnings. GCC 4.1 warns about this (with -Wall) and Clang 3.4 warns about this too, without any warning flag.

replies(4): >>17516174 #>>17516220 #>>17517715 #>>17518178 #
jstimpfle ◴[12 Jul 18 16:32 UTC] No.17516220[source]▶
Not having a problem in the first place is preferable to fighting it with tools. == vs = is a classic mistake that I'm sure every C programmer has wasted some time on. (I'm just undecided if I prefer dealing with this very problem occasionally, or choosing either of the verbosity of := assignments or the non-orthogonality of = assignment statements plus := assignment expressions.)
replies(2): >>17516712 #>>17517362 #
sbjs ◴[12 Jul 18 18:35 UTC] No.17517362[source]▶
A programming language and the tools you use with it are tightly integrated: you're never using a language, you're always using a language via a tool. And if all C compilers you might use have warnings enabled for this buggy expression, then there's no problem.
replies(3): >>17519011 #>>17519479 #>>17519488 #
1. jstimpfle ◴[12 Jul 18 23:35 UTC] No.17519488[source]▶
The most important "program" that reads your source code is probably in your brain. You probably have some "tooling" in their that is on the watch for "if (x = y)" and other patterns, but I'm sure you'd prefer to not have to run it.

As another counterexample let me give you "language tooling". For example, write a tool that generates a FFI from $LANGUAGE to C. Is it really so unimportant that $LANGUAGE is clean and simple and easy to parse?

replies(3): >>17520132 #>>17520708 #>>17521430 #
2. sbjs ◴[13 Jul 18 02:39 UTC] No.17520132[source]▶
> "The most important "program" that reads your source code is probably in your brain."

Not if you have a good Integrated Development Environment (or IDE for short)! That's an even better "program" than your brain, because it shows syntax errors and other warnings right next to your code. It will literally put little red squiggly lines right under `if (x = 1)` and show the file as red in your file explorer side-bar, and when you hover over this line it will give you a tool tip saying "this assigns a new value, it's probably not what you meant, I can either turn it into x == 1 or ((x = 1)), which one do you want?" That is the power of IDEs and they are amazing. We should consider them an integral part of writing code and not fight them or be afraid of them!

replies(1): >>17520454 #
3. b0rsuk ◴[13 Jul 18 04:06 UTC] No.17520454[source]▶
You can't assume that every single person will have a good IDE. And you will be reading and maintaining code written by people who don't. In that case I prefer to deal with a language which guarantees no trivial errors.
replies(1): >>17520713 #
4. skywhopper ◴[13 Jul 18 05:27 UTC] No.17520708[source]▶
I disagree... I don’t really have this problem though. = and == are pretty visually distinct to me. As much as > and < or & and @ (or == and :=).

But the best solution is probably to just drop the = as an operator altogether.

5. skywhopper ◴[13 Jul 18 05:28 UTC] No.17520713{3}[source]▶
I agree with your points about IDEs but alas no such language exists to keep you from simple errors.
6. jstimpfle ◴[13 Jul 18 08:49 UTC] No.17521430[source]▶
> that $LANGUAGE is clean

s/\$LANGUAGE/C/