5 ms·

My Reality Moment. Why did I ever agree to do this?

46 points by rubikscube 11y ago

chucksmash 11y ago
Interesting article though it feels a bit incomplete. The writer very briefly introduces this concept of a "reality moment" , gives an example and that's that. The example is interesting and the concept rings true; I'd like to see more time spent discussing the concept in and of itself. The only time I remember seeing this addressed outside of a "programmers are bad at estimating tasks so do x to get better estimates" context was a post by Jeff Atwood about the tendency of programmers to look at something like StackOverflow and see, basically, two CREATE TABLE statements[1]. The reality moment, then, sounds like the moment one sees past that "weekend worth of coding". A bit more fleshing out, maybe with an examination of why we think this way would be a great read. [1]: http://blog.codinghorror.com/code-its-trivial/ http://blog.codinghorror.com/code-its-trivial/
- meric 11y ago
  Reality moment usually sets in a bit late for me. When I used to get a new job or contract I used to have incredible initial enthusiasm. Even three months in dealing with spaghetti code and inexperienced programmers I think to myself improvement in my working environment is around the corner and I'm going to be able to fix things myself. And then the reality moment sets in. Why did I agree to this In the first place - I'm working in a terribly unorganised company, being underpaid working with inexperienced programmers who never has a chance to improve properly because the company was too stingy to hire enough good and experienced programmers. But then I look at the state of things - they have been improving because I kept thinking I could fix it, the only issue is I should have been paid more as I've done a lot for the company. Stressed and frustrated I go looking for a new job. The process grants me a big boost of enthusiasm. I interview at a company that really likes me. I see some red flags with the way they produce software, but I ignore them and bury them in the back of my mind. "Do I stay at my place where my effort is having an effect or do I go to this new company?" This new company sounds so exciting! This time I'm thinking I might be happier taking this job offer back to my current company and get a good pay rise, but I'm not 100% decided yet.
carsongross 11y ago
We need creativity mixed with discipline to make a difference here. Or we could pick a non-insane language to standardize on. Even better, we could pick a non-insane bytecode to standardize on.
- bjwbell 11y ago
  Like WebAssembly (technically not a bytecode).
Mithaldu 11y ago
And those kinds of issues are why Perl has ==/!=/+ for numbers and eq/ne/. for strings.
- xlm1717 11y ago
  Those are great. I wish PHP had borrowed eq and ne. It does have . for strings, which makes things a little easier. Since JS doesn't have any of those string operators, you end up with the fun example that was posted in the article. It will default to using + to concatenate the strings, but - is not defined to strings, so it converts them to numbers first and then applies the operator. Easy to remember once you know what's going on, but still irrational.
joshribakoff 11y ago
I only have experience in dynamic languages. I don't get the point of the article? Is the article implying type coercion is bad because its inefficient in terms of CPU cycles? In a decade of programming in dynamic languages, I've never had string comparison be a bottleneck. It is usually IO that is the bottleneck, and the trade off is that by using dynamic languages like JS it becomes easy to make your IO non blocking. If you really have some logic that needs to compare millions of strings, you could always write that algorithm in a static compiled language, and shell out to it from your dynamic language.
- dragonwriter 11y ago
  > I don't get the point of the article? The point -- as is often the case -- is precisely stated at the end of the article: "What this boils down to is that when we approach any of these server dynamic languages to optimize, we can't employ the same tried-and-true techniques we have used for decades (literally) in C, C++ and Java. We need creativity mixed with discipline to make a difference here." Its not making a point of bad or good. Its discussing the features of the languages that make optimizing them challenging.
- MichaelGG 11y ago
  What's so special about JS's dynamic side that makes async IO easy? Any functional language should be able to do so. And even better than JS, as they may have syntax to avoid all those nested callbacks, while still flowing the environment/error handling. In fact, JS doesn't seem to have anything that's specifically suited for async IO at all, apart from clumsy closures. Also, string handling can often be a bottleneck. Anything dealing with HTTP the protocol, for instance, will have all sorts of crazy hacks to parse that messed-up text format as fast as possible. (And this is a major reason why HTTP/2 isn't text-based.)
dumael 11y ago
As a compiler developer I honestly shudder reading this. From the last example: > $ node > "5" + "1" > '51' > "5" - "1" > 4 How is this in anyway reasonable behavior? '+' is string concatenation but '-' is interpret these strings as numbers and perform arithmetic? Does the principle of least surprise apply here?
- Nadya 11y ago
  >'+' is string concatenation but '-' is interpret these strings as numbers and perform arithmetic? That's precisely it. You cannot subtract a string so it coerces "5" and "4" to integers instead of treating them as strings. So it results in 5 - 4. The first concatenates two strings, "5" and "1" and results in "51". It's perfectly reasonable behavior. If you want to add numbers you should give it integers - namely 5 and 1 instead of two strings "5" and "1". The unreasonable behavior is giving integers as strings.
  - casion 11y ago
    The unreasonable behaviour is this not being an error.
  - kyllo 11y ago
    You cannot subtract a string Maybe in Javascript you can't, but you sure could design a language where you could subtract strings, if you wanted to. You could treat the strings as two arrays of characters and subtract them. The result would be the characters that are in the first string but not in the second string. "Hello" - "o" would be "Hell". I'm sure you could do this in Ruby by monkeypatching the string class to overload the minus method.
    - Nadya 11y ago
      How would your method subtract "lo" from "Hello" and leave "Hel" instead of "He"? It gets complicated enough that I think you'd be re-implementing a more limited version of regex. Also I was speaking in context of Javascript so I fail to see how this applies.
danans 11y ago
12 years ago, I was working on a PHP library to parse XMLRPC requests, and I ran into it's numeric type slipperiness in a painful way. I was (naively) using PHP's eval to parse a decimal numeric string. I noticed what seemed like random numeric errors in a random subset of RPCs. It turned out, after what seemed like eons of investigation, that some clients were stringifying decimal integers with leading zeros, which made PHP interpret them as octal numbers, and hence the random seeming errors. Having come from a strongly-typed-language background (C/C++/Java), that was a major learning experience about the caveats of weakly typed languages.
- herge 11y ago
  What does typing have anything to do with this 'feature' in the number parser? If atoi in C also parsed octal numbers, you would have had the same problem. Your issue is with the too liberal number parser.
  - danans 11y ago
    It was a tangentially related personal anecdote from 12 years ago. You are welcome to ignore it if you find it irksome.
makeitsuckless 11y ago
> But the usage of "===" is fairly uncommon in most PHP programs. I don't code PHP anymore, but the use of "===" has been standard practice for ages, and checking for it fully automated. It's one of the many areas in which uninformed people like to criticize PHP for bad practices that in reality have been left behind a long time ago and are only still supported by the language for backward compatibility reasons.
asah 11y ago
Yes, dynamic languages are... dynamic... http://www.eecs.berkeley.edu/Pubs/TechRpts/1994/CSD-94-812.pdf http://www.eecs.berkeley.edu/Pubs/TechRpts/1994/CSD-94-812.p...
- antod 11y ago
  It wasn't dynamic (vs static) typing that was horrifying the author, it was weak (vs strong) typing. The unsurprising strongly typed Python example was still dynamically typed.

46 points by rubikscube 11y ago

Interesting article though it feels a bit incomplete. The writer very briefly introduces this concept of a "reality moment" , gives an example and that's that. The example is interesting and the concept rings true; I'd like to see more time spent discussing the concept in and of itself. The only time I remember seeing this addressed outside of a "programmers are bad at estimating tasks so do x to get better estimates" context was a post by Jeff Atwood about the tendency of programmers to look at something like StackOverflow and see, basically, two CREATE TABLE statements[1]. The reality moment, then, sounds like the moment one sees past that "weekend worth of coding". A bit more fleshing out, maybe with an examination of why we think this way would be a great read. [1]: http://blog.codinghorror.com/code-its-trivial/ http://blog.codinghorror.com/code-its-trivial/

meric 11y ago
Reality moment usually sets in a bit late for me. When I used to get a new job or contract I used to have incredible initial enthusiasm. Even three months in dealing with spaghetti code and inexperienced programmers I think to myself improvement in my working environment is around the corner and I'm going to be able to fix things myself. And then the reality moment sets in. Why did I agree to this In the first place - I'm working in a terribly unorganised company, being underpaid working with inexperienced programmers who never has a chance to improve properly because the company was too stingy to hire enough good and experienced programmers. But then I look at the state of things - they have been improving because I kept thinking I could fix it, the only issue is I should have been paid more as I've done a lot for the company. Stressed and frustrated I go looking for a new job. The process grants me a big boost of enthusiasm. I interview at a company that really likes me. I see some red flags with the way they produce software, but I ignore them and bury them in the back of my mind. "Do I stay at my place where my effort is having an effect or do I go to this new company?" This new company sounds so exciting! This time I'm thinking I might be happier taking this job offer back to my current company and get a good pay rise, but I'm not 100% decided yet.

carsongross 11y ago

We need creativity mixed with discipline to make a difference here. Or we could pick a non-insane language to standardize on. Even better, we could pick a non-insane bytecode to standardize on.

bjwbell 11y ago
Like WebAssembly (technically not a bytecode).

Mithaldu 11y ago

And those kinds of issues are why Perl has ==/!=/+ for numbers and eq/ne/. for strings.

xlm1717 11y ago
Those are great. I wish PHP had borrowed eq and ne. It does have . for strings, which makes things a little easier. Since JS doesn't have any of those string operators, you end up with the fun example that was posted in the article. It will default to using + to concatenate the strings, but - is not defined to strings, so it converts them to numbers first and then applies the operator. Easy to remember once you know what's going on, but still irrational.

joshribakoff 11y ago

I only have experience in dynamic languages. I don't get the point of the article? Is the article implying type coercion is bad because its inefficient in terms of CPU cycles? In a decade of programming in dynamic languages, I've never had string comparison be a bottleneck. It is usually IO that is the bottleneck, and the trade off is that by using dynamic languages like JS it becomes easy to make your IO non blocking. If you really have some logic that needs to compare millions of strings, you could always write that algorithm in a static compiled language, and shell out to it from your dynamic language.

dragonwriter 11y ago
> I don't get the point of the article? The point -- as is often the case -- is precisely stated at the end of the article: "What this boils down to is that when we approach any of these server dynamic languages to optimize, we can't employ the same tried-and-true techniques we have used for decades (literally) in C, C++ and Java. We need creativity mixed with discipline to make a difference here." Its not making a point of bad or good. Its discussing the features of the languages that make optimizing them challenging.
MichaelGG 11y ago
What's so special about JS's dynamic side that makes async IO easy? Any functional language should be able to do so. And even better than JS, as they may have syntax to avoid all those nested callbacks, while still flowing the environment/error handling. In fact, JS doesn't seem to have anything that's specifically suited for async IO at all, apart from clumsy closures. Also, string handling can often be a bottleneck. Anything dealing with HTTP the protocol, for instance, will have all sorts of crazy hacks to parse that messed-up text format as fast as possible. (And this is a major reason why HTTP/2 isn't text-based.)

dumael 11y ago

As a compiler developer I honestly shudder reading this. From the last example: > $ node > "5" + "1" > '51' > "5" - "1" > 4 How is this in anyway reasonable behavior? '+' is string concatenation but '-' is interpret these strings as numbers and perform arithmetic? Does the principle of least surprise apply here?

Nadya 11y ago
>'+' is string concatenation but '-' is interpret these strings as numbers and perform arithmetic? That's precisely it. You cannot subtract a string so it coerces "5" and "4" to integers instead of treating them as strings. So it results in 5 - 4. The first concatenates two strings, "5" and "1" and results in "51". It's perfectly reasonable behavior. If you want to add numbers you should give it integers - namely 5 and 1 instead of two strings "5" and "1". The unreasonable behavior is giving integers as strings.
- casion 11y ago
  The unreasonable behaviour is this not being an error.
- kyllo 11y ago
  You cannot subtract a string Maybe in Javascript you can't, but you sure could design a language where you could subtract strings, if you wanted to. You could treat the strings as two arrays of characters and subtract them. The result would be the characters that are in the first string but not in the second string. "Hello" - "o" would be "Hell". I'm sure you could do this in Ruby by monkeypatching the string class to overload the minus method.
  - Nadya 11y ago
    How would your method subtract "lo" from "Hello" and leave "Hel" instead of "He"? It gets complicated enough that I think you'd be re-implementing a more limited version of regex. Also I was speaking in context of Javascript so I fail to see how this applies.

danans 11y ago

12 years ago, I was working on a PHP library to parse XMLRPC requests, and I ran into it's numeric type slipperiness in a painful way. I was (naively) using PHP's eval to parse a decimal numeric string. I noticed what seemed like random numeric errors in a random subset of RPCs. It turned out, after what seemed like eons of investigation, that some clients were stringifying decimal integers with leading zeros, which made PHP interpret them as octal numbers, and hence the random seeming errors. Having come from a strongly-typed-language background (C/C++/Java), that was a major learning experience about the caveats of weakly typed languages.

herge 11y ago
What does typing have anything to do with this 'feature' in the number parser? If atoi in C also parsed octal numbers, you would have had the same problem. Your issue is with the too liberal number parser.
- danans 11y ago
  It was a tangentially related personal anecdote from 12 years ago. You are welcome to ignore it if you find it irksome.

makeitsuckless 11y ago

> But the usage of "===" is fairly uncommon in most PHP programs. I don't code PHP anymore, but the use of "===" has been standard practice for ages, and checking for it fully automated. It's one of the many areas in which uninformed people like to criticize PHP for bad practices that in reality have been left behind a long time ago and are only still supported by the language for backward compatibility reasons.

asah 11y ago

Yes, dynamic languages are... dynamic... http://www.eecs.berkeley.edu/Pubs/TechRpts/1994/CSD-94-812.pdf http://www.eecs.berkeley.edu/Pubs/TechRpts/1994/CSD-94-812.p...

antod 11y ago
It wasn't dynamic (vs static) typing that was horrifying the author, it was weak (vs strong) typing. The unsurprising strongly typed Python example was still dynamically typed.