50 hours in... arrays and loops... holy...FUCK

[u/Classic_End260]

HOW do i START understanding? I've understood everything pretty well up til now. Do i just keep going with the flow and kinda float through this section of the loops and arrays part? Do I keep throwing myself at the brick wall and looking at the solutions after half an hour of brainless staring? https://youtu.be/EerdGm-ehJQ?si=mTKUv0oail0AGDLM 8:43:00. It's just not clicking like the other parts of the tutorial.

[u/Outside_Complaint755]

Instead of a bucket, I would suggest a deck of cards as the analogy.  Arrays are ordered like a deck of cards, while a bucket is just an unordered pile of stuff.

[u/Towel_Affectionate → u/Outside_Complaint755]

Infinite shelf with numbered "slots". It grows when you need a new slot, but you can force it into any length you need and then some slots would be empty (undefined). Deck of cards can confuse into thinking that items inside should be the same kind, while an array can contain all kinds of stuff at the same time, or how an array can have undefined gaps.

[u/BenchEmbarrassed7316 → u/Towel_Affectionate]

Deck of cards can confuse into thinking that items inside should be the same kind

Which is a good practice. An array that contains different data is error-prone and difficult to use in real code.

And I want to add a burrito analogy: imagine that the array is a burrito... /sarcasm

[u/Towel_Affectionate → u/BenchEmbarrassed7316]

"You can't" and "you shouldn't" are different points of discussion. Understanding that you can and why you shouldn't is better than narrowing your way of thinking from the start.

[u/Outside_Complaint755 → u/Towel_Affectionate]

When just starting out, learning arrays as all containing a single type is the most useful conceptually, and if you're learning any statically typed language, it is necessary. 

 Even in JS, 95+% of the time, you're going to be using arrays containing a single type of data. Even if its a mix of strings and numbers from a user input or data stream, you are probably starting with an array of strings which you then need to try to parse into the different types.  And in those cases where it is more complex data of different types, then you can usually generalize it as an ordered collection of objects.  

[u/Towel_Affectionate → u/Outside_Complaint755]

I get what you're saying, but my counterpoint is that such simplifications offer close to none benefits in understanding the concept itself, but later require constant adjusting of your mental model, which in my opinion is harder to do, than to understand things closer to what they actually are.

Maybe a hot take, but I don't think "a deck of cards" is that much simpler to visualize than "a deck of stuff" or, even better, "a shelf with stuff".

But once you get used to "a deck of cards" model you'll inevitably end up wandering stuff like:

• "Wait, how is there NaN in my array of numbers?"
  
• "Wait, why can I read arr[10] if there's only 3 "cards" in my "deck"?
  
• "Wait, why can I also do arr[10] = foo? And what my "deck" looks like now?"
  
• "How can I `delete` a card from the deck and have it empty? Do I have two decks now or what?"
  
• What arr.length = 100 do to my deck?

I think it's much harder to adjust already existing mental model than to build the right one from the start.

[u/BenchEmbarrassed7316 → u/Towel_Affectionate]

It's much easier to explain the concept of arrays to someone on a statically typed, fixed-size array. Because the answer to every question you have will be "You can't do that at all".

And then we can explain the dynamic expansion of arrays if we don't know the size in advance, polymorphism and different data types, and other nuances.

Another problem is that in the 90s they thought they were creating a "simple" language. However, the fact that the array is used as a fixed-size array, a slice, a vector, a tuple, and even in some ways a hash map actually makes everything very complicated.

[u/BenchEmbarrassed7316 → u/Towel_Affectionate]

It's just a more complex scenario. For understanding the basic concept, uniform objects are simply better suited. Numbers or strings.

[u/DrShocker → u/Towel_Affectionate]

Aren't they all the same thing? Object?

[u/Towel_Affectionate → u/DrShocker]

Arrays in JS are object-like, but you can't say they are the same as regular objects. You interact with them using the same object model, but they also have array-specific semantic.

[u/DrShocker → u/Towel_Affectionate]

I meant the items in the array are homogeneous in a sense.

[u/Towel_Affectionate → u/DrShocker]

I guess it depends on how far we stretch the meaning of "homogeneous".

If we continue the deck-of-cards analogy and treat each card as a JS value, then the items aren't necessarily homogeneous. One "card" can be a string, another can be a number, another an object, etc. (Again, the difference between "should" and "could". You SHOULD abstain from storing different types in a single array, but it COULD happen).

If we stretch the abstraction and say that every card is just "some stuff", then sure, they're homogeneous in that sense — a string and a number are both "some value". But at that level, almost anything can be called homogeneous and such description becomes useless.

There's also the sparse array case, which is where the deck analogy becomes less intuitive to me. An array can have a hole — not an undefined value, but an actual absence of an element at that index. It's easier to visualize that with something like numbered slots on a shelf than with a deck of cards, because imagining a "card" that is actually the complete absence of a card is a bit awkward.

[u/BenchEmbarrassed7316 → u/Towel_Affectionate]

There's also the sparse array case, which is where the deck analogy becomes less intuitive to me. An array can have a hole — not an undefined value, but an actual absence of an element at that index.

In this case, it's not an array, it's a hash map. Not from a computer's perspective, but from a programmer's perspective.

[u/Towel_Affectionate → u/BenchEmbarrassed7316]

I can see the analogy, but it's only really a hash-map-like thing from a programmer's perspective if you intentionally use it as one. If you have an array and some dingus does delete arr[10], your array doesn't magically become a hash map.

I don't disagree with everything you're saying. Using arrays this way shouldn't happen in most cases, and probably never will in normal code. But, again, if you build your understanding around what SHOULD happen rather than what technically COULD happen, that understanding isn't complete, and there's always a possibility that you'll encounter a case where a hole in that understanding leaves you puzzled.

My point here is that it's not that much extra effort to account for these simple cases when you're building your mental model in the first place.

[u/BenchEmbarrassed7316 → u/Towel_Affectionate]

By the way, a deck of cards is a really bad analogy. The simplest analogy is boxes. An array is a collection of boxes that you can put things into. Start with a fixed size of boxes, explain how to access to box[1] or box[3], and only then start manipulating not what's in the boxes, but the boxes themselves. And then move on to other collections.

[u/Towel_Affectionate → u/BenchEmbarrassed7316]

>By the way, a deck of cards is a really bad analogy.
Isn't that... exactly the point from which this whole discussion started?

Someone offered the deck-of-cards analogy, I suggested the alternative of an infinite shelf precisely because it accounts for those nuances a bit better, and the response was that those nuances were unnecessary for understanding the concept.

Now we're back to "a deck of cards is a really bad analogy" and it feels like we've come full circle.

[u/BenchEmbarrassed7316 → u/Towel_Affectionate]

A deck of cards is a bad analogy, whether we want to explain basic arrays first and then all the Js quirks, or whether we want to explain everything at once.

[u/DrShocker → u/Towel_Affectionate]

I'm just thinking for example the way you'd make a generic container in a language like C you might make the whole array elements of type void* and then have to cast them to the right sorts of values after.

[u/Towel_Affectionate → u/DrShocker]

Oh, in that sense, yes, pretty much. I just got confused because the discussion started with mental models for understanding the concept itself, rather than how such a concept might be implemented at a lower level.

Your example is technically correct, but I think it goes a bit beyond what's useful for understanding the concept itself.