En tant que programmeur, vous devez être familier avec plusieurs langages

L'une des décisions clés que nous, programmeurs, devons prendre lorsque nous nous lançons dans un projet est de choisir un langage, ou un ensemble de langages, à utiliser pour implémenter le système. Cette décision affecte non seulement la mise en œuvre du système, mais également sa conception. Par exemple, devrions-nous utiliser un langage orienté objet ou un langage procédural ? Le langage que nous choisissons a un impact profond sur le projet et le cycle de vie du programme qui fait partie du projet. Bien souvent, nous nous y mettons sans réfléchir. trop basé sur des facteurs très inconstants. Choisissez un langage : c'est le langage que j'utilise habituellement pour implémenter ce type de système ; ce langage que je comprends le mieux ; c'est mon langage préféré et j'aime programmer dans ce langage, etc.

Étant donné que cette décision entraînera des conséquences profondes et à long terme, devrions-nous être plus pragmatiques en faisant ce choix ? Plusieurs fois, nous serons aveuglément biaisés par le langage que nous choisissons ? Et parfois, les raisons pour lesquelles nous n’aimons pas choisir cette langue peuvent être les mêmes raisons pour lesquelles nous choisissons cette langue.

Si nous pouvons nous ouvrir et être honnêtes sur nos préjugés, nous pouvons atténuer une partie de la douleur liée à la tentative d'insérer une cheville carrée dans un trou rond lors de la décoration. Bien qu’il n’y ait pas de secret pour choisir la langue idéale pour un projet, certains principes peuvent nous aider à faire un choix linguistique meilleur et plus approprié.

Aucune langue n'est parfaite

C'est ce que l'on peut attendre de n'importe qui, même d'un débutant, et beaucoup d'entre nous sont prêts à admettre : "Bien sûr, cette langue n'est pas une langue parfaite", mais en même temps, beaucoup d’entre nous diraient encore : « Ce langage est le meilleur langage de programmation ». La clé pour dire qu’une langue est la meilleure langue pour un projet est le contexte du projet, c’est-à-dire que la meilleure langue n’existe que dans une certaine portée. C'est notre premier principe :

Il n'y a pas de langue parfaite : chaque langue a ses forces et ses faiblesses.

Par exemple, de nombreux développeurs qui utilisent généralement des langages d'exécution tels que Java ou Python affirment que le C ou le C++ sont à bout de souffle en raison de préoccupations concernant des détails de bas niveau tels que la gestion de la mémoire, ou de préoccupations concernant la granularité stricte de la compilation. -temps de vérification du type tout en étouffant les responsabilités décentralisées vers les développeurs. Cela est vrai tant que le projet que nous développons ne se concentre pas sur des tâches apparemment triviales telles que la gestion de la mémoire ou le nombre d'affectations de copies qui se produisent dans une seule boucle.

À l'inverse, si nous travaillons sur un projet, ou une partie d'un projet, il est naturel d'avoir des besoins biaisés quant à l'efficacité du code et au degré de critique et de sécurité du programme, et ces détails apparemment fastidieux peuvent être exactement ce sur quoi nous travaillons. Le niveau de granularité à rechercher. Dans ce nouveau contexte, la nature de l'exécution de Java ou de Python semble trop indifférente ou trop distraite. Au lieu de cela, nous voulons être en mesure de contrôler strictement le nombre d'affectations de déplacement et de copie exécutées lorsque la mémoire est allouée et libérée, et détecter autant d'erreurs que possible au moment de la compilation, plutôt que de laisser les erreurs s'infiltrer dans le moteur d'exécution (se comportant comme durée d'exécution anormale).

Alors qu'en théorie "aucun langage n'est parfait" semble évident, notre comportement en tant que développeurs s'écarte souvent de ce concept : nous disons que nous savons que nos langages préférés sont imparfaits, mais nous continuons à utiliser ce langage pour les projets. nous développons, que cela soit adapté ou non. De plus, lorsqu'un autre développeur remet en question notre choix de langage, nous défendons vigoureusement notre choix plutôt que de voir la vérité dans sa réfutation. N'oubliez pas : chaque langue a ses avantages et ses inconvénients. Comprenez les forces et les faiblesses des langues que vous maîtrisez puis faites votre choix en fonction de votre situation.

La raison pour laquelle vous n'aimez pas une langue peut être la raison pour laquelle vous devriez l'utiliser

Cela peut sembler contre-intuitif, mais parfois, la raison pour laquelle nous n'aimons pas une langue peut être la raison vous devriez l'utiliser Pour certaines raisons linguistiques. Toujours avec l'exemple ci-dessus, d'après mon expérience en tant que développeur C++, la réalisation d'un projet prend souvent trop de temps car il y a tellement de concepts différents à suivre (gestion de la mémoire et durée de vie des objets, les trois principes de la programmation C++, etc. .) Une fonction simple peut devenir encombrante. Après quelques semaines de développement en C++, utiliser Python, Java ou un autre langage "supérieur" peut ressembler à un cadeau : mais est-ce vraiment le cas ?

Parfois, peut-être. Les raisons pour lesquelles nous n'aimons pas un langage sont les raisons mêmes nous l'utilisons. Si je développais un pilote ou un système en temps réel critique pour la sécurité, les raisons évoquées ci-dessus pour sa lourdeur seraient probablement le plus grand avantage de ce langage. Par exemple, C++ fournit un mécanisme pour exprimer la logique qui est exécutée lorsqu’un objet est copié, ce qui est inestimable lorsque l’efficacité et la rigueur sont de mise.

Tout cela peut paraître beau et génial, il est donc difficile d'identifier un contexte dans lequel une langue que vous n'aimez pas pourrait être plus utile. Alors, comment savoir quelles langues que vous n’aimez pas sont utiles ? Cela nous amène à notre deuxième principe :

Soyez honnête avec vous-même : sachez pourquoi vous n’aimez pas une langue, ne l’aimez pas. Dogmatisez votre propre haine.

Par exemple, dans l'exemple C++ ci-dessus, la raison pour laquelle je n'aime pas programmer en C++ pendant longtemps est que ce langage nécessite une réflexion rigoureuse, sinon il est facile de faire des erreurs, tout comme d'être piégé dans le jungle. (Trop de concentration sur les arbres plutôt que sur la forêt dans son ensemble). Cette rigueur empêche les développeurs de se poser des questions telles que : "Est-ce que je crée des objets sur la pile ou sur le tas, ou une partie sur la pile et une partie sur le tas ?" ou "Pour rendre cette classe extensible, cela doit se faire via des paramètres". ou héritage?" et d'autres décisions. Dans d'autres langages, les développeurs peuvent accomplir ces tâches en créant simplement un objet chacun et en utilisant l'héritage orienté objet, puis passer à la fonctionnalité suivante car le langage (ou, plus précisément, le compilateur ou l'interprète) s'occupe de ces tâches. détail.

Cependant, si je suis honnête avec moi-même, j'admets que la raison pour laquelle je n'aime pas ces fonctionnalités du C++ est parce que cela m'oblige à exprimer ces détails. Dans d'autres langages, non seulement je ne suis pas responsable de ces détails, mais je n'ai pas non plus la responsabilité de les exprimer : ils sont soustraits au développeur. Dans un contexte où ces détails sont essentiels, les raisons pour lesquelles je n'aime pas le C++ sont exactement les raisons pour lesquelles je devrais utiliser ce langage.

Cela signifie-t-il que nous devrions froncer les sourcils et utiliser des fonctionnalités qui nous irritent par la langue ? Peut-être pourriez-vous voir les choses sous un autre angle : au lieu de considérer ces fonctionnalités comme des inconvénients, nous devrions peut-être les considérer comme des nécessités pour accomplir le travail. Au lieu de dire : « Quelle tragédie », nous devrions dire : « Dieu merci, je peux le faire dans cette langue. » Rappelez-vous : dans certains contextes, ces capacités seront un cadeau, et dans d’autres cas, elles sont un handicap. Soyez honnête avec vous-même quant aux raisons pour lesquelles vous n'aimez pas une fonctionnalité d'une langue.

Plus vous êtes familier avec d'autres langues, mieux c'est

Pour cela, voici notre troisième principe :

Si le seul outil dont vous disposez est un marteau, alors vous tu vois, chaque problème ressemble à un clou.

Cette règle ne s'applique pas au génie logiciel, mais elle caractérise nettement de nombreuses situations de développement logiciel. Souvent, nous choisissons un langage ou un outil pris en charge par un langage (tel que JMS de Java, ASYNCIO de Python, Ruby de Rails, etc.) parce que nous savons qu'ils existent. Si le seul langage que nous connaissons est Java, alors nous adapterons tous les problèmes que nous rencontrons au contexte de Java. Par exemple, « J'ai besoin de créer un cadre de routage pour une application de communication. Comment puis-je procéder en Java ? » Cela limite les outils dont nous disposons et limite artificiellement notre capacité à choisir le bon outil pour le travail.

La solution à ce problème est d'élargir vos horizons et de comprendre les capacités et les subtilités des autres langues. Comme le suggèrent Andrew Hunt et David Thomas dans « The Pragmatic Programmer », une bonne pratique consiste à apprendre une nouvelle langue chaque année. Ce n’est pas aussi facile qu’il y paraît, et apprendre une langue aura une signification différente pour différentes personnes. Un autre problème dérivé est que nous n'utilisons souvent cette langue que pour des projets en cours, ce qui rend inutile l'apprentissage d'une autre langue. Par exemple, si je suis un développeur Android et que j’utilise uniquement Java tous les jours, alors apprendre le C# peut sembler une perte de temps intempestive.

Ne vous laissez pas berner par les illusions. L’avantage d’apprendre une autre langue est que nous pouvons voir un problème sous un angle différent et utiliser les outils les plus adaptés au problème. Pour ce faire, nous devons connaître les mises en garde associées aux autres langages et la manière dont les développeurs utilisent ces langages pour résoudre les problèmes. Par exemple, si un développeur souhaite effectuer une métaprogrammation en C++, il peut alors utiliser la métaprogrammation de modèles (TMP) en C++, mais il peut également utiliser la réflexion en Java. Comprendre comment d'autres langages résolvent des problèmes similaires réduit le risque que nous le jugions inutile.

Comme autre exemple, si nous devons pouvoir modifier les caractéristiques d'exécution d'une classe, un développeur C++ qui connaît parfaitement les subtilités du C++ peut être tenté de concocter un langage de compilation qui étend le limites de cette solution. Et un autre développeur C++, parce qu'il a également une certaine compréhension de Java, peut dire : "J'aime le C++, mais la réflexion d'exécution de Java est mieux adaptée pour résoudre ce problème

À cause de cela, il y a tellement de programmation." langages parmi lesquels les développeurs peuvent choisir, il est important de prioriser les langages à apprendre. Autant commencer par les langages les plus populaires aujourd'hui (veuillez vous référer aux "langues les plus populaires sur Github", "Tendances linguistiques sur Github", "Les 9 langages informatiques les plus populaires", "selon le Facebook pour les programmeurs ", etc.).

La langue est un moyen plutôt qu'une fin

C'est le quatrième et dernier principe, qui peut paraître le plus philosophique, mais on peut aussi dire qu'il est le plus important :

Les langages de programmation sont un moyen, pas une fin.

À moins que vous ne soyez l'auteur d'un standard de langage ou d'un compilateur, vous devez traiter les langages de programmation comme un moyen plutôt que comme une fin. Le but est de terminer le projet : le but ultime est de terminer le projet, et non. en utilisant un langage spécifique. Cela ne veut pas dire que chaque développeur n'a pas le droit d'exiger ce qu'il aime ou n'aime pas dans le langage (en fait, si nous sommes honnêtes avec nous-mêmes, ces goûts et dégoûts peuvent jouer en notre faveur ; voir le deuxième principe ci-dessus), mais nous ne devrions pas nous leurrer en prenant des décisions telles que « C'est une excellente opportunité pour moi d'utiliser cette fonctionnalité du langage », à moins que les fonctionnalités du langage ne correspondent vraiment aux besoins du projet.

Il est important de se rappeler que le langage n'est qu'un moyen d'exprimer comment résoudre le problème en question : assurez-vous de choisir le langage qui exprime le mieux le domaine du problème que vous résolvez.

Autres éléments à prendre en compte

Voici quelques éléments à prendre en compte lors du choix d'une langue :

Considérez comment la langue interagit avec d'autres langues. Par exemple, si vous décidez que Python est le meilleur langage pour la plupart des projets, mais qu'il existe un composant bien défini dans votre projet qui nécessite un niveau de granularité ou d'efficacité extrêmement élevé (ce qui serait mieux adapté au C ou au C++), cela ne signifie pas que vous ne pouvez pas utiliser Python sur ce projet. Envisagez plutôt d'utiliser Python, d'écrire un composant spécifique en C ou C++, puis d'utiliser l'API Python C pour vous connecter à ce composant. Notez que pour formuler une telle solution, nous devons savoir que Python dispose d’une API C ; il est donc utile de connaître ces fonctionnalités des langages les plus populaires ;

Le middleware peut permettre l'utilisation de plusieurs langues. Par exemple, si vous avez deux applications qui doivent communiquer, comme un appareil mobile et une application serveur, cela ne signifie pas qu'elles doivent utiliser la même langue (bien sûr, elles peuvent être les mêmes si vous décidez que c'est la meilleure décision). . Si l'appareil mobile est un téléphone Android et que l'application serveur est parfaitement adaptée en tant qu'application Python, alors l'utilisation d'un courtier de messages tel que RabbitMQ permet de communiquer en utilisant les deux langages en même temps : l'application Android peut utiliser l'API Java RabbitMQ. , tandis que les applications serveur peuvent utiliser l'API Python RabbitMQ.

Embrassez les bizarreries des autres langues. Si vous êtes un développeur Java, vous utiliserez des packages pour séparer les unités logiques du code source ; si vous êtes un développeur Python, vous utiliserez la structure des packages de Python pour faire la même chose ; utiliserait un espace de noms ou préfixerait le nom de la classe (c'est-à-dire "DZone_MyClassName"). Comprenez les particularités de la langue que vous parlez et acceptez-les : à Rome, faites comme les Romains. Sinon, ce serait comme parler allemand avec un accent italien parce que vous préférez la prononciation italienne des mots, qui sonneraient indescriptibles. Bien sûr, il est également possible qu'une caractéristique d'une langue existe depuis longtemps, mais dans ce cas, il doit y avoir une raison : assurez-vous de bien comprendre la raison.