Rename the project - Githubissues

bamboo commented 8 years ago

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 commented 8 years ago

Kradle

JBirdVegas commented 8 years ago

Gradlin

cypressious commented 8 years ago

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 commented 8 years ago

GSK

Abbr of: Gradle Script Kotlin Script Kotlin

Follows the recursive acronym pattern of GNU

dlew commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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

kubukoz commented 8 years ago

Grotlin? ;)

ghost commented 8 years ago

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

Jkly commented 8 years ago

Gradle Statikt

IRus commented 8 years ago

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 commented 8 years ago

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:

writing build scripts in Kotlin, which is what we are talking about
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.

interkelstar commented 8 years ago

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 :)

interkelstar commented 8 years ago

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

pledbrook commented 8 years ago

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 commented 8 years ago

Kottle :)

hhariri commented 8 years ago

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 commented 8 years ago

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

asafamit commented 8 years ago

Groklin

pawegio commented 8 years ago

Groovy -> Gradle Kotlin -> Kodle

CauchyPeano commented 8 years ago

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 commented 8 years ago

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:

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).
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:

"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:

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."
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.
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)
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:

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.
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.
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

ghost commented 8 years ago

Call it "Hadron".

carlosrogue commented 8 years ago

@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 commented 8 years ago

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.)