3 ms·

I can relate with your frustration. Sometimes it's important to you, and just having something exist is awesome. But sometimes it's not so important, and I was

I can relate with your frustration. Sometimes it's important to you, and just having something exist is awesome. But sometimes it's not so important, and I was going through my life fine without it, and seeing the project made me try it out[1]. Then one can feel sucked in if it mis-sets expectations. Perhaps if both hackers and users took some pains to set expectations and investigate codebases in advance (respectively), there'd be less frustration all around. I've been on both sides of this divide. [1] Yesterday's fuzzy-autocompleter for vim is an example: https://news.ycombinator.com/item?id=5169062 https://news.ycombinator.com/item?id=5169062. I don't really consider autocomplete to be that useful (mild payoff in small codebases; being laggy 1% of the time negates all benefit), but it still seemed cool enough to be worth trying out. I was self-aware that it might lead to frustration (because it did a good job setting expectations), but to its credit the documentation was excellent.

IgorPartola 14y ago
I agree, it is very important to check whether a given library is maintained and the quality of the code before relying on it. You should also check for how quickly the project is evolving. Using the cutting edge in production means either never upgrading or re-writing your codebase to suite what the library is doing with the new release all the time. For example at my previous company I advocated for using the "boring" Django over Pylons/Pyramid/etc. The latter went through a number of merges and evolution over the time when we enjoyed Django's painstaking attention to reduce backwards incompatible changes. But back to setting expectations, yes you are right. Perhaps being honest in our README's would be good: "here's a piece of code I used. You might find it useful, but I don't plan on maintaining it;" or "This thing was a one time script. You will have to modify it to use it" a la GitHub's Hubot. The biggest issues come back some time later, when you start relying on a library, build a business around it, then realize that it has a glaring issue, but the upstream maintainer has disappeared. You can't always anticipate this. For example, I believe the following is still a bug in Python's MySQL driver: c.executemany("INSERT INTO breakfast (name, created_on) VALUES (%s, DATE(%s))", list_of_name_dates) (The issue is that MySQLdb has a regex which matches the first closing parentheses to repeat the parameters.) The above is an issue that's bitten many people, yet everyone continues using MySQLdb.

IgorPartola 14y ago

I agree, it is very important to check whether a given library is maintained and the quality of the code before relying on it. You should also check for how quickly the project is evolving. Using the cutting edge in production means either never upgrading or re-writing your codebase to suite what the library is doing with the new release all the time. For example at my previous company I advocated for using the "boring" Django over Pylons/Pyramid/etc. The latter went through a number of merges and evolution over the time when we enjoyed Django's painstaking attention to reduce backwards incompatible changes. But back to setting expectations, yes you are right. Perhaps being honest in our README's would be good: "here's a piece of code I used. You might find it useful, but I don't plan on maintaining it;" or "This thing was a one time script. You will have to modify it to use it" a la GitHub's Hubot. The biggest issues come back some time later, when you start relying on a library, build a business around it, then realize that it has a glaring issue, but the upstream maintainer has disappeared. You can't always anticipate this. For example, I believe the following is still a bug in Python's MySQL driver: c.executemany("INSERT INTO breakfast (name, created_on) VALUES (%s, DATE(%s))", list_of_name_dates) (The issue is that MySQLdb has a regex which matches the first closing parentheses to repeat the parameters.) The above is an issue that's bitten many people, yet everyone continues using MySQLdb.