28 karma · joined July 26, 2014
[1] : https://en.wikipedia.org/wiki/Lars_Bak_(computer_programmer)
body {
margin: 1em auto;
max-width: 40em;
font: 1.2em/1.62em sans-serif;
}
It's a reasonably complicated topic, but the basic idea is that since the data structures are immutable, much of their structure can be shared between versions with few changes. Most of these data structures end up using a Tree of some sort. Performance characteristics can be influenced to an extent by using bucketing to control the width/height of the tree.
[1] : Purely Functional Data Structures (Amazon: https://www.amazon.com/Purely-Functional-Structures-Chris-Ok...) [2] http://hypirion.com/musings/understanding-persistent-vector-... [3] https://www.youtube.com/watch?v=7BFF50BHPPo
2.0 was released 28 days ago
It reminded me a lot of Randal Munroe's "What If" blog on the XKCD site [1]. Easy to understand, open ended questions that encourage readers to learn a little about topics _outside_ of math to answer the question. The class gave me an appreciation for math that was lost during all those years of study before that, and it's basically my career now.
I think this depends on whether GitHub treats URLs as just URLs, or more generally as URIs. Based on their documentation [0], they refer to them as URIs, which means they are intended to represent both Location and Identity [1]. The domain represents the "where", the repository path is the "what".
They should be able to change their URL schema relatively easily, by including the appropriate redirects - a mapping from the old schema to the new. Which is exactly the strategy they discuss in the HTTP Redirects section.
(edit) Formatting
[0] : https://en.wikipedia.org/wiki/Uniform_Resource_Identifier
Option[Int] is simply an alias to the type Int | Null, so Int | Option[Int] would become Int | Int | Null after replacement, which simplifies to Int | Null since Int | Int is equivalent to just Int.
The vim command structure makes it trivial to define transformations on common blocks of text; words, sentences, paragraphs (lines), blocks of code inside {..}, etc. It makes it easy to repeat those commands, by repeating them a fixed number of times, applying them to every instance in the file, or asking for confirmation around each one.
But, most importantly, it means that we can now extract that little bit of text-transforming functionality into a script we can save and bind to a new command (if it's something particularly reusable). This is really what vim is about to me - providing a language to describe text transformations, in the form of sequences of commands. This means that the way I code every day, conveniently saving me a few seconds like you mentioned above, is the same method I use when writing/editing plugins/macros for the editor to do more complicated tasks, like say consistently formatting every line of a log file that begins with [ERROR] and removing all other lines, so we can process it with some other tool.
Sure, you could write a script in [python/perl/ruby/etcetcetc] to do all that just as well, but the point is that Vim provides a nice little domain specific language right at your fingertips, optimized for working with text at a higher level, capable of handling one-off jobs as easily as big jobs over a whole log file or even as a little command to be reused later.