3 ms·

> Easier to take 20 minutes and just write the tool. What? That would be a huge red flag in my book. Where are your unit tests? I'm not trusting your 20 minute

by p4wnc6 11y ago

> Easier to take 20 minutes and just write the tool. What? That would be a huge red flag in my book. Where are your unit tests? I'm not trusting your 20 minute off the cuff reproduction of classic algorithms in any business critical piece of the code, not ever. This would get you booted from a lot of places, or at least given a stern talking to for doing something that seems slick, cool, and time-saving in the short term (yay, let's roll our own!) when really it's immature and time-wasting in the long run. Never (!) homebrew that shit unless you have to (like, you're in an embedded environment or your use case requires some bleeding edge research algorithm). It's like seeing someone write their own argument-parsing code. Holy shit, what a bad idea. Never (!) do that.

ljw1001 11y ago
Agreed. Spending twenty minutes finding a good library would be time much better spent
serge2k 11y ago
> It's like seeing someone write their own argument-parsing code. Holy shit, what a bad idea. Never (!) do that. So we did that. works well. I dunno, maybe this company is just full of incompetents. I mean, I doubt it, but it is possible. I appreciate judgement without context as well. Really, it's awesome.
- p4wnc6 11y ago
  If you did write your own argument parsing code, then yes the choice to commit to that was incompetent, barring some extraordinary situation. I don't think it's controversial or insulting to say so in the least. It's a solved problem in every major language and most fringe languages. Spending time re-inventing it is just obviously wrong. It's not insulting or judgmental to say that it's wrong. It's just a fact. I do not understand being offended or angry about my statement of that fact. If we're talking about what is effective engineering and what is not, writing your own argument parsing tool for actual business usage (as opposed to doing this as a pedagogical side project or something), without evidence of some exceptional corner case, is ineffective engineering. It's practically the definition of ineffective engineering.
lastofus 11y ago
The pseudo-code of BFS is all of 20 lines, and that's accounting for a graph possibly containing cycles. A graph without cycles (such as a tree) would be even simpler/shorter. https://en.wikipedia.org/wiki/Breadth-first_search https://en.wikipedia.org/wiki/Breadth-first_search Correct arg parsing is actually significantly more complicated in comparison because of all the possibilities and edge cases. > Never (!) homebrew that shit unless you have to (like, you're in an embedded environment or your use case requires some bleeding edge research algorithm). I can't help but think this mentality is what lead to the recent left-pad debacle
- p4wnc6 11y ago
  > I can't help but think this mentality is what lead to the recent left-pad debacle It borders on category error to compare homebrewing argument parsing with an overreliance on microframeworks extending all the way down to leftpad. Argument parsing is almost always supported directly by the language implementers in a standard library. And even if it wasn't, it's such a critical task with huge overhead for handling corner cases, cross-platform details, etc., that the value of a central implementation is obvious. A left pad operation ought to be part of the standard language (which is actually what the leftpad debacle was about, Javascript's incredible failures as a language), but it's too trivial to compare it to something like argument parsing. > The pseudo-code of BFS is all of 20 lines, ... If it's only 20 lines, that's great because it means it was easy for the other 500 library writers to write it, write tests, and observe and fix issues over time. So, whew, that's 20 lines I totally shouldn't waste my time on, plus unit tests and routine maintenance I don't have to commit to. And also, given the wide acknowledgement that a good programmer should be writing at most a few hundred lines of code per day (otherwise it's probably mostly junk), 20 lines of code is not trivial. Probably most programmers write a whole lot more than that per day (especially if counting copy/pasted code), but this is in part a sign of a bad programmer, or perhaps more so a sign of the anti-quality constraints placed on them by most employers.
  - lawrjone 10y ago
    What the hell sort of library would you crack out to do a breadth first search traversal? This is my main problem with the OP, BFS isn't some arcane complex cryptic algorithm, it's a way of moving through a data structure that becomes natural and very obvious when you think about how you can effectively traverse it for some tasks. If I were ever to want to traverse something in a breadth first search manner, then I would just write it. It would take longer to search for another library and read how it's somehow implemented this search than it would to write it, test it, get it reviewed, and we've still avoided adding another potentially crappy dependency to our project. It's not category error to compare this to leftpad. leftpad actually makes more sense imo, as it's a common microfunction that may be used more than once. BFS is typically far more coupled with the underlying data and is more naturally written inline.

by p4wnc6 11y ago

ljw1001 11y ago

Agreed. Spending twenty minutes finding a good library would be time much better spent

serge2k 11y ago

> It's like seeing someone write their own argument-parsing code. Holy shit, what a bad idea. Never (!) do that. So we did that. works well. I dunno, maybe this company is just full of incompetents. I mean, I doubt it, but it is possible. I appreciate judgement without context as well. Really, it's awesome.

p4wnc6 11y ago
If you did write your own argument parsing code, then yes the choice to commit to that was incompetent, barring some extraordinary situation. I don't think it's controversial or insulting to say so in the least. It's a solved problem in every major language and most fringe languages. Spending time re-inventing it is just obviously wrong. It's not insulting or judgmental to say that it's wrong. It's just a fact. I do not understand being offended or angry about my statement of that fact. If we're talking about what is effective engineering and what is not, writing your own argument parsing tool for actual business usage (as opposed to doing this as a pedagogical side project or something), without evidence of some exceptional corner case, is ineffective engineering. It's practically the definition of ineffective engineering.

lastofus 11y ago

The pseudo-code of BFS is all of 20 lines, and that's accounting for a graph possibly containing cycles. A graph without cycles (such as a tree) would be even simpler/shorter. https://en.wikipedia.org/wiki/Breadth-first_search https://en.wikipedia.org/wiki/Breadth-first_search Correct arg parsing is actually significantly more complicated in comparison because of all the possibilities and edge cases. > Never (!) homebrew that shit unless you have to (like, you're in an embedded environment or your use case requires some bleeding edge research algorithm). I can't help but think this mentality is what lead to the recent left-pad debacle

p4wnc6 11y ago
> I can't help but think this mentality is what lead to the recent left-pad debacle It borders on category error to compare homebrewing argument parsing with an overreliance on microframeworks extending all the way down to leftpad. Argument parsing is almost always supported directly by the language implementers in a standard library. And even if it wasn't, it's such a critical task with huge overhead for handling corner cases, cross-platform details, etc., that the value of a central implementation is obvious. A left pad operation ought to be part of the standard language (which is actually what the leftpad debacle was about, Javascript's incredible failures as a language), but it's too trivial to compare it to something like argument parsing. > The pseudo-code of BFS is all of 20 lines, ... If it's only 20 lines, that's great because it means it was easy for the other 500 library writers to write it, write tests, and observe and fix issues over time. So, whew, that's 20 lines I totally shouldn't waste my time on, plus unit tests and routine maintenance I don't have to commit to. And also, given the wide acknowledgement that a good programmer should be writing at most a few hundred lines of code per day (otherwise it's probably mostly junk), 20 lines of code is not trivial. Probably most programmers write a whole lot more than that per day (especially if counting copy/pasted code), but this is in part a sign of a bad programmer, or perhaps more so a sign of the anti-quality constraints placed on them by most employers.
- lawrjone 10y ago
  What the hell sort of library would you crack out to do a breadth first search traversal? This is my main problem with the OP, BFS isn't some arcane complex cryptic algorithm, it's a way of moving through a data structure that becomes natural and very obvious when you think about how you can effectively traverse it for some tasks. If I were ever to want to traverse something in a breadth first search manner, then I would just write it. It would take longer to search for another library and read how it's somehow implemented this search than it would to write it, test it, get it reviewed, and we've still avoided adding another potentially crappy dependency to our project. It's not category error to compare this to leftpad. leftpad actually makes more sense imo, as it's a common microfunction that may be used more than once. BFS is typically far more coupled with the underlying data and is more naturally written inline.