My intent was not to compare Cypher vs Gremlin.  Cypher is a proprietary,
closed language that can be used with a single vendor product, which isn't
very interesting regardless of merits.

I still think the barrier to use Gremlin is real and didn't go away in TP3.

If you ask a non-hardcore graph developer to sum a "distance" property on
edges they just traversed between several nodes, most could not do it in
Gremlin.  Next time you are face to face with non graph types, give that a
try and see what the results are.

Maybe they head to the Sum documentation....
The sum step is described as this:
"Note that the current traverser number is multiplied by the traverser bulk
to determine how many such numbers are being represented."

Traverser number ?  Traverser bulk ?  What if the number of edges between
two nodes of interest is variable ?  Whoa.

Gremlin may be readable once a query is written, but if someone is starting
from scratch to write a query, I suggest it isn't easy.

But I was not trying to fire up an argument about that and I am fond of
Gremlin.


On Mon, Nov 2, 2015 at 1:24 PM, Marko Rodriguez <[email protected]>
wrote:

> Hi,
>
> > Gremlin, based on my experience, is a barrier for many people who fall
> into
> > category 1 (and even 2 at times).
>
> With TinkerPop3, I don't see that argument holding anymore. There has
> always been this notion in the zeitgeist that Gremlin is "hard to read."
> However, when Gremlin3 is compared to Cypher/SQL/SPARL, I don't see it
> anymore. Look at the "side-by-side" representations dispersed throughout
> https://news.ycombinator.com/item?id=10434372. With the
> match()/where()/select()-clauses in Gremlin3, the "SQL"-vibe is there and I
> don't see it as being all that complicated (of course I'm not the person to
> judge this), moreover, its more "embedded" in the language than either
> Cypher/SPARQL/SQL. For instance:
>
>         SELECT ?x, ?y WHERE { ?x knows ?y . ?x name ?z . FILTER(?z ==
> "marko" } }
>         SELECT x,y FROM table WHERE x.knows.y AND x.name="marko" //
> shorthand
>         MATCH (x)-[:knows]->(y) WHERE x.name = "marko" RETURN x,y
>
>
> g.V.has('name','marko').as('x').out('knows').as('y').select('x','y')
>
> With Gremlin you don't need this "external" WHERE/FILTER notion. Its part
> of the walk.
>
> Anywho…rambling…
>
> Marko.
>
> http://markorodriguez.com
>
> >
> > On Wed, Oct 28, 2015 at 9:51 AM, Alaa Mahmoud <[email protected]>
> wrote:
> >
> >> I was at GraphConnect last week and I attended a Cypher training session
> >> (just for the heck of it :-)) I was amazed how easy it was to pick up
> in a
> >> short amount of time. I believe Cypher's Match/Where/Return syntax is a
> >> good starting point for those coming from an RDBMS/SQL background and
> >> there's a lot of those.
> >>
> >> Implementing a Cypher driver could make it easier for those with SQL to
> >> move or at consider graph as a option.
> >>
> >> Regards
> >> Alaa
> >>
> >> On Tue, Oct 27, 2015 at 3:05 PM, Ran Magen <[email protected]> wrote:
> >>
> >>> Hey Marko,
> >>>
> >>> Gremlin is definitely the best over-all "GQL" around. That's why I
> think
> >>> that before we develop any language-driver, we need to ask ourselves if
> >>> there's are any use-cases in which that language would be a better
> choice
> >>> than gremlin.
> >>>
> >>>   - SPARQL - Many people are familiar with SPARQL, so a driver would
> >> help
> >>>   them easily get to work with a TP graph.
> >>>   - GraphQL - QBE is a great definition. The cool thing about these
> >>>   queries is that they're very "composable", which is perfect for a
> >>> composite
> >>>   application in which you have deeply nested components, each
> >> specifying
> >>>   its own sub-query (e.g. the standard practice in React UIs). Granted
> >>>   gremlin is much more powerful, and I'd use it in almost all
> >>> applications,
> >>>   but when building something like a React application, GraphQL could
> >>> come on
> >>>   top.
> >>>   - OpenCypher - While it's an over-all more "able" language than
> >> SPARQL &
> >>>   GraphQL, I haven't seen any use-case in which it trumps gremlin.
> >> That's
> >>> why
> >>>   IMO there is no point in implementing it.
> >>>
> >>> My 2 cents.
> >>> Cheers,
> >>> Ran
> >>>
> >>>
> >>> On Tue, 27 Oct 2015 at 02:37 Marko Rodriguez <[email protected]>
> >> wrote:
> >>>
> >>>> Hi Ran,
> >>>>
> >>>> Here are my thoughts on GraphQL now that I have learned more about it.
> >>>>
> >>>>        1. Matt Frantz and David Robinson nailed it -- its not really a
> >>>> "graph language." Its more a QBE (query by example -- first time I
> >> heard
> >>>> that was from Matt).
> >>>>                - As such, do we want to support it in TinkerPop when
> >> we
> >>>> can do much more complex queries with the Gremlin machine?
> >>>>        2. I think we should try and get the GraphQL guys to implement
> >> a
> >>>> compiler for Gremlin VM.
> >>>>                - You said it -- providers have to implement a server
> >> to
> >>>> execute it. Why not just implement graph.structure API and let the
> >>> Gremlin
> >>>> VM do the work for you.
> >>>>                - Is this a Facebook thing? Perhaps someone can find
> >>> their
> >>>> repository and post a ticket and see where it goes.
> >>>>
> >>>> The one thing that GraphQL has going for it (like SPARQL) is the ease
> >> of
> >>>> the development/maintenance of the compiler. Cypher and SQL are going
> >> to
> >>> be
> >>>> insanely complex compilers to implement/maintain -- it will take
> >>> manpower.
> >>>>
> >>>> Marko.
> >>>>
> >>>> http://markorodriguez.com
> >>>>
> >>>> On Oct 26, 2015, at 11:49 AM, Ran Magen <[email protected]> wrote:
> >>>>
> >>>>> I'd be much more interested in GraphQL support.
> >>>>> The cool thing about GraphQL is that you can easily create a unified
> >>>> "graph
> >>>>> query" from different components in an application, while keeping the
> >>>>> separation between the components. It's a great feature for composite
> >>>> UIs (e.g.
> >>>>> React).
> >>>>> As I understand it, GraphQL is mostly a standard for graph queries,
> >> but
> >>>> the
> >>>>> user has to implement a server to actually execute the queries. And
> >>> what
> >>>>> better execution engine than the Gremlin VM?
> >>>>>
> >>>>> On Mon, 26 Oct 2015 at 15:17 Marko Rodriguez <[email protected]>
> >>>> wrote:
> >>>>>
> >>>>>> Hey,
> >>>>>>
> >>>>>> After reading Stephen's reply, I was like -- "huh, sure." I didn't
> >>>> really
> >>>>>> don't care one way or another until I just read this:
> >>>>>>
> >>>>>>       http://neo4j.com/blog/open-cypher-sql-for-graphs/
> >>>>>>
> >>>>>> Look at the tone and lies that Neo4j is portraying.
> >>>>>>
> >>>>>>       * Marko Rodriguez as "just some buddy of Emil's."
> >>>>>>       * Aurelius is some company. No, its called DataStax.
> >>>>>>       * Not once is Apache TinkerPop discussed or referenced --
> >> "just
> >>>>>> Marko and a band of merry 'graphistas'."?!
> >>>>>>       * DataStax is NOT involved in their efforts for OpenCypher.
> >>>>>>
> >>>>>> The problem with Neo4j is they are corrupt. They use lies to control
> >>> the
> >>>>>> population. If we support Cypher in TinkerPop (like actively put it
> >>> into
> >>>>>> the repository as a distribution) we will see press releases like:
> >>>>>>
> >>>>>>       * TinkerPop drops Gremlin in favor of Cypher.
> >>>>>>       * TinkerPop realizes that Cypher is the superior language.
> >>>>>>       * TinkerPop follows Neo4j in learning how to do graph
> >>> processing
> >>>>>> the right way.
> >>>>>>       * etc.
> >>>>>>
> >>>>>> Its going to be a bunch malarky like that that I don't want
> >>> surrounding
> >>>>>> our project. It would behoove us to be smart about how we interact
> >>> with
> >>>>>> people like this as they will use every opportunity they can to
> >>> destroy
> >>>> our
> >>>>>> project to better their economic efforts.
> >>>>>>
> >>>>>> I don't do lies nor interact with people who use misinformation and
> >>>>>> deception to get "ahead,"
> >>>>>> Marko.
> >>>>>>
> >>>>>> http://markorodriguez.com
> >>>>>>
> >>>>>> On Oct 26, 2015, at 4:35 AM, Stephen Mallette <[email protected]
> >>>
> >>>>>> wrote:
> >>>>>>
> >>>>>>> I'd be open to have cypher and sparql as first class citizens of
> >> The
> >>>>>>> TinkerPop. As I see it, there are two groups of graph users on the
> >>>> fringe
> >>>>>>> of TinkerPop and they live in the cypher world and in the RDF
> >> world.
> >>>>>>> Having both of these projects in TinkerPop would allow us to reach
> >>> both
> >>>>>> of
> >>>>>>> those communities.  Doing so would help to expand usage and
> >>> potentially
> >>>>>>> attract more committers.
> >>>>>>>
> >>>>>>> On Fri, Oct 23, 2015 at 1:08 PM, Marko Rodriguez <
> >>> [email protected]
> >>>>>
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>>> Hi,
> >>>>>>>>
> >>>>>>>> I (personally) am interested in getting another language into
> >>>>>> TinkerPop's
> >>>>>>>> distribution. I see an imbalance in the following table:
> >>>>>>>>
> >>>>>>>>      TinkerGraph | Gremlin-Java8
> >>>>>>>>      Neo4j             | Gremlin-Groovy
> >>>>>>>>      Hadoop          | NOTHING
> >>>>>>>>
> >>>>>>>> That is, we have 3 graph distributions, why not have 3 language
> >>>>>>>> distributions. Moreover, I don't want yet another Gremlin-JVMLang
> >>>>>> language
> >>>>>>>> as that doesn't showcase the virtual machine aspects of Gremlin as
> >>>> well
> >>>>>> as,
> >>>>>>>> for example: SPARQL-Gremlin or SQL-Gremlin.
> >>>>>>>>
> >>>>>>>> I (personally) am NOT interested in openCypher as the 3rd language
> >>>>>>>> distribution for the following 2 reasons:
> >>>>>>>>
> >>>>>>>>      1. It will be at least a year+ before it culminates into
> >>>>>> something.
> >>>>>>>>      2. It doesn't fold a different computing space into
> >> TinkerPop.
> >>>>>>>>
> >>>>>>>> To expand on #2, Hadoop is NOT typically seen as a graph system,
> >> but
> >>>>>> with
> >>>>>>>> TinkerPop, we have Hadoop serving as a graph engine. With SPARQL,
> >> we
> >>>>>> pull
> >>>>>>>> in the RDF guys (thats cool). With SQL, we pull in the world. I
> >>> sorta
> >>>>>>>> prefer SPARQL as its an easy language to handle (thanks in part to
> >>>>>> Apache
> >>>>>>>> Jena). With SQL we have Apache Calcite offering help, but SQL is
> >>>> nasty
> >>>>>>>> looking for graph queries and is just suuuuuch a beast of a
> >> language
> >>>>>> that
> >>>>>>>> it would need someone dedicated to its maintenance/evolution.
> >>>>>>>>
> >>>>>>>> Anywho -- thats what I think about another language in TinkerPop.
> >>> I'm
> >>>>>> pro
> >>>>>>>> SPARQL-Gremlin if it matures and people are excited about it.
> >>>>>>>>      https://github.com/dkuppitz/sparql-gremlin
> >>>>>>>>
> >>>>>>>> Thanks,
> >>>>>>>> Marko.
> >>>>>>>>
> >>>>>>>> http://markorodriguez.com
> >>>>>>>>
> >>>>>>>> On Oct 23, 2015, at 10:45 AM, pieter-gmail <
> >> [email protected]
> >>>>
> >>>>>>>> wrote:
> >>>>>>>>
> >>>>>>>>> Is a opencypher <
> >> http://neo4j.com/blog/open-cypher-sql-for-graphs/
> >>>>
> >>>> ->
> >>>>>>>>> gremlin compiler something the tinkerpop team would consider
> >>>>>>>> implementing?
> >>>>>>>>> Perhaps, hopefully with help from neo4j themselves.
> >>>>>>>>>
> >>>>>>>>> Thanks
> >>>>>>>>> Pieter
> >>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>>>
> >>>>
> >>>>
> >>>
> >>
>
>

Reply via email to