Try the "Recursive Mono" or "PT Mono" variants of Iosevka.

You can actually use the bottom of a ceramic mug as a whetstone to sharpen knives if you're dedicated enough!

Minke whales are not in any way endangered (or close to it). Check your facts. https://en.wikipedia.org/wiki/Minke_whale

Yet. I take the view that the human race should only be harvesting things it really needs. The case for whaling (that I'm aware of) seems pretty weak. And if Norway did sign up to protect marine wildlife in exchange for oil rights (I'm taking that at face value at the moment) then it does seem like a jerk move to take the oil and not protect the whales.

"Protect marine wildlife" is not the same thing as "ban harvesting of a species that is not endangered."

This is where we part company. My belief is that they are. It is my view that the end result of "protecting wildlife" should be that the wildlife flourishes.

So you would suggest using external text files to store every SQL/Cypher query that is used in a model-based node app?

Well, if the query is longer than a 3-4 lines then it's really a program in its own right, and yes, I think it deserves its own file.

I use Browserify with Coffeescript modules, and the source maps work great. I'm using Coffeeify to do it: https://github.com/jnordberg/coffeeify

Chrome on iOS is Safari in a box.

I respect where you're coming from, but I disagree. One of the huge advantages of npm for me is that it's so transparent and I can see exactly how it's mapping to the file system. I know exactly which code is being run, from where—because it's incredibly easy to traverse the dependency tree. If you abstract away the fs level and flatten the dependencies into a single folder, you take this away, and you make the dependency tree essentially a big intimidating blob of code that requires slogging through package lists to determine what is actually being used.

Nothing in what I'm doing prevents what you like about npm. In fact npm already abstracts away what you want in a little known command called `npm explore`.

Let's say you want to explore the dependency `foo` in your project. At the root of your project type `npm explore foo` and press enter and you'll be in a shell exploring the foo module. Then if you want to return, type `exit` and return and you'll be back in your project. Or if you want to go down the rabbit hole to a dependency of foo called bar, type `npm explore bar` and press enter.

`npm explore` is a great way to explore things and navigate to the dependencies used by the dependency you want to investigate. It basically uses the information in the current package.json to find the dependency you want.

I disagree. I think node's approach is easily understandable, and quite robust. It's incredibly easy to dive down the dependency chain and see every package, and know exactly which one is being used where. Not something that can be said about package managers that use the flattened approach.

Pretty Printing the full dependency tree is a feature that could be easily added to npm itself, and in a way easier way to understand than trying to read through a directory tree

I'm slightly confused by your wording but I think the functionality you're referring to is already available via Object.defineProperty's "get" and "set" options: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Object.defineProperty allows to overload get/set for a single key at a time.

Harmony proxies catch everything, and really overload the getter/setter mechanism.

You can set a custom getters and setters, but I wouldn't call it operator overloading. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

So...

    > var x = {}
    > Object.defineProperty(x, 'value', { get: function() { return 1 }, set: function() { console.log('set') } })
    > x.value
    1
    > x.value = 2
    set
    > x.value
    1