« first day (3046 days earlier)      last day (46 days later) » 

Ali
12:12 AM
@DanteS. Y aquí viene el tema de la inferencia de tipado automático, no es necesario hacer val foo: String = "", por que ya infiere que el tipo es String, así que solo te queda val foo = ""; kotlin explota mucho el tipado inferido, no eres redundante.
@DanteS. si eso si es cierto, pero las llaves te ayudan, especialmente cuando tienes bloques hijos al mismo nivel, si tienes dos metodos seguidos, tienes que detenerte lentamente a ver la tabulación a que método le pertenece (suele pasar en pyton), pero si tienes un utilitario la llave el mismo ide te va a decir a que bloque le pertenece.
@DanteS. si el código es de una linea, yo prefiero no usar llaves, por ejemplo un if(condicion) return; por que se entiende, y escribir llaves está de más, pero si son muchas lineas, o muchos niveles, de verdad se las extraña, no sé si has visto sass vs scss, es lo mismo pero uno tiene llaves y el otro no, cuando en sass manejas clases anidadas, eso se vuelve un dolor de cabeza.
 
@Yussef la indentación importa incluso si se usan llaves, así que el problema es casi el mismo
 
ya ves que al toque se hace amigos por estos lares @Ali
 
Ali
@fredyfx internet se ha hecho para discutir. Dale la contra a alguien y siempre habrá espacio para conversar.
 
@Ali no creo que lo logre entender, no te preocupes. Para mi, el lexer dice "esto es string, ya que tiene x sintaxis o esta otra especificando explicitamente qie es String" y se indica lo mismo.
 
@Ali XD!!!
 
12:26 AM
Estoy hablando de comparar String hola = "mundo" y hola:String = "mundo"
 
lo segundo me parece a TypeScript
 
Ali
@DanteS. si, y no es necesario, en kotlin no escribes hola: string = "mundo", no lo necesitas, solo necesitas escribir val hola = "Mundo" es más, ni punto y coma necesita.
 
@Ali yo no uso las llaves para eso ni tengo la mente adecuada para algo tan abstracto
@Ali ya veo. Opinamos diferente.
@Ali eso está bueno!
@fredyfx en Python se escribe así el tipado opcional, y por lo que vi también en kotlin
 
@DanteS. recién me enteré que Python tiene tipado, ando feliz :D
 
@fredyfx si, eso está bueno para hacer documentación :D pero no se tiene que cumplir estrictamente, a diferencia de java
 
12:32 AM
XD!!!!!!
 
XD
Python dice "si grazna como pato y tiene patas de pato, es un pato" (Duck Typing) y tiene sus pros y contras
 
a veces hay que ser explícito para evitar problemas por confiarse de variables "flexibles"
 
 
1 hour later…
1:37 AM
Verdad
 
 
4 hours later…
Ali
5:50 AM
@DanteS. XD que buena expresión, @DanteS. conoces algún buen Linter para obligar a los desarrolladores a tapar en python? algo como el eslint de python que puedes forzar a todos a no usar any?.
@DanteS. Typescript me gusta, pero aún dependemos de buenas prácticas, y buenos devs para forzar a todos a usar el tipado. Tipar salva vidas.
 
¿tapar o tipar?
Devs que usan TS con any para todo, son un peligro para la sociedad :v
 
Ali
6:05 AM
@fredyfx tipar*
@fredyfx una vez he visto un manual, que cambiaban la librería de angular con any porque el angular les devolvía abstract control, y les daba error, y en vez de hacer algo como (form['field'] as ArrayControl) para castear al tipo específico, el manual de instalación decía, que luego de hacer npm Install, entraran al nodo modules y modificaran un archivo para que ese control se devuelva como any.
Debería haber un offtopic de screens y cosas curiosas que encontramos en los proyectos.
 
@Ali oooooooztia tío
Pues, en su tiempo, tomé bastantes screenshots de preguntas graciosas en SOes, luego de años dicté una charla de cosas curiosas cuando moderas SOes.
 
Ali
Al menos está bien documentadito.
 
6:35 AM
Cosas random: Hago pruebas unitarias, todo sale bien, ejecuto desde VS, todo verde tal cual pastizal de Windows XP, ejecuto desde línea de comandos y 1 lanza error. En teoría, en ambos casos debería tirar error.
 
Ali
@fredyfx esto puede ser por que hay pruebas que afectan variables compartidas/globales, entonces ensucian las demás pruebas, puede pasar que corres las pruebas y estas se ejecutan en un orden distinto y verás que a veces te funcionan y otras no, o puede ser que corren con un aislamiento distinto en el ide/linea de comandos.
 
pues, justo para este caso, cada prueba unitaria tiene sus propios mocks
algo anda raro ahí
nos vemos estimados, voy de salida.
 
 
6 hours later…
1:26 PM
@Ali no, y admito que no estaría bueno. Así que mejor no obligar
@Ali verdad
@fredyfx ufff
@fredyfx yo tengo alguna foto. Temgo una de uno que, como decimos en mi pais, puteó a ña comunidad. Si la encuentro en mi compu se las paso
Me arrepiento de no tener la foto de la del desafío de tik tok
@fredyfx nos vemos! Que te vaya bien!
 

« first day (3046 days earlier)      last day (46 days later) »