Por qué Kotlin es increíble, pero te quedarás con Java de todos modos

Independientemente del grupo al que pertenezca, hay una razón por la que se queda con Java. Y no le estoy culpando. Tiene posiblemente el ecosistema más desarrollado, universal y completo de todo el empresa mundo. El lenguaje tiene un conjunto de capacidades muy bien adaptado, en algún lugar en la zona correcta entre demasiado y demasiado poco. Y poco a poco se van añadiendo nuevas funciones, lo que lo mantiene al día de las nuevas tendencias en el mundo de la programación.

¿Sabe usted Lombok Sin embargo... Si no, te recomiendo que lo pruebes. Si te gusta, entonces tengo algo para que pruebes. Un lenguaje completamente nuevo, que por sus características deja obsoleto al Lombok. Se llama Kotlin.

¿Kotlin? ¿Te refieres al lenguaje de Android?

Kotlin en Android fue bendecido por el propio Google hasta el punto de convertirse en el lenguaje de facto de elección para la plataforma. No es en esto en lo que me centraré en este artículo, pero Android es de hecho el lugar donde conocí Kotlin por primera vez.

Mi compañero de trabajo estaba desarrollando una aplicación para una proyectopor su cuenta. Sin embargo, los plazos se acercaban rápidamente, así que me delegaron la tarea de ayudarle a cumplirlos. Permítanme retroceder en el tiempo hasta ese momento. Y... ¡Qué asco! ¿Por qué está usando un lenguaje raro que suena como un marca de ketchup!? ¡Se ve horrible!

¿Por qué se escribe "fun" antes de cada función? Como si no supiera ya lo que es. Además, ya estoy teniendo divertido con Java de todos modos. ¿Y dónde está el tipo de retorno? ¿Al final? ¿Estás loco? ¿Qué es eso, estás asignando algo a una función? ¡No tiene ningún sentido! Todo parece Java con pasos adicionales Espera, ¿dónde está la clase a la que pertenece este método? ¿Dónde lo escondiste ketchup-sonido, Java ¿Imitando la excusa de un lenguaje de programación? Oh, no. Oh no, no lo hiciste. ¿ES UNA FUNCIÓN GLOBAL? Eso es todo, he terminado, voy a llamar a la policía.

Spoiler alert: no llamé a las fuerzas del orden. Me gustara o no, tuve que ajustar mi mentalidad centrada en Java para adaptarme a otro lenguaje. Aunque no será tan malo, ¿verdad? Sigue siendo un lenguaje JVM, seguramente es sólo un lenguaje diferente. Java. ¿Quizá incluso con algunas funciones adicionales? De mala gana, empecé a trabajar en el proyecto.

Java con pasos adicionales

Si Java es tan bueno, ¿por qué no existe Java 2? Bromas aparte, eso es lo que pensé para mí mismo. Voy a fingir que Kotlin es Java 2. Nueva sintaxis y todo, pero sólo tengo que aprender lo suficiente para terminar el proyecto. Vaya si me equivoqué.

Después de probarlo durante uno o dos días, me di cuenta rápidamente de que tanto Kotlin como Java no son tan elásticas. Tratar de doblarlos uno hacia el otro termina inevitablemente con uno de ellos partiéndose por la mitad. Se hizo evidente que Kotlin es una cosa en sí misma, y el hecho de que funciona en una JVM significa casi exactamente nada desde el punto de vista del programador. (Como nota al margen, también puede transpilar a JavaScripto ser compilado a un binario nativo).

Plan B entonces. En realidad, conocer el lenguaje. Leer la documentación por primera vez produce escalofríos a un programador Java experimentado. Por ejemplo:
- anteriormente mencionado contexto de nivel superior aka global
- tipos de parámetro y de retorno de función especificados al final

fun suma(a: Int, b: Int): Int {
   return a + b
}

el cuerpo de la función puede ser una expresión (utilizando el signo de igualdad)

 fun suma(a: Int, b: Int) = a + b

la sentencia if puede proporcionar un resultado

 val y = if (x == 1) {
 "uno"
 } else if (x == 2) {
 "dos"
 } else {
 "otro"
 }

Vale, tendré que acostumbrarme. Sólo una sintaxis diferente. ¿Qué más tienes que ofrecer, señor Kotlin?

 ¿valor?.method() // ejecutar si no es null

Oh ok, deshacerse de si (valor == null)un punto para ti. ¿Qué más tienes?

fun comprobar(lista: Lista, alternativo: Booleano) = cuando {
 lista es ListaEnlazada -> print("enlazada")
 alternativa -> print("alternativa")
 list.tamaño > 50 -> print("grande")
 else -> print("otro")
 }

Hmm bien, podría ser útil para evitar si los bloques de otros, todavía parece un truco sin embargo.

 objeto SingularObject: Counter() {
 var a = 14
 fun test() = if (a > 10) "más" else "menos"
 }

Ok, ese parece realmente útil, ¡me gusta! Por otro lado, puedo crear un singleton en Java también. Quizás no sea tan elegante, pero no es nada realmente nuevo. ¿Algún as en la manga? ¿Como, verdaderos pesos pesados?

var s: String = null // no compila, tipo no nulo.

Espera... ¿qué?

El error del billón de dólares

Imagina una base de código en la que no tengas que preocuparte por la seguridad de los nulos. Imagina dar por sentado que cada referencia contiene algo significativo. Imagina estar seguro de que todos los problemas relacionados con los nulos están resueltos de antemano.
No te imagines más. Todas las referencias en Kotlin no son anulables por defecto. Si quieres hacerlas anulables, tienes que conscientemente tomar esa decisión, y explícitamente indíquelo en el código:

var s: ¿Cadena? = null

Comprendo que en este momento se muestre escéptico ante la idea. Estás acostumbrado a las referencias anulables. Lo tienes en la cabeza mientras codificas. Has aprendido dónde tienes que tener cuidado. Es exactamente lo que pienso. Viniendo de Java...me sentí raro al principio. ¿Qué sentido tiene? No va a hacer desaparecer mágicamente todos los problemas relacionados. Sólo tendré que añadir "?" en todas partes, suena como una tarea.

Pero decidí sumergirme en el lenguaje, ¿no? Hagámoslo a su manera señor Kotlin. Empecé a esforzarme por eliminar tantas variables, campos y parámetros anulables como pudiera. Paso a paso, aprendí a utilizar las características del lenguaje que facilitaban la eliminación de las referencias anulables, por ejemplo, el operador de llamada segura "?.", el operador elvis "?:", las propiedades delegadas, el método "let", etc.

Con el tiempo, conseguí que algunas clases sólo contuvieran campos y parámetros de métodos no nulos. Básicamente, sabía que si una clase se instanciaba con éxito, casi podía olvidarme de la anulabilidad en los cuerpos de los métodos. Era una bendición. Con el tiempo, lo aprecié cada vez más. En última instancia, sin embargo, no pensé en ello como una característica asesina, Java todavía se sentía como en casa. Hasta que...

El regreso

El proyecto se acercaba a su fin. Fui conociendo Kotlin más y más, y con este conocimiento, el código se hizo cada vez más ordenado, legible y conciso. Podías ver las mejoras a simple vista en el historial de commits. Pero por fin ha llegado el momento. Con recuerdos inesperadamente gratos del nuevo lenguaje, era hora de decir adiós y volver a la dulce zona de confort de Java. O eso creía yo.

¿Conoces esa sensación cuando empiezas a apreciar algo en el mismo momento en que desaparece? ¿Cuando no te das cuenta de lo mucho que dependes de algo hasta que ya no puedes usarlo? Fue el mejor ejemplo de esa sensación que probablemente haya experimentado en mi vida.

Cuando volví a escribir el código en JavaEstaba casi aterrorizado por la falta de algunas características. Era como si mi cerebro, subconscientemente, retroadaptara erróneamente características de Kotlin a Java. Experimenté situaciones en las que empecé a implementar algo, sólo para darme cuenta de que no funcionaría en este lenguaje. En el mejor de los casos, podría escribirlo como Kotlin, pero sería voluminoso, ilegible y/o requeriría demasiada repetición.

La seguridad nula era, por supuesto, la característica que más echaba de menos. Pero me sorprendió cuántas cosas más pequeñas se volvieron naturales para mí: parámetros con nombre, propiedades en lugar de getters y setters, "==" como iguales y "===" como igualdad referencial, "this" cualificado, funciones de extensión, parámetro lambda implícito singular, "_" para parámetros lambda no utilizados, clases de datos, funciones de ámbito, otras funciones stdlib de Kotlin, operadores y más. Y la forma en que todo encaja a la perfección. En comparación, Java parecía... primitivo.

De hecho, me sentí tan mal que empecé a considerar cambiar a Kotlin por completo. En teoría, es totalmente interoperable con Java, sólo tienes que añadir soporte para Kotlin a un proyecto existente y empezar a escribir nuevas clases. El lado Kotlin sabe cómo "hablar" con Java, y el lado Java ni siquiera sabe que está "hablando" con otro lenguaje. Y después de la compilación a bytecode, realmente no hay ninguna diferencia para la JVM.

Comprobación de la realidad

¿A qué esperas? Si el lenguaje es tan bueno como dices, ¡úsalo! Tal vez no en los proyectos existentes, aunque sé que debería ser interoperable, pero mezclar dos lenguajes diferentes de esta manera suena feo.

Ok, así que para los nuevos módulos - Kotlin es. ¿O no? Estás trabajando en un equipo. Hay que consultarles y convencerles de la grandeza de esta nueva lengua. ¿Qué? ¿No les gusta? Parece que no quieren esforzarse en aprenderlo. No puedes culparles, tú también eras escéptico al principio.

¡El jefe de proyecto! ¡Sí! Seguro que entenderá el gran valor que Kotlin aportaría a nuestro equipo. ¡Oh, la grandeza que vendrá!
-No
-Espera, ¿por qué?
-El equipo no lo sabe.
-¡Aprenderán!
-No quieren aprender.
-¡Tú puedes hacerlos!
-No necesitan aprender.
-Es cierto, pero ¡piensa en las posibilidades!
-Sí, qué tal si piensas primero en los problemas.

La leyenda dice que existe un proyecto. Un proyecto grande y complejo, pero bien escrito en todas sus partes. Un proyecto en el que todos los desarrolladores están de acuerdo sobre las soluciones utilizadas. Donde las nuevas funcionalidades fluyen suavemente de los teclados de los programadores. Donde los errores son raros y fáciles de solucionar.

¿Has visto un proyecto así? Yo no. Algunos estuvieron cerca, pero la mayoría son un gran lío de código heredado. Y si no lo son, probablemente lo serán en algún momento en el futuro. Ahora imagina añadir otro lenguaje a la mezcla. Introduce nuevas formas de cometer errores. Requiere que los desarrolladores sepan lo que están haciendo. Es un riesgo, como mínimo.

También hay que tener en cuenta la rotación de los desarrolladores. La gente va y viene. ¿Harás que cada nuevo desarrollador aprenda un lenguaje completamente nuevo? No, es contraproducente. ¿Contratarás a desarrolladores de Kotlin en primer lugar? Buena suerte con eso, contratar a un buen desarrollador Java ya es bastante difícil.

La gente lo ha intentado. Tengo que decir que no estoy de acuerdo con la mayoría de las acusaciones en ese artículo. Hay algunas críticas válidas allí, pero creo que no usaron Kotlin lo suficiente como para entender realmente "la manera Kotlin". Muchos comentaristas bajo ese artículo parecen pensar de manera similar.

Pero eso no importa. Apuesto a que esto también pasaría en tu proyecto. "Lo probé, no me gustó". No harás que le dediquen más tiempo. No harás que lo intenten de nuevo. No harás que le den otra oportunidad. Y desde un punto de vista práctico, puede que tengan razón. Java es tan popular, que usar cualquier otra cosa en la JVM parece redundante.

¿Por qué este artículo entonces?

Acabas de dedicar mucho tiempo a escribir un artículo que parece no tener sentido. ¿Por qué iba a intentar aprender un idioma si usted dice que no tiene sentido?

Bueno, no creo que no tenga sentido. Sigo pensando que Kotlin es genial. Todavía quiero usarlo de verdad (y de hecho lo hago para mis proyectos privados). Si pudiera, me pasaría a él y me olvidaría de las limitaciones de Java. Pero la realidad actual dice que no puedo. Y quiero intentar cambiar eso.

Mi intención para ti, querido lector, es que al menos contemples la posibilidad de salir de la acogedora zona de confort de Java. Porque tal vez, sólo tal vez, te encante Kotlin tanto como a mí. Y si lo haces, serás un desarrollador conocedor de Kotlin más en la red. mercado.

Más información:

El mejor tipo de proyectos para Java

3 Desafíos comunes del desarrollo de productos de software para startups

La forma correcta de encontrar los mejores desarrolladores Java