Simplemente usa Java
(teamten.com)- Mi lenguaje favorito es Python. Aun así, uso Java para todo, incluso para scripts simples.
- Algunas experiencias:
- En una empresa basada en Java, escribí escenarios de prueba en JavaScript. Pero era difícil rastrear los stack traces y terminé haciendo esfuerzo de más escribiendo código puente entre Java y JavaScript.
- Estábamos guardando logs en formato JSON, y un compañero creó un programa llamado
logcatpara manejar esos logs. Estaba satisfecho con ese programa, pero después, al hacer un programa similar en Java, mostró una mejora de rendimiento de más de 10 veces. - Gracias a la amplia experiencia y cantidad de recursos sobre Java, para crear servicios web Java fue más rápido que Python. Estrictamente hablando, esta es una ventaja de usar un solo lenguaje.
- El debate más fuerte sobre Java es que es verbose (verboso). Pero eso no es una desventaja en absoluto. Mira estos dos códigos.
// java
Map<String,User> userIdMap = new HashMap<String,User>();
// python
userIdMap = {}
- Pero en la práctica, es mucho más probable que el código en Python esté escrito así. (Si no, de verdad sería muy difícil de mantener)
# Map from user ID to User object.
userIdMap = {}
- Es decir, usar un lenguaje de tipado dinámico es como sacrificar la productividad después de 14 días para poder hacer algo genial en 30 minutos.
- Stack Overflow soportó 60,000,000 pageviews con 5 servidores usando ASP.NET (en 2010).
- Veamos el ejemplo de las pruebas unitarias. Escribir y mantener pruebas unitarias consume tiempo. En especial, los casos excepcionales que se pueden verificar fácilmente con tipos tampoco suelen ser bien detectados por pruebas unitarias en lenguajes dinámicos (por ejemplo: un parser).
- (Agregando una razón más para no usar Python) una solución improvisada (quick hack) va creciendo hasta convertirse en una herramienta muy importante, pero como no hay tiempo para reescribirla, al final uno termina sufriendo cada vez que la usa por rendimiento y mantenimiento.
- Por último, las razones por las que prefiero Java en lugar de otros lenguajes de tipado estático
- C/C++ es difícil de aplicar a mi trabajo
- C# tiene poco soporte cross-platform
- Scala es demasiado complejo
- Otros lenguajes como D o Go son demasiado nuevos para incorporarlos a mi trabajo
- Hay varias razones por las que traje este artículo a GeekNews:
- Me sorprendió porque es la primera vez que veo un texto que diga “¡de verdad me encanta Java!” (viendo solo el título pensé que vendría un giro al final...)
- Me pareció interesante que tenga su propia caja de herramientas hecha en Java. Me hizo pensar en la imagen de un anciano sacando poco a poco armas antiguas de sus bolsillos.
- Personalmente me gustan mucho JavaScript y Python. Pero, a simple vista, también parece que en estos lenguajes la tendencia es “introducir tipos de alguna manera” (TypeScript para JavaScript, typing/mypy para Python). Viendo este texto, pensé que quizá usar un lenguaje de tipado estático por mi cuenta (sin forzar los tipos de ninguna forma) se parece un poco a una satisfacción personal.
- El autor compara directamente Java y Python porque tiene experiencia con ambos, pero no creo que sea necesario limitar la discusión solo a esos dos. Desde una perspectiva más amplia, ¿qué opinan ustedes sobre los lenguajes de tipado estático y de tipado dinámico?
PS. No despreciemos sin sentido a un lenguaje específico :D
58 comentarios
Creo que, aunque sea una experiencia muy personal, el mayor problema de Java no es tanto el lenguaje sino la JVM.
Me ha pasado demasiadas veces, en varias versiones de la JVM, que no maneja bien la memoria.
Entonces también hagan y usen
pandasynumpyen Java. A quien hace ese tipo de afirmaciones no hay que tenerlo cerca.Java se usa para el backend web y Python para la IA.
Si vamos a hablar de rendimiento, entonces habría que usar Rust; ¿no es algo que todos ya saben?
Pero como se espera que la proporción de IA siga creciendo en el futuro, da la impresión de que
ya llegó el momento de dejar de lado Java, ¿no? En nuestro país mucha gente tiene la mentalidad de que no podemos quedarnos atrás jaja
Si la IA se vuelve más demandada y reemplaza las APIs REST comunes o las tareas CRUD simples, de modo que ya no se construyan ese tipo de sistemas, entonces quizá se podría dejar Java. Además, como hay casos en los que un proyecto no está compuesto por un solo lenguaje, tampoco creo que se pueda hacer una correspondencia uno a uno entre el lenguaje y el propósito del proyecto. Como la interfaz de programación suele ser Python y las partes donde el rendimiento es importante usan código nativo. Aunque en nuestro país no es muy común estructurar proyectos de esa manera.
La introducción deja un poco que desear. Si primero nos hubieran dicho la fecha en que se escribió el texto original, creo que la mitad de los que estamos aquí lo habríamos entendido hasta cierto punto...
Yo también me di cuenta después de ver los comentarios de otras personas.
Pero yo supuse apresuradamente que había sido escrito hace poco, y no sentí ninguna rareza al leer el contenido. Al menos para mí, sigue siendo un texto convincente.
Aparte de eso, de vez en cuando sí me fijaré en la fecha jaja
La discusión se está acalorando.
Si tienen una réplica, por favor escriban solo su contenido.
Los comentarios que incumplían las normas de uso del sitio han sido eliminados.
Además, tengan en cuenta que se han bloqueado las cuentas que repetidamente realizaron actividades que no se ajustan a las normas de uso.
Les pedimos mantener una discusión sana.
Yo confío más en Google (V8) que en Oracle (JVM).
Cuando hacía Python y vi Java por primera vez, de verdad me pareció muy verboso, pero viendo el código que hoy en día hace falta para agregar type hints completos en Python, ya no me lo parece tanto jaja. Más bien, lo que siento que le falla a Java es esa convención de nombres de querer ponerles nombres larguísimos a los métodos.
1 de junio de 2014
Yo también prefiero los lenguajes con tipado estático.
Aunque los lenguajes de tipado dinámico tienen partes cómodas, a veces se vuelven difíciles de mantener en un entorno de producción.
Además, los lenguajes de tipado dinámico suelen tener como filosofía de diseño el objetivo de "escribir código simple", así que a nivel de lenguaje hay muchas cosas que se gestionan implícitamente; por eso, muchas veces también hay menos margen para optimizar.
Al final, parece que lo mejor es pensarlo y elegir según el entorno de desarrollo, entre la facilidad de implementación y un mayor margen de optimización.
Un post de hace 10 años, wow.
Tal cual jaja
Mi vida se volvió más tranquila desde que dejé Java.
Hay buenas razones por las que Java sigue bajando en popularidad en la encuesta de Stack Overflow.
En Corea, en particular, sirve para conseguir trabajo porque ese maldito framework gubernamental quedó prácticamente atado a Spring,
pero en Occidente, fuera del legado, parece que casi ya no se elige Java al arrancar proyectos nuevos.
Es cierto que hay una razón para eso, pero creo que están viendo esa razón de otra manera.
Incluso en el sitio de TIOBE se menciona que el ranking de lenguajes de programación debe verse solo como referencia y que no está directamente relacionado con la cuota de mercado o la popularidad.
La conclusión es: Python está en el puesto 1 por una cuota abrumadora, pero ¿hay herramientas en el mercado?
Lo que se encuentra con más frecuencia es C/C++, .NET, Java (Kotlin) y Swift.
Que haya muchas preguntas y búsquedas no significa que sea un lenguaje muy usado.
Python es un lenguaje que cualquiera puede usar aunque no haya estudiado la carrera.
No se puede negar que es popular, pero en el mercado de desarrollo la historia es distinta.
Instagram usa Python en el backend.
Es un poco ambiguo qué significa eso de "herramientas disponibles en el mercado", pero... ¿no son ya suficientes herramientas como Django, FastAPI, PyTorch, NumPy y Pandas, entre otras...?
Vine esperando los comentarios apenas vi el título jajaja. Últimamente se ha ampliado mucho cuánto dependemos del lenguaje.
Si lo limitas solo al tema de costos, Java sí termina saliendo caro en la nube por el uso de memoria. Es muy común que programas escritos en un lenguaje estático que necesitan 100 MB o 200 MB de memoria, si se escriben en Java terminen necesitando 1 GB o 2 GB, y muchas veces los hilos ligeros no se pueden usar por problemas de compatibilidad con las librerías.
Java también es un lenguaje estático, pero... el problema de la memoria corresponde al recolector de basura o a la JVM, y ese "programa en lenguaje estático que necesita 100 MB, 200 MB de memoria" del que hablas probablemente se refiera a lenguajes nativos como C o C++.
Perdón por la alucinación. T_T Java también es un lenguaje estático. Si sumas varios costos en la nube, hay que calcular alrededor de 30 mil wones por cada 1 GB de memoria, así que los servicios desarrollados en Java terminan generando costos muy altos.
Si existen excepciones, es un lenguaje de tipado dinámico. Aparte de eso, estoy de acuerdo con el punto de que el sistema de tipos y el uso de memoria son temas distintos.
Siento que el significado de la excepción que mencionas se percibe de forma demasiado amplia; ¿podrías explicarlo un poco más en detalle?
Según la definición de lenguajes con tipado estático/dinámico que yo conozco, si el tipo de una variable queda determinado en tiempo de compilación y para cambiarlo hay que hacerlo explícitamente, entonces es un lenguaje de tipado estático; en cambio, un lenguaje de tipado dinámico es uno en el que, en tiempo de ejecución, el tipo de una variable puede determinarse libremente y también puede cambiarse de forma implícita.
Si te encuentras con una situación como hacer un downcasting en tiempo de ejecución, Java tiene que verificar los tipos en tiempo de ejecución. Por esa razón se dice que Java es de tipado dinámico en ese momento, y lo que ocurre ahí son las excepciones.
En el fondo, si no existiera esa brecha, no habría necesidad de llamar excepción a una excepción.
throwsería azúcar sintáctica para un patrón de guardar el objeto que se lanza en una variable global y hacergoto.De forma similar a lo que mencionaste, a los lenguajes que realizan la verificación de tipos en tiempo de ejecución se les llama de tipado dinámico. Pero esto se refiere a todos los valores que maneja el programa. Como el artículo trata de Java, si usamos Java como ejemplo, el código Java se verifica en tiempo de compilación, pero esto implica algo importante: que el valor correspondiente a esa variable debe coincidir con el tipo de la variable.
Si la verificación de tipos se hace en tiempo de ejecución, ¿entonces C también sería un lenguaje de tipado dinámico? Según entiendo, existe el concepto de puntero
void, pero ¿cuál es exactamente la diferencia entre ambos?¿Qué compilador de C inserta comprobaciones de tipos en el código y genera un error explícito cuando los tipos no coinciden? Si existe una implementación así, por favor denme solo un ejemplo.
En C no hay nada parecido a verificación de tipos en ese proceso. ¿No ves que no pasa nada aunque leas datos de punto flotante como enteros? No es que sea de tipado dinámico, simplemente es peligroso.
Sí, si C hiciera la verificación de tipos en tiempo de ejecución, sería un lenguaje de tipado dinámico.
Como no es así, es de tipado estático.
Un puntero
voides simplemente un puntero raw cuyo tipo original no se puede conocer. No se puede saber qué tipo hay en la dirección a la que apunta ese puntero.Mi principio es que el mejor lenguaje es el que ya conoces.
Estoy de acuerdo. Parece que tampoco es fácil alejarse del lenguaje que usa el equipo o la organización.
Entre las varias razones por las que se separan los contenidos o las asignaciones de trabajo, cuando se añade un lenguaje se genera una sobrecarga para ciertas personas y, si hay cambios de personal, el trabajo no avanza. Como también es un factor que afecta la contratación, creo que hay que ser muy cuidadosos al elegir el stack tecnológico.
Sin embargo, por otro lado, si se insiste en mantener un lenguaje solo porque resulta familiar, aunque tenga un pool de contratación pequeño o requiera aprendizaje adicional después de contratar, eso también es un problema.
Simplemente usen Java
¿Por qué C# tendría carencias en multiplataforma? Hoy en día, la mayoría de las aplicaciones de servidor en .NET se despliegan en servidores Linux.
Python ni siquiera es comparable desde el principio y, en comparación con Kotlin y C#, sí parece cierto que es más verboso y que le faltan muchas funciones necesarias.
Ah, es un artículo de hace 10 años. Ahora la situación ha cambiado mucho.
C# también es un lenguaje que usa una máquina virtual, así que el soporte multiplataforma debió haber llegado mucho antes, pero hasta donde sé salió hace muy poco, y por eso creo que por un tiempo seguirá existiendo la percepción de que, más que nada, se puede ejecutar en sistemas operativos que no sean Windows.
Además, si se trata de un entorno Linux enfocado en servidores que operan los 365 días del año, también es cierto que se tiende a evitar .NET frente a otros lenguajes cuya estabilidad ha sido comprobada por más de 10 años en ese sistema.
En ese sentido, ¿no será por eso que dicen que le falta soporte multiplataforma?
Pero, ¿cuál es exactamente el criterio con el que se comprueba la estabilidad? No me queda claro si simplemente se refieren al tiempo de uso.
Como es un texto de hace 10 años, fue escrito así no mucho después del nacimiento de .NET Core.
Las aplicaciones de .NET ya funcionan de forma estable y sin problemas en Linux y Mac.
Descubrí por casualidad GDScript mientras buscaba algo como un lenguaje con la sintaxis concisa de Python pero con tipado estático, pero su gran desventaja es que es demasiado difícil de usar de forma generalizada.
Si tienen la oportunidad, les recomiendo hacer un proyecto pequeño con Godot y probar un poco GDScript.
Simplemente usen Java
Conocí Kotlin y terminé desarrollando una especie de aversión a Java...
Me dio la impresión de que, cada vez que se necesita alguna funcionalidad en Java, ya existe una respuesta probada.
Simplemente usa Kotlin.
Aun así, yo también, como usuario de Kotlin, le pregunté por correo su opinión sobre Kotlin, pero me respondió que, como no lo ha usado, le resulta difícil hablar desde la experiencia.
Me gustan los lenguajes de tipado estático. Reducen la necesidad de estar pensando en ciertas cosas, y así puedo usar ese tiempo para pensar en otras.
Java es un lenguaje en una posición realmente única. La última vez que lo usé en el trabajo fue hace unos 10 años, pero incluso hoy, si tuviera que desarrollar algún programa para trabajo y no como hobby, seguiría estando en mi lista de primeras opciones a considerar.
Ahora mis lenguajes principales en el trabajo son Ada y C, pero las herramientas que uso de forma personal o dentro del equipo las escribo principalmente en PowerShell. Pero mientras las escribo, apenas pasa un poco de tiempo (solo 5 minutos...) y ya me encuentro pensando: "¿Qué tipo tenía esta variable?". Por eso últimamente me aseguro de declarar siempre el tipo. (En PowerShell se puede especificar el tipo al definir una variable, o bien omitirlo y usarla dinámicamente).
Tampoco me gusta mucho C. Errores relacionados con tipos que en Ada el compilador detectaría, C no los detecta en absoluto. A menudo pienso que sería bueno que existiera un lenguaje con una sintaxis como la de C, pero con el sistema de tipos de Ada.
No logro encariñarme con Javascript ni con Python. Perl o Shell Script... prefiero ni pensarlo.
Parece que es inevitable por la filosofía básica del lenguaje C de "confía en el programador"..
Ah, y además, aunque me gusta Java, odio Maven.
¡En los buenos viejos tiempos se podía hacer todo con Ant!
Me parece un alivio que Java, aunque sea poco a poco, vaya alcanzando a los lenguajes más modernos con la incorporación de records y pattern matching.
Java está bien porque tiene muchas referencias, pero si fuera solo por eso, me pregunto por qué no sería mejor usar C++.
Me habría gustado que se hablara un poco más de las ventajas de Java.
Principalmente uso C++, así que solo lo puse como ejemplo. Yo también creo que Java es un buen lenguaje, pero lo que quería señalar era que en esa publicación original faltaba hablar de las ventajas de Java.
Si escribes algo como “me encanta Java”, entonces el enfoque principal debería ser hablar de sus ventajas, pero me pareció que el foco estaba más en criticar otros lenguajes.
Como comentaste, también creo que la JVM de Java es muy buena.
Estoy totalmente de acuerdo. La aclaración de no limitar innecesariamente la discusión solo a Java iba con esa intención. Pero parece que no se transmitió del todo...
Como la comparación es entre Java y C++, de alguna manera la credibilidad cae muchísimo jajaja
Java corre sobre la JVM, así que se puede configurar el entorno local y el de las máquinas de forma idéntica. Si intentas hacer que todos los desarrolladores y máquinas tengan el mismo entorno con C++, te va a llevar bastante tiempo. Además, es difícil de mantener...
Parece que el autor original simplemente usa Java porque es un trabajo en el que resulta difícil aplicar C++. Quizás, si tuviera que elegir entre Python y C++, ¿no habría elegido C++?
corrección: "Por último, por qué preferir Java en lugar de otros lenguajes de tipado estático" -> "Por último, razones para preferir Java en lugar de otros lenguajes de tipado estático"
Cómo prende este material para leña... recomendado.
No es el fuego que quería 😭
Está... calientito...