jesusabdullah

Equal representation for O-Town!! What's the history of T-graph? Peralta? San Parblo? I bet MLK (nee Grove) has some interesting history.

(I assume T-graph followed a telegraph route between Oakland and Berkeley. I more or less know where West MacArf got its name.)

There are some tools for using npm for large scale deployments. Packages are scoped locally to an app, you can bundle them if you want, and there's a "shrinkwrap" command for making sure the installed deps are exactly the same every time. Personally, I would either go with, "peg every version to an exact semver" or "bundle ALL the deps".

I think getting a usable web stack on julia will take it a long way in terms of making it useful for problems at-scale.

My major nitpick with julia so far, if I can be real, is that its package tooling isn't enough like npm. <_< While this gives away my obvious biases, I do think that spending time on making a really good package ecosystem is important, and is something not enough people take seriously.

Heather's cat finding demos are siiiiick.

> the imprecise Imperial Unit

englilsh units aren't any less precise than SI/metric ones. They're just more awkward and less used worldwide. The cases which I find particularly irritating in US units are lb mass vs. lb force, and HP/BTU/foot-pounds/calories/Calories (and kWh) when all you need is a J.

Just passing through. Anyways: Nodejitsu made package.json.jit.su well over a year ago (August-ish 2011 iirc) and I'm honestly a bit surprised to see it popping up here now of all times.

Generator's not bad. Nodejitsu never made anything like that on the web, though `npm init` and jitsu's built-in prompts fulfill a similar need on the cli.

numpy and scipy are poor examples because they're not core python modules. You still install them from separate people.

As a noder, I'm like half-way with you.

In javascript, as with other languages, you can totally use inheritance (prototypal in js) when making things. But, it's usually better to expose an object than a constructor (imo) when it comes to exports. Being expected to do something like:

    var Foo = require('foobar').Foo;

    var Bar = function (opts) {
      Foo.call(this, opts);
      this.baz = "biff";
    }

    require('util').inherits(Bar, Foo);

This sort of behavior is all well-and-good, but it should be contained because it's boilerplate-y. In javascript, at least, it's not a very good pattern, and I suspect this carries over to other environments (to an extent).

I also think that standard libraries have to strike a balance between "batteries included" and "not cluttered with a bunch of crap that was relevant in 1995", and that different standard libraries attempt this in different ways. I think python neglects the latter to supply the former, while node swings the other way and compensates by having a really nice package manager. Time will tell which is a better approach, but I'm betting on Node's model.

> The "radical reusability" section is just the author realizing that modules are awesome. Again, welcome to the party.

Modules are awesome! You sound like a python guy, meaning your module system is actually pretty good when it comes to qualified imports. Compare python imports to ruby's require, or browser-side script tags sometime, and I think you'll find that there's an awareness problem when it comes to qualified imports. :( That said, the package management side is kinda shitty for python (at least when compared to npm).

Is this something I can do after-the-fact? I'm pretty noob at HN's interface.