Object model reformation?

Brendan Eich 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 
enough care.

> 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 
> baroque.

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 
hashes in-the-large.

/be


More information about the es-discuss mailing list