5 ms·

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 al

by sbjs 8y ago

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.

orf 8y ago
No, your using a language, and if you know the language enough you begin using a tool
deleted 8y ago
[deleted]
jstimpfle 8y ago
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?
- sbjs 8y ago
  > "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!
  - b0rsuk 8y ago
    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.
    - skywhopper 8y ago
      I agree with your points about IDEs but alas no such language exists to keep you from simple errors.
- skywhopper 8y ago
  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.
- jstimpfle 8y ago
  > that $LANGUAGE is clean s/\$LANGUAGE/C/

by sbjs 8y ago

orf 8y ago

No, your using a language, and if you know the language enough you begin using a tool

deleted 8y ago

[deleted]

jstimpfle 8y ago

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?

sbjs 8y ago
> "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!
- b0rsuk 8y ago
  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.
  - skywhopper 8y ago
    I agree with your points about IDEs but alas no such language exists to keep you from simple errors.
skywhopper 8y ago
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.
jstimpfle 8y ago
> that $LANGUAGE is clean s/\$LANGUAGE/C/