Efficiency of Code vs Utility - Lodash Project DropWhile() method

Projects
#1

Hi,

Still working through the Lodash project and I’m wondering something.

The idea of the dropWhile code is to drop the elements in an array until the function argument returns a falsy value. for this, my code is -

image

The tutorial/programmer wrote this code -

image
image.jpg650×527 66.1 KB

Both codes run fine. What I’d like to know is why did the instructor go with something so much more complicated? I get that my code runs under the scenario presented, however, what about other scenarios? Is their code superior in more contexts? How do we decide what code is appropriate, even if it’s simple and gets the job done? Do we wait for issues or attempt to iterate before they come forward?

#2

Creating a second variable to a value that you already have a variable referring to won’t help you.
Comparing true to true results in true, and comparing false to true results in false, in both cases the result is the same as the original value so the comparison doesn’t help.
Your code doesn’t check for end of the array. It may continue forever.

What makes you say the other code more complicated?

3 Likes
#3

You also modify the original array and I’m not so sure the result is right at all, have you tested it, seen it actually produce the right result for non-trivial input?

2 Likes
#4

Hi Ionatan,

"Creating a second variable to a value that you already have a variable referring to won’t help you."

I assume you mean for this -

let newArr = array;

"Comparing true to true results in true, and comparing false to true results in false, in both cases the result is the same as the original value so the comparison doesn’t help."

Do you mean for this -

while (predicate(array[i], i, array)===true)

Would my while loop continue if i didn’t include the === true? How will it know when to end?

"Your code doesn’t check for end of the array. It may continue forever."

Is this really an issue? won’t an array come to an end eventually? Have you seen examples otherwise?

"What makes you say the other code more complicated?"

Of course, in the bigger projects these few lines of code difference is nothing, since I’m starting off I find that when the instructor creates another function (cb), then uses findIndex, and then another variable called droppedArray it seems all excessive.

Even in the codecademy description it says -

"Congratulations! This method wasn’t especially long, but it used a lot of advanced concepts. Great job working through it!"

Which is why I wonder if I’m supposed to use advanced concepts.

"You also modify the original array and I’m not so sure the result is right at all, have you tested it, seen it actually produce the right result for non-trivial input?"

In terms of the node test that occurs in the codecademy panel, it runs with everything passing. So that’s why I’m confused. Shouldn’t there be more parameters to check? or maybe the codecademy node check is enough…

#5

Yeah the array will end but you don’t pay attention and continue looping anyway.

I just explained why it makes no difference. It is dead code. It does not have an effect.

let a = true
console.log(a) // you already have the answer. there is nothing else to compare.
console.log(a === true) // same result, don't bother.
2 Likes
#6

Their code also doesn’t look like it behaves correctly either if no p(x) is false. They’ll get a position of -1, slice, get the wrong amount of elements.

2 Likes
#7

I see!

So if I’m understanding you correctly Ionatan,

True === true, or True === false is no different.

How would you create a while loop to stop when the predicate is false then?

Well, I’m going to let the professionals figure that out, and continue my simple learning journey :smiley:

1 Like
#8

If it makes no difference then you would do it exactly the same way.

2 Likes
#9

Please excuse me, I’m not too savvy in terms of what that means.

What exact code would you type to accomplish the task? Could you type out a while function you think would work please?

#10

You seemed to be saying that === true was required to make it work.
It doesn’t do anything.
If you delete it, it will still be doing exactly the same thing.
That’s what no difference means, right.

2 Likes
#11

Okay I agree. What I mean is, if you wanted to create a while loop, so that when the function returns a false value it will break out of the loop, so that it doesn’t go on forever, how would you do it?

As you stated, my while loop is not checking for the end of the array. How to check for the end of the array when the idea is to only end when a false value is returned?

#12

You can figure out whether you’ve gone past the end by comparing the current location to the size of the array

There are two conditions to stop.

If all values satisfy the condition, then an identical array should be the result.

2 Likes
#13

I see!

So you mean using something like

While (function(…) && i < array.length)

Correct?

Notice I removed the === true there. I’m learning :smile:

1 Like
#15

Uh. well, that’s obviously incorrect. It should be empty. I almost got it right.

2 Likes
#16

Yeah, didn’t notice that. Become a sheep for a moment.

Either way, thanks Ionatan! I haven’t been posting on the forums much and just realized how incredibly beneficial this has been.

Blessings!

#17

So, the two pieces of code weren’t equivalent, both wrong in their own way (yours mutates the original, doesn’t check for end, theirs doesn’t check for end either but with a different and also incorrect outcome)

Having somewhat processed that,
Finding the first location that satisfies not . p is helpful, because that is the location where the resulting array’s values begins.
not . p is not complicated. The javascript way to express that is not ideal, but the concept is good, simple.

Using another function to do work means that no code needs to be read. There is no loop to mentally parse and figure out. If there exists a subproblem that another function solves, then you should probably almost always use that function to solve that subproblem. You can’t introduce bugs here, because you’re not writing code. Additionally, your loop is ad-hoc, it’s not something you can glance at and say “oh it’s that thing”.

Regarding “is this correct?” This takes a lot of effort to figure out whether it really is correct. Better to stick to discussing general concepts. Additionally, it’s something you should be reasoning about yourself instead of taking it on faith from somebody else. When planning out a function you’ll probably always want to be reasonably convinced that the general concepts are correct, and then stick to that plan without compromise (or otherwise your reasoning no longer applies, and why would you change what you have already figured out anyway) If you instead write a bunch of code and later try to figure out whether it’s correct… It’s probably not, and you’ll have a much hard time reasoning about your code than the idea version, better to process those ideas before writing anything at all.

2 Likes
#18

This is nuts.

One, I just realized that there is quite a bit of programming lingo that I’m not versed to.

If to any/all of the questions below your recommendation is browse the forums or read some FAQ posts, please let me know.

For instance, not . p? so p is the function, then why not use !function. What is the . for…

No code needs to be read? Why would using another function eliminate code being read? Or is there a definition of read in this context I’m not aware of…

I’m not writing code? No bugs being introduced?

I’m getting what you mean by hold true to your vision. I’m guessing that the tools will always exist to make your vision a reality, as long as the logic is sound.

The news that using ad-hoc code, or code for only one purpose, is not ideal is also something I have to grapple with.

#19

You mean, !p
Because the inputs/outputs of that won’t align. You wouldn’t get a function back. What you’d get back is false.

> p = (x) => false
> !p
false
> (!p)(true)
// error, can't call false

My . there is for function composition. Run the predicate, then give the result to not. Compose p with not.

const not = (x) => !x
const compose = (f, g) => (x) => f(g(x))
const lessThan5 = (x) => x < 5

const notLessThan5 = compose(not, lessThan5)

console.log(notLessThan5(4)) // false
console.log(notLessThan5(5)) // true
console.log(notLessThan5(6)) // true

If you use a function to do something then you don’t have to implement that thing. So you would write zero amount of code. There are no bugs in non-existing code. Some code that a beginner thinks is more difficult is easier to someone experienced. The beginner doesn’t get to see the implementation, so what is happening? The experienced programmer doesn’t have to see the implementation, they know which function it is. It would also be repeated code if something else already does it.

You’ll need to adapt the idea to use only things that you know how to implement. Basically you need to use things where you can account for everything involved to make it happen. How does your understanding of human speech function? Yeah no clue, can’t write code for that. Long division? That’s fine.

3 Likes
#20

You know Ionatan, it seems like I’m going to ask an endless array of questions that will result in you pulling out your 3 strands of hair. I’m reading over response at least 5 times. Really valuing your replies.

For now, I’m going to digest what you’ve said and reflect on this.

Can’t even imagine how discussions about AI go. Stepping stones eh? :slight_smile:

Speak again soon.

(Couldn’t reply sooner, they barred me from posting too much on my first day!)

1 Like