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]
> It's a bit awkward to read on large screens. Long lines and whatnot
For years and years and years I always had a half-screen-width browser window, precisely because it's easier to read text that way. But then site authors started assuming that I'd have a full-width window, and using CSS to waste half the window width.
I still think that the correct response to 'window too wide' is 'shrink the window,' but it's a losing battle.
Wait, why wouldn't the solution be "define a max width"? Site authors should not be wasting your window width, windows should not be "too wide" for text, and you shouldn't have to choose between the two solutions you mentioned.
Only because it seems to me that if the user really wants a terribly wide window … that's his choice. Who am I to prevent someone from doing something which seems stupid to me? Maybe he wants a half-inch high window at the bottom of his screen where he can scroll through my text slowly, or something. His call, not mine.
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.
FYI: Oct. 8 release by the Angular team on their adoption of semantic versioning and handling of rc. and beta releases. Looks like they are going for a major release every roughly 9 months:
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.
My university's Engineering Science department runs a competition each year for high school students along the same lines -- mathematical modelling of an open-ended question.
I also found it very valuable; it was one of the factors that pushed me over the line into studying STEM at university (I was a better English and economics student in school).
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.
[1] : https://en.wikipedia.org/wiki/Lars_Bak_(computer_programmer)