The concept of "a whole bunch of thingies" is a vital one in just about every programming language. Some languages support it right in the language itself. For example in C++ you can have an array of integers, or Employee objects, or Customer pointers. And when you use an array, you know that it's a continuous block of memory, and it's possible to interact either with just one element of the array or with the entire array. VB has arrays, and so does C#, and while the syntax is different between them, the essential concepts are not.

The thing is, an array is only the simplest and most accessible way to say "a whole bunch of thingies". It's important that you learn other ways to express that concept - typically by using a class of some sort that someone has written to represent it. There are a ton of these depending on whether order matters to you, does insertion speed matter more than traversing/iterating speed, and so on. Some folks, having learned one way to say "a whole bunch of thingies", look at all the other options, roll their eyes up into their heads, and stick with the one way they know.

This is bad. Not just because your code could be faster, neater, and easier to write, but also because arrays are really poorly suited for certain tasks. They especially hamper parallel programming - and you know that the future is concurrent, right?

Eric Lippert has written a cogent and compelling explanation of why arrays are rarely the right choice, and what you should do instead. It's written, naturally, from a C# perspective, but it's applicable to C++ and VB too. It boils down to this: Object Oriented Programming is the norm. Start trusting object writers. Use a class that someone else wrote and provided with your compiler, and you'll be a happier developer. And if you don't have some neurons fire over the phrase "considered harmful", here is a history lesson on that.

Kate