Problemas (como mantenimiento) en desarrollo con lenguaje impopular

31

Estoy desarrollando alguna aplicación con clojure (lisp) solo en mi equipo. Comienza como una pequeña aplicación. No hay problema. Pero como tiene características y extiende el área, se está convirtiendo en un programa importante.

Me preocupaba el mantenimiento o algo así. Nadie en mi equipo sabe clojure o lisp ni está interesado en idiomas como ellos.

Entonces, ¿no está mal hacer programación en lenguajes impopulares? (¿para mi propia diversión?) ¿Debería usar idiomas más populares? (al menos como python)

Estoy seguro de que si dejo el equipo, no digo que me vaya. :) - nadie lo mantendría. Este programa será destruido y algunos se desarrollarán con otro lenguaje.

Sin embargo, estoy disfrutando mucho desarrollando con clojure, me di cuenta de que podría no ser para mi equipo.

¿Qué piensas sobre esto? Creo que muchos programadores que aman los lenguajes impopulares se han preocupado por problemas similares.

Híbrido
fuente
2
¿No tiene estándares de programación locales con respecto al uso de lenguajes para el desarrollo local?
temptar
No, no hay tales estándares. Le acabo de decir a mi jefe y fue aceptado sin ningún comentario. Creo que mi jefe simplemente respetó y permitió mi decisión.
Híbrido
12
"Impopular" no es el gran problema. "Sin soporte" es mucho peor. Por ejemplo, Lisp le gana a VB 6.0.
MSalters
1
Si la aplicación es tan importante, lo reemplazarán con alguien que sepa lo que está haciendo. El hecho de que su equipo actual sea limitado no significa que no puedan encontrar a nadie que conozca este idioma.
JeffO

Respuestas:

22

Siento tu dolor, me encantaría hacer más codificación en programación funcional (¡Haskell se ve tan divertido!). Siento que acabo de arañar la superficie porque todavía tengo que usarlo en un contexto comercial.

Sin embargo, recomendaría encarecidamente no hacerlo . Si programa en un idioma que solo usted conoce, solo podrá apoyarlo. A menos que desee tener que lidiar con todos los problemas de soporte (incluso cuando tenga otros plazos / prioridades), codifique en un idioma que su equipo conozca y pueda brindar soporte. ¿Qué sucede cuando algo se rompe mientras estás de vacaciones? ¿Qué pasa si quieres ser promovido?

Le recomendaría que tenga al menos otro miembro del equipo a bordo con usted. Muéstrales algunas características geniales del lenguaje. Con dos personas a bordo se vuelve viable y no se le cargará con todo el soporte.

Tom Squires
fuente
8
Tengo que estar en desacuerdo. Si un idioma diferente es la herramienta adecuada para el trabajo, úselo. Gran parte de la complejidad incidental en el desarrollo de software moderno proviene de los programadores que obligan a que toda su aplicación se adapte a un idioma. Si su idioma tiene poca concurrencia, por ejemplo, entonces podría ser bastante apropiado usar otro idioma para manejar el paso de mensajes.
Quanticle
@quanticle OP dice "Entonces, ¿no está mal hacer programación en lenguajes impopulares? (¿para mi propia diversión?"). Si hay un caso sólido para usar otro idioma, como la concurrencia, acepto que valdría la pena los problemas de soporte.
Tom Squires
1
@quanticle: lo contrario es cierto: demasiados idiomas (es decir, más de uno) conducen a la redundancia, esfuerzos duplicados y la reinvención innecesaria de la rueda.
ThomasX
Correcto, el apoyo es definitivamente importante. Me encanta su sugerencia de que otro miembro del equipo se una a bordo. Pensaré profundamente en cosas así.
Híbrido
17

Estoy seguro de que si dejo el equipo, no digo que me vaya. :) - nadie lo mantendría.

Posiblemente falso.

Si el programa tiene valor y la gerencia lo ve, le encargarán a alguien aprender Clojure y mantenerlo.

Pasa todo el tiempo.

Este programa será destruido y algunos se desarrollarán con otro lenguaje.

Siempre cierto. Entonces, ¿por qué preocuparse por eso?

Todos los programas deben eventualmente ser reemplazados.

S.Lott
fuente
Dado que Clojure se ejecuta en cualquiera de JVM, CLR o javascript, incluso si ninguno de los compañeros de trabajo de Hybrid quiere usar clojure, debería ser posible una traducción (probablemente fea) de la fuente en un lenguaje convencional. En los primeros casos al reflexionar sobre el bytecode / msil, en el segundo capturando los js que se emiten directamente.
Dan Neely
2
@DanNeely: ¿cree que una ruta de mantenimiento válida está compilando Clojure a IL a través de un proyecto homebrew (muy bueno) y luego descompilando ese código en C #? No estoy totalmente convencido de que sea más fácil que pedirle a alguien que aprenda el idioma.
@TheMouthofaCow sospecho, especialmente para una aplicación más grande, aprender Clojure sería más fácil; pero el enfoque del gran martillo permitiría que los programadores monolíticos obstinados hagan modificaciones sin requerir una reescritura completa. Eventualmente, refactorizar para eliminar el reflejo cruft probablemente resultaría en una reescritura de facto; pero distribuya el costo en varias modificaciones en lugar de exigir que se haga todo antes de agregar la primera nueva característica.
Dan Neely
Gracias. Es un gran apoyo en mi mente. Al superar esta situación de alguna manera, podría tener en mente esos pensamientos optimistas también.
Híbrido
1
" Todos los programas deben ser reemplazados " . Oh, eso sería cierto. Hay una gran cantidad de código COBOL en ejecución que se volvió a escribir cuando el almacenamiento en disco era terriblemente costoso, y que fue parcheado para sobrevivir a Y2K (¿recuerda Y2K?), Y eso todavía se está ejecutando. De hecho, la mayoría de los programas mueren jóvenes por desuso o viven esencialmente para siempre. Entonces, la elección de la tecnología es realmente muy importante. Porque su descendencia puede estar manteniendo estos programas.
Ross Patterson
10

Estoy exactamente en el lugar en el que imagina que está su sucesor. Me encargaron agregar funciones a un programa heredado que usaba Clojure y Erlang para realizar búsquedas asincrónicas y convertirlas en un programa que realiza búsquedas asincrónicas distribuidas. Cuando llegué a este trabajo, todo lo que sabía era Python y Java.

Mi consejo para ti: usa la mejor herramienta para el trabajo . Si esa herramienta es Clojure, que así sea. Los lenguajes de programación no son tan difíciles de aprender. El código bien escrito en un idioma apropiado para la tarea en cuestión siempre es más fácil de leer que el código que intenta hacer algo para lo que el lenguaje no fue diseñado. Será más fácil para su sucesor leer Clojure limpio que Java destrozado.

cuantícula
fuente
5

Adoptar nuevos idiomas o lenguaje " independiente " por alguna tarea es un alto riesgo en un proyecto.

Si esa parte del sistema tiene un problema o esa parte debe ser descartada, debe encontrar un programador que debe aprender las habilidades sobre ese idioma. En ambos casos perdiste mucho tiempo.

En algunos casos, este problema se puede utilizar para mejorar y diversificar las habilidades de un equipo por tareas futuras.

Espíritu
fuente
Estoy de acuerdo, aunque una de las ventajas que se está desarrollando en clojure está afectando a mi equipo de alguna manera. También estoy de acuerdo en que este es un alto riesgo. Debería tener cuidado. Gracias.
Híbrido
4

Clojure podría tener una pequeña base instalada en la actualidad (apareció en 2007) pero no es impopular, de hecho es posiblemente el nuevo lenguaje "más popular". Me sorprendería si no pudieras encontrar a otras personas interesadas en aprenderlo.

De todos modos, si adoptar un nuevo lenguaje siempre debe ser una decisión basada en el valor para el negocio . Puede hablar con su gerente en las siguientes líneas:

Ventajas de adoptar Clojure:

  • Más productivo que otros idiomas utilizados, como lo demuestra la cantidad de funcionalidades útiles que ha brindado en poco tiempo y con menos líneas de código.
  • Ya tenemos una aplicación importante (la suya) escrita en Clojure, por lo que vale la pena desarrollar habilidades de Clojure para mantenerla (en lugar de hacer una reescritura costosa)
  • El uso de Clojure se considerará innovador y puede ser una buena forma de motivar a los desarrolladores talentosos a unirse / permanecer en la empresa.

Desventajas de adoptar Clojure

  • Un idioma adicional para apoyar
  • Los desarrolladores pueden necesitar más capacitación y tiempo para ponerse al día

Si yo fuera un gerente que evaluara esta decisión, probablemente me gustaría la idea de una mayor productividad de Clojure lo suficiente como para permitir algunos experimentos limitados, y diferir la decisión hasta que quede claro qué tan bien el equipo lo estaba tomando. En ese caso, probablemente necesite ser un defensor, actuar como un buen maestro y ayudar a atraer a los demás.

mikera
fuente
3

No te preocupes, se feliz.

Claramente, el programa tiene valor, o no lo extenderías. Felicitaciones por un proyecto exitoso. Presumiblemente, eligió Clojure porque hacerlo le ahorró tiempo y, por lo tanto, le ahorró dinero a su empleador. Si lo hubiera escrito en Java, el programa sería, por lo tanto, aún más difícil de mantener. Incluso si sus colegas pudieran entender más fácilmente el programa línea por línea, ¿podrían mantenerlo y extenderlo?

Kevin Cline
fuente
2

¡Te diría más poder! Lisp es el abuelo de los lenguajes informáticos y sigue siendo relevante hoy en día; El hecho de que no sea tan popular, creo que se debe al hecho de que no tiene los IDE cálidos y esponjosos de C # y Java, y la implementación del compilador principal en Windows solo se ejecuta bajo Cygwin (¡yuk!). El desarrollo parece tener lugar en Emacs y supongo que funciona mejor con Linux o Mac.

Esta competencia de codificación fue ganada por un programa Lisp en 2010: http://planetwars.aichallenge.org/

En el pasado, podían depurarlo en vivo desde aproximadamente 100 millones de millas: http://www.flownet.com/gat/jpl-lisp.html

Definitivamente está renunciando a una bandera roja de mantenimiento, pero piense que es una oportunidad de aprendizaje para otra persona. Si estaba usando un lenguaje de pesadilla (como MUMPS) o un lenguaje tedioso (como TCL), entonces creo que deberían hacerse preguntas. Pero creo que debería ser considerado como un tipo que intenta mantener la mejor de las viejas tradiciones :)


fuente
Tcl es un lenguaje agradable, no lo llamaría tedioso. Solo mira Tkinter (en Python) para ver que es una buena herramienta para saber.
Francesco
@Francesco - Debo señalar que dije Tcl no Tcl / Tk. El conjunto de herramientas gráficas podría ser excelente. Dije que Tcl era aburrido porque fui a una entrevista de trabajo hace unos años en un lugar que solo usa Tcl (aceptan programadores junior y luego les enseñan un lenguaje muy poco comercial para que sea difícil dejarlo) y rechacé el trabajo porque Tcl parecía tedioso. No digo que no sea funcional (podría serlo). Solo pensé que terminaría mordiéndome los brazos si tuviera que escribir Tcl durante más de un par de días. Estoy de acuerdo con eso.
2

Hay muchas buenas respuestas, pero me gustaría agregar un punto.

He estado en una situación similar pero con un idioma diferente. Tuve que aprender todo de la manera difícil, es decir, a través del método de prueba y error debido a la falta de orientación. Lo que aprendí de mi experiencia al señalar el mantenimiento / extensibilidad se convertiría en un problema, ya que uno podría no conocer enfoques efectivos debido a la falta de orientación.

Le sugiero que hable con su gerente para obtener la ayuda adecuada para que pueda evitar cualquier problema en el futuro.

¡Buena suerte!

Karthik Sreenivasan
fuente
2

En algunos casos, un lenguaje como Lisp puede acelerar o facilitar la implementación de la funcionalidad que sería muy difícil en un idioma diferente. También influye en la forma en que ves los problemas, dándote una perspectiva que otros miembros de tu equipo pueden no tener. Tener una gama más amplia de capacidades y una visión más amplia de lo que es posible puede ser muy valioso para una empresa que puede comprenderlas y utilizarlas. Sin embargo, el precio de esas capacidades es una falta de estandarización.

Muchas empresas intentan estandarizar en uno o dos idiomas porque les da más flexibilidad organizativa: pueden mover a los desarrolladores de un proyecto a otro sin tener que volver a capacitarlos, tienen una reserva incorporada de conocimiento sobre los idiomas que utilizan, y los gerentes no tienen que considerar las fortalezas y debilidades de usar un idioma u otro para un proyecto determinado. Cuando todo lo que tienes es un martillo, todo parece un clavo.

Como he señalado, ambos enfoques tienen ciertos beneficios y desventajas. Como suele ser el caso, no hay un enfoque correcto o incorrecto. Solo está intercambiando un conjunto de beneficios y desventajas por otro. Una empresa tampoco tiene que ir completamente en una dirección u otra. Es perfectamente razonable hacer la mayoría del trabajo en C ++ o Java, pero sumerge un dedo en Lisp o Python de vez en cuando para probarlos y ver qué funciona. Parece que eso podría ser lo que está haciendo su empresa.

Así que adelante (pero no Forth), aprenda todo lo que pueda y conviértase en el experto de Clojure en el que su gerente puede confiar para obtener información que sus colegas podrían no tener. Y no se sienta mal por eso ... preocuparse por las cosas organizativas es el trabajo de sus gerentes.

Caleb
fuente
1

Recomendaría comenzar a reescribir su programa en un idioma diferente (más conveniente) cuando empiece a sentir que el mantenimiento tiene grandes posibilidades de ser un problema dominante.

Si lograste escribirlo en forma cerrada (lo cual no sabías cuando comenzaste a crear tu aplicación, tal como lo entendí), entonces no será problema reescribirlo usando un lenguaje más familiar / conveniente. El cierre utiliza conceptos completamente diferentes y, por lo tanto, la implementación puede ser difícil de transferir a otro idioma. Pero la cuestión es que si te diviertes escribiendo una nueva aplicación para cerrar, entonces puede que te resulte interesante transferir conceptos e ideas que usaste a otro lenguaje conveniente. Puede ser divertido comparar diferentes idiomas y sus capacidades. Creo que su caso es perfecto para tales experimentos.

altern
fuente
Hago esto bastante. Escribiré lo que parece una utilidad de una sola vez en Perl o Erlang, luego se usa con la frecuencia suficiente como para que se convierta en una utilidad, así que la reescribo usando el idioma principal del proyecto (Java o C #).
TMN
1

Ciertamente no está mal hacer programación en lenguajes "impopulares". ¿Por qué realmente te importa si son populares o no? Estoy totalmente de acuerdo con @quanticle en esto. Si Clojure u otro lenguaje no convencional es la mejor herramienta para el problema que está resolviendo, debe elegirlo.

No veo por qué el mantenimiento será un problema. Si aplica Unit, Integration, etc. Prueba y documenta su código, cualquier programador con interés en programación funcional podrá mantener su programa. En mi humilde opinión, el hecho de que sus colegas no se preocupen por Clojure no es un buen argumento para no usarlo, excepto si es una política de la empresa que debe respetar.

sakisk
fuente
0

El hecho de que el programa continúe o no después de su partida no le preocupa en mi opinión. Puedes usar el lenguaje de programación para hacer algo que le guste a tu jefe, me parece bastante bueno. Preocuparse por la continuación es algo que su jefe debería hacer.

Paul Hiemstra
fuente
3
El trabajo de su jefe es preocuparse por la continuación. Pero es su trabajo asegurarse de que el jefe esté al tanto de los problemas por los que deben preocuparse. Deberías hablarlo con el jefe.
MarkJ
Estoy de acuerdo, aunque el OP no debería preocuparse si el jefe decide no hacer nada.
Paul Hiemstra
0

Organiza un tutorial o una sesión de entrenamiento. Si los miembros de su equipo no quieren actuar como profesionales y aumentar su conocimiento, especialmente si el programa se está volviendo más importante, está fuera de su alcance. En el peor de los casos, puede hablar con la gerencia y ellos tal vez puedan exigir este tipo de sesión de capacitación. Puede parecer un imbécil, pero al menos no será el único que debe mantener el programa. La otra opción es sugerir que se agregue al equipo un segundo programador que conozca clojure.

Rudolf Olah
fuente