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

14

He visto algunos idiomas que cambian rápidamente (me refiero a que se mejoran todos los años, por ejemplo) y otros que mejoran lentamente.

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

    
pregunta Simon Smith 21.10.2011 - 02:46
fuente

8 respuestas

16
  

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

Bien

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

malo

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

¿A los programadores les gusta aprender algo nuevo en el lenguaje o prefieren quedarse con lo que ya saben?

Muchos programadores disfrutan satisfaciendo su curiosidad jugando con las nuevas funciones. Sin embargo, esto no significa que las nuevas características sean siempre 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 la actualización en la situación específica de cada uno.

Podría divertirme o disfrutar aprendiendo sobre nuevas funciones, 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 para tener un soporte y estabilidad razonables, pero no tan antiguo que no pueda ser razonablemente productivo.

    
respondido por el Doug T. 21.10.2011 - 03:08
fuente
11

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

C # hace esto muy bien. Añaden expresiones lamdba de cosas, mejor soporte para multiprocesamiento, linq, ... Pero su programa C # 2.0 de cinco años seguirá funcionando bien sin necesidad de cambios y se puede actualizar fácilmente a C # 4.0 sin necesidad de cambios.

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 de aprendizaje significa ahorrar sus horas en tiempo de desarrollo, vale la pena.

    
respondido por el Carra 21.10.2011 - 09:33
fuente
5

Quiero mejoras regulares, pero no quiero que se rompa un código base de 500 kloc & desencadenar un "proyecto de actualización" masivo solo para hacer que el código funcione como lo hace con la versión anterior.

    
respondido por el mcottle 21.10.2011 - 03:07
fuente
4

La estabilidad del idioma es una necesidad para los negocios y para los desarrolladores. Los cambios en el idioma son bienvenidos si solucionan problemas o introducen funciones que se perdieron en versiones anteriores, pero cambiar de idioma para que sea moderno o simplemente porque quiere ponerse al día con un competidor no es tan bueno.

Cuando el idioma es estable, con el tiempo, los desarrolladores dejan de concentrar sus esfuerzos en aprender el idioma porque lo habrían dominado y comenzarían a centrar sus esfuerzos en servir a la empresa con lo que saben. ¡El resultado es un proyecto más corto, usuarios finales felices y más desarrolladores 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 características. Esto agrega una carga significativa para que los desarrolladores se entrenen a sí mismos o no. ¡Esto no es trivial, los cursos especializados pueden ser de $ 1500- $ 3500 cada uno!

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

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

    
respondido por el NoChance 21.10.2011 - 06:00
fuente
2

No creo que haya una sola respuesta que sea correcta.

En términos generales, cuando un idioma es relativamente joven, hay mucha más libertad para hacer 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 idioma envejece, asumiendo que es lo suficientemente amplio como para que a cualquiera le importe, la base del código existente comienza a imponer restricciones cada vez más estrictas sobre los cambios que se pueden hacer. No solo hay más códigos que utilizan más funciones, por lo que es más difícil adivinar qué cambios podrían romper el código, sino también las expectativas de las personas.

Por ejemplo, supongamos que hay aproximadamente la misma cantidad de personas que escriben Ruby y Fortran. Además, supongamos que había aproximadamente la misma cantidad de código en ambos. Yo diría que hay muchas posibilidades de que un cambio que rompa exactamente el mismo porcentaje de cada uno (y de una manera que haya tenido que corregir el mismo trabajo) sea un lote más aceptable para los usuarios de Ruby que los usuarios de Fortran como regla general (al menos suponiendo que lo vieran como una mejora).

Creo que mucho también depende de la percepción que las personas tienen del lenguaje para comenzar. Las personas que eligen un idioma porque es "de vanguardia" tienen muchas más probabilidades de soportar cambios importantes que rompen muchos códigos existentes, si eso es lo que se necesita para mantener en el filo de corte.

Otro factor es el tamaño y la esperanza de vida de los proyectos para los cuales está destinado el idioma. Un lenguaje que se adapta a proyectos relativamente pequeños o que sabemos que tienen una vida útil corta (p. Ej., Una interfaz de usuario web) puede salirse con la suya con relativa frecuencia, ya que es poco probable que muchas personas sigan usando el mismo código base. Por, digamos, 10 años como sea. Un lenguaje (p. Ej., C ++ o Java) que se adapte más a proyectos más grandes y de mayor duración que pueden tardar, digamos, 5 años en llegar a una versión inicial, puede estar en uso regular (y desarrollo continuo) durante tres o cuatro décadas que obviamente exigen Un excelente ofrece más estabilidad.

    
respondido por el Jerry Coffin 21.10.2011 - 06:57
fuente
2

Un hombre me dijo que le gusta su C ++ y seguirá siéndolo. No le importa o no tiene interés en D, no quiere saber ni usar C #. Aprendió java porque TENÍA que hacerlo para los muchos proyectos que necesitaba hacer y aparentemente hace un buen trabajo en los idiomas que conoce

Otro ama C # y no conoce todas las palabras clave o conoce las bibliotecas .NET 4 (async y todas) y no ha usado las palabras clave abstractas o los atributos utilizados.

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

Ahora, los efectos de la actualización son importantes (para librerías o código compilado) a las personas les importarán.

    
respondido por el user2528 21.10.2011 - 09:43
fuente
0

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

Este cambio de función causa algunos problemas cuando te aproximas al "estilo" de un idioma:

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

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

Diferentes tipos de verificación de estilos

  • Escritura dinámica
  • Escritura estática

No siempre está claro cuándo desea utilizar uno u otro.

    
respondido por el volothamp 21.10.2011 - 12:21
fuente
0

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

    
respondido por el Jetti 21.10.2011 - 15:01
fuente

Lea otras preguntas en las etiquetas