That is a very nice effort, and a useful tool I might add to my command-line toolbox.
I just pity it hasn’t reused Troff’s GRAP’s language, which is very readable, clear, English-like and follow the UNIX philosophy, besides being a well-thought product of Brian Kernighan; instead, they chose a JSON-based one, which seems very polluted to my eyes.
What do you think it is cleaner in clip’s compared to Gnuplot’s syntax?
And how do you compare GRAP’s and Gnuplot’s syntax, except both use (most of time, for Gnuplot) proper English tokens as their command set?
I looked at your repository, and I could mostly understand the Gnuplot files, even though I am not used with the syntax.
On the other hand, I struggled to “plot the graph in my mind” looking at clip’s examples.
I suspect that our divergence my be only on taste grounds, and I guess it is difficult to make a proper comparison without getting a big graph and plotting it in the three applications.
I see no quotes around keys; possibly? support for comments; what appears to be number support, but I suppose it might be brain-dead floats like json; semicolon as line/statement separator?
keys and values are not enclosed by quotes, except if text (e.g., path);
keys and values are separated by colon;
property’s (i.e., key-values) declaration finishes with semicolon;
multiple values are separated by spaces;
some values are defined by “function calls”, such as rgba();
named blocks, delimited by curly-braces, agglomerate properties.
While I see good value in the influence of CSS and the analogy between language for graphical design and language for plot design, I am in conflict with that choice for a command-line tool: I would have expected the “line experience” seen pervasively in the *NIX world—and, with that, a lower cognitive load for those I believe is the tool’s most potential users—instead of a “language of the web”.
Also, I feel that the art of creating (domain-specific, but also programming) languages with tokens as English words, and making their represented code read like natural language, seems to be dying. GRAP had that, in my opinion.
But setting my sentiment and bias aside, I re-state there is a value in basing its language on CSS, and it might be it will reach more people than if it had followed “the UNIX tradition”: I guess there are more people, nowadays, who know CSS than people who grok grep.
That is a very nice effort, and a useful tool I might add to my command-line toolbox.
I just pity it hasn’t reused Troff’s GRAP’s language, which is very readable, clear, English-like and follow the UNIX philosophy, besides being a well-thought product of Brian Kernighan; instead, they chose a JSON-based one, which seems very polluted to my eyes.
IIRC Gnuplot takes after GRAP. I’ve been doing a lot of Gnuplot lately and clip’s language looks cleaner to me.
Would you mind expanding your comparison?
What do you think it is cleaner in clip’s compared to Gnuplot’s syntax?
And how do you compare GRAP’s and Gnuplot’s syntax, except both use (most of time, for Gnuplot) proper English tokens as their command set?
I looked at your repository, and I could mostly understand the Gnuplot files, even though I am not used with the syntax.
On the other hand, I struggled to “plot the graph in my mind” looking at clip’s examples.
I suspect that our divergence my be only on taste grounds, and I guess it is difficult to make a proper comparison without getting a big graph and plotting it in the three applications.
Personally, the initial example of GRAP seems way easier to plot using that tool than clip, based on their “Getting Started” document. However, I suspect clip is easier at some kind of plots (e.g., their
charts-scientific/streamgraph) than GRAP, but I cannot say so (for lack of knowledge) about Gnuplot.I’m not sure how you mean this is “json based”? Looks like it avoids most of the pitfalls of json, and is rather golang/c-like?
https://clip-lang.org/examples/charts-scientific/vectorfield/
I see no quotes around keys; possibly? support for comments; what appears to be number support, but I suppose it might be brain-dead floats like json; semicolon as line/statement separator?
Your comment made me evaluate it better, and see it is neither based on JSON nor C-like as you suggest, but it seems based on CSS.
The similarity with CSS can be better seen in the
charts-scientific/streamgraph:rgba();While I see good value in the influence of CSS and the analogy between language for graphical design and language for plot design, I am in conflict with that choice for a command-line tool: I would have expected the “line experience” seen pervasively in the *NIX world—and, with that, a lower cognitive load for those I believe is the tool’s most potential users—instead of a “language of the web”.
Also, I feel that the art of creating (domain-specific, but also programming) languages with tokens as English words, and making their represented code read like natural language, seems to be dying. GRAP had that, in my opinion.
But setting my sentiment and bias aside, I re-state there is a value in basing its language on CSS, and it might be it will reach more people than if it had followed “the UNIX tradition”: I guess there are more people, nowadays, who know CSS than people who grok
grep.This is really nice. Thanks!
The name just makes me think of that generative art AI that people have been using. And now I want to see the two combined somehow.
Substantive comment: very cool, definitely going to try this out next time I have data to plot.