Après Java et python, que faire ?

Bonjour je vais terminer cette année avec un bagage de base mais suffisant en Java et python et ce serait bien d’avoir un plus sur mon CV si j’apprenais encore un petit langage en plus. L’idéal serait un langage facile à apprendre connaissant Java et python (donc exit le htlm), mais tout aussi utile/populaire que ceux ci.

J’ai vu un tuto C++ sur ce site qui a l’air alléchant, peut être existe-t’il un tuto en C aussi ou encore d’autres langages alors ma question c’est :

Après le Java et python, quel langage apprendre pour :

• se perfectionner en apprenant de nouveaux paradigmes
• être à jour sur la communauté des développeurs (donc exit l’assembleur et PASCAL, COBOL…)
• être pas trop éloigné de Java si possible

J’ai la vague impression que le C++ serait le meilleur choix mais le C semble fort utilisé en robotique, donc quels sont vos conseils, retours d’expériences, je prends tout ! Pour le domaine, peut importe, j’aimerais être chercheur en programmation plus tard ou professeur. Ou simplement coder des trucs sympas.

Et le but principal de tout ça serait d’avoir un langage en plus sur mon CV et étendre mes connaissances en programmation logicielle. Que le gars qui lise mon CV se dise "ah lui, vu ses connaissances, il pourrait être utile pour l’entreprise !"… Merci pour vos réponses.

Bonsoir,

Ce qui est important, n’est pas seulement le ou les langages, mais tout son écosystème. Par exemple, maîtrises-tu le versioning, les bases de données, … ? Si oui, alors lance toi dans un langage avec un autre paradigme. Tu utilises beaucoup l’objet, pourquoi pas aller vers tout sauf objet ?

Si non, je trouve ça plus important dans le sens que malgré les difficultés liées à l’apprentissage de chaque langage, on ne te demandera pas seulement cette compétence, mais le travail d’équipe, l’analyse d’un concept, …

Salut !

Changer de paradigme est une bonne idée je pense, tu peux faire du Haskell pour la programmation fonctionnelle. Après apprendre le C juste pour la robotique serait dommage surtout que de nos jours avec une Raspberry Pi tu peux programmer en à peu près n’importe quel langage.

Si tu tiens à rester sur un langage proche du Java, le C++ est une superbe idée, étant en train de l’apprendre ici même, je peux te dire que c’est un langage très riche et agréable à utiliser avec de nombreux paradigmes (et non ce n’est pas que de l’OO).

Sinon, être un dev, c’est pas uniquement connaître tout les langages, comme le fait remarquer @fred1599.

Salut,

Il est si peu visible que ça ? T_T

Sinon, plus sérieusement, pour compléter ce qu’a dit @fred1599, cela dépend aussi des plateformes pour lesquelles tu vas ou veux développer. Si tu penses programmer pour Windows et/ou téléphone, laisse tomber le C (et a fortiori le C++, mais dans une moindre mesure), tu galèreras juste pour avoir un truc fonctionnel (la faute aux environnements en question, pas au langage lui-même). Si en revanche tu comptes programmer pour Linux et/ou BSD, alors le C ou le C++ font nettement plus sens, à plus forte raison si tu t’intéresses à la programmation système.

En dehors de l’aspect pratique, le C peut également être intéressant à apprendre comme une forme de lingua franca. Je m’explique : le C a été massivement utilisé par le passé (il l’est toujours aujourd’hui, mais son utilisation décline lentement) et il y aujourd’hui encore énormément de code écrits en C qui sont utilisés (que ce soient des programmes ou des bibliothèques). De ce fait, il y a de fortes chances pour que tôt ou tard et d’une manière ou d’une autre tu sois confronté à des lignes de C.

Cela ne veut pas dire que tu dois apprendre le C, ni que tu devras nécessairement mettre ton nez dans du code C, mais le connaître peut être un avantage de ce côté.

Pour ma part, je suis d’accord avec @Taurre sur le C et je trouve que énormément de langage ont une syntaxe similaire au C comme les langages à JVM, le C++, etc… Je pense que c’est un langage intéressant mais lourd à utiliser pour de grosses applications.

EDIT: quelques langages

Salut,

Tu pourrais te tourner vers des choses différentes, par exemple, un langage fonctionnel. En « proche » de Java, tu as Scala, mais peut-être trop proche, je conseillerais plutôt d’ouvrir de nouveaux horizons quitte à s’éloigner totalement de Java. De même, tu pourrais t’intéresser à la programmation logique avec des langages comme Prolog ou Oz.

Une autre chose intéressante serait de regarder des domaines connexes (et pourquoi pas plus théorique) en fonction de ce qui t’intéresse (de l’algorithmie, de la théorie des langages, de la compilation). Par exemple, la géométrie algorithmique est plutôt cool et permettra de voir des choses théoriques mais aussi de les coder. Ou tu pourrais t’intéresser à la preuve de programme avec des trucs comme Coq et Agda. Et il y a d’autres domaines : cryptographie, apprentissage statistique, etc.

Il faut arrêter de croire que connaître un catalogue de langage c’est bénéfique pour le CV. Connaître peu de langage mais bien les connaître c’est mieux, enfin c’est mon point de vue. Tu seras probablement confronté un jour à bosser sur un projet avec un langage/une techno que tu ne connais pas, eh bien ce n’est pas forcément très grave, un coup de formation et tu seras « opérationnel ».

Et surtout, comme ça a était dit plus haut, cible le langage par rapport à ce que tu veux faire.

Garde également à l’esprit qu’un langage est un support, on n’apprend pas la programmation avec un langage, le langage est un intermédiaire pour arriver à ses fin.

Et outre l’aspect programmation, est-il y des aspects plus théoriques qui peuvent être intéressant de connaître suivant le secteur d’activité que tu vises, comme le mentionne Karnaj.

Sinon, puisce que tout le monde vend son langage, je vais faire de même; très loin syntaxiquement de Java, mais excellent langage pédagogique (bien qu’il ait une faible communauté, mais une communauté de gens très compétents), tu as Ada.

merci pour les rélfexions alors avant de faire une réflexion appronfondie je vais réfléchir à vos pour et contre, mais c’est encore abstrait car je suis encore aux études.

Pourrais tu préciser pourquoi le C tu le déconseilles sous windows parce que j’ai cru comprendre que le C ne pouvait tourner que sur window?

Ça m’étonne que personne ne lui ai proposé Javascript.

Le C est très intéressant mais il est peut probable que demain on t’embauche pour faire du C (à moins de trouver un job particulier, ça arrive). Le C tourne sous pratiquement tous les systèmes par seulement Linux, BSD, le micro contrôleur de ta télé, Windows, … Il apprend une certaine rigueur et est proche de la machine. Ça fait qu’on apprend finalement pas mal quand on apprend le C.

Javascript, c’est un langage plutôt simple, utilisé majoritairement sur le Web mais tu peux en trouver un peu partout. Mais pas sur les micro-contrôleur par exemple. Bref, c’est un langage qu’on considère intéressant à apprendre car indissociable du Web.

Sache qu’il est bien plus intéressant de maîtriser les langages que tu connais que d’en apprendre à la chaîne.

Je trouve qu’il est très bien d’apprendre un nouveau langage (d’autant plus si tu te tournes vers un nouveau paradigme) : ça permet d’aborder les choses d’une manière différente et de mettre en perspective ce que tu sais déjà.

En revanche je doute de l’intérêt de le faire pour ajouter une ligne à ton CV, comme dit précédemment ce dernier ne doit pas refléter une collection de langages divers, il est plus valorisant de n’y faire figurer qu’un nombre restreint que tu as réellement pu approfondir.

Personnellement je chercherais un langage qui peut facilement compléter et s’interfacer avec l’un de ceux que je connais.

Du coup, dans cette optique, C, C++ et Rust me semblent de bons choix pour complémenter Python.

• L’interpréteur est écrit en C, donc tu peux écrire des modules en C ou C++ et les utiliser depuis Python, soit en les programmant directement avec l’API C standard de Python, soit en utilisant un outil comme Cython (qui gère les deux).
• Rust est plus moderne, et s’interface également très bien avec Python grâce à la crate PyO3.

Beaucoup de gens pensent bien connaître Python jusqu’au jour où ils découvrent qu’il y a une autre face derrière l’interpréteur. Je pense que c’est important d’apprendre à marier le meilleur des deux mondes de façon cohérente. Là où je bosse, c’est un bonus indéniable sur un CV.

Tu dois confondre avec le C# qui est langage développé par Microsoft pour le système d’exploitation Windows (même s’il tourne sous Linux via Mono par exemple). Sinon, je déconseille l’usage du C sous Windows car c’est loin d’être une sinécure de l’employer sous cet OS. Pour faire bref :

1. La bibliothèque standard fournie par Microsoft est vieillissante et ne sera pas mis à jour par rapport aux normes C99 et C11 (et suivantes) ;
2. Il est pénible de mettre en place un environnement de développement car il faut nécessairement se baser sur des outils et projets externes (MinGW, Msys2, CygWin, etc.) ;
3. La gestion de la localisation par la console de Windows (que ce soit cmd.exe ou la console Powershell) est juste calamiteuse.

Évidemment, le tuto C explique comment faire a minima (on allait pas demander aux lecteurs d’installer un autre OS avant de commencer…), mais cela n’empêche que Windows est de loin la moins bonne option pour apprendre le C.

C’est un troll ou c’est sérieux ?

merci pour ces explications je reviens vers le sujet lorsque j’aurais un peu recherché en détails

Concernant C#, c’est maintenant du multiplateforme avec .NET Core. Ce n’est vraiment plus limité à Windows. Et avec la version 3 qui arrive, le spécifique Windows se réduit encore plus, avec le portage de WPF et Entity Framework 6.

Bonjour, je rejoins Fred sur l’importance d’apprendre des paradigmes plus que des langages.

Petite liste non exhaustive :

• Algorithmes de tri (tri à bulle, tri par insertion, quicksort).
• Algorithmes de chiffrement (AES, DES, RSA, cipher).
• Algorithmes de pathfinding.
• Algorithmes d’indexation.
• Usage de Map / reduce / filter.
• BDD SQL / NoSQL, modélisation.
• Sockets (ex: chat en temps réel).
• Distribution des données (routing, dispatcher/subscriber, queues).
• Affichage (MVC, MVVM, templates).
• Services (API, serveur de données / fichiers, OAuth).
• Traitement, extraction et analyse des données (Big Data, Data Mining).
• Apprentissage des données (IA, Machine Learning, Deep Learning, LSTM, GANs).
• Création et animation graphique (génération de fractale, système de particules, affichage de sprites, projection 3D).
• Création d’une blockchain (PoW, chaînage des blocs, synchronisation).
• Outils de DevOps (Kubernetes, Docker, outils de versioning, tests automatisés).

Y’a tellement de chose à apprendre sans même parler de langage de programmation. Effectivement un langage va nous apporter certaines spécificités, POO / pas de POO, cross platform ou pas mais la véritable problématique des entreprise c’est : Es-tu rentable ? Est-ce que tes compétences peuvent aboutir à un projet concret ?

Es-tu rentable ? Est-ce que tes compétences peuvent aboutir à un projet concret ?

Certes, mais à cette question si on me répond "oui, je sais faire un heap sort !", personnellement j’éclate de rire.

Par contre si la personne est capable de tenir une discussion sur la différence entre un thread et un processus, les limites des threads en Python, et les solutions pour mitiger les problèmes qu’ils posent, ou bien me dire quelle est la complexité de telle opération dans la bibliothèque standard de son langage, là on a de la matière : ça montre que la personne a au moins une fois cherché à pousser ses connaissances pour améliorer la qualité / les performances de son code dans un projet.

C’est bien joli de dropper des acronymes, mais une personne "rentable" n’a pas besoin de ça, c’est juste de la culture : si elle ne sait pas faire un map reduce ou ne sait pas ce qu’est AdaBoost mais peut comprendre le principe en 10 minutes et le coder en quelques heures par la suite, ça me suffit largement.

Et encore, quand je recrute un profil junior, je ne pose aucune de toutes ces questions-là et je me contente de discuter avec la personne de ce qu’elle a déjà codé, en entreprise ou encore mieux, pour le fun sur son temps libre. J’estime qu’il vaut mieux lui transmettre correctement les notions dont elle a besoin pour bosser dans mon équipe, plutôt que de reposer sur le fait qu’elle les a déjà (peut-être mal) apprises ailleurs.

PS : les tests automatisés ne sont pas des outils de DevOps.

Et encore, quand je recrute un profil junior, je ne pose aucune de toutes ces questions-là et je me contente de discuter avec la personne de ce qu’elle a déjà codé, en entreprise ou encore mieux, pour le fun sur son temps libre. J’estime qu’il vaut mieux lui transmettre correctement les notions dont elle a besoin pour bosser dans mon équipe, plutôt que de reposer sur le fait qu’elle les a déjà (peut-être mal) apprises ailleurs.

Je n’ai pas dit le contraire Nohar, ça ne sert rien d’inventer un homme de paille. C’est justement l’application de ces algorithmes / compréhensions de ces paradigmes dans des projets personnels et professionnels qui permettent à un développeur d’évoluer. La liste non exhaustive était une simple énumération des axes d’études qui aujourd’hui sont importants pour se constituer des compétences et des connaissances techniques. Je ne sais pas si Marius007 a déjà entendu parler de toutes ces choses, si ça peut lui donner des idées. mon propos n’allait pas plus loin que ça.

C’est justement l’application de ces algorithmes / compréhensions de ces paradigmes dans des projets personnels et professionnels qui permettent à un développeur d’évoluer.

Je n’invente pas d’homme de paille, je dis juste exactement le contraire de ça : tous ces algos /paradigmes sont bien pour pour la culture mais fondamentalement ce ne sont pas eux qui font qu’un développeur est compétent. De la même manière, ce n’est pas directement le fait d’avoir étudié des tonnes d’auteurs classiques qui font que l’on sait s’exprimer correctement en français ou non, mais bel et bien le fait d’avoir pratiqué la langue, à l’écrit comme à l’oral.

J’éprouve un réel rejet pour ces énumérations un peu gratuites : elles sont intimidantes (en donnant l’impression qu’il faut tout connaître, "si t’as jamais codé de MVC tu peux pas dire que tu sais développer une IHM") sans pour autant traduire des compétences réellement importantes à mes yeux. Ces trucs-là, on les découvre le jour où on en a besoin.

PS : Pour préciser ma pensée. Oui, c’est important de découvrir des paradigmes différents, mais ça l’est tout autant de les découvrir et de les utiliser dans des langages qui font que l’on dispose d’une stack cohérente sur son CV. Quand je dis discuter de ce que les gens ont déjà codé quand je recrute des débutants, c’est pas du tout pour savoir quelles notions ils ont touché dans cette liste, mais plutôt pour cerner la façon dont ils ont abordé les problèmes, comment ils les ont résolus, ce qu’ils en ont appris (ce qu’ils changeraient aujourd’hui avec le recul), bref comment ils sont câblés.

J’entends bien Nohar, ça ne suffit pas pour qu’un développeur soit bon. Pour autant, je vais te montrer que c’est essentiel de travailler la culture des paradigmes et des algorithmes :

Quasiment à chaque fois que mon patron est en train de chiffrer un cahier des charges pour un client, il m’expose le projet et la technologie sous-adjacente. A ce moment là, il me demande de chiffrer mon temps (pour que je sois rentable). Si la technologie, je la connais - pas de problème, je peux estimer très précisément mon temps. Mais si je la connais pas ?! Faut bien que je lui réponde. Pour mon patron, c’est parfois plus rentable de choisir un développeur en sous-traitance ; il a besoin d’une réponse. il faut que l’objectif soit également atteignable, sinon ça retombe sur moi - j’ai mal estimé mon temps.

Pour cela, j’étudie le projet pour estimer dans les grandes lignes, les algorithmes qu’il me faudrait mobiliser pour atteindre mes objectifs. Ça passe donc par ma culture IT. Je vais peut-être me tromper d’1 jour ou 2 parce que (encore une fois) la technologie, je ne la maîtrise pas. En revanche, mon chiffrage de temps pour la réalisation des algorithmes sous-adjacents au projet seront eux bien réel. Pourquoi ? Parce que je les connais, parce que je les déjà utilisé dans des projets personnels, pendant mes études ou durant mes heures de travail.

C’est d’ailleurs ce que tu marques dans ton dernier post-scriptum, je pense que tu m’as mal compris. La liste n’est pas à marqué texto dans son CV, ce serait contre-productif - ça polluerait le sens premier du CV "interpeller le recruteur sur notre profil" (au sens large, savoir-faire, savoir-être, compétences, réalisations etc) mais c’est essentiel pour consolider ses compétences. Mettre la veille technologique au centre de son activité de développeur et en discuter lors d’un entretien d’embauche, ça ne peut qu’apporter des plus.

Ok, en fait tu viens de me montrer qu’on ne travaille pas du tout dans le même univers.

Les estimations, chez moi elles se font en équipe, le chiffrage porte sur une quantité d’effort et non directement sur le temps (car on a compris que le temps pour compléter une tâche dépend de tellement de facteurs qu’il est impossible de l’estimer directement), et il fait intervenir tous les membres d’une équipe de développement (expérimentés et débutants) en même temps, de manière à ce que tous s’approprient le sujet.

Surtout, dans mon univers, ce n’est pas l’algorithme employé qui a la plus grande influence sur la complexité d’une tâche, par rapport au temps pris par l’intégration, les tests, la documentation, la configuration, ou encore les allers-retours en code review… Pour caricaturer, si j’avais du Machine Learning à faire, le fait d’utiliser des réseaux de neurones, du boosting, des SVM ou n’importe quoi d’autre n’aura aucune influence sur le temps que prendra le truc à se terminer : la seule chose qui va bouger, dans les faits, c’est la classe de scipy que j’utiliserai pour ça.

Pour un développeur junior, c’est encore pire : il n’a même pas ce style de choix à faire au départ, ils ont déjà été faits soit par un ingénieur plus expérimenté (un tech lead ou un architecte), ou bien ça a été fait collégialement (en le faisant participer à la réunion pour qu’il ait l’occasion de se frotter à ce genre de conception). Et c’est en cumulant les expériences où ces choix sont de moins en moins pré-mâchés que le développeur forge sa culture.

Merci pour ton retour d’expériences. Effectivement, on ne travaille pas dans le même cadre de travail. c’est cool de se rendre compte que le même métier peut être transposé de différentes manières, selon la taille de l’entreprise et de l’organisation. Je travaille dans une PME.

car on a compris que le temps pour compléter une tâche dépend de tellement de facteurs qu’il est impossible de l’estimer directement

Oh oui, c’est pour cette raison que mes estimations de temps nécessitent un recul bien plus important sur les compétences que je peux mobiliser et ceux de mes collègues. Pour autant je ne pense pas que ce soit forcément un mauvais choix entrepreneuriale, c’est simplement que les enjeux de rentabilités ne sont pas les mêmes.

Et c’est en cumulant les expériences où ces choix sont de moins en moins pré-mâchés que le développeur forge sa culture.

Sauf que tu parles d’une culture d’entreprise. Celle-là par contre on la développe en interne. On développe nos outils, nos modèles, nos règles à respecter pour développer en équipe mais ça me paraît pas ambiguë de rajouter à cela de la recherche personnelle hors entreprise - qui serait de la culture IT dont l’objectif premier est de découvrir soi même des technologies. On a pas toujours la possibilité d’utiliser certain algorithmes : le client ne le demande pas, on ignore les performances donc on ne l’applique pas ou encore le temps alloué pour la production n’est pas suffisant pour passer par de la R&D. Ce dernier point ne semble pas un frein dans ton univers, le mien si !

Bon il me semble que l’on devrait s’arrêter là. La discussion dérive un peu trop. J’espère que Marius007 s’y retrouvera dans tout ça.