Andreas Rossberg wrote:
On 27 December 2012 05:53, Brendan Eich <bren...@mozilla.com
<mailto:bren...@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
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
