Hacker News Reader

Comment by Tuna-Fish | Hacker News Reader

That's both wonderful and scary. I think the UI of it needs work -- if you want to treat all shell commands as functions, they imho should just return their outputs by default. (Potentially as a lazy list of lines?)

Also, I think that path should not be passed in as an environment variable, but in Clojure somehow. There's no reason for a program to pollute a global namespace with it's internal details.

View on HN

Agreed, namespace clashes are an obvious problem. "My program that worked last week now crashes? Oh, it's because I apt-get installed something completely unrelated."

Well, (use :as) fixes that one.

Namespaces are a honking great idea, let's have more of those!

Also, I think I just realized an another problem -- if I understood the lib correctly, it scans through the PATH once at require time. This is bad, because Clojure is often deployed in places where processes run for very long times. Even things as immutable as tools in PATH can change when given long enough time.

There's no (use :as), only require. (require [shake.core :as sh])

That's a step in the right direction, but it still triggers tons of warnings replacing vars in clojure.core.

use does accept an :as option:

    => (use '[clojure.set :as set])
    => set/intersection
    #<set$intersection clojure.set$intersection@58ca40be>

Prior to the addition of :refer to require, this was often paired with an :only (...) in order to alias a namespace as well as refer in some limited set of vars if desired, all in one declaration.

Huh, I checked the docs before I commented. It is indistinguishable from require :as, thought, right?

As far as I know. Honestly, by use/require/refer-fu is not very strong, I always just use the ns macro.

Yes, the :as option is the same whether you use it with require or use.

I'm also looking for better ways to index path. If I can pass some options in (use) and initialize with options, it will be better.

I really think "not indexing path" is the better choice. Instead of (uname -a), why not just export a single symbol and do (shake uname -a)? (or even just (sh uname -a)?) Then find the correct program to run at invocation time. It's more clear about what happens, and allows much simpler implementations with much less weird failure modes.

Reply on news.ycombinator.com