Interesting, another use of a SQL-like language as the query language for a data store that's definitely not an SQL database. (YQL is another example.) I really don't understand why ORMs always seem to want to create their an object-based query language--SQL is just fine for querying.
It's difficult to provide tooling for SQL in a way that provides a good experience for the user. For example, providing auto-completion in a SELECT statement is hard because attributes are specified before the tables which contain them are declared, leading to a-more-annoying-than-it-should-be editing experience.
It would be cool if there was some kind of meta-DSL which allowed you to create your own DSL. That way, more developers could go that route without having to learn all the intricacies of compiler theory and stuff like that.
I am imagining DSLs being useful both on the server side and the client side. For the former, imagine sending off a single query instead of doing a bunch of different API calls. For the latter, well, JQuery is an existing example of a popular client-side DSL (technically it's not, but it feels that way).
It's called Lisp. I hate to be Yet Another Hacker News Lisp Punditparrot, but it's true.
For example, take a look at how easy it is to implement BrainF inside Racket, a lisp focused on language experimentation. http://hashcollision.org/brainfudge/ I bet you could walk through these steps in maybe half an hour with little to no prior experience.
It's absolutely not the same thing : the Racket example is not a Brainfuck interpreter, it's an actual DSL inside Racket, which benefits from it's whole infrastructure (JIT compilation etc.). It's not the Racket language running a BF interpreter. It's the BF language running.
Does it? It's a single semicolon-free Python expression. Looks like one line to me.
Besides, that is a terrible example of a "good" Brainfuck interpreter. The Scheme example is easily 100x easier to understand (/debug/troubleshoot/extend/etc).
I hold that it's far easier to read and step through Danny Yoo's BrainF interpreter than to try and piece together your one-line pythonic monstrosity.
Of course, if you're arguing that your Python version is somehow better than the longer idiomatic Racket implementation, I think we both agree that leveling the playing field would create a more fair comparison. Heavens, wouldn't it make more sense to compare a one-line BF interpreter written in Racket to your one-line BF interpreter written in Python? ;)
Both this example and your one-line python example are similarly incomprehensible. While we're on the topic of meaningless benchmarks, please allow me to point out that my racket version is 163 bytes shorter than your python version, without trying to abbreviate variable names and without smashing whitespace. That's even including the "Hello World" BF program near the beginning of the source.
Ok, yes, you have a point -- the article I cited earlier is long and focuses on Racket's awkward tooling. However, my point is that we're comparing apples to oranges here. It would be better to compare Danny's article to a Python article that implements a BF interpreter, covers some optimizations, and describes how to package it as an Egg and upload it to PyPi. None of these topics are trivial, especially to a beginner, hence Danny's thurough coverage.
I... don't think so. Not in the way you're thinking of, anyway. In this BrainF example, your language "compiles" (translates, really) to Racket expressions; then, the Racket VM "compiles" it to Racket bytecode just before running it.
For something as simple as BrainF, it's not hard to write your own translator. Just replace every [ with while (* ptr) {, replace + with (* ptr)++; replace < with ptr--; and so on. Then it's essentially a BrainF-to-C translator.
It's not so simple for racket in the general case. Danny Yoo is working on "Whalesong", a javascript interpreter that interprets racket bytecode so you can run racket in your web browser. http://hashcollision.org/whalesong/ It's still not a Racket->Javascript translator though.
I'm not aware of similar projects for other languages.
Anyone who implements this might want to bear in mind that you will have created a very chatty backend based on JSON calls.
It should be fairly obvious that you're quite likely to now have pain points in serialising and deserialising that much JSON.
It seems to me that you now have 2 choices:
1) You forget this approach and instead perform REST composition and aggregation by adding a datastore in the composition/aggregation service to reduce the number of calls to the back end.
2) You ditch the internal REST services and change to using protocol buffers or something else to remove the JSON bottle neck internally.
Either of which will make ql.io redundent.
ql.io appears to be trying to solve REST as the language of enterprise services, without using a service bus or BPEL to aid with composition or aggregation.
I agree there is a problem space here, and whilst I have an immense amount of respect for Subbu (worked on ql.io, authored REST book) I'm unconvinced that this approach is the solution to the problem.
Ah, looks like this is the library Subbu Allamaraju refers to at http://www.subbu.org/blog/2011/11/apis-are-a-pain--the aim of ql.io is to alleviate the challenges of "aggregation, parallelization, and orchestration of forks and joins." (i.e. in practice, "consistent RESTful APIs don’t matter as much as we think," nice though they may be.)
OData specifies a resource model, resource metadata and URI naming conventions for HTTP APIs. The query formats in OData are part of the producer-implemented APIs as queries happens at the origin. ql.io is a layer above such APIs, and generally operates across several such APIs.
Ah, thanks for the github link. It looks like an interesting project although I'm not sure what it brings over a more 'traditional' approach to API consumption
What I got from their website earlier is that it's meant to reduce the number of API requests by bundling multiple datarequests, giving you better performance.
