Hacker News Reader

Comment by Zetice | Hacker News Reader

That's kind of my point, though? Caring about "blind dogmatism", one way or another, is not required to be a highly effective software dev.

For example with lodash, the process for deciding to use it could be, "Hey this looks like it could save me time, let's try it." That's it. You don't have to go on this large, multi-hour/multi-day journey discovering every little thing about it first.

I'm arguing here that highly effective developers are able to use software to solve business problems favoring efficiency over correctness.

And I'm not sure it's efficient to care much about whether or not lodash could be rebuilt internally.

View on HN

You say "one way or another". What is the "another" way, and who's advocating it? This page is NOT an invitation to rebuild lodash on every single project. It is not a prescriptive website. It is teaching material.

This page is here, for example, so that people who only know about Lodash can know how it's implemented. If they ever start working on a no-Lodash project, they might not need to import Lodash.

This is not a call-to-arms to uninstall Lodash from all projects and replace with hundreds of functions. Why would it be?

Then this page could be replaced by looking at lodash's source code. In fact this page is harmful as it does not represent, precisely, what lodash is actually doing and should not be used to understand lodash.

Further, I'm not responding to the page itself, but the discussion here around the page. A lot of developers are using their emotions (e.g. disgust, fear) to navigate their professional role, and I'm suggesting that this need not be the case.

You can set all of that aside and be a highly effective developer. You don't need to care about any of this, and I'm seeing a lot of devs here who think they have to care in order to be effective.

It couldn't be replaced by looking at Lodash's source code, because A LOT of the alternatives here are built into Javascript, and the Lodash code is significantly larger.

Check flatten in this website:

    array.flat();

Versus Lodash:

    function baseFlatten(array, depth, predicate, isStrict, result) {
      predicate || (predicate = isFlattenable)
      result || (result = [])

      if (array == null) {
        return result
      }

      for (const value of array) {
        if (depth > 0 && predicate(value)) {
          if (depth > 1) {
            // Recursively flatten arrays (susceptible to call stack limits).
            baseFlatten(value, depth - 1, predicate, isStrict, result)
          } else {
            result.push(...value)
          }
        } else if (!isStrict) {
          result[result.length] = value
        }
      }
      return result
    }

About your point: sure, nobody has to care about all of this. But I don't see why we should give people a hard time because they do on their free time.

Exactly; lodash doesn't use `array.flat()`, so the site does not teach, "how it's implemented."

And I'm not giving people a hard time, I'm saying you don't have to care about all of this to be good at your developer job. If this was an obvious point to you, great!

The point of this website is not to show how Lodash implements things. Why would it be?

It says so in there: it is "a description of how one would go about doing the same thing in vanilla JavaScript".

You're arguing with yourself now, as I just quoted you:

> This page is here, for example, so that people who only know about Lodash can know how it's implemented.

I said "for example".

Yes, and I responded to that example. Not sure what the problem is. Do you not think it's a good example?

To be more precise, my point was more that this website shows how it is implemented in general. There is still something to be gained by showing that you can do array.flat() instead of just copy pasting from Lodash.

Yes, for sure, I didn't mean to imply the website is entirely worthless, sorry.

But my larger point here is just that you don't have to care about "only importing lodash if absolutely necessary" to be a good dev. You can care about those things, but for the folks who think they have to care, I'm here to say you don't.

It's not that hard to do a basic cost benefit analysis of adding a package before you throw it in your package manifest. It usually takes minutes, not hours (and certainly not days). Skipping this step doesn't gain you major efficiencies and definitely doesn't make you a better developer.

If you're unsure why this must be said, you've never worked in a large corporate environment. People will spend weeks on decisions like this.

However, going into such multi hour/day journey once in a while is very effective way to learn. And writing down that journey is also very effective in forcing you to really go through and really learn.

Reply on news.ycombinator.com