As the person who implemented it originally, it was not a technical limitation but a design choice.
In the early implementation of Warcraft 1 (1993-ish) I made it possible to select all the units on-screen at once with drag-select, and even more by scrolling and shift-clicking or shift-click-dragging.
Allen Adham (president of Blizzard, and exec producer for Warcraft) argued convincingly that only 4 units (for War 1) should be selected at a time. I argued against it pretty vociferously at the time … and in later days (post launch, most likely) came around to his way of thinking. Attacking with a superfluid of units takes less skill than selecting troops in small batches, and so requires to use more intent & skill.
Warcraft 2 allowed 9 units to be selected, and StarCraft more.
• The first group sees something in the world as wrong / broken / requiring change, or just "could be better"; they see themselves as a force for that change; and they see any organization they're a part of, as infrastructure to enable/multiply their force. To these people, the organization is only relevant/valuable as long as it is providing leverage for individuals like them "on the front lines" to accomplish change. To these people, "everything staying the way it is" is an awful concept — if they were willing to accept things as they were, they wouldn't have bothered to become $profession! They will consider their life wasted if things don't end up changing for the better!
• The second group sees nothing wrong with the world, because (in part) they see those frontline people working toward positive change, to be an inherent part of the equilibrium-state of the world. They do think the problem is a problem worth solving! (That's probably why they gravitated to this industry.) But they think that "things are going great" in addressing the problem, insofar as there are these other people who are willing to "fight the good fight." They don't think it matters much whether any particular individual is involved in that fight, as long as in aggregate "people who are motivated to solve the problem" are minted faster than they burn out. People in this group don't feel motivated to be directly involved in solving the problem; and they also aren't much concerned with "losing" people who are directly involved — since they believe that there will always be new "new blood" coming in with a fresh reserve of morale.
The first group ("vocationals") will focus on the work to the exclusion of maintaining the organization. In a crisis, they will let the organization fall apart so that the work can continue happening.
The second group ("professionals") knows this, and thinks this is silly — to them, the work will always get done soon enough (because, if vocational A can't do it, vocationals B/C/D will feel compelled to pick up their slack, at their own expense.) But the organization itself might become paralyzed or fall apart — which these people believe would prevent the work from happening for a much longer time. So they dedicate themselves to keeping the organization functioning — which often involves cutting costs (i.e. making the first group's lives harder), imposing regulations (i.e. punishing the first group for the times they go above-and-beyond to get the work done at the organization's expense), etc.
These groups are rarely aligned, because their world-views are rarely aligned.
It can happen, though. If it becomes clear that the number of people in the first group is declining over time, such that the organization cannot simply rely on "new blood" — then the second group's behavior toward the first group changes dramatically.
Ruby has method aliases. Python does not allow a string to capitalize itself.
Ruby uses Ruby methods within Ruby classes to extend Ruby. Python has decorators so you can write functions that return functions that return functions to create a new function.
Ruby has strict object-oriented encapsulation. Python is laid-back about objects, because you probably know what's going on inside them anyway.
Ruby lets you leave off parentheses so you don't miss objects having attributes too much. Python will let you mix tabs and spaces for indentation, but passive-aggressively mess up your scoping as punishment.
Ruby has seven kinds of closures. Python has one, in the unlikely case a list comprehension won't do.
Ruby's C implementation is a mess of support for language-level flexibility. Python's C implementation is so clean you get the unsettling thought that you could probably write Python using C macros.
Ruby supports metaprogramming for cases when programmers find it more descriptive. Python supports metaprogramming for cases when programmers find it necessary.
Ruby is expressive. Python is direct.
Ruby is English. Python is Esperanto.
Ruby is verse. Python is prose.
Ruby is beautiful. Python is useful.
I like Python, but coming to it after using Ruby for seven years, well, I think it's like dog people and cat people. You can like having one species around, but you're always thinking -- why they can't be more like the other?
In the early implementation of Warcraft 1 (1993-ish) I made it possible to select all the units on-screen at once with drag-select, and even more by scrolling and shift-clicking or shift-click-dragging.
Allen Adham (president of Blizzard, and exec producer for Warcraft) argued convincingly that only 4 units (for War 1) should be selected at a time. I argued against it pretty vociferously at the time … and in later days (post launch, most likely) came around to his way of thinking. Attacking with a superfluid of units takes less skill than selecting troops in small batches, and so requires to use more intent & skill.
Warcraft 2 allowed 9 units to be selected, and StarCraft more.