w01fe

7 ms·

31.
by w01fe 13y ago
I think there are a few benefits. First and foremost, schemas are simple , minimal, easy to read and write, and gracefully extend Clojure's existing type hints. This means that (in my biased opinion) they are significantly better for
32.
by w01fe 13y ago
Nice! Really looking forward to the release!
33.
by w01fe 13y ago
You're welcome :) Please let us know if you have ideas for improving it
34.
by w01fe 13y ago
Thanks for the feedback! Actually, schema can express arbitrary constraints. Your example translates to schema as: {String {(s/required-key "product") [String] (s/required-key "type") (s/en
35.
by w01fe 13y ago
We don't want write access to your Google account. Unfortunately (at least at the time we set this up) they didn't offer a read-only permissions option for contacts or Reader. We also offer a 'stealth' account with no
36.
by w01fe 13y ago
Huh, cool! I kinda assumed the JIT already took care of this sort of low-hanging fruit, we'll test this out and if it works include it in the next version of hiphip.
37.
by w01fe 13y ago
> If your goal is more "Clojurey" syntax then just spend a > day or two wrapping the functions you want over a tried > and tested numerics implementation. This is exactly what we're trying to do: provide some Cloju
38.
by w01fe 13y ago
We did, and we've been talking to the developers about a potential future collaboration. Our goals are really complementary; hiphip is about getting your code into the inner loop of Java bytecode (not just a set of canned operation
39.
by w01fe 13y ago
Oops, thanks for letting us know! Fixed now.
40.
by w01fe 13y ago
Wish I could take credit, but I think all praise (and groans) must be directed at @aria42
41.
by w01fe 13y ago
Thanks for the kind words, we really appreciate it! If you get a chance to check out the library, be sure to let us know what you think.
42.
by w01fe 13y ago
We're also anxiously awaiting this -- it seems with gvecs and reducers and primitive fns the pieces are all there, we just need the glue to put them all together. Unfortunately, for now I think we're stuck with arrays, and we&#x2
43.
by w01fe 13y ago
We have sparse vector code built on hiphip that's slated for open-source release down the road (once we get the resources to polish it) -- stay tuned!
44.
by w01fe 13y ago
One of the authors here. We're excited to hear your feedback on hiphip, and will be around all day to read feedback and answer questions.
45.
by w01fe 13y ago
Yes, we do! Using Java from Clojure is much more pleasant than using it from Java IMO :)
46.
by w01fe 13y ago
Sure, analyzing code into an AST is easier in LISP (trivial, even). But you don't necessarily want to monitor every sub-function call within your function, because of performance overhead, and to limit noise. And if you want to sub out
47.
by w01fe 13y ago
Short answer: because Graphs are data , it's easy to do tons of things with them that are difficult to do with code. In principle tooling may eventually bridge the gap, but for now it's hard to take a function and automatically monitor it
48.
by w01fe 13y ago
Re: interactive visualizations, we haven't gotten there yet, but it sounds like a really cool (and feasible) idea. On this front, libraries like 'lamina' look like a nice place to start. https://github.com/ztellman/lamina Graph backtrace
49.
by w01fe 13y ago
Graph is currently just in-process (no cross-machine distribution), although it's definitely a possibility down the line. The currently released parallel strategy is also just a pedagogical example, not really meant to be used. Here's som
50.
by w01fe 13y ago
Coauthor of Graph here, I'm happy to answer any questions.
51.
by w01fe 13y ago
We're working on it! We removed the software because it needed extensive cross-project reorganization, consolidation, and cleanup which just wasn't possible to do with a clean upgrade path using available resources (3 backend engineers). P
52.
by w01fe 14y ago
Fine-grained oauth is clearly better and something we plan to do eventually, but we're a very small team and we've been prioritizing building features and improving the design and relevance for the time being.
53.
by w01fe 14y ago
I understand your concern ... see my response here: https://news.ycombinator.com/item?id=5373701 Short answer, we don't want access to manage your contacts, there's just not a read-only option (last time I checked).
54.
by w01fe 14y ago
We ask to read your contacts to autocomplete email addresses for email shares and help you find friends on Prismatic (if you choose to do so). Last time I checked, Google didn't have a read-only contacts permission level, or we'd be using i
55.
by w01fe 14y ago
Thanks for the feedback -- this is a great idea, and something we've been thinking about for awhile ... stay tuned :)
56.
by w01fe 14y ago
Don't worry, we're on your side :) We ask to read your contacts to help autocomplete email addresses for email shares and help you find friends on Prismatic (if you choose to do so). Last time I checked, Google didn't have a read-only con
57.
by w01fe 14y ago
Sorry for your bad experience. The import adds both your subscriptions as well as topic feeds we think you'll be interested in based on your GR activity, so it's not going to be exactly the same content. You can remove them if you like by
58.
by w01fe 14y ago
Right on all counts. On the upside, we're smarter than an RSS reader for high-volume feeds currently, and sort things based on how much we think you'll like them (based on topics, social information, and more) rather than just by time. Su
59.
by w01fe 14y ago
I'd love to chat about this as well -- I'll send you an email.
60.
by w01fe 14y ago
Interesting, I hadn't heard of StructureMap. It seems related, but Graph is less complex -- just the dependency and composition parts, without being tied to any particular use case.

More ›