Deprecate snake_case symbols (warning level forever) in favor of names following Kotlin conventions

[LouisCAD]

For reference, I'm linking the official naming conventions of Kotlin: https://kotlinlang.org/docs/coding-conventions.html#naming-rules

I'm suggesting to always keep the snake_case symbols at warning deprecation level for discoverability when people come from Python, quite like the deprecated symbols in kotlinx.coroutines for people coming from RxJava or RxWhatever, except that here, it'd compile and run, so you can see it work before making it idiomatic.

[alshan]

The Let's-plot Kotlin API was designed this way (copied from ggplot2 API, frankly) keeping in mind the people who use and love the original ggplot2 library in R or its Python ports (there are some, including Lets-plot itself).

Note that Let's-plot API is not following neither Kotlin nor Python's PEP 8 style guides as its classes and functions alike use snake_case symbols.

We are not planning to deprecate these symbols in Lets-plot (if this is your proposal) but, I heard there is another plotting API in development, which would be 100% Kotlin idiomatic so that one can choose according to preferences.

[holgerbrandl]

What/where is this other api?

[alshan]

This one Roman Belov is working on.

[holgerbrandl]

Although being a long term (10y+) R professional , it feels not kotlinesque (but imho rather inconvenient) to deviate from java/kotlin naming conventions here.

One beauty of kotlin for data-science is, that it ties in naturally into complex domain models written in kotlin/java, so providing a natural API experience clearly outweighs the initial mental migration when coming from r to kotlin.

A third strong argument imho in favor of kotlin naming conventions for lets-plot-jvm is, that the intersection of R users and kotlin developers is rather small. Even after years of searching for such like-minded colleagues, I have not personally met a single one yet (except myself in the mirror). Cleary there is a lot of perception bias in this argument, however I still think its valid more generally.

A kotlin-naming-compliant ggplot API can look very natural, see https://github.com/holgerbrandl/kravis#first-example. Clearly, I'd prefer lets-plot here in the long run, because of its much better backend implementation (that does not rely on R/ggplot itself).

[alshan]

An expression like:

lets_plot() + geom_point() + ggsize()

if brought in compliance with kotlin naming convention, would look:

letsPlot() + GeomPoint() + ggsize()

All right, it less resembles ggplot2 and ugly on its face. I just don't see a value in such transition.

[holgerbrandl]

Clearly, letsPlot should comply more with general kotlin API design and not stick to R patterns here. E.g. letsPlot(data).geomPoint{x="bla"}.size(100, 200) would feel more natural. Also Hadley - the author of ggplot - had pointed out that the original + style for composition was more a relict of past times, and he would prefer the typing operator %>% nowadays but can not do so because it literally break half of all modern R code.

In terms of kotlin, there is also no point in sticking to R-naming such as ggsize which just results from the fact R has lots of naming collisions and library authors need to disambiguate names. In kotlin with the clear type it must just be size . Same applies to ggtitle which should be just title

Not strictly ticket related, but imho just closing and locking a ticket with most upvotes in a repo without a fix or finished discussion, lacks appreciation for community feedback in my understanding of github culture.

[alshan]

I've transferred the entire exchange form "issues" to "discussions" and certainly didn't mean to offend anybody.
Closing/locking does happen automatically in this case.

I apologize for GitHub in case they sent you and others a rude or offensive notification.

[holgerbrandl]

No offence was taken. I think we all want to maximize elegance/fun/style when doing data-science with kotlin. Having intense discussions is a natural part of this process towards a smooth-as-butter API experience I guess.

[alshan]

I'm just trying to say that I haven't closed and locked this ticket out of lack of "appreciation for community feedback". Instead I've transferred it to the "Discussions" category which is perhaps better suited for discussions.

[alshan]

letsPlot(data).geomPoint{x="bla"}.size(100, 200)

Is a good alternative and this would be a different, not ggplot-like API.

The world, it seem is devided to folks who think that ggplot is elegant and to anti-ggplot crowd.

I myself appreciate and on a regular basis compose plot features like:

ab = a + b

plot1 = c + ab
plot2 = d + ab

From a library design standpoint, having an API class representing a plot layer is a lot superior in comparison to API methods, because this allows to factor various traits out to abstract classes and interfaces and then use inheritance to combine these traits.

So, I have designed a ggplot-like API.
However, I now think that for a set of commonly used exploratory plots it would be beneficial to have a set of specialized kotlinesque classes - just for building these plots really quick. Something like "seaborn" plots maybe.

Currently, the only example of such a specialized class is CorrPlot.

[holgerbrandl]

I don't think that your ab use case is actually supported by ggplot (which does not imply that it may not be useful). In ggplot its afaik always gplot+ smths --> ggplot. Your syntax seems to be smthg + smthngelse = smthgbig; plot + smthgbig which is not supported by ggplot2. Or could you maybe provide an R example?

I guess I struggle less with the + instead of ., but more with the _ which I have not yet encountered at all in kotlin names. Dot notation in kotlin is more prevalent, whereas + mainly seems to apply to collections.

Great notebook, with very nice visuals.

[alshan]

No kidding? I probably never tried this in R, simply always presumed equivalence: a+b+c=a+(b+c)

We can get rid of _ if this creates an extra friction for lets-plot adoption by Kotlin DS fans. This will break an existing users code though.

[LouisCAD]

@alshan Unless you do as I initially suggested: Deprecate without removal the snake case symbols, and provide a ReplaceWith clause to help migrate existing users to the Kotlin conventions compliant naming.

That way, no one will be broken by that change.

[alshan]

I wonder, could Kotlin kernel handle ReplaceWith? @ileasile

[holgerbrandl]

I still haven't given up hope, that kernel integration will be eventually fixed in Intellij's ipynb 2-column Notebook editor. There, the editor could easily process the annotation I guess.

[alshan]

Hi guys, I have a linguistic / terminological question.

We are renaming
geom_crossbar --> geomCrossbar and guide_colorbar -> guideColorbar (because "crossbar" and "colorbar" are existing words).

"linerange" is likely an existing word as well, so:

geom_linerange -> geomLinerange

But what would be better for geom_pointrange and geom_errorbar?

a) keep doing the same: geomPointrange and geomErrorbar
b) more CamaeCase: geomPointRange and geomErrorBar

Another question is about "2-dimentional" and "2-dimentional filled":

Rename geom_density2d, geom_density2df to:

a) geomDensity2d, geomDensity2df
b) geomDensity2D, geomDensity2DF

What do you think?

[LouisCAD]

As for "geom", isn't it simply an abbreviation for "geometric"?

@holgerbrandl do you think these abbreviations should stay, or do you think it's better to keep it a bit short?

[holgerbrandl]

A more kotlinesque naming is great news.

geomErrorBar seems more correct from a camel-case point of view because errorbar is not an English word.

@LouisCAD I think the important point from an R API design point of view was to convey that all geoms add a layer with a certain geometric shape. So imho it makes sense in R to use a common prefix to all shape-adding methods. In kotlin with its type system, it could potentially make sense to deviate from this naming, but I'm not sure how something better might look like. Keeping geom as prefix would keeping it closer to the original and conveys a clear intent. In particular with stat, coord*, scale* and so on which can be mixed in ggplot2 in a very flexible way, a clear naming paradigm is mandatory to produce readable plot specs.

[alshan]

Depends on which word is intended for the given symbol.
If the meaning is the one of "line range", then use lineRange. If the meaning of "linerange" is more accurate, use linerange.

The meaning is "use line to show a range", not "a range of lines". So - "linerange" probably. The same goes to "pointrange".

[alshan]

A notebook that uses these geoms: https://nbviewer.jupyter.org/github/JetBrains/lets-plot-kotlin/blob/master/docs/examples/jupyter-notebooks/error_bars.ipynb

[LouisCAD]

Still lineRange for that since the two words are not one in your explanation.

[alshan]

FYI: a bit of problem with Kotlin kernel: Kotlin/kotlin-jupyter#185

[alshan]

Hi all, check-out the camelCase naming style in just released v2.0.1.

[LouisCAD]

Great! Thank you for addressing our concerns!

[holgerbrandl]

So cool @alshan. Thank you so much for your great work here to make kotlin a viable alternative for data science.

[alshan]

@LouisCAD @holgerbrandl thank you for the valuable input!

Yesterday we discussed internally a new API which is radically different, not even dot-notation. The idea and a prototype have been around for a while and it looks promising. I'm planning to look at it more closely and am counting on some community help as well.)