21–30 of 32 posts
Having the "fork me" button above the scrollbar (at least in Chrome on Windows) looks pretty ugly.
This looks a lot like OData... strange that they don't mention it when they compare themselves to other querying technologies on the 'about' page. http://www.odata.org/
I've been thinking lately that certain APIs would benefit from two distinct 'entry points': 1. a nice, object-oriented hierarchical RESTful interface for standard queries and getting started e.g. /api/user/12345/friends/ 2. a sql-esque query language interface for arbitrary, complicated requests e.g. /api/?q=select id from users where name="Joe" It looks like ql.io could be a good way to provide the latter.
Earlier quoted context omitted.
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, we…
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.
Granted it expands to more than one line, but I'm not seeing that as a good example of lisp's superiority.
Earlier quoted context omitted.
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, we…
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.
Earlier quoted context omitted.
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.
eh easy? that's one of the longest pages on the Internet! Here's a BrainF interpreter in 1 line of Python: http://www.cs.princeton.edu/~ynaamad/misc/bf.htm Granted it expands to more than one line, but I'm not seeing that as a good example of lisp's superiority.
Earlier quoted context omitted.
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.
eh easy? that's one of the longest pages on the Internet! Here's a BrainF interpreter in 1 line of Python: http://www.cs.princeton.edu/~ynaamad/misc/bf.htm Granted it expands to more than one line, but I'm not seeing that as a good example of lisp's superiority.
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).
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.
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.