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.
I touch on this point in OP, I am not saying owners should receive some absolute right, I am saying I believe an indefinite right (referring to the term only) of existing protections subject to existing infringement and defenses (fair use, derivative, news worth, ect...)
Your use of song is a good example, just because I create a song (and receive indefinite protection) does not mean someone else can not sample it, only that I am entitled to a royalty..any why shouldn't I be whether I created the song yesterday or 100 years ago and transferred the copyright to my heirs?
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 remember reading an article about this phenomenon, and arguing from that "plagiarism" as a concept will eat the "copyright" concept. unfortunately i cannot find it right now.
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.
Apparently, git does not allow you to alias default git commands (like "pull", "push", "commit", etc) to something else. In the given situation, a user is trying to alias the default "pull" command to "pull --ff-only" so that pull will not automatically merge changes and will only fast-forward.
However, since git does not allow you to alias default commands, when the Git Master runs "git pull" it ignores the alias entirely and does a normal pull, and in so doing merges changes. The student is confused, but eventually figures it out.
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.
