Ivan Sagalaev

This implementation was used from 3.6, right?

It's interesting that the idea mail mentions that nothing changes about the implementation (including order) but the memory layout. Which would imply insertion order was already preserved in older versions (not the case IIRC) or the idea underwent a few more changes that did in fact impact order.

EDIT: I couldn't quite find an answer but https://softwaremaniacs.org/blog/2020/02/05/dicts-ordered/ mentions the behavior happens since then because the implementation only tracks indices in the hash table itself and relies on maintaining entries separately in a second array that gets expanded in insertion order.

This would also seem straightforward but it raises a few questions such as how deletion is implemented (efficiently).

EDIT2: Okay, the talk (https://youtu.be/p33CVV29OG8) mentions they just leave holes until the next resize (at around 42:00).

Raymond also mentions there that his original idea didn't preserve ordering but happened due to an additional compacting optimization? Should probably watch the whole thing some time to get the history. Sounds like a fun talk.

Thanks, yeah, I was very careful to avoid claiming they're mutually exclusive. However, although I stopped trying to learn Rust back in 2016, unless it's changed its fundamentals radically (which I understand it hasn't), I'm not sure if it's really a counterexample here for expressiveness. Can you use different allocators for different vectors in the same function in Rust? Can you have custom move semantics for objects that might know about pointers to them? And does the compiler no longer complain about code that really should work just fine? [1] I understand the answers to most if not all such questions is still "no", at which point I stop believing it really has the same flexibility as C++ or the same ease of writing as Python, but would be happy to hear if things have changed.

[1] http://softwaremaniacs.org/blog/2016/02/12/ownership-borrowing-hard/en/

highlight.js [1] does this, though by running highlighters rather than using some learning-based mechanism. It feels wasteful to run this on display rather than storage, though. SourceClassifier [2] also works, though with less languages. And here's [3] an implementation made with Bayes and Go.

[1] http://softwaremaniacs.org/soft/highlight/en/ http://softwaremaniacs.org/media/soft/highlight/test.html

[2] http://blog.chrislowis.co.uk/2009/01/04/identify-programming-languages-with-source-classifier.html

[3] https://github.com/octplane/go-code-classifier

The app depends on highlight.js which currently supports a limited set of languages, and unfortunately, Brainfuck isn't one of them.

http://softwaremaniacs.org/media/soft/highlight/test.html

I wonder what would happen to the accuracy of highlight.js highlightAuto method if more languages were to be supported. Highlight.js recognizes languages based on how many language constructs it can recognize. More languages = more overlap in language constructs, and therefore more likelihood of wrong matches.