À fond des dizaines, non. Mais avoir une connaissance assez large pour pouvoir s’adapter, oui. Écrire du code métier en Ruby parce que c’est le plus pratique et lui faire appeler des microservices écrits en Go parce qu’on a un gros besoin de performances sur ces quelques services-là spécifiquement, par exemple. Ou avoir une base de code en PHP parce que c’est l’habitude de l’entreprise, et quand on a besoin de faire des calculs lourds, les réaliser avec Spark et les écrire en Scala. D’ailleurs, à ma connaissance, la plupart des gens trouvent déjà normal d’utiliser un langage pour le code métier et un autre — l’une ou l’autre variante de SQL — pour les requêtes en bases de données, ce qui n’a rien d’évident (on pourrait très bien gérer ses données dans le même langage que le reste).
[^] # Re: Juste pour la discussion...
Posté par ɹǝıʌıʃO . En réponse à la dépêche Appel à conférences PolyConf 17 à Paris (7 au 9 juillet) : « The Universe of Programming Languages ». Évalué à 6.
À fond des dizaines, non. Mais avoir une connaissance assez large pour pouvoir s’adapter, oui. Écrire du code métier en Ruby parce que c’est le plus pratique et lui faire appeler des microservices écrits en Go parce qu’on a un gros besoin de performances sur ces quelques services-là spécifiquement, par exemple. Ou avoir une base de code en PHP parce que c’est l’habitude de l’entreprise, et quand on a besoin de faire des calculs lourds, les réaliser avec Spark et les écrire en Scala. D’ailleurs, à ma connaissance, la plupart des gens trouvent déjà normal d’utiliser un langage pour le code métier et un autre — l’une ou l’autre variante de SQL — pour les requêtes en bases de données, ce qui n’a rien d’évident (on pourrait très bien gérer ses données dans le même langage que le reste).