Kotlin-dsl-samples: Rename the project

[bamboo]

Hi everybody,

As you know, naming things is one of the hardest problems of our field. So when we started this project a few months ago, with all of its challenges still ahead of us, we thought it would be wiser to focus our energy on delivering value first and, instead, settle for the mnemonic name of _Gradle Script Kotlin_, i.e. support for writing _Gradle_ build _scripts_ in _Kotlin_.

The name served us well so far, but there's no denying it's a mouthful. As we get closer to our big 1.0 release, we would like to ask for your help in finding a suitable, good, simple—and maybe even beautiful—name for the project. Together we can crack this nut!

Please suggest a name by posting a comment to this issue. Alternatively, vote on an existing suggestion by adding a thumbs up reaction to its comment.

Thanks in advance for participating!

[kitsjingkeily]

Kradle

[JBirdVegas]

Gradlin

[cypressious]

Gradle.kts

It emphasizes that this is still Gradle and it is consistent with the naming of the actual build files. Nevermind the parallel to the JavaScript convention of naming everything "something.js".

[JBirdVegas]

GSK

Abbr of:
Gradle Script Kotlin
Script
Kotlin

Follows the recursive acronym pattern of GNU

[dlew]

I'd like to explain my thumbs-down for "Kradle": it's too similar sounding to "Gradle" and will just lead to "wait, what did you say?" moments.

[dsvoronin]

ginko: GradleINKOtlin
http://haikuspirit.org/ginkoEN.html

A Ginko is a haiku walk.
During the walk the haiku writers discuss, take note or write haiku.

[dwursteisen]

GSK is already a company name. (so, sorry...thumb down)

[kubukoz]

Grotlin? ;)

[vasilevungureanu]

If Gradle [G] is form Groovy then already ^^^ purposed Kradle [K] from Kotlin ))

[Jkly]

Gradle Statikt

[IRus]

Ginko sounds nice, and even more
http://www.urbandictionary.com/define.php?term=ginko

My suggestion: Kobalt :trollface:

Krystal - means that with Kotlin build files became clear and transparent
http://www.urbandictionary.com/define.php?term=Krystal

[melix]

I'm -1 on Kradle or anything too fancy. Basically I'm for the status quo, that is, no rename. The reason is actually pretty simple: in the end, when Kotlin build scripts become the _main_ language for writing Gradle build scripts, you will have the choice to write your build scripts in Kotlin or Groovy without having to think about the name of this feature.

There's no Kradle distribution. Kotlin and Groovy scripting are already present in the distribution, and it's all about an internal dependency (that you _may_ want to override, but once it's stable it's unlikely you'll do). In other words, Gradle is Gradle. You wouldn't have to _name_ the Kotlin scripting ability to use it, it's there just like Groovy is. So, if we find a new name, that's mostly for cosmetics, but it will have implications on the technical side: how to name the dependency that we use in Gradle, or how we refer to the repository where it is developed. For most users, this is irrelevant. It's only for developers of Gradle itself that it matters.

Especially, in the future, documentation is going to be unified. When you'll go to the Gradle website, you will not have to look at an external repo like this one to understand how to write Kotlin build scripts. The samples, the docs, everything will be "dual coded" with both Groovy and Kotlin code.

Eventually, the name should not be confusing wrt what is Kotlin support in Gradle, because there are two things:

1. writing build scripts in Kotlin, which is what we are talking about
2. writing applications in Kotlin, which is irrelevant here.

Typically, when the documentation refers about "Groovy", it's how to build Groovy applications, not how to write Groovy build scripts. Technically, this discussion is similar to what aether is to Maven (its dependency engine). We could use a very different name, in the end, 99% of people wouldn't have to know.

So when you think about this, I'm finding that gradle-script-kotlin is not that bad. Marketing wise, it would be "Kotlin build scripts for Gradle". But in the end, it's all Gradle and its model that matters.

[kelstar95]

Krypton
It has something from Kotlin and Gradle and something completelly new. Also it sounds cool and like ultimate threat for any other build system :)

[kelstar95]

Also, I can understand why Kradle is confusing (it sounds very similar) and maybe we can use
Kradlin

[pledbrook]

I like one of the earlier suggestions, but prefer a two-letter suffix to a three-letter one: Gradle.ks

The downside is that the file extension is _.kts_ 😢

[anibyl]

Kottle :)

[hhariri]

I agree with @melix. At the end of the day this is Gradle and what you're offering is the ability to use a different language to write your scripts in. Naming it differently night also lead to confusion in that it might be something different.

[tenwit]

Klingr.
Because I like GradleINKOtlin, but to my way of thinking, this project is KotLINinGRadle.
And because Lingr is already taken.

[asafamit]

Groklin

[pawegio]

Groovy -> Gradle
Kotlin -> Kodle

[CauchyPeano]

I've searched for words containing g, k, t and s characters. I think those names are pretty nice:

• gasket
• gearstick
• grubstake
• Kingston
• backstage

Only g,k,s

• kegs

And there are more: http://www.wolframalpha.com/input/?i=words+containing+gkts
Maybe you will find something better.

[cbeams]

Thanks everyone for the suggestions and votes so far.

As @melix and @hhariri point out above, the current name—gradle-script-kotlin (read aloud as "Gradle Script Kotlin")—is accurate and intention-revealing as to the nature and purpose of the project. I'm glad they think so, because I suggested this name at the project's inception.

I've also suggested that we consider renaming the project now, as we approach its 1.0 release, because I've noticed over time—in the Kotlin Slack #gradle channel and other public places—that users tend not to refer to the project by it's full _Gradle Script Kotlin_ name in their everyday writing and speaking. This is understandable. Much of our communication is written; it's unrealistic to expect folks to write (or even say) "Gradle Script Kotlin" in full each time they refer to the project.

Instead, people—myself among them—tend to abbreviate the name in one way or another. "GSK" is a common one, and my usual go-to, but they vary: "Gradle Kotlin", "Kotlin Gradle", "Kotlin scripting for Gradle", "Gradle's Kotlin scripting support", "the Gradle Kotlin DSL", "the Kotlin DSL" and sometimes even the unqualified "Kotlin".

This variation is a good and natural thing, and I think it's best regarded as feedback that users want and need a more concise name for the project. Gradle Script Kotlin is three syllables long, and just as many people with three-syllable names (like Christopher) come up with a short version (like Chris) to make life easy for those who know them, it seems to me that we should now shorten Gradle Script Kotlin's name too.

With the above in mind, I have two suggestions for a new project name:

1: gradle-kts

In this option, we would:

• shorten the project's repository name from gradle-script-kotlin => gradle-kts, and
• change its proper name from "Gradle Script Kotlin" to "Gradle Kotlin Script" or "Gradle KTS" for short

Pros:

1. as @cypressious suggested in https://github.com/gradle/gradle-script-kotlin/issues/182#issuecomment-262290694 with his similar proposal to call the project "Gradle.kts", the kts suffix here is consistent with the suffix of the build files themselves, and naturally reveals that the scripting language in use is Kotlin [S]cript (see note to @hhariri at bottom for clarification on how to refer to Kotlin scripts themselves).
2. in a future in which Gradle's Groovy scripting support is separated out into its own module, as is gradle-script-kotlin today, we would name this module gradle-groovy, and they would enjoy the following symmetry:
   
   
   
   • gradle-kts: support for writing Gradle build scripts in Kotlin
   
   
   • gradle-groovy: support for writing Gradle build scripts in Groovy
   
   

Cons:

1. "Gradle Kotlin Script" is still just as long, and it's proposed short spoken form "Gradle KTS" will likely still devolve to "Gradle Kotlin" in practice, which is less than ideal. "Gradle Kotlin" may suggest on first glance that the project is some kind of Gradle-flavored variant of the Kotlin language, which it is not. It is a 100% Kotlin-based language frontend for scripting Gradle builds. "Gradle Kotlin" may also easily be confused with "support for building and automating Kotlin-based projects with Gradle", which it also is not (that is handled by the kotlin-gradle-plugin).

2: gradle/kotlin-dsl

In this option we would:

• rename the repository from gradle/gradle-script-kotlin => gradle/kotlin-dsl
• change its proper name from "Gradle Script Kotlin" to:
  
  
  
  • the Gradle Kotlin DSL, and/or
  
  
  • Gradle's Kotlin DSL
  
  

Pros:

1. It writes, speaks and reads naturally, e.g.:
   
   
   
   • "Have you tried using Gradle's new Kotlin DSL yet?"
   
   
   • "Version 1.0 of the Gradle Kotlin DSL was released today."
   
   
   • "Please add an issue to the gradle/kotlin-dsl repository."
   
   
2. There is no shorter form of the name likely to emerge in search of greater concision. I suspect that given a name like Gradle's "Kotlin DSL", users will not further shorten it to "Gradle Kotlin" or some such.
3. It is a consistent extension of what we have already long called the "Gradle DSL", which would evolve naturally under this scheme to being called:
   
   
   
   • the Gradle Groovy DSL (gradle/groovy-dsl), and
   
   
   • the Gradle Kotlin DSL (gradle/kotlin-dsl)
   
   
4. Omitting the leading gradle- from the name of the repository helps identify that the kotlin-dsl module is not like other, plugin-based modules. Indeed it is not a plugin at all, but a low-level service (in the Java ServiceLoader sense of the word). This should help avoid there being any confusion at all between support for writing Gradle build scripts in Kotlin (kotlin-dsl) and support for building and automating Kotlin-based projects (gradle-kotlin-plugin).

Cons:

1. DSL is a poorly-defined term in general, in the sense that when you ask different well-informed people to define it, you will often get different, mutually exclusive answers.
2. DSL is a term that peaked in popularity in the late 2000's (right when Gradle was being incepted), and may not be familiar or intention-revealing to folks outside the enterprise software development ecosystem, especially those who weren't around during that time.
3. What we call Gradle Script Kotlin today is not really a DSL. It is pure Kotlin, plus pure Kotlin libraries, used to interface with Gradle's pure Java API. It is true that Gradle Script Kotlin and Gradle's Groovy scripting support both expose certain DSL-ish elements (like the plugins and buildscript blocks), and more importantly, that they _enable users and plugin authors to craft their own DSLs_, but I believe that Gradle's Kotlin and Groovy scripting frontends are not themselves DSLs, per se. As @bamboo once put it, Gradle [scripting frontends] can be seen as "islands of DSLs in a sea of general-purposeness".

It's for the reasons directly above that I encouraged us to drop the DSL term altogether and to find something better—for both Gradle's Kotlin and Groovy scripting support—as part of this larger effort. In practice over these last months, however, no clearly superior alternative to the DSL term has presented itself. Whatever the official definition of DSL may be, in Gradle-land, DSL has come to mean "scripting frontend", such that in any given sentence, "Gradle DSL" can be read as "Gradle's Groovy scripting frontend" or "Gradle's Kotlin scripting frontend". I welcome alternatives to the DSL acronym that carry with it the same "scripting frontend" semantics and similar concision without the downsides. I'm afraid at this point, though, that we will not find any.

Note that in both of the suggestions above, I recommend we leave the project's base package name—org.gradle.script.kotlin—as-is.

@hhariri: how do you (i.e. JetBrains' Kotlin team) want people to refer to .kts sources? Are they programs written in "Kotlin Script" (proper noun), or are they simply "Kotlin scripts" i.e. pure Kotlin, but in its lighter-weight scripting form?

With regard to voting, I have put forth two distinct suggestions above, so a simple +1/-1 will may lead to confusion. To resolve this, please react with:

• :+1: / :-1: if you like or do not like what's written here in general
• :heart: if you prefer naming option 1: gradle-kts
• :tada: if you prefer naming option 2: gradle/kotlin-dsl

[rdblack]

Call it "Hadron".

[carlosrogue]

@cbeams if gradle/kotlin-dsl does not fit because this is not exactly a DSL, why not call itgradle/kotliner? Given you mentioned this is an actual interface between both.

[dwursteisen]

I agree with @melix and @hhariri : we don't use a new build system only based on kotlin or for only kotlin project.
Instead, Gradle can now execute Kotlin build script as it can execute Groovy build script.

So when you think about this, I'm finding that gradle-script-kotlin is not that bad. Marketing wise, it would be "Kotlin build scripts for Gradle". But in the end, it's all Gradle and its model that matters.

• gradle-script-kotlin doesn't show (enought) that it's Kotlin build scripts for Gradle (is it a script to build kotlin project ? or maybe to build kotlin ?)
• kotlin-build-script-support-for-gradle is obvisouly too long.

(but gradle/kotlin-build-script-support can be, a least in my mind :smile: , an option.)

[davidecavestro]

• DSL => recipe (as Gradle _recipes_ come in Groovy and Kotlin flavors)
• gradle-script-kotlin => grask, GraSK for marketing (unless _recipe_ goes further replacing even _script_)

[district82]

Grade Cradle

[district82]

Grade tree tops

[district82]

Grade leaf

[district82]

Cots

[district82]

Grade birth

[district82]

Gradle rebirth

[district82]

G-Life

[district82]

Just throwing some out on the table.

[district82]

Sorry about the error correction, stupid mobile

[district82]

Gradle Harmony

[kaHaleMaKai]

What about Ko-Script (or any variant of that like ko script…)? It emphasizes

• Kotlin
• scripting
• being an alternative (sound of ko same as in e.g. coworker) to the groovy dsl

…plus it's short! And although @dlew is right about the similarity of the guttural sounds K and G, one can easily distinguish between Ko-Script and Go-Lang.

Actually, other project exists called _go script_, e.g. GO! Script, a small windows program and ./go script, a ruby gem. But I don't assume any chance of confusion there due to their very different domains.

[palpa]

gradle/kotlin-bs => Gradle's Kotlin Build Script

[voddan]

@kaHaleMaKai note that scripting in Kotlin, in general, has nothing to do with Gradle and may be used in multiple applications.

[otrosien]

@cbeams I very much like the "DSL" suffixed name proposal, and I would actually say that according to the term definition gradle is indeed providing an "internal DSL" (see http://martinfowler.com/books/dsl.html) to fluently write build scripts in Kotlin.

I would even phrase it "Kotlin Gradle DSL" - because it's the DSL for writing gradle builds in Kotlin. WDYT?

[yole]

@cbeams We don't yet have an established naming pattern for .kts files, but I think it should be "Kotlin scripts" and not "files written in Kotlin Script". Among other reasons, "Kotlin Script" could be interpreted as "Kotlin targeting JavaScript", which would be an extra source of confusion.

[mhshams]

"Skript" ??

Or
"Yekan" A random name

[rovkinmax]

May be try use word combiner?
For example http://unique-names.com/word-mixer.php or http://namecombiner.com

[hellerim]

What about Beo? It's a bird with doubtless talent for several languages - at least as talented as a parrot! Gradle Beo speaks Kotlin. And one day in the future, maybe another language or two?
Could also be Beo-ktl, then Beo-grv and Beo-py, for example.
In addition, it's a short name.

[otrosien]

gradle-with-kotlin?

[orangy]

Gradle Script in Groovy (Gradle in Groovy, GiG)
Gradle Script in Kotlin (Gradle in Kotlin, GiK)
GIG, GIK are _pronounced like in gif, not like in jif_

[voddan]

@orangy those sound like TV show names, TBH ;)

[JLLeitschuh]

KOG
Sounds like "Cog" ⚙ which is good because it's driving your build system.

I'm not sure what the "O" would stand for though (feel free to suggest)

Kotlin On Gradle
Kotlin Over Gradle

My senior project had a great acronym: GRIP = Graphically Represented Image Processing Engine (the E is silent)

It may be easier to find an acronym that spells a word than it is to find a mashup word of gradle and kotlin.

[berkus]

Kable

as in "cabling that sets up kotlin builds" :)

[berkus]

Kongregate

[berkus]

Krokodile

[sdeleuze]

@cbeams I think I would vote for gradle-kotlin.

This is a variation of your gradle-kts proposal. The fact that you are using *.kts files and Kotlin Script is an implementation detail and I don't see a lot of value using it, especially for a project name. The big selling point is that you are using Kotlin as a language.

gradle-kotlin is meaningful, each time I want to refer to "Gradle Script Kotlin" this is the name which comes the first in my mind and this is 100% consistent with the gradle-groovy that you seems to plan later for the Groovy variant.

Keep it simple and meaningful please ;-)

[MrTact]

This is very computer-sciency (or maybe one might argue very Linux-y) but what about gradlek (pronounced "gradle-kay"), in a similar vein to gradlew and also gradle-kotlin (which I like, but is still a bit of a mouthful).

[AlexCzar]

I assumed it will just become stable, docs will be updated and we'll just refer to it as Gradle. Build file having separate extension is enough distinction, in my humble opinion.
If we do need the name, my suggestion is

GroK

Which is

1. Short and easy to remember
2. Gradle →←niltoK or Gradle on Kotlin (latter suggested by Madis Pink)
3. Emphasizes intuitiveness and understanding
   

[sdeleuze]

If Gradle Script Kotlin will be successful (and I expect it to be), I think in the long run people will gradually refer to it just by saying "Gradle" (in a few years) and will use "Gradle Groovy" for the historic variant. So with that in mind, "Gradle Kotlin" would allow a much smoother transition. That's why I am not sure there is a need to create a new product name.

[bamboo]

Hi, everyone!

First of all, thanks for your suggestions, comments and votes. It was really helpful and fun to watch.

After much deliberation we decided to settle on kotlin-dsl. :tada:

In the end we considered the pros listed by @cbeams in his well thought-out comment far outweighted the cons.

The github repository has been renamed to reflect this decision and all mentions to _Gradle Script Kotlin_ have been replaced by _Gradle Kotlin DSL_ (except in past release notes). Please let us know if you find any discrepancies.

If you have a local clone, please update it with the new origin:

git remote set-url origin [email protected]:gradle/kotlin-dsl.git

The base package has also been renamed from org.gradle.script.lang.kotlin to org.gradle.kotlin.dsl so you'll need to update any imports after upgrading to the upcoming 0.10.0.

We hope you are as satisfied with this move as we are.

Thanks for riding along with us!

[sdeleuze]

This new name makes sense. I tend to think in practice people will end up by refering to the variants as Gradle Groovy as a shortcut for "Gradle with Groovy DSL" and Gradle Kotlin for "Gradle with Kotlin DSL".

[santalu]

too late... kotle was such a good name