coucou747

Ce blog présente principalement les évolutions du compilateur metalang : les nouveaux backends, les nouvelles corrections de bugs, les nouvelles features, nouvaux tests, son utilisation dans le cadre du concours prologin.

le 05/06/2014

Pourquoi connaitre beaucoup de langages

Un langage exprime

On peut faire une analgie entre les langues et les langages de programmation : les langues expriment des idées qand les langages de programmations vont exprimer : des expressions, des instructions, des contraintes, etc... On exprime les choses d'une façon différente dans deux langues, parfois c'est plus court en anglais qu'en français, parfois l'inverse, parfois on est plus précis en français, parfois l'inverse. Mon meilleur exemple est celui du mot free qui peut se traduire par libre ou gratuit. En français on est plus précis avec un seul mot.

Pour les langages, c'est la même chose : deux langages vont avoir des caractéristiques différentes, non seulement pour leur vitesse d'execution mais aussi pour leur expressivité.

Mais on peut pousser la comparaison beaucoup plus loin : un langage c'est aussi une culture, une façon de faire les choses, un peuple, etc... Dans les langages on a des comunautés, des outils, des façons de faire, des concepts, bref la comparaison est évidente. Pourquoi le mélange des cultures ne choque personne alors que les gens ont de grosses réticences à changer de langage ?

Parfois, la culture qui vient d'une communauté autour d'un langage peut s'appliquer dans un autre langage : on voit même parfois une évolution des cultures, voir une évolution des langages en eux mêmes. Exemple : C# qui se met à utilser link parce-que F# (ce dérivé d'ocaml) a fait comprendre aux gens que le fonctionnel c'est cool.

Bref, maitriser plusieurs langages (donc plusieurs cultures) c'est pouvoir s'adapter plus facilement aux situations que l'on croise tout autour de nous.

En entreprise

En entreprise, on ne le choisit pas. Cette assertion peut paraître évidente, mais peu de gens en ont conscience.

Bien sur, on entend toujours une phrase pour rassurer, du genre : "t'inquiète pas, java c'est comme C#", mais la réalité en est toute autre : si ces deux langages se ressemblent, d'une part leurs subtilités en font des langages uniques qu'il ne faut pas restreindre à leur sous-ensemble, et d'autre part en entreprise, on ne fait pas qu'écrire du code : on passe aussi beaucoup de temps à en lire. Lire du code quand on maîtrise mal un langage est non seulement inconfortable, mais aussi risqué.

Un de mes amis a été embauché dans une entreprise qui devait lui proposer une mission en ocaml, une fois sur place sa mission a changé et il a du faire du C et du SQL. Personnellement, dans mon ancien poste, je suis arrivé pour faire du caml et de l'OPA, et finalement, j'ai aussi du faire du javascript. Plus récemment, dans mon poste actuel, nous avons effectué un "virage technologique" et donc j'ai du abandonner java pour faire principalement du C#, et occasionnellement de l'objective-C et du C. Bref le monde bouge et pour rester compétitif, il faut savoir bouger avec lui, et quand il s'arrète, il faut savoir le pousser pour qu'il continue de bouger.

Bref, on ne choisit pas forcément le langage que l'on utilise, et pire : très souvent on en change. Quand on en change en entreprise, on reste généralement sur des concepts connus et proches de ce que l'on connaît, mais pas toujours.

Formation ?

Comment être préparé à ça ? Je pense que la meilleur façon d'être prêt à des changements de technologies est d'être habitué à en changer, et d'en connaître beaucoup de types différents. De cette façon, on se retrouve moins perdu quand on doit changer de langage : d'une part on est habitué aux changements, et d'autre part on peut plus facilement trouver des similitudes avec des choses que l'on connaît déjà.

On peut y voir un parallèle avec les diplomes d'ingénieurs : les ingénieurs ont un tronc commun scientifique qui leur permet de discuter avec n'importe quel autre ingénieur. Ainsi un informaticien peut faire un logiciel de chimie en collaboration avec un chimiste, puisque son diplome d'ingénieur lui a donné les bases pour le comprendre. De la même façon, un bon informaticien doit avoir des notions de chaque domaine de l'informatique pour pouvoir discuter avec n'importe quel autre informaticien de n'importe quel projet. Le but n'est pas de tout connaitre par coeur (google existe toujours) mais d'avoir des bases dans chaque domaine et dans les principaux langages.

Pour moi, il faut au moins maitriser un SQL, le C, un langage web (php ou python par exemple), un langage objet et le caml pour avoir les notions suivantes : SGBD, programmation impératives, pointeurs & gestion de la mémoire, langage web, garbage collector, objet, programmation fonctionelle et typage.

Idéalement, il faudrait ajouter prolog, R, Lisp, pour avoir de la programmation réactive, logique et des macros, mais ces choses ne s'utilisent pratiquement jamais en entreprise (même si c'est super intéressant)

Les notions importantes

  • Objet
    • garbage collector
      • programmation fonctionelle
      • typage
      • programmation logique
      • SGBD
      • macros
        • en C
        • en forth
        • en LISP
      • notion d'execution
        • ASM
        • machine virtuelle
        • just in time

      Pour maitriser l'environement qui entoure le developpeur, on peut aussi ajouter les points suivants :

      • les DSL pour le parsing (lex, yacc)
      • rapports de bugs
        • trouver des traces
        • trouver un petit exemple
      • maitriser des outils de débugs (ou techniques)
        • valgrind
        • ocamldebug
        • gdb
      • maitriser des outils de tests
        • tests unitaires
        • couverture de code
        • performances
      • maitriser son éditeur (et un peu celui de nos collègues)
      • maitriser son gestionnaire de versions (et ceux qui nous entourrent)
        • git, mercurial, etc...
        • SVN
        • TFS
      • maitriser son environement de build
        • make
        • ANT
        • ocamlbuild

      Encore une fois, l'idée n'est pas de tout connaitre. On peut s'adapter à mercurial si on ne connait que git, mais par contre, s'adapter à git quand on ne connait que SVN me semble beaucoup plus difficile.

      Dans Catégories/Misc.

      Sujets : #général