jdp

Matt Might wrote a blog post about using standard CLI tools for this purpose: http://matt.might.net/articles/sql-in-the-shell/

Rather than making a custom tool to issue SQL, the idea is that regular CLI tools map well to the traditional relational algebra operations. sed is like selection, cat is like union, etc.

It already exists: http://defunkt.io/repl/. Installing it and running `repl git` will put you into a git REPL.

I created a very similar project in Python a few weeks ago, based on csvkit[1]. Check out the Gist[2].

[1]: https://pypi.python.org/pypi/csvkit [2]: https://gist.github.com/jdp/8447221

This looks pretty cool, I'm a happy Pinboard user but my bookmarks toolbar is still full of stuff I want to check later on but don't want clutter up my Pinboard with. I was able to sign up and install the Chrome extension, but clicking the extension's button on my toolbar does nothing. No login dialog or anything, nothing at all happens. Then I tried to see if I could play with the web interface, but there's no link to login on the home page. So I went to the signup page, guessed the login URL from there, and was finally able to log in. The interface is nice, if a little finicky. Deleting items and collections is not intuitive, overriding right-click in a web app is awkward. There's also no hover indicator when you're dragging a link onto a collection, so if you miss somehow Chrome redirects the tab to the URL you just dropped onto the page. These problems aside, I like the idea behind it and I hope you keep plugging away at it.

Gulp has a lot in common with the venerable make(1) in its approach to building targets, but make is seemingly overlooked in certain circles. It's definitely worth checking out. I wrote something of an introduction to make with the setting of managing a JS app's codebase:

http://justinpoliey.com/articles/make-for-front-end-developm...

Make is old, but still pretty relevant. Maybe some peoples' avoidances come from the association with autotools and the complexities involved in building portable C programs. Using make to manage something like a front-end codebase, which doesn't suffer that family of complexity, is pretty straightforward and kinda enjoyable.

I like the idea behind this, right now I query against a few disparate data sources (and platforms) and a unified interface would be nice. I use BigQuery[0] a lot and would hope to see it integrated into JackDB in the future, or even make it so that BigQuery is obviated. A big use case for me is loading a bunch of disparate datasets into BigQuery and then querying across them. Are there any result or export row limits on the enterprise plan? I also had high hopes for Induction[1] but it looks like abandonware now.

[0]: https://developers.google.com/bigquery/ [1]: http://inductionapp.com/

Also worth checking out is Open, extensible object models[0] which brings prototypal inheritance and message-passing semantics to C. Along with a well-detailed paper is a very digestible example implementation.

[0]: http://piumarta.com/software/id-objmodel/

You're right, maybe I've mis-categorized as them major caveats, but they're not so obscure because both myself and others have had to wrestle with these properties in production. I'm not saying use easy_install by any stretch (pip is great), they already have open tickets and I hope to see them fixed before being rolled into Python proper and do become defining problems within pip.

Hopefully it will also bring about some improvements to pip. It's a pretty great tool but with a couple major caveats. The first is that although it supports many forms of package specification, including VCS repositories, it does not report the package spec according to the way that it was installed, but rather according to the package name and version according to its setup.py. Say you install a package from a git commit that fixed a bug in the PyPI 1.0.0 package whose version is still reported as 1.0.0 in setup.py at the commit. Then you freeze the environment to requirements.txt to distribute. It's still reported as package==1.0.0 instead of the git spec, so the next person to install will pull down the broken version from PyPI instead. The other headache is that installing from a requirements file just installs dependencies in the order they're listed, so oftentimes you need to re-organize the output of `pip freeze` to make sure dependencies are installed in the right order, otherwise you can encounter things like unexpected package versions due to other packages making ambiguous dependency specs for dependencies of your own app.

If government has ruled that detainees are no threat, why are they still treated as if they are, shackled even when alone and watching television? It costs $2MM per year per detainee to keep them in Gitmo. Wouldn't it be much more cost-effective to provide some relocation assistance? I get that repatriation isn't always possible but can it really be true that less than 200 people can't get at least temporary visas somewhere else? That's less than the capacity of a single trans-oceanic flight. It seems silly (and apparently very expensive) to me to perpetuate the farce, and wringing our hands and talking about rationality while letting people rot in prison just because they can't be repatriated without exploring other options seems either equally silly, or not to be the real reason they remain there.

Leaving PUT out might be a mistake. The rationale from the slide deck is sound but the framework neglects the case in which you are creating a resource with a known identifier. The POST verb is good for when you don't know the identifier, and want to leave it up to the handler to generate one for you. You could just define the same semantics for POST as for PUT, but that breaks the spec in that a resource created by POST should be subordinate to the requested resource.

Another cool project is bam[1], a constant key/value server built on similar principles. A single input file (in this case, a TSV file instead of the SPL log file) and an index file. The cool thing about bam is that it uses the CMPH[2] library to generate a minimal perfect hash function over the keys in the input file before putting them in the index file.

[1]: https://github.com/StefanKarpinski/bam [2]: http://cmph.sourceforge.net/

I had the same reaction. I'm pretty put off by the form factor, it's shaped like a slice of Wonderbread.

Nice implementation of a concatenative language, and the relatively robust standard library it already has is nice. Is there anything different about its execution model from languages like Factor or Joy?

As far as being purpose-built for code golf goes, there are already even more compact concatenative languages, like F[1] and XY[2], that might give this a run for its money due to K's obvious influence. Then again, it wouldn't be hard to have a rewrite layer to turn mnemonic operations into their expanded rhoScript words :)

[1]: http://nsl.com/k/f/f.htm [2]: http://nsl.com/k/xy/xy.htm

"Software efficiency halves every 18 months, compensating Moore's Law." - May's Law

JSON isn't a configuration language, it's just another data encoding format with the added benefit of being readable by humans. That and its ubiquity make it an appealing choice for stuff like ad-hoc configuration at first glance, but it's not the best choice. If you want a config language for shared human and machine consumption, use one designed for that purpose. JSON is pretty much just an encoding that is easy for humans to inspect and debug.

The older, HTTP/1.X compatible versions maybe. What happens after the web upgrades to 2.0? How long until compatible tools make it to default installs? Even now, OSX doesn't ship with wget.

No, but a lot of people are writing them in telnet prompts and through netcat pipes.

Reminds me of a beefed-up version of this similar project: https://github.com/chjj/node-tiny

It is hard to judge whether or not this is a case of facilitated communication just by that photo, it could just be that the whole family was posed for the photo for the article.

Why are you so dismissive of the humanities? I'm a Computer Science major myself, but I can't fathom how you've come to the conclusion that colleges are vocational schools for STEM subjects.

Here's one from the Arch mailing list. Also does the ~ expansion for home directories: http://www.mail-archive.com/arch-general@archlinux.org/msg07...

> Have you noticed how Github helpfully shows which words have changed inside a line when looking at diffs?

GitHub's web UI only does a line diff. Which is not particularly helpful when you change a word or two in a six sentence paragraph. It's possible to do a word diff locally of course: `git diff --word-diff` but that's not the general use case for a code host, right now most code is line oriented and the UI suits it well. That is one of the reasons that the article advocates formatting thoughts with newlines, good portability. These input texts are closer to code than prose, so why format it like it was? Splitting thoughts into units digestible by your coding environment has the huge benefit of working with individual thoughts instead of individual paragraphs.

The title is One sentence per line, but he clarifies to include clauses in the body of the article. This also has nothing to do with where the margin ends, but editing text in developer formats that is later transformed to end-user formats in a way that gels well with the tools of the Unix environment. Your comment is unnecessarily venomous and not representative of the contents of the article.

The _links field may not be necessary. There is already an HTTP Link header proposal, and is already being used by API's like GitHub's: http://www.w3.org/Protocols/9707-link-header.html

From their examples, this is the equivalent representation:

    Link: <http://www.tld/orders/523>;rel=self, <http://www.tld/warehouse/56>;rel=warehouse, <http://www.tld/invoices/873>;rel=invoice

It also allows for multiple Link headers to be sent instead of the comma-separated version.

Cool idea! Was also pleasantly surprised to find my Python A* gist near the top of the toplist :) https://gist.github.com/1687840

Let language tinkerers keep tinkering, the slow convergence toward Lisp is continuing. Hopefully by the time the convergence is complete it will have brought with it the niceties of its successors: a single standard library, a de facto package manager, and other things that have sharded the various Lisp communities.

Github has also remedied that in their 3rd version of the API. For example, their issues comments collection is exposed through the URI /repos/:user/:repo/issues/comments/:id

That could be related to their decision to use only JSON as the interchange format though.

Brainfuck is obscure, but only because of its restricted character set. 8 operators is not very expressive and requires large, but eventually recognizable, idioms to get most common tasks done. Languages like J [1] keep the terse syntax but have a much more expressive set of operators. J is also very regular, so once one knows the basic vocabulary the programmer is able to infer the meanings of more complicated operators. Compactness itself is not what obfuscates meaning.

[1]: http://www.jsoftware.com/

Such terse languages have a long history -- going back all the way to APL. Current environments, like K and J, continue the legacy but their syntax only includes glyphs from the ASCII character set as opposed to APL's specialized keyboard. The FALSE [1] and F [2] languages are similar to GolfScript, the former being a stack-based language, minimalistic compiler, and inspiration for Brainfuck. The latter is a more recent implementation and purely functional implementation in K.

[1]: http://strlen.com/false-language [2]: http://www.nsl.com/k/f/f.htm