To be fair, I'm pretty sure some of the engineers at Google and Facebook have spent some time with the language and platform graybeards at Microsoft, Sun, or Adobe. Some of them are those "graybeards" (in quotes, because they don't literally have gray beards). [1]
The canonical text discussing how this is achieved refers to data structures optimized for immutability as "purely functional data structures". [1] These type of data structures are the default for Clojure as well, and there are a number of blog posts and presentations discussing their implementation. [2] [3]
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.
So much this. Through a series of unexpected events, I ended up studying math in undergrad with no clue why or what I was going to do with it. My senior year I took a class called "Applied Modelling". The first project was a simple, one sentence question: "What would happen if the Greenland ice cap melted?".
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.
Based on the slides discussing Pypy performance, it looks to me that they're not confident that rewriting those 80k lines of C would provide sufficient performance. It might, but if you're not sure that's a lot of risk to take on.
> The Go maintainers have conflated what a library is and where a library is. That's an important distinction that should not be glossed over like this.
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.
It's not perfect, there's still some learning to do around the fringes where it interacts with emacs, but it is by far the BEST vik - like - but - not - vim experience I've seen so far. Much better than Sublime's vintage or any of the IDEs that provide Vim keybindings.
I believe Ceylon will actually further refine Int | Option[Int] to simply Option[Int].
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.
That kind of makes sense. How often do you view Tweets on a desktop? Even when I'm actively using a desktop browser, I usually check Tweets on my phone. Why? Because that's where I get notified first. Fits the "underpowered devices" category, right?
Features like Scala's implicit parameters could be argued to be a kind of "dynamic scope". True, the language is lexically scoped and most code is written expecting that, but it does allow you to "opt out" of this scoping mechanism and look for values to be specified in the environment.
Even in type inferred languages they serve some use, namely in avoiding mis-typed variable names. Languages which require "var" make a distinction between the intent of declaring a new variable vs setting the value of an existing variable, and so are able to catch instances where the programmer tries to set a non-existent variable.
People often mistake the succinctness of vim's commands as an attempt to save a few keystrokes typing, but that's only a side benefit.
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.
[1] : https://en.wikipedia.org/wiki/Lars_Bak_(computer_programmer)