Hacker News Reader

Comment by PaulHoule | Hacker News Reader

It’s stretching it to say that GraphQL has a ‘specification’. It has a grammar but the algebra behind it is sketchy. (Just like that JSON spec that doesn’t say what the semantics of numbers are.) That is some of why it is popular because a lot of people seem to ‘fade out’ when they are forced to think rigorously.

(E.g. SPARQL really has an algebra which is well-defined and it gets talked about 1% as much on HN. Compare a good language spec like Common Lisp or Java to an undefined behavior festival like the early C ‘spec’.)

View on HN

There's no "algebra" behind GraphQL. It's just a type system specification, with no behaviors.

The equivalent would be the TypeScript type system.

I don't bother debating GraphQL with folks anymore because I've learned the hard way there's a lot of misunderstanding.

When people say "GraphQL" they usually mean some particular implementation of a GraphQL API they had a positive or negative experience with, not the idea as a whole.

The specification as a concept is a bit hard to critique because it defines no implementation behavior. It's sort of like saying "REST API's are slow" or "REST API's that fetch nested relations produce bad SQL".

GraphQL helped me to understand a very important fact.

Even smart people don't understand stuff that is outside of their niche. And I mean Kernel-dev levels of smart. It's not that the tech they're critique is really bad, it's just not possible for them anymore to think outside their box.

  >  It's not that the tech they're critique is really bad

I think marketing is somewhat to blame here. I work in the GraphQL space and there's not a lot of incentive to do neutral education.

The goal is to get users to associate "GraphQL" with particular products/implementations.

Half of my dayjob consists of explaining to others why $OTHERCOMPANY is not a competitor, because despite us both being GraphQL tools we do orthogonal things. Marketing doesn't help this.

On top of this, GraphQL is (in my opinion) pretty complicated. It's not explainable in a sentence the way you can RESTful URLs, it takes a bit longer to grasp.

Despite all of this, GraphQL is the best thing since sliced bread as far as I am concerned and I will continue building services in it until something better comes along.

That "neutral education" is a good point.

The same problems happened in the Object Management Group which standardizes a number of technologies such as UML and CORBA and applications of those technologies. (The map-vs-territory problem w/ UML has been addressed by various forms of "Executable UML" such as the Object Constraint Language which itself an algebra over UML-modeled objects)

Look at the specs though and you find they are deliberately designed to be hard to implement.

For instance there is the meta-object facility MOF which is great for modelling a set of objects in a language like Java. The point of MOF seems to be that you could bootstrap the whole UML edifice from a very simple foundation, and at the very least have a machine that can build a set of objects to represent both a collection of UML objects that function as a "schema" and also a collection of instance objects that are modeled by the schema.

(This is a lot like the vision of the semantic web but going about it a very different way; in fact I am about to open source something that converts MOF models into RDF inside Python and also builds Python stub functions that let you 'call methods' on an RDF node while having access to the objects via SPARQL queries and other RDF tools.)

If you actually try it however you find there are some inconsistencies, unresolved circularities, conflation of UML 1 and UML 2 concepts and other problems you run it.

I'm certain that if I was "on fire" I could bend MOF enough to bootstrap UML-in-RDF in a month or two of working overtime. I've done that kind of thing before and that's just the start of your problem because then you have to market it...

The result is that some incumbents have a "moat" but also that UML is out of the mainstream and addresses a much smaller market than it could.

I'd say GraphQL and Schema.org were both "asymmetric technologies" in the sense of asymmetric warfare but maybe the other way around.

Both of them tackled some of the problem space the "semantic web" tackled (e.g. the linked data idea of do an http request and receive a graph) but in a way that privileged the large organizations that pushed them.

With no semantics Facebook can return whatever they want from a GraphQL query, whatever is in the commercial interests. (I'd add that they have ethical constraints on top of that involving privacy, spam control, etc.) They have no real concern that anybody else can publish GraphQL and they are big enough that they can go it alone and be a defacto standard to interact with Facebook no matter how GraphQL fares in the real world.

When schema.org came out my wheelhouse was information extraction from Wikipedia, Freebase, things like hat, and I was like... There is no 'reification of subjects' in schema.org, it's not really that much better from my perspective than extracting facts from text. In fact if anything it is more of a way for Google to get a training set for a real text extractor than a way to publish facts Google can use directly.

So I was bearish on it initially but the standard really improved and technology got better both in terms of natural language processing and my understanding of matching engines that can 'reify subjects' by matching graph patterns. I don't see schema.org as difficult to consume now.

to be fair, a kernel dev is so far down his rabbit hole that web services and web tech is not something that they're particularly interested in. They also know intricate details on what my kernel does that I have no hope of ever understand or desire to. They exceed at what they're passionate about.

I'll say that many systems programmers are less effective at their jobs because they don't understand applications programming.

You see it in frameworks like ASP.NET, ASP.NET MVC, etc.

Someone once said that Rust is so effective, because it the first big project built with it wasn't just a compiler.

I mean... https://spec.graphql.org/June2018/

It’s a grammar plus some hand waving around types. Not a behavioral spec. It’s much less complete than SQL or SPARQL (e.g. SPARQL is like SQL in that it is based on relational operators but it has a good spec that describes what the operator algebra is exactly)

When post-structuralism burned out I think people would have gotten it that language doesn’t give any insight into behavior, at best people leave words behind like the evidence at the scene of a crime. Grammars are profoundly empty and meaningless.

Spat my tea out at "undefined behavior festival like the early C ‘spec’." Is there a support group for those of us that endured?

hum https://spec.graphql.org/June2018/

Grammar + undefined behavior. It’s like saying ANSI C is a specification. It looks like a specification and quacks like a specification but compare it to a quality specification and you are looking into that void Badiou warned you about.

This is what a specification for a query language should look like

https://www.w3.org/TR/sparql11-query/

It is a little terse and not the easiest read but everything you need to know to write SPARQL or implement a SPARQL engine is in there. It's short.

(Now I would say that SPARQL needs to extend the algebra to deal with ordered collections, but that's what is nice about SPARQL being so well specified. If somebody wants to add a feature to SPARQL it is completely straightforward to amend the algebra AND the grammar, often you don't have to mess with the grammar and the use of namespaces means anybody can add anything.)

The GraphQL 'spec' on the other hand is like the singularity of a black hole... It's a place where computer science breaks down.

It's more than that though. Have you read it? It defines execution behavior (execution and validation algorithms, response shape, etc) and not only the grammar. We can argue about the quality of it all day but it is not just a grammar.

It's still not complete.

Think of what the Common LISP, Java, or Python specs would be if you deleted all of the specification of the semantics. The horror of it is that people would make languages that look like Common LISP, Java, or Python but they wouldn't interoperate and when you zoomed in on the details they'd all behave in nonsensical ways because, with no guidance to correct semantics, people will make up wrong things.

We live in an age when we are informed by good specifications. ALGOL and PL/I had hopelessly flawed specifications that weren't really implementable... There were lawsuits over COBOL specifications... But Common Lisp and Java were two early languages developed by adults.

In 2022 we should be at least up to a 1984 standard for writing standards.

This raises the question, is there a standard that describes how programming and query language standards should be written?

Reply on news.ycombinator.com