De fait, chaque langage finit par être plus utilisé dans certains types de métiers ou d’activités, pour certains types de projets, dans certains environnements. Plus important encore, un langage appelle d’autres outils, et un certain type de collègue, et même si, comme d’habitude, la généralisation est un piège à con, il y a bien des stéréotypes visibles qui se dégagent.

Ainsi, Java et PHP sont des langages pour lesquels il est très facile de trouver du travail. Il y a une telle base de code là dehors qu’il y a des annonces partout, et tout le temps. En revanche, les environnements Java sont généralement très très lourds à manipuler. Pas en terme de performance (Java est aujourd’hui très rapide), mais en terme de charge de travail : énormément de configuration, beaucoup d’abstractions et de design pattern imbriqués, des APIs et des formats très verbeux…

Travailler dans un monde Java, c’est généralement travailler à un rythme lent, plus souvent dans des grosses boîtes, pour des systèmes assez larges avec un grosse inertie. Ne vous attendez pas à des Java-party avec vos collègues après le boulot.

PHP, c’est la même chose, avec des projets et composants plus simples (dans des entreprises de toutes tailles), et souvent bien plus dégueulasses. Non pas qu’on ne puisse pas écrire du PHP propre, mais 15 ans de PHP codé à l’arrache ne s’effacent pas avec quelques années de Symfony, et autre cakePHP. Du coup on hérite souvent d’un projet moche comme ta mère.

Bref, Java et PHP vous garantissent un job, mais les projets sont rarement marrants, et l’ambiance au taff sera pas pumped up. Par contre il y a de la doc et des tutos, même si généralement ceux pour PHP sont de meilleure qualité que pour Java (qui peuvent être assez indigestes).

Il y a une alternative intermédiaire : le C#. Beau langage, beaux outils, c’est propre sans être trop lourd, et la base de code est pas à vomir. Mais on reste dans le corporate, et la plupart du temps, sur du 98% Microsoft ou affiliés.

Après vous avez des langages spécialisés comme Erlang, Scala, Lisp. Là, trouver du taff sera généralement un challenge. Ce n’est pas le genre de truc qu’on voit partout. Et le niveau sera difficile : un débutant peut arriver avec la bite et le couteau dans un projet PHP, mais si vous vous pointez avec 3 mois d’expérience sur une gateway jabber haute tolérance, le bidouillage ça va pas le faire.

Ce sont des langages qu’il faut choisir si on aime le taff de haut niveau, la débrouillardise et les solutions intelligentes. En général les missions sont super intéressantes, mais la reconversion est dure. Par contre, vous rencontrerez des collègues qui valent le détour.

Puis il y a les langages de bas niveau, type C/C++. Aujourd’hui, c’est massivement des missions scientifiques ou de l’embarqué : analyse d’image, cartes électroniques, petites machines, etc. Il y a encore des trucs pas cool genre Windev (j’ai un pote coincé là dedans, c’est triste, fuyez ces annonces), mais ce n’est plus la majorité. Ces langages, c’est une question de tempérament. Est-ce que vous aimez la minutie ? L’efficacité des algos ? Le travail sous contrainte technique ? Si oui, alors ce genre de taff peut être très sympa. Sinon, choisissez un langage plus dynamique.

Ensuite il y a les langages de niches : Cobol, Power Builder, etc. Là c’est généralement des projets de merde très bien payés. Plus personne ne veut coder avec ces trucs, mais ça coûte trop cher à changer. Les jeunes sont acceptés, les formations offertes, le salaire de début de carrière est bon, mais par contre, le code est un truc de mémé. C’est pas mal pour commencer une carrière et se faire un peu de thune, mais faut savoir en sortir, et ça ne donne pas de bonnes habitudes en prog.

Et pour finir il y des langages dit “modernes” (ce qui est un abus… de langage, car ils ne datent pas d’hier) comme Python, Ruby ou Javascript. Le côté “moderne” vient surtout du fait qu’ils sont maintenant très adaptés à des projets modernes, où la souplesse de développement a priorité sur le reste des caractéristiques. Choisissez ces langages si vous visez des missions, principalement Web, sur des produits récents. Ce sont les communautés les plus sympas et dynamiques, ça brasse pas mal dans le milieu et c’est assez jeune. Mais un grand nombre de start up, donc il faut pas chercher la sécurité de l’emploi.

Une petite parenthèse pour Python tout de même : il n’est pas autant limité au Web et on le voit aussi beaucoup dans le secteur scientifique et bancaire. C’est sa versatilité et la facilité de reconversion qu’il offre qui me fait dire que c’est un très bon choix comme premier langage. Mais. Car il y a un “mais”. Trouver une offre Python sera plus difficile qu’une offre Ruby, et BEAUCOUP plus difficile qu’une offre PHP ou Java. Après perso je n’ai jamais connu le chômage.

Warning ! Il faut faire gaffe à se lancer dans le dev Web. C’est très tentant, mais contrairement aux autres carrières, ça veut dire une courbe d’apprentissage beaucoup plus longue. Vous ne pouvez pas juste apprendre votre langage, ses libs et son env et vous vendre comme “expert”.

J’ai laissé pas mal de truc de côté, comme l’objective C, Haskell, Smalltalk, le Bash, Perl et quelques milliers d’autres langages. On ne peut pas tout faire, et je voudrais surtout peindre un tableau global du marché. En me relisant, je me dis que c’est bourré d’idées reçues, qu’il y a plein d’exceptions, etc. Mais je pense que les infos données peuvent permettre à des gens qui se posent la question de l’orientation de prendre une décision moins mauvaise que “je lance un D20 et on verra bien”.

En vérité c’est extrêmement simple : Python permet de se mapper directement sur un .dll ou un .so, et d’appeler n’importe quelle fonction qu’il contient depuis le code Python comme si c’était une fonction normale. Il n’y a rien à installer, c’est fourni d’office.

On peut tester ça facilement. Je ponds une lib d’une folle puissance grâce à mes talents de codeurs C internationalement connus dans le quartier :

#include<stdio.h>
 
/*
Attend un pointeur sur un array de caractères (une chaîne en C) 
et l'affiche.
*/
dit_papa(char * p)
{
    printf("%s\n", p);
}
 
 
/*
Attend deux entiers et les multiple
*/
multiplier(long a, long b)
{
    return a * b;
}
 
/*
Attend un pointeur de pointeur sur un array de char
parce qu'on aime les risques.
*/
jakadi(char ** p)
{
    printf("%s\n", *p);
}

On compile tout ça. Comme je suis sous Nunux, j’utilise GCC et j’obtiens un .so, mais sous Windows c’est pareil avec VisualStudio et les .dll.

gcc -shared -Wl,-soname,ZeLib -o ZeLib.so -fPIC ZeLib.c

ZeLib.so est prête et frétille d’impatience à l’idée de vous servir. Il ne reste plus qu’à lancer le shell Python…

D’abord on fait ses imports, c’est dans la lib standard tout ça :

>>> import ctypes

Ensuite on se bind sur le binaire, il faut préciser un chemin absolu sinon ça ne marche pas :

>>> zelib = ctypes.CDLL("/home/sam/Work/projet/ZeLib.so")

Et derrière on peut appeler une fonction (Python fait la conversion entre tous les types de bases Python et C) :

>>> res = zelib.multiplier(2, 3)
>>> print res
6

Si on veut faire des chaînes, on ne peut pas passer de l’unicode. Comme mon shell a toutes les chaînes en unicode par défaut, je dois encoder dans le charset de sortie (sur mon système, c’est UTF8):

>>> zelib.dit_papa("papa".encode('utf8'))
papa
5

Notez au passage que la fonction retourne quelque chose même si je n’ai pas précisé de valeur de retour. Du coup j’aurais mieux fait de mettre un bon return 0 à la fin.

Si on veut appeler une fonction qui attend un pointeur, il faut d’abord caster son type en un type C, puis appeler by_ref dessus, qui va passer l’argument par référence, plutôt que par valeur :

>>> from ctypes import *
>>> s = ctypes.c_char_p('kiwi'.encode('utf8'))
>>> zelib.jakadi(byref(s))
kiwi
5

Voilà.

Voilà, voilà.

Bon attention quand même, le C n’est pas aussi conciliant que le Python : le debug est plus dur (pas de stacktrace, mais un bon vieux core dump), pas de completion dans ipython, et on peut même planter la VM si on se débrouille bien :-)

P.S: je ne vais pas mettre le code C à télécharger et le code Python, franchement, il est pas énorme. Donc petite exception dans cet article : y a rien à DL et la syntaxe est pas à base de comments.