Live data from Hacker News

JavaScript Algorithms and Data Structures (2018)

github.com

11–20 of 36 posts

Re: JavaScript Algorithms and Data Structures (2018)

#12
post #11

Is there any practical reason use, say, a linked list from this library vs javaScript's native growable array. You can use unshift() to delete in the middle.

Only the usual reasons to use a linked list. E.g. if you want to store stable references to cells in the linked list as in a linked hash map.

Re: JavaScript Algorithms and Data Structures (2018)

#13

Do we really need yet another list of algorithms to memorize for interviews? Is another list going to make a better JavaScript engineer? Will help me understand JavaScript better? Will it help me on the job? Will it make me a faster and better React developer? The obvious answer to all of the above rhetorical questions - fuck no. That being said, it is still a topic of interviews, so I will up-vote bc this is pretty…

Reciting algorithms is reverse gatekeeping. If an employer wants to grill you on them, get out of there.

Re: JavaScript Algorithms and Data Structures (2018)

#14

I think there is a strong correlation between the number of Javascript programmers interested in algorithms and data structures and the number of C programmers interested in front-end frameworks.

C programmers love front-end development. The compiler front-end! :)

[deleted]

Re: JavaScript Algorithms and Data Structures (2018)

#15
post #11

Is there any practical reason use, say, a linked list from this library vs javaScript's native growable array. You can use unshift() to delete in the middle.

Presumably, inserting and removing from the middle of a linked list is much faster than from an array.

Re: JavaScript Algorithms and Data Structures (2018)

#17
post #15
post #11

Is there any practical reason use, say, a linked list from this library vs javaScript's native growable array. You can use unshift() to delete in the middle.

Presumably, inserting and removing from the middle of a linked list is much faster than from an array.

Though, weirdly, the author lists the deletion BigO as O(n). I would have thought maybe they meant traversing to the item to be deleted, but that would imply insertion is also O(n), since you'd have to traverse to the point of insert. Unless they are treating deletion as deleting from an arbitrary location, and insertion only at the head. Very strange.

But, yes; while real life performance characteristics vary (cache locality can lead to surprising wins for arrays even on insertions/deletions), at least theoretically, there are use cases where a LinkedList will win out.

EDIT: Huh. They also list the insertion and deletion cost of a hash table as being O(n). That...is not right. I mean, they call out "in the case of a perfect hash function it would be 1", but treating the literal worst case as the actual runtime is like saying quicksort runs in O(n^2) (which the author does not do).

Re: JavaScript Algorithms and Data Structures (2018)

#18

Well, it's good resource. pleased by it. Can anyone suggest good Data structures and algorithms resource like this but not written in JavaScript?

There is a resource that shows algorithms in multiple languages - rosettacode.org - it exposes the task (problem to solve) and its solution implementation.

Re: JavaScript Algorithms and Data Structures (2018)

#19
post #15
post #11

Is there any practical reason use, say, a linked list from this library vs javaScript's native growable array. You can use unshift() to delete in the middle.

Presumably, inserting and removing from the middle of a linked list is much faster than from an array.

This property is only helpful if you have a reference to the node or are only making head/tail updates. If you have to do any amount of iteration, you're usually better off just rebuilding the list. It takes less memory, and is better on the cache.

The one other time a linked list is really good is if the list is large, and you can't afford the chance that you need to resize the array backing the vector.

Re: JavaScript Algorithms and Data Structures (2018)

#20

Do we really need yet another list of algorithms to memorize for interviews? Is another list going to make a better JavaScript engineer? Will help me understand JavaScript better? Will it help me on the job? Will it make me a faster and better React developer? The obvious answer to all of the above rhetorical questions - fuck no. That being said, it is still a topic of interviews, so I will up-vote bc this is pretty…

Reciting algorithms is reverse gatekeeping. If an employer wants to grill you on them, get out of there.

Doesn't GOOG go hard in the paint with those questions though?
Post reply on HN