¿Cómo evalúa el nuevo artículo de Wang Yin, "Hablar de justicia a Java"?

Solía ​​escribir Java y recientemente escribo principalmente Ruby y un poco de JavaScript.

Creo que hay varios puntos en el artículo que son muy deseables:

Las herramientas que utilizas para programar son importantes, pero las herramientas no son tan importantes como tu propia tecnología después de todo. . Mucha gente pasa demasiado tiempo probando varios lenguajes nuevos, con la esperanza de que mejoren milagrosamente la calidad del código y terminan sin nada. La condición más importante para elegir un idioma debe ser "suficientemente fácil de usar", porque el éxito de un proyecto depende en última instancia de las personas, no del idioma.

Muchas veces estamos ocupados aprendiendo diferentes idiomas e ignoramos el propósito último del lenguaje, que es escribir programas que puedan resolver problemas.

IntelliJ también puede realizar transformaciones estructurales muy rápidas, lo que te hace sentir como un artista construyendo una escultura. Puedo ser audaz al principio y cortar el código en una forma aproximada, y luego refinarlo cuidadosamente y amasarlo hasta darle una forma mejor, más fácil de entender y más atractiva.

Sí. La experiencia de usar IntelliJ para refactorizar código Java es de hecho mucho mejor que usar RubyMine para refactorizar código Ruby o WebStorm para refactorizar código Javascript. Aunque la última experiencia es mejor que cuando se usa Vim, usar IntelliJ es más agradable y nunca tendrá que preocuparse por errores de nombres debido a Refactor (si no se usa Reflection).

Mucha gente odia Java porque los primeros patrones de diseño de GoF intentaron crear plantillas sencillas, lo que aportaba una complejidad innecesaria al programa. Sin embargo, el lenguaje Java en sí no es equivalente a los patrones de diseño. Los diseñadores de Java y los diseñadores de Design Pattern son personas completamente diferentes. Puedes escribir código muy simple en Java sin usar patrones de diseño.

Estoy muy disgustado con los patrones prescritos por algunas grandes empresas, como "Programación hacia la interfaz, no hacia la implementación": esto da como resultado muchas interfaces y solo una implementación al leer el código; Transfiere muchos archivos para encontrar lo que necesitas. Pero creo que esto es un problema para la persona que escribe el código y no tiene nada que ver con Java. Es sólo que muchas personas toman "Programación a interfaz" demasiado literalmente cuando escriben Java.

Entonces no estoy de acuerdo con esto:

Python está bien y puede usarse en lugares sin importancia, Ruby es basura y JavaScript es basura entre la basura. La razón es muy simple, porque los diseñadores de Ruby y JavaScript son en realidad simples civiles.

Personalmente, me gusta el diseño de Ruby, principalmente desde la parte de MetaProgramación: realmente puede reducir la cantidad de código. Reducir la cantidad de código de abstracciones de nivel superior significa directamente que todo el programa se vuelve más fácil de leer y comprender. No creo que algo diseñado por Minke no sea bueno. Además, es fácil depurar programas Ruby: RubyMine también tiene un buen soporte para el punto de interrupción StepTrace. Además, debido a que es un lenguaje Script Base, puede leer/modificar fácilmente el código de la biblioteca y comprender rápidamente la biblioteca correspondiente.

JavaScript todavía tiene algunos inconvenientes, como la falta de una clase nativa (la clase ES6 parece ser solo una sugerencia de sintaxis para la función) y la relación entre el prototipo mágico y esto, pero después de comprender el principio, Estos obstáculos son bastante obvios. Además, hay muchas buenas aplicaciones y marcos desarrollados con JavaScript, y la idea de programación asincrónica también es muy buena (por supuesto, cualquier lenguaje puede admitir cosas como ideas).

"Basura de basura" es demasiado parcial.

Tengo pocos conocimientos de Go/Scala/Clojure y no puedo comentar.

Entonces déjame hablar de lo que no me gusta de Java: es largo y la función no es un objeto.

1. Recuerdo vagamente que cuando estaba escribiendo varios objetos de acceso a datos, había varios Getters/Setters en ellos. Aunque los Getters y Setters se pueden generar automáticamente usando el IDE, todavía es... muy difícil de leer/mantener.

2. Solía ​​escribir programas de Android y agregar EventListener. De hecho, es solo una función, pero solo se puede realizar a través de una clase anónima y definir la función en su interior: agregue un EventListener y sangra en 2 niveles. Haz que el código sea feo.

(En Java8, Lambda es compatible, lo cual debería aliviarse un poco; todavía no lo tengo muy claro)