Si un idioma cambia rápidamente, ¿se considera algo bueno?

He visto algunos idiomas que cambian rápidamente (quiero decir que se mejoran cada año, por ejemplo) y otros que se mejoran lentamente.

Mi pregunta, si un idioma cambia rápidamente, ¿es esto algo bueno o malo para el programador? ¿A los programadores les gusta aprender cosas nuevas en el idioma o prefieren seguir con lo que ya saben?

Si un idioma cambia rápidamente, ¿es bueno o malo para el programador?

Bueno

• Los cambios podrían agregar un poco de azúcar sintáctico agradable haciendo que el código futuro sea más fácil de escribir con menos errores
• Los cambios pueden estandarizar un patrón de diseño / idioma común que los programadores han tenido que implementar o confiar en terceros.
• Los cambios pueden facilitar la integración con tecnologías con las que normalmente se usa el lenguaje
• Los cambios pueden ayudar a prevenir errores comunes
• Los cambios pueden desaprobar o eliminar prácticas de programación peligrosas
• Los cambios pueden tener adiciones útiles a la biblioteca estándar del idioma para cosas que solía tener que implementar o confiar en terceros.

Malo

• El lenguaje ha agregado complejidad: las nuevas características pueden no siempre jugar bien con las características heredadas (es decir, la relación de C ++ con C)
• El código heredado puede estar desactualizado y dejar de funcionar en la nueva versión del lenguaje sin actualizaciones (Python 2.x -> 3.x)
• Los compiladores y otras herramientas para el idioma deben actualizarse. Ahora existen versiones potencialmente múltiples.
• Es posible que las bibliotecas de terceros no admitan la versión más reciente del idioma.
• A pesar de la existencia de un estándar, puede llevar tiempo encontrar una forma estándar / normal de implementar nuevas características y definir algunos de los casos más oscuros de su comportamiento.

¿A los programadores les gusta aprender cosas nuevas en el idioma o prefieren seguir con lo que ya saben?

Muchos programadores disfrutan de satisfacer su curiosidad jugando con las nuevas funciones. Sin embargo, esto no significa que las nuevas características siempre sean apropiadas en el código de producción. Esta es una decisión caso por caso que tiene que sopesar los beneficios de las nuevas características frente al costo de actualización en una situación específica.

Podría divertirme o disfrutar aprendiendo sobre nuevas características, pero al final del día lo que realmente me importa es entregar un producto útil a alguien. Tengo que elegir el conjunto de herramientas que será lo suficientemente moderno como para tener un soporte razonable y estabilidad, pero no tan antiguo que no pueda ser razonablemente productivo.

Las mejoras son geniales ... si son compatibles con versiones anteriores .

C # hace esto muy bien. Añaden expresiones de lamdba, mejor soporte para subprocesos múltiples, linq, ... Pero su programa C # 2.0 de cinco años seguirá funcionando bien sin necesidad de ningún cambio y puede actualizarse fácilmente a C # 4.0 sin necesidad de ningún cambio.

Aprender cosas nuevas es genial si te permite hacer tus tareas de una manera más fácil y rápida. Si pasar una hora aprendiendo significa ahorrar sus horas en tiempo de desarrollo, vale la pena.

Quiero mejoras regulares, pero no quiero que rompa una base de código de 500 kloc y desencadene un "proyecto de actualización" masivo solo para que el código funcione de la misma manera que con la versión anterior.

La estabilidad del lenguaje es imprescindible para las empresas y los desarrolladores. Los cambios en el idioma son bienvenidos si resuelven problemas o introducen características que se perdieron en versiones anteriores, pero cambiar los idiomas para que esté de moda o simplemente porque desea ponerse al día con un competidor no es tan bueno.

Cuando el lenguaje es estable, con el tiempo, los desarrolladores dejan de enfocar sus esfuerzos en aprender el idioma porque lo habrían dominado y comienzan a enfocar sus esfuerzos en servir al negocio con lo que saben. ¡El resultado es un proyecto más corto, usuarios finales felices y desarrolladores más orgullosos!

El cambio también viene con el costo y el tiempo de aprendizaje. No todos los empleadores están dispuestos a educar a los desarrolladores en nuevas funciones. Esto agrega una carga significativa a los desarrolladores para capacitarse a sí mismos o de lo contrario: ¡Esto no es trivial, los cursos especializados pueden costar $ 1500- $ 3500 cada uno!

El cambio continuo puede bloquear a los desarrolladores en el software 'heredado'. Tomemos el caso del desarrollador ASP que no capturó MVVM en 2 años a partir de ahora o el caso de un desarrollador de Windows Forms que no aprendió WPF. Este bloqueo puede dañar significativamente la carrera de desarrollador.

En horas extras, la arquitectura del software en un negocio se parece a una ensalada de jardín. Todo tipo de herramientas y versiones y encontrará proyectos que comienzan a hacer nada más que actualizar el software de una versión a la siguiente sin ningún beneficio comercial.

No creo que haya una respuesta correcta.

En términos generales, cuando un idioma es relativamente joven, hay mucha más libertad para realizar cambios relativamente grandes con relativa rapidez. No hay una gran base de código existente para romper, por lo que las personas generalmente están mucho más abiertas a la experimentación.

A medida que el lenguaje envejece, suponiendo que se convierta en un usuario lo suficientemente amplio como para que a alguien realmente le importe, la base del código existente comienza a imponer restricciones cada vez más estrictas sobre los cambios que se pueden realizar. No solo hay más código haciendo uso de más funciones, por lo que es más difícil adivinar qué cambios podrían romper el código, sino que también cambian las expectativas de las personas.

Solo por ejemplo, supongamos que había aproximadamente la misma cantidad de personas escribiendo Ruby y Fortran. Además, supongamos que había aproximadamente la misma cantidad de código en ambos. Diría que las posibilidades son bastante buenas de que un cambio que rompió exactamente el mismo porcentaje de cada uno (y de una manera que requirió el mismo trabajo para corregir) sería mucho más aceptable para los usuarios de Ruby que los usuarios de Fortran como regla general. (al menos suponiendo que lo vieron como una mejora).

Creo que mucho también depende de la percepción que las personas tienen del idioma para comenzar. Las personas que eligen un idioma porque es "vanguardista" tienen muchas más probabilidades de soportar cambios importantes que rompen una gran cantidad de código existente, si eso es lo que se necesita para mantenerlo a la vanguardia.

Otro factor es el tamaño y la esperanza de vida de los proyectos para los que está destinado el idioma. Un lenguaje que atiende a proyectos relativamente pequeños o que conocemos por adelantado tiene una esperanza de vida corta (por ejemplo, una interfaz de usuario web) puede salirse con la suya con relativa frecuencia, porque es poco probable que muchas personas continúen usando la misma base de código por, digamos, 10 años de cualquier manera. Un lenguaje (por ejemplo, C ++ o Java) que atiende más a proyectos más grandes y de mayor duración que pueden tomar, por ejemplo, 5 años para llegar a una versión inicial, puede estar en uso regular (y desarrollo continuo) durante tres o cuatro décadas, obviamente, demanda una gran estabilidad mucho más.

Un tipo me dijo que le gustaba su C ++ y que seguirá así. No le importa ni tiene interés en D, no quiere saber ni usar C #. Aprendió Java porque TENÍA que hacerlo por los muchos proyectos que necesitaba hacer y aparentemente hace un buen trabajo en los idiomas que conoce

Otro ama a C # y no conoce cada palabra clave ni conoce las bibliotecas .NET 4 (asíncrona y todas) y no ha usado las palabras clave abstractas o los atributos usados.

Simplemente digo que a la mayoría de las personas NO les importa

Ahora, los efectos de la actualización se están rompiendo (para libs o código compilado) A las personas les importará.

Contestaré por C # (pero este análisis también puede aplicarse a Scala):

Este cambio de características causa algunos problemas cuando se acerca al "estilo" de un idioma:

En 2011, C # puede hacer muchas cosas diferentes, y esto es bueno. Lamentablemente tiene dos paradigmas diferentes (si no más):

• OOP
• Funcional (piense en las funciones lambda y LINQ)

Diferentes estilos de comprobación de tipos

• Typing Dinámico
• Mecanografía Estática

No siempre está claro cuándo quieres usar uno u otro.

Creo que realmente depende del idioma y de lo siguiente que tenga el idioma. Por ejemplo, creo que si C # y Java comenzaran a aparecer cambios a un ritmo más rápido de lo que sería aceptado (siempre y cuando sean compatibles con versiones anteriores, como dijo Carra ). Sin embargo, si el idioma aún no ha ganado tracción y todavía está cambiando rápidamente, sé que no me molestaría, ya que existe la posibilidad de que lo que intento aprender hoy sea totalmente diferente de lo que sale en 6 meses y Como el lenguaje es nuevo / impopular, no sería perjudicial para mí (léase: mi carrera) que lo transmita.