3 ms·

why would a programmer? Because the programmer would just run the code and check what different methods return as result. Then if it looks like the ordered keys

by gbog 10y ago

why would a programmer? Because the programmer would just run the code and check what different methods return as result. Then if it looks like the ordered keys, said programmer will rely on this behavior. For instance, I'm writing some javascript recently. I try a little array in the console, if Array.keys() returns the orders keys, I will assume it is, and would check the docs (where?) only if I had a problem. Something unstable should not look stable. I agree with the Golang way, make it look like what it is by the specs.

tedmiston 10y ago
> check the docs (where?) Thankfully that's more obvious in Python.
noobiemcfoob 10y ago
I have trouble understanding a programmer who takes a couple samples of a method's behavior and feels confident enough to trust that as the actual behavior of the function. At least guard you're flippant assumption with a check or something!
- gbog 10y ago
  The problem is not to add some checks (asserts? No, just kidding), the problem is that you're quickly writing a little thing for a demo out an experiment, and faster than you'd expect these ten lines of innocuous code have grown in a gigantic ball of mud upon which many businesses are built. To me the less worse way to handle this is a softened TDD, where a consequent part of the code is covered (described, checked, structured) by a suite of reasonably atomic automated tests.
Someone 10y ago
"try a little array in the console, if Array.keys() returns the orders keys, I will assume it is" That may work for some toy script you write for your own use, but must be avoided if you intend to engineer a program. Certainly, that kind of thinking will lead to very bad results if you ever do low-level multi-threaded programming or try to write portable code. For multi-threaded programming, "is this call thread-safe?" is not something answered in a test, and certainly not in a quick test. For portable programming, you simply cannot run the test on all possible systems. In general, when you program like that, you will not only rely on implementation details that may change (for example, this may change for arrays with lots of entries) but also forget to handle error conditions.

by gbog 10y ago

tedmiston 10y ago

> check the docs (where?) Thankfully that's more obvious in Python.

noobiemcfoob 10y ago

I have trouble understanding a programmer who takes a couple samples of a method's behavior and feels confident enough to trust that as the actual behavior of the function. At least guard you're flippant assumption with a check or something!

gbog 10y ago
The problem is not to add some checks (asserts? No, just kidding), the problem is that you're quickly writing a little thing for a demo out an experiment, and faster than you'd expect these ten lines of innocuous code have grown in a gigantic ball of mud upon which many businesses are built. To me the less worse way to handle this is a softened TDD, where a consequent part of the code is covered (described, checked, structured) by a suite of reasonably atomic automated tests.

Someone 10y ago

"try a little array in the console, if Array.keys() returns the orders keys, I will assume it is" That may work for some toy script you write for your own use, but must be avoided if you intend to engineer a program. Certainly, that kind of thinking will lead to very bad results if you ever do low-level multi-threaded programming or try to write portable code. For multi-threaded programming, "is this call thread-safe?" is not something answered in a test, and certainly not in a quick test. For portable programming, you simply cannot run the test on all possible systems. In general, when you program like that, you will not only rely on implementation details that may change (for example, this may change for arrays with lots of entries) but also forget to handle error conditions.