Actualmente trabajo en una gran aplicación de Django, y en mi trabajo anterior trabajé en un gran proyecto de Java (aplicación de escritorio, no en la web, pero aún apropiado para esta discusión), y estoy medio dividido entre estar de acuerdo y en desacuerdo con el autor.
Mientras disfruto de Python en Java, y tengo amplia experiencia trabajando con otros lenguajes de tipado dinámico como Ruby y Objective-C, todavía no estoy convencido de cuál es mejor (estático frente a dinámico). A veces, en Python-land, creo que sería mejor tener tipos estáticos y un compilador para evitar algunos errores; No me gusta el modelo tipo Java, pero Scala tiene un sistema de tipo decente que no interfiere pero evita muchos errores.
Dicho esto, creo que los éxitos/fracasos del uso de Python o Java tienen más que ver con la experiencia y los antecedentes de un equipo. Siento que este artículo debería estar mejor titulado "Extraerse de Java me pone nervioso", ya que el autor parece estar diciendo principalmente: "Tengo experiencia con Java. No entiendo/tengo experiencia con Python. más cómodo escribiendo código Java ". Creo que los desarrolladores experimentados de Python aprenden a trabajar con/alrededor de la mayoría de los "problemas" que percibe; Python no es Java y requiere un enfoque diferente para la programación.
también tuve que reír en esta línea un poco:
Java tiene un bien pensado jerarquía de excepciones comprobadas y tiempo de ejecución.
creo que la mayoría estaría de acuerdo en que la jerarquía de excepciones de Java es confuso en el mejor, y que comprueba excepciones fueron un experimento que vale la pena, pero no que en realidad no hacer el código más robusto (supongo que hacen si se utiliza correctamente, pero ¿cuántos programadores de Java usan las excepciones propiamente como?).
Parece que lo está haciendo mal. Por lo menos, incluso si el código que ha encontrado no se hace de esta manera, no hay nada que impida que un equipo de programadores documente correctamente su código (utilizando documentos, etc.) de manera que la documentación le diga lo que no dice el código en sí mismo debido a la falta de tipeo estático. Y dado que Python es un lenguaje interpretado y, a menudo, se ejecuta desde un intérprete, obtener la documentación de un método es tan simple como importar el método y escribir 'help ([method_name])'. (El problema sería conseguir que documenten su código correctamente, supongo). – JAB
el autor del post no está acostumbrado al estilo de trabajo pythonic. él no menciona doc-strings. Leería doc-strings. Leería la documentación. Esperaría que un equipo que trabaja en una biblioteca de Python documente todo, o construya algo que pueda descifrar cómo usarlo, sin leer todo su código. Lo primero que vería, cuando empiece a usar una biblioteca, no son las firmas de función, son los casos de prueba y la aplicación principal "main.py" que contiene el código de inicio y apagado. –
Como regla general, trato de no preocuparme por los problemas planteados por los bloggers que no pueden expresarse sin blasfemias. Piense en ello como un "olor a argumento". –