3 ms·

My summary: he worked at Google in the early 2000's (when there were indeed many astonishingly productive progammers), and he saw them being super productive in

by chubot 8y ago

My summary: he worked at Google in the early 2000's (when there were indeed many astonishingly productive progammers), and he saw them being super productive in languages like Python. And he himself became productive in such non-Lisp languages. He uses the hash table as an example, and I think it's apt. Lisp does feel "old" to me with respect to having 10 different choices for hash tables in 10 different dialects. (I briefly worked with Julia's femtolisp a couple years ago and felt this.) I also felt it when trying OCaml like 5 years ago. I loved the language, but having to "choose" which hash table to use felt odd. Newer languages like Go and Rust (I think) both have Python/Perl-like hash tables built-in, or at least close to the core where all libraries can interchangeably use them. I think this is here to stay. Hash tables won :)

sshine 8y ago
Also, standard libraries that make good choices have won. These are some of the most annoying part of any language: In Perl the key of a hash must be a string, in Haskell, String is a linked list. And so on.
- lizmat 8y ago
  FWIW, in Perl 6, keys to so-called "object hashes" can be objects without them being stringified. See https://docs.perl6.org/language/hashmap#index-entry-object_hash https://docs.perl6.org/language/hashmap#index-entry-object_h...
drmeister 8y ago
You have four different choices for hash-tables. You choose how the key hashing should work with four levels - pointer hashing (which is very fast) to hashing the contents of arrays and list keys (which is slow). If you only get one choice then hash-tables wouldn't be as powerful.
- dreamcompiler 8y ago
  And in many implementations you have several options for weakness on hash tables. While not required by the standard, weakness is a very powerful enhancement to hash tables. (Weakness is the kind of thing programmers could add themselves if CL had a MOP for the garbage collector.)
gowld 8y ago
Did Google have a lot of Python in the early 2000s? In 2002, C++ had a plethora of non-standard hash-tables: http://www.drdobbs.com/the-standard-librarianhash-tables-for-th/184403822 http://www.drdobbs.com/the-standard-librarianhash-tables-for... Today there are a plethora of standard hash tables. Yet C++ isn't dying like Lisp.
sullyj3 8y ago
Clojure places a lot of emphasis on its built in hashmaps.

by chubot 8y ago

sshine 8y ago

Also, standard libraries that make good choices have won. These are some of the most annoying part of any language: In Perl the key of a hash must be a string, in Haskell, String is a linked list. And so on.

lizmat 8y ago
FWIW, in Perl 6, keys to so-called "object hashes" can be objects without them being stringified. See https://docs.perl6.org/language/hashmap#index-entry-object_hash https://docs.perl6.org/language/hashmap#index-entry-object_h...

drmeister 8y ago

You have four different choices for hash-tables. You choose how the key hashing should work with four levels - pointer hashing (which is very fast) to hashing the contents of arrays and list keys (which is slow). If you only get one choice then hash-tables wouldn't be as powerful.

dreamcompiler 8y ago
And in many implementations you have several options for weakness on hash tables. While not required by the standard, weakness is a very powerful enhancement to hash tables. (Weakness is the kind of thing programmers could add themselves if CL had a MOP for the garbage collector.)

gowld 8y ago

Did Google have a lot of Python in the early 2000s? In 2002, C++ had a plethora of non-standard hash-tables: http://www.drdobbs.com/the-standard-librarianhash-tables-for-th/184403822 http://www.drdobbs.com/the-standard-librarianhash-tables-for... Today there are a plethora of standard hash tables. Yet C++ isn't dying like Lisp.

sullyj3 8y ago

Clojure places a lot of emphasis on its built in hashmaps.