Second this. Their BDFL's personality is not suited for the job IMHO.
Example: Nim's hash table data structures (Python dict, Go map) are called tables. There are several variants of these, including OrderedTable. Deleting a key from an OrderedTable had O(n) performance because Nim built an entirely new OrderedTable, filtering out the key to be deleted. There were a couple of reasons for this:
- the internal list that preserved element order was only forward threaded, making an O(1) delete impossible
- Nim tables allowed the same key to be inserted multiple times, each with different values. I thought this was a bit crazy compared to other languages.
I tried to changed OrderedTable to use a doubly-linked list to allow O(1) deletes, and to get the multiple key feature removed.
What I didn't realize is that Araq, the BDFL, used ordered tables a lot in the Nim compiler, used the multiple value feature, and didn't want to add the memory overhead of a 2nd list to OrderedTable. His main reason was "deletes don't happen too often". At that point it became impossible to convince him that for a hash table to have O(n) delete performance was ridiculous and would be unexpected for anyone using OrderedTable. I gave up, left, and haven't been back.
Andreas is simultaneously brilliant and myopic to needs outside of his own (compiler dev).
It's amazing how many fights he gets into with Status-IM engineers who are the biggest financial supporters of the project and the only noteworthy company that heavily uses Nim.
Has OrderedTable been ported to Nimony? Does it still have this bug?
OrderedTable is now a synonym for Table, ie, both are ordered. To delete a key, the key is looked up to get an index position x in a Seq, the Seq entries after x are shifted left, the Seq is trimmed of the last element, and then the entire table is rehashed because shifting the Seq invalidates the previous hash codes. The performance is better than Nim OrderedTables because at least an entirely new table isn't created, and it probably works fine for small tables, but it still isn't O(1). The performance would be similar to removing an item from a single-threaded sorted list: most painful to remove the 1st element, least painful to remove the last element, but then you still have to rehash the entire table.
Second this. Their BDFL's personality is not suited for the job IMHO.
Example: Nim's hash table data structures (Python dict, Go map) are called tables. There are several variants of these, including OrderedTable. Deleting a key from an OrderedTable had O(n) performance because Nim built an entirely new OrderedTable, filtering out the key to be deleted. There were a couple of reasons for this:
- the internal list that preserved element order was only forward threaded, making an O(1) delete impossible
- Nim tables allowed the same key to be inserted multiple times, each with different values. I thought this was a bit crazy compared to other languages.
I tried to changed OrderedTable to use a doubly-linked list to allow O(1) deletes, and to get the multiple key feature removed.
What I didn't realize is that Araq, the BDFL, used ordered tables a lot in the Nim compiler, used the multiple value feature, and didn't want to add the memory overhead of a 2nd list to OrderedTable. His main reason was "deletes don't happen too often". At that point it became impossible to convince him that for a hash table to have O(n) delete performance was ridiculous and would be unexpected for anyone using OrderedTable. I gave up, left, and haven't been back.