Object model reformation?
brendan at mozilla.com
Thu Dec 27 08:44:45 PST 2012
Andreas Rossberg wrote:
> On 27 December 2012 05:53, Brendan Eich <brendan at mozilla.com
> <mailto:brendan at mozilla.com>> wrote:
> I have a theory: hashes and lookup tables (arrays or vectors) have
> displaced most other data structures because most of the time, for
> most programs (horrible generalizations I know), you don't need
> ordered entries, or other properties that might motivate a
> balanced tree; or priority queue operations; or similar
> interesting data structures we all studied in school and used
> earlier in our careers.
> It's good to have these tools in the belt, and great to teach
> them, know their asymptotic complexity, etc.
> But they just are not that often needed.
> Not often used =/= not often needed.
True, and hard to prove.
> Seriously, I contest your theory. I think such observations usually
> suffer from selection bias.
Definitely the big weakness of my "theory". It's not mine alone of
course, and it is not falsifiable _in situ_ or by
simulation/reproduction, like a lab experiment. But my gut says there's
something going on here beyond hashes-and-arrays selection bias.
Hashes and arrays are strong in memory safe languages but one still sees
other data structures evey in dynamically typed languages, especially
the rise of functional data structures.
What I do not see yet: more elaborate "Collections" APIs that were
popular decades ago, but that do not scale well out of the d-cache.
> In imperative languages, you see arrays used for almost everything,
> often to horrible effect. In the functional world many people seem to
> think that lists is all you need. In scripting languages it's often
> hashmaps of some form. I think all are terribly wrong.
JS hackers use objects and arrays, but also lately more map/fold-based
stuff. At small scale its overhead doesn't matter, and with the right
discipline it can scale up to very large working sets.
We hope with RiverTrail and other research to go beyond that. I've seen
v8-cgi-programmed 48 core boxes with global (slow) and local (to the
core, but only that core) memory using this style, it can work with
> Every community seems to have its predominant collection data
> structure, but the main reason it is dominant (which implies vastly
> overused) is not that it is superior or more universal but that it is
> given an unfair advantage via very convenient special support in the
> language, and programmers rather shoe-horn something into it then
> losing the superficial notational advantage. Languages should try
> harder to get away from that partisanship and achieve egalite without
That is a good reason for more languages and language innovation. JS
ain't everything to all programmers, thank goodness. Mozilla is
investing in Rust to elevate safety and concurrency beyond C++, and this
requires new thinking (an ownership system with enough richness to
capture all the safe-ish C++ idioms).
> But yes, ES is probably not the place to start fixing this. :)
Not generally. However, the functional style is on the rise in JS, and
we're pushing it farther with things like RiverTrail. It's not
unthinkable that JS could evolve into a better eager/mutating functional
language, with more functional data structures and fewer arrays and
More information about the es-discuss