Problèmes (tels que la maintenance) dans le développement avec un langage impopulaire

Je développe une application avec clojure (lisp) seule dans mon équipe. Cela commence comme une petite application. Aucun problème. Mais comme il a des fonctionnalités et étend la zone, il devient un programme important.

Je m'inquiétais pour l'entretien ou quelque chose. Personne dans mon équipe ne connaît le clojure ou le lisp et n'est intéressé par des langues comme celles-ci.

Alors, n'est-ce pas mal de faire de la programmation dans des langages impopulaires? (pour mon plaisir?) Dois-je utiliser des langues plus populaires? (au moins comme python)

Je suis sûr que si je quitte l'équipe, - je ne dis pas que je pars. :) - personne ne le maintiendrait. Ce programme sera détruit et certains se développeront avec une autre langue.

J'aime beaucoup développer avec clojure, je suis tombé sur le fait que ce n'était peut-être pas pour mon équipe.

Que pensez-vous de ceci? Je pense que de nombreux programmeurs qui aiment les langages impopulaires ont été confrontés à un problème similaire.

Je ressens votre douleur, j'aimerais faire plus de codage en programmation fonctionnelle (Haskell a l'air si amusant!). J'ai l'impression que je viens de gratter la surface car je ne l'ai pas encore utilisé dans un contexte commercial.

Je recommanderais fortement de ne pas le faire . Si vous programmez dans une langue que vous seul connaissez, vous seul pourrez la prendre en charge. À moins que vous ne vouliez avoir à gérer tous les problèmes de support (même lorsque vous avez d'autres délais / priorités), codez dans une langue que votre équipe connaît et peut prendre en charge. Que se passe-t-il lorsque quelque chose se casse pendant vos vacances? Que se passe-t-il si vous souhaitez être promu?

Je vous recommanderais d'embarquer au moins un autre membre de l'équipe avec vous. Montrez-leur quelques fonctionnalités linguistiques intéressantes. Avec deux personnes à bord, cela devient réalisable et vous ne serez pas chargé de tout le soutien.

Je suis sûr que si je quitte l'équipe, - je ne dis pas que je pars. :) - personne ne le maintiendrait.

Peut-être faux.

Si le programme a de la valeur et que la direction en voit la valeur, elle chargera quelqu'un d'apprendre Clojure et de le maintenir.

Arrive tout le temps.

Ce programme sera détruit et certains se développeront avec une autre langue.

Toujours vrai. Alors pourquoi s'en inquiéter?

Tous les programmes doivent finalement être remplacés.

Je suis exactement à l'endroit où vous envisagez que votre successeur soit. J'ai été chargé d'ajouter des fonctionnalités à un programme hérité qui utilisait Clojure et Erlang pour effectuer une recherche asynchrone et le transformer en un programme qui effectue une recherche asynchrone distribuée. Quand je suis entré dans ce métier, je ne connaissais que Python et Java.

Mon conseil: utilisez le meilleur outil pour le travail . Si cet outil est Clojure, qu'il en soit ainsi. Les langages de programmation ne sont pas si difficiles à apprendre. Un code bien écrit dans un langage approprié à la tâche à accomplir est toujours plus facile à lire qu'un code qui tente de faire quelque chose que le langage n'a pas été conçu pour faire. Il sera plus facile pour votre successeur de lire Clojure propre que Java mutilé.

L'adoption de nouvelles langues ou d'une langue " autonome " par une tâche est un risque élevé dans un projet.

Si cette partie du système a un problème ou si cette partie doit être supprimée, vous devez trouver un programmeur qui doit apprendre les compétences de cette langue. Dans les deux cas, vous avez perdu beaucoup de temps.

Dans certains cas, ce problème peut être utilisé pour améliorer et diversifier les compétences d'une équipe par tâche future.

Clojure a peut-être une petite base installée à l'heure actuelle (il est apparu en 2007) mais ce n'est guère impopulaire - en fait, c'est peut-être la nouvelle langue "la plus chaude". Je serais surpris si vous ne pouviez pas trouver d'autres personnes intéressées à l'apprendre.

Quoi qu'il en soit, l'opportunité d'adopter une nouvelle langue devrait toujours être une décision basée sur la valeur pour l'entreprise . Vous pouvez discuter avec votre responsable de la manière suivante:

Avantages de l'adoption de Clojure:

• Plus productif que les autres langages utilisés - comme en témoigne la quantité de fonctionnalités utiles que vous avez livrées en peu de temps et avec moins de lignes de code
• Nous avons déjà une application importante (la vôtre) écrite en Clojure, il vaut donc la peine de développer des compétences Clojure pour la maintenir (plutôt que de faire une réécriture coûteuse)
• L'utilisation de Clojure sera considérée comme innovante et peut être un bon moyen de motiver des développeurs talentueux à rejoindre / rester dans l'entreprise.

Inconvénients de l'adoption de Clojure

• Une langue supplémentaire à prendre en charge
• Les développeurs peuvent avoir besoin de plus de formation et de temps pour se mettre à jour

Si j'étais un gestionnaire évaluant cette décision, j'aimerais probablement l'idée d'une productivité plus élevée de Clojure suffisamment pour permettre des expériences limitées, et reporter la décision jusqu'à ce qu'il soit clair à quel point l'équipe s'y prenait. Dans ce cas, vous devrez probablement être un défenseur, agir comme un bon enseignant et aider à faire participer les autres.

Ne vous inquiétez pas, soyez heureux.

De toute évidence, le programme a de la valeur, sinon vous ne le prolongeriez pas. Félicitations pour un projet réussi. Vraisemblablement, vous avez choisi Clojure parce que cela vous a fait gagner du temps et donc de l'argent de votre employeur. Si vous l'aviez écrit en Java, le programme serait donc encore plus difficile à maintenir. Même si vos collègues pouvaient plus facilement comprendre le programme ligne par ligne, pourraient-ils le maintenir et le prolonger?

Je te dirais plus de pouvoir! Lisp est le grand-père des langages informatiques et est toujours d'actualité; le fait qu'il ne soit pas si populaire, je pense, est dû au fait qu'il n'a pas les IDE chauds et moelleux de C # et Java et l'implémentation du compilateur principal dans Windows ne fonctionne que sous Cygwin (yuk!). Le développement semble avoir lieu dans Emacs et je suppose qu'il fonctionne mieux avec Linux ou Mac.

Ce concours de codage a été remporté par un programme Lisp en 2010: http://planetwars.aichallenge.org/

Il y a bien longtemps, ils pouvaient le déboguer en direct sur environ 100 millions de miles: http://www.flownet.com/gat/jpl-lisp.html

Vous renoncez définitivement à un drapeau rouge de maintenance, mais considérez-le comme une opportunité d'apprentissage pour quelqu'un d'autre. Si vous utilisiez une langue cauchemardesque (comme MUMPS) ou une langue fastidieuse (comme TCL), je pense que des questions devraient être posées. Mais je pense que vous devriez être considéré comme un gars qui essaie de maintenir le meilleur des anciennes traditions :)

Il y a beaucoup de bonnes réponses, mais je voudrais ajouter un point.

J'ai été dans une situation similaire mais avec une langue différente. J'ai dû tout apprendre à la dure, c'est-à-dire par la méthode d'essai et d'erreur en raison du manque de conseils. Ce que j'ai appris de mon expérience, comme vous l'avez souligné, la maintenance / l'extensibilité deviendrait un problème car il se peut que l'on ne connaisse pas les approches efficaces en raison du manque de conseils.

Je vous suggère de parler à votre responsable pour une aide adéquate afin que vous puissiez éviter tout problème à l'avenir.

Bonne chance!

Dans certains cas, un langage comme Lisp peut accélérer ou faciliter l'implémentation de fonctionnalités qui seraient très difficiles dans un autre langage. Cela influence également la façon dont vous regardez les problèmes, vous donnant une perspective que les autres membres de votre équipe peuvent ne pas avoir. Avoir un plus large éventail de capacités et une vision plus large de ce qui est possible peut être très précieux pour une entreprise capable de les comprendre et de les utiliser. Le prix de ces capacités, cependant, est un manque de standardisation.

De nombreuses entreprises tentent de standardiser une ou deux langues car cela leur donne plus de flexibilité organisationnelle: elles peuvent déplacer les développeurs d'un projet à un autre sans avoir à les recycler, elles disposent d'une réserve de connaissances intégrée sur les langues qu'elles utilisent, et les gestionnaires n'ont pas à considérer les forces et les faiblesses de l'utilisation d'une langue ou d'une autre pour un projet donné. Quand tout ce que vous avez est un marteau, tout ressemble à un clou.

Comme je l'ai souligné, les deux approches présentent certains avantages et inconvénients. Comme c'est souvent le cas, il n'y a pas de bonne ou de mauvaise approche. Vous échangez simplement un ensemble d'avantages et d'inconvénients contre un autre. Une entreprise ne doit pas non plus aller entièrement dans un sens ou dans l'autre. Il est parfaitement raisonnable de faire la plupart des travaux en C ++ ou Java, mais plongez de temps en temps dans Lisp ou Python pour les essayer et voir ce qui fonctionne. Il semble que ce soit ce que fait votre entreprise.

Alors allez-y (mais pas en avant), apprenez autant que vous le pouvez et devenez l'expert Clojure sur lequel votre manager peut compter pour obtenir des informations que vos collègues pourraient ne pas avoir. Et ne vous sentez pas mal à ce sujet ... vous soucier de l'organisation est le travail de votre manager.

Je recommanderais de commencer à réécrire votre programme dans une langue différente (plus pratique) lorsque vous commencez à penser que la maintenance a de fortes chances de dominer le problème.

Si vous avez réussi à l'écrire en conclusion (ce que vous ne saviez pas lorsque vous avez commencé à créer votre application, comme je l'ai compris), il ne sera pas difficile de le réécrire en utilisant un langage plus familier / plus pratique. La fermeture utilise des concepts complètement différents et, par conséquent, la mise en œuvre peut être difficile à transférer dans une autre langue. Mais le fait est que si vous vous êtes amusé à écrire une nouvelle application en conclusion, vous pourriez trouver intéressant de transférer les concepts et les idées que vous avez utilisés dans une autre langue pratique. Il pourrait être amusant de comparer différentes langues et leurs capacités. Je pense que votre cas est parfait pour de telles expériences.

Il n'est certainement pas faux de faire de la programmation dans des langages "impopulaires". Pourquoi vous souciez-vous vraiment de leur popularité ou non? Je suis entièrement d'accord avec @quanticle à ce sujet. Si Clojure ou une autre langue non courante est le meilleur outil pour le problème que vous résolvez, vous devez le choisir.

Je ne vois pas pourquoi la maintenance sera un problème. Si vous appliquez Unit, Integration, etc. Tester et documenter votre code tout programmeur intéressé par la programmation fonctionnelle pourra maintenir votre programme. À mon humble avis, le fait que vos collègues ne se soucient pas de Clojure n'est pas un bon argument pour ne pas l'utiliser, sauf si c'est la politique d'une entreprise que vous devez respecter.

Que le programme se poursuive ou non après votre départ ne vous concerne pas. Vous pouvez utiliser le langage de programmation pour créer quelque chose que votre patron aime, ça me semble plutôt bien. Votre patron devrait se soucier de la poursuite.

Organisez un tutoriel ou une session de formation. Si les membres de votre équipe ne veulent pas agir comme des professionnels et accroître leurs connaissances, surtout si le programme devient plus important, c'est hors de vos mains. Dans le pire des cas, vous pouvez parler à la direction et elle peut peut-être rendre obligatoire ce type de formation. Vous pourriez ressembler à un imbécile, mais au moins vous ne serez pas le seul à devoir maintenir le programme. L'autre option est de suggérer qu'un 2ème programmeur qui connaît la clôture soit ajouté à l'équipe.