I use projectile with caching turned off with flx-ido for sorting. I heavily favor (projectile-find-buffer) once I get going since loading the whole tree is pretty slow on a large project. I'm way more happy with this setup than I was with CtrlP.
There is joint initiative by local municipalities and universities to bring in a private company to run fiber (http://ncngn.net). It's not clear to me how this will be affected by the Google announcement. (They released a rather vague statement about it.)
Copyright is traditionally an area of law that has been served by moderation. The government offers some protection to creators, but not absolute rights. For instance, songwriters have a right to receive royalties when someone else records and distributes their song, but they don't have the right (in the US) to set the price of that royalty, or to veto a particular artist covering their song. It's a balancing act.
On the one side, if you don't have copyright at all, it severely limits the ability of creators to monetize easily copied works. This became a problem with the printing press and copying has only gotten easier as technology has progressed.
On the other side, there are a number of problems with granting an absolute, indefinite copyright. One is that you stifle the creation of derivative works. Another is that obscure works can easily fall out of print and be lost forever. A larger philosophical concern is whether corporations should be allowed to hold control over the shared cultural heritage of a society long after the actual creators have died.
Almost everyone sees the need for some kind of compromise here. Personally, Canada's life+50 years sounds pretty reasonable to me.
Plagiarism is passing someone else's work off as your own. Unauthorized copying is just providing a work for others to consume without claiming credit for it, but without having a legal right to do so. Plagiarism doesn't really relate to authorization at all. If you have permission from someone to put your name on their work, that doesn't change the fact that you are lying, which can have consequences of its own (especially in an academic context).
I thought this was obvious, but maybe it isn't? I see disclaimers on Youtube all the time ("I don't own this") which seem to imply the person posting the video doesn't understand the difference.
I think the answer is the dynamic environment. In terms of syntax and semantic constructs Ruby is not very much like Lisp at all. But the dynamic runtime is very lisp-like. You can modify any part of the environment at runtime—in fact there is really no distinction between run-time and compile-time.
IMO the biggest flaw in Ruby is that it doesn't really take advantage of this design choice. Of course there is a performance cost to this kind of dynamism, and all it really buys you in Ruby is the ability to monkey-patch other people's code (the advisability of which is debated). In the Lisp world you have tools like SLIME which provide a much shorter feedback loop to the developer by connecting the dynamic runtime to the editing environment.
Tools like pry move Ruby forward in this area but it is still nothing like SLIME. My impression is that the weakness of Ruby's module system, along with heavy use of OO classes, make it unlikely for Ruby to ever support that kind of development process.
(There are other examples of Ruby's Lisp heritage, such as everything-is-an-expression and implicit return values, but I think those are relatively small design choices compared to the runtime thing.)
I'm not sure what Silence is about. My git-config-fu fails me.
One Thing Well demonstrates how one command (git checkout), while it does do 'one thing well' (changing your working directory to match something in the index), can handle a wide variety of seemingly unrelated use cases.
Only the Gods demonstrates how history can mean different things: commit parentage, which is usually immutable, and branch history, which is ephemeral.
The Hobgoblin probably refers to the Emerson quote "A foolish consistency is the hobgoblin of little minds."
The Long and the Short of It is about how git accepts `git --help command`, `git command --help`, and `git command -h` but `git -h command` returns an argument error.
A theme here is that git does not try to anticipate your workflow. Its commands and options are named based on what they do, rather than how you should probably use them. This makes git a very powerful tool, but with an interface that is often counter-intuitive.
I think this is fundamentally flawed. Take HAML, for instance. It tends to be polarizing, but not along the axis he has laid out. People who don't like it usually point to the unfamiliar and non-standard syntax (conservative), but the thing that I like about it is that it is more structured, and less error-prone than string splicing (also conservative).
In general, when I fall on the liberal side of an argument, I think it is for the reasons he gives (no fear, resist ossification). But when I fall on the conservative side (which happens just as often) it is not because of fear, but because I think that mathematically rigorous abstractions (pure functions, persistent data structures, etc) offer a more powerful way to approach the problem.
I think my attitude toward bugs (which he suggests is the defining issue) is more nuanced than this spectrum allows. Bugs are inevitable, and it's not the end of the world when you have a bug. We need debuggers. But I think that over time, if we are doing anything right, we should be growing a stable core of our codebase that is increasingly flexible and bug-free. I guess maybe this could be considered a centrist view. It is certainly neither liberal nor conservative.
Someone in the thread mentioned pragmatism vs. idealism. I think this is a much more useful distinction. I would definitely consider myself an idealist. But the pragmatic-ideal axis doesn't map to the conservative-liberal axis at all.
In my experience, if you are counting characters or lines in regular vim editing, you are doing it wrong. The smarter jump commands, text objects, and a high key repeat rate are all far superior to counting 20 characters. I do use counts a bit with w/W for words. The main advantage is making your edit in a single command so you can reuse it with dot.
I think he's talking about when an app is in a bad state, and you can kill it to force a cold launch. If the app truly crashed it would cold launch anyway.
I liked it as well. Some other thoughts on the film:
1. The bulk of the story is framed as Cobb & Saito's recollection in limbo. My theory is that the recollection (rather than the gun) is what wakes them up.
2. There is no explanation for why the first kick in dream level 1 (the one they miss) doesn't wake up Arthur, who is awake in dream level 2.
Whether it pastes a newline or not depends on whether you yanked one. I guess this is what you mean by "vim preserves new lines". Don't all editors work this way?
If you want to yank a line character-wise, you would do something like ^y$. I have Y mapped to y$ for this sort of thing.
You cannot yank a substring of a line line-wise. That doesn't really make sense. I typically open a new line with o and then paste in insert mode with <C-r>". So o<C-r>".