Comment by moron4hire | Hacker News Reader

Comment by moron4hire | Hacker News Reader

Parent Full thread

I skipped over it because it's a solution in search of a problem.

I think developers should be expected to understand the native constructs of the language they use. You previously also talked about "being more familiar to onboarding developers". Why should Lodash be more familiar than the native looping constructs to anyone? Why would Lodash be more familiar to a developer you're onboarding who is more used to some other library completely?

If you're not used to using Lodash, then it would not be a time savings to use it, as you'd have to spend time learning its idioms. It means you've probably learned other idioms, instead (perhaps, you know, the ones you should have learned to be able to claim to know how to use the language). So if you know the native idioms, there isn't a point to learning Lodash.

You had to take time to look up operator-in because you're not used to using operator-in. Regardless, it was a waste of time. What's wrong with the following code?

    for(var k in obj){
       if(obj[k].age === 1){
          // there you go
       }
    }

And I mean problems with that code itself, not problems that are actually a problem with upstream code? And how much of the problems with that upstream code are because your project is a Gordian Knot of 3rd party dependencies?

You default assume other people's code is better than yours. In the last 20 years of software development, I've seen code better than mine in several standard libraries. But the JS ecosystem is not one of them.

>You had to take time to look up operator-in because you're not used to using operator-in

I'm using in (`if('age' in value)`), but not for..in. There's a difference. I don't need to use that (you didn't in your example, even though you should have), but then my code would blow up in many of the same cases as yours will.

Anyway, what's wrong with that code is you'll need a hasOwnProperty check, you'll need to break out of the loop when done, it blows up if 'age' isn't a property on one of the objects in the object, it blows up if one of the properties of obj isn't an object, it blows up if obj is null/undefined, and it will deoptimize the entire function it's in in most cases in V8.

To at least fix the bugs that yours has that mine didn't, your code should be:

    for (var key in obj) {
      if (obj.hasOwnProperty(key)) {
        var val = obj[key]
        if ('age' in val && val.age === 1) {
          // there you go
        }
      }
    }

but again that still needs some undefined/null guards at a few spots, and it needs to be able to handle both an array and an obj at where obj is to really be an equivalent of what i was using _.filter for.

>You default assume other people's code is better than yours.

No, I know the lodash code i'm using is better than mine because i've looked at it, i've looked at it's test coverage, i've looked at it's performance numbers, and i've looked at it's usage.

Also... >I skipped over it because it's a solution in search of a problem.

Then why did you skip this part in my last comment:

>it's disingenuous at best and borderline lying to say that lodash is 500kb. The DEVELOPER version is 500kb, the production version is 67kb before gzipping, and 22kb after gzipping

You made me curious, so i actually took a look at my current in-development app i'm writing that i include lodash. The grand total from all lodash functions is 22k un-gzipped, and 7k gzipped.

For that i've significantly reduced my code complexity, increased compatibility, reduced the amount of tests i needed to run and maintain, and improved performance in one pretty out-there edge case.

You don't need to use lodash, and in many cases you shouldn't. But don't act like your applications are better than others in any way because you aren't using lodash.

> it blows up if 'age' isn't a property on one of the objects in the object

No it doesn't. It will return as undefined, which evaluates to false when compared to 1 using either triple- or double-equals.

And why call hasOwnProperty here? I'm pretty sure I want to know the age of any properties inherited into my object from a superclass.

At worst, I will grant you an undefined/null check:

    var val = null;
    for(var k in obj){
      if(obj[k] && obj[k].age === 1){
         val = obj[k];
         break;
      }
    }

This works with both objects and arrays.

I'm guessing after repeated use you'd abstract that into a function. Maybe even a collection of them.

No, why would you? It's just a loop. Not all code deduplication is a good idea.

;)

> No, why would you?

Because he's a better programmer than you are, and he knows it.

> It's just a loop.

There are many kinds of common patterns in loops, abstracting them into resuable higher order functions, aka a collections api is rather basic functional programming; "it's just a loop" is a blub phrase of someone who doesn't see the point because they have tried it long enough to understand the value in a different paradigm.

I know it's currently thought as so, but functional programming is not the be-all, end-all paradigm. If you've been around for a while, you'd have seen the ebb and flow a few times already.

No one said it was, but in this use case it's far superior to hand written loops. Virtually all modern programming languages have a functional collections API precisely because of this advantage. If you're still writing loops by hand, in nearly all cases, you're stuck in a less effective procedural programming mindset and have simply stopped updating your skills beyond the basics.

If you've been around for a while, you should have already accepted the benefits of functional programming in the places it's most effective and banished low level procedural programming of loops except in cases where extreme optimization is required. There's no eb and flow here, higher order map/reduce/filter style has been the best way since the 60/70/80's when Lisp and Smalltalk were doing it.

Reply on news.ycombinator.com