Discussion :

[RyzenOC]

A l'école lors de mes tp en C, on passait 90% du temps à corriger des "segmentation fault".
Le C++ est quand meme plus appréciable dans le sens ou on as (nativement et de manière propre) des structures plus intéressantes comme les listes ou les objets.

A titre personnel je trouve pas le C++ plus compliqué que le python. Il a une syntaxe plus rigoureuse mais les concepts reste assez similaire (en python aussi y'a la notion de pointeurs).
Par contre le passage du C++ à C moi je la sens.
Faut pas croire que Python c'est simple, c'est un langage qui offre plusieurs approches, on peut manipuler des listes très simplement mais on perd en performance, ou bien utiliser Numpy et avoir un truc très performant, mais qui induit une complexité supérieure.
De meme aussi pour les calcules, on peut le faire en python pure ou bien en opencl.
Avec python on es as pour tous les gouts.
D’ailleurs avec Python 3.6 on as la fonction malloc qui est apparue comme en C. On peut manipuler la mémoire presque aussi finement qu'en C.


C'est pareil avec PHP, php pour débuter oui c'est très simple de faire un formulaire en PHP, mais PHP sa s'utilise avec un framework et la le niveau de complexité et tous autre, symphony sa se maîtrise pas en 3 jours.

bref PHP et Python sont aussi complexe que le C/C++.

[Pierre Louis Chevalier]

Je me permet de vous rappeler que avant que la mode vienne à Java et à Python pour l'éducation, le premier langage de programmation le plus utilisé en éducation, par exemple en Fac, c'était le Pascal, et pas le C.
Le Pascal est beaucoup plus intéressant que le C à titre éducatif pour tout un tas de raison, donc dans certaines écoles c'était par exemple Pascal puis ADA. D'ailleurs le Pascal est encore le standard dans beaucoup d'écoles, mais cependant le Python est devenu le langage le plus à la mode la mode pour le premier langage en éducation, après quoi en deuxième langage c'est généralement Java, ou parfois C# ou C++.

Le portage par l'INRIA du Pascal/CDC sur l'Iris 80 a mis ce langage à la disposition des centres de calcul universitaires à la fin des années 1970. À partir de 1980, des universités et des écoles d'ingénieurs s'en sont servis comme support de l'algorithmique et de la programmation structurée. En effet, il était :

plus efficace et plus ouvert qu'Algol 60,
plus ouvert, plus structuré et moins permissif que Fortran,
plus clair, plus structuré et moins permissif que PL/I.

L'arrivée des micro-ordinateurs introduisit une certaine compétition entre Pascal UCSD, Microsoft Pascal, et Turbo Pascal.

L'enseignement de l'informatique en classes préparatoires n'est introduit qu'en 1987, basé sur Pascal (plus précisément Turbo Pascal). Une bibliothèque (« MODULOG »), développée par l'ALESUP37 et l'IREM de Marseille, était également mise à disposition des lycées38,39,40.

Avec la réforme de 1995, l'enseignement de l'informatique en prépa scientifique est séparé en un tronc commun, basé sur un logiciel de calcul formel, et une matière optionnelle en MPSI et MP basée, au choix, sur Pascal ou Caml. Le succès de ce dernier est tel qu'au « stage de Luminy » en 1997, seulement trois participants choisissent le Pascal41. Très minoritaire dans la filière MP, Pascal est officiellement abandonné à partir de la session 2015 des concours, et depuis seul Caml est autorisé aux épreuves de l'option informatique.

Les prépas BCPST ont suivi un chemin similaire : le Pascal est introduit au programme en 1987, puis retiré au début des années 2000, au profit de MATLAB et Scilab. Le Pascal n'est plus proposé aux concours à partir de 200442.

[berceker united]

... mais PHP sa s'utilise avec un framework ...

La meilleur de la journée. T'es sérieux là ?

Tu peux utiliser PHP sans framework. Ces derniers, à l’échelle de l'histoire de PHP sont arrivé tardivement et avant nous développions sans. Même si ça te fait mal au cœur il y a beaucoup d'entreprises utilisant PHP ne le font pas avec un framework.


Pour revenir à la position de Java, il y a une explication à prendre en compte. Les SSII poussent beaucoup plus vers des projets en java alors que ça peut être fait en PHP. Pour l'avoir souvent entendu Java est un "langage plus noble". Cela m'a été souvent dit et sans filtre. Pourquoi ils poussent Java car il y a une meilleur facturation.

[KX_KX]

Bonjour,

bien que l'attitude agressive d'Oracle au niveau des licences Java risque d'avoir une influence à l'avenir

Il faudrait peut-être éviter de propager des informations incorrectes pour une remarque qui n'a même pas vraiment sa place dans cet article (ou alors il faudrait parler également de la santé des autres langages...)

Il suffit de lire le premier message de la discussion citée pour remettre en cause la source principale de l'information et donc l'article tout entier.

En réalité, cette histoire pue l’intox. The Register n’est pas une source fiable, c’est un journal sensationnaliste comme le tabloïd The Sun.

Rappelons également que les SSII ESN s'arrachent les développeurs et que pour 1 mission chez le client (travail réel) il peut y avoir 10 offres d'emploi pour des boites de prestataires différentes, ce qui peut avoir tendance à déséquilibrer ce genre de statistiques.

[Chuck_Norris]

Il faudrait peut-être éviter de propager des informations incorrectes

Attention, tu ne fais pas confiance à la source, c'est ton droit, mais rien ne prouve non plus que la source a tort, ou même partiellement tort. Il faudrait peut-être éviter de nier systématiquement. Oracle a bien utilisé plusieurs fois ces pratiques pour Oracle Database, c'est bien documenté. Du coup ce qui serait a priori invraisemblable le devient, même si j'espère de tout cœur qu'effectivement cela ne serait pas vrai, bien que je n'ai rien à carrer personnellement de Java.

ou alors il faudrait parler également de la santé des autres langages...

Il me semble que la santé des différents langages est justement le but de cet article.

[louxorman]

Salut, sauf erreur de lecture de ma part il n'est pas précisé à quel périmètre géographique se rapportent ces statistiques.

[LEKHEBASSENE]

Il aurait été intéressant d'avoir en complément des informations croisées sur le types de projets : application de gestion, supervision, workflow, sites web, jeux, calcul scientifique, simulation, logiciel de communication, interfaces graphiques, web services, migration de données ... Je pense que ça ne sera qu'à partir de là que nous aurons un corpus d'information intéressant, car certains langages ont des avantages sur certains cas d'usage.

Il est vrai que Java est un langage quasi-universel : systèmes embarqués, web, application d’entreprise, application mobiles, systèmes de communication, DAB, puces ... avec les avantages de la portabilité, une pléthore de bibliothèques une énorme communauté, l'existence d' IDE hyper-structurés et ouverts, des cadriciels (frameworks) stables, matures. Ces facteurs étant des facteurs de cercle vertueux qu'aucun autre langage n'a su réunir et qui explique une domination de Java depuis l'après bulle informatique.

Cependant, pour nuancer encore la réalité, je n'ai pas connu dans ma propre expérience d'application qui n'utilise pas moins de 3 langages (avec le quasi inévitable SQL avec ses variantes PL/SQL & co. !!!). Ensuite il est vrai qu'on peut parler de la dominante qui est impliquée dans les traitements les plus importants.

Il est toujours judicieux de se poser la question des outils les plus adaptés à utiliser et à adopter ceux qui le sont même si au départ nous ne les maîtrisons pas, à plus forte raison pour des projets qui portent sur des applications durables. C'est ce que j'ai fait récemment en allant à contre courant d'un avis quasiment imposé sur le langage Bash pour une application de supervision. J'ai dû forcer la main pour proposer de travailler avec Python et l'idée au départ n'a pas été bien acceptée car "il y avait déjà plusieurs modules qui tournaient en Bash" et que c'était une perte de temps d'utiliser un nouveau langage !

J'ai malheureusement expérimenté la perte de temps sur les débugage de scripts Shell et sur le risque de perdre du temps en maintenance du fait de l'absence de paradigme objet de . La nature de mon projet était de plus grande ampleur que celle des modules écrits en Bash. Les codes Shell sont difficilement maintenables, capricieux, et des grosses surprises peuvent vous attendre si vous migrez sur une autre version d'Unix par exemple (c'est du vécu) !!! Donc, la parole de fin, c'est de dire qu'à chaque chose sa place, mais qu'il faut éviter le mauvais casting !

[Jacti]

Je suis maintenant retraité mais j'ai terminé ma carrière comme "Expert en systèmes complexes à logiciel prépondérant", ce qui caractérise l'ingénierie système et pas seulement l'ingénierie logicielle. C'est principalement le domaine du spatial (satellites, missiles, navettes spatiales, etc), du nucléaires, du transport d'énergie (genre RTE), de l'avionique, des systèmes d'armes et, maintenant, les véhicules autonomes, etc. Dans l'armée de terre, les systèmes de commandement sont principalement écrits en Java et C++ (logiciels de plusieurs millions de lignes). Pour ma part ces 10 dernières années, dans ces domaines, j'ai vu surtout du Java, du C++ et il reste aussi du C. Dans ce genre de système il est TOTALEMENT exclu d'utiliser des langages à typage dynamique comme Python ce qui est une aberration pour ce genre de logiciels. Pour les fusées, il y aussi de l'ADA.
Ma conclusion c'est que pour choisir dans quels langages vous souhaitez travailler, il faut regarder les domaines d'application. Ceux qui veulent faire du Python ou du PHP doivent plutôt choisir les applications Web et encore, ça dépend lesquelles parce que dans les applis de e-commerce qui utilisent des web services transactionnels, il y a intérêt à regarder de près les environnements et les frameworks utilisés par l'entreprise avant de se lancer. Pour le big data, il faut connaître R (et Java pour les grosses applis). En gestion, je ne sais pas mais il y a encore du ... COBOL ! Pour "l'urbanisation" des systèmes d'information il est utile de connaître xml et xml. Il est également très utile de se pencher sur l'ingénierie dirigée par les modèles (IDM) (MDE et MDA).
L'avenir du développement c'est la production de code à partir de spécifications formelles comme ce qui a été fait, dès 1998, par exemple, pour les aspects sécurité de la ligne 14 du métro parisien, à savoir, spécifications formelles en B (langage de Jean-Raymond Abrial) et génération automatique du code en ADA. On est loin des langages Python, PHP, Perl et VBA ou VB.net.
Pourquoi l'avenir c'est la génération automatique du code à partir de spécifications formelles ? Parce que les systèmes deviennent de plus en plus complexes et que le code à écrire va devenir très rapidement non appréhendable par un humain. C'est déjà le cas pour certains logiciels d'intelligence artificielle ou les règles engendrées sont issues d'algorithmes d'apprentissages à partir d'énormes quantités de données (big data).

[Grogro]

Pourquoi l'avenir c'est la génération automatique du code à partir de spécifications formelles ? Parce que les systèmes deviennent de plus en plus complexes et que le code à écrire va devenir très rapidement non appréhendable par un humain. C'est déjà le cas pour certains logiciels d'intelligence artificielle ou les règles engendrées sont issues d'algorithmes d'apprentissages à partir d'énormes quantités de données (big data).

Pour des systèmes qu'il est possible de spécifier formellement, oui. Pour des besoins spécifiques de pointe, oui. Dans la vraie vie de nos clients, donc le plus souvent de l'informatique de gestion pour les grands groupes, non. Parce que des spécifications cohérentes, non ambiguës, non contradictoires, exhaustives, j'en ai jamais vues. C'est pas pour rien si 70% des bugs qui remontent de la production sont des problèmes de conception.

[Jacti]

Pour des systèmes qu'il est possible de spécifier formellement, oui. Pour des besoins spécifiques de pointe, oui. Dans la vraie vie de nos clients, donc le plus souvent de l'informatique de gestion pour les grands groupes, non. Parce que des spécifications cohérentes, non ambiguës, non contradictoires, exhaustives, j'en ai jamais vues. C'est pas pour rien si 70% des bugs qui remontent de la production sont des problèmes de conception.

Je suis d'accord avec vous pour l'informatique de gestion. Dans mon premier job dans les années 70 je m'occupais des applications du personnel dans une grande banque. Même dans la convention collective des banques il y avait des contradictions. La directive de la direction du personnel, à l'époque, était de programmer ce qui était à l'avantage du salarié lorsqu'il y avait contradiction ou plusieurs possibilités.

[el_slapper]

Pour des systèmes qu'il est possible de spécifier formellement, oui. Pour des besoins spécifiques de pointe, oui. Dans la vraie vie de nos clients, donc le plus souvent de l'informatique de gestion pour les grands groupes, non. Parce que des spécifications cohérentes, non ambiguës, non contradictoires, exhaustives, j'en ai jamais vues. C'est pas pour rien si 70% des bugs qui remontent de la production sont des problèmes de conception.

Et puis désolé d'être pédant, mais si on fait une specs totalement complète, qui contient toutes les décisions du code, complète formellement, ce n'est plus une spec, c'est déjà du code. De plus haut niveau, mais c'est du code. A partir du moment ou la machine n'a plus qu'à suivre les ordres, alors les ordres, on appelle ça du code.

[Grogro]

Et puis désolé d'être pédant, mais si on fait une specs totalement complète, qui contient toutes les décisions du code, complète formellement, ce n'est plus une spec, c'est déjà du code. De plus haut niveau, mais c'est du code. A partir du moment ou la machine n'a plus qu'à suivre les ordres, alors les ordres, on appelle ça du code.

Ce qui me fait penser à ce strip de l'excellent CommitStrip :

[Jacti]

Et puis désolé d'être pédant, mais si on fait une specs totalement complète, qui contient toutes les décisions du code, complète formellement, ce n'est plus une spec, c'est déjà du code. De plus haut niveau, mais c'est du code. A partir du moment ou la machine n'a plus qu'à suivre les ordres, alors les ordres, on appelle ça du code.

Les spécifications décrivent le QUOI, le code décrit le COMMENT.
Les spécifications ne sont pas des ordres donnés à la machine mais des assertions.Avez-vous déjà utilisé des systèmes comme LCF, la méthode B de Jean-Raymond Abrial ou COQ et fait des preuves avec ?
Connaissez-vous le lambda-calcul typé d'ordre supérieur, la théorie des types, la sémantique axiomatique, la logique de Hoare, etc. ?
Avez-vous fait généré du code à partir de spécifications formelles ?

[el_slapper]

Les spécifications décrivent le QUOI, le code décrit le COMMENT.
Les spécifications ne sont pas des ordres donnés à la machine mais des assertions.Avez-vous déjà utilisé des systèmes comme LCF, la méthode B de Jean-Raymond Abrial ou COQ et fait des preuves avec ?
Connaissez-vous le lambda-calcul typé d'ordre supérieur, la théorie des types, la sémantique axiomatique, la logique de Hoare, etc. ?
Avez-vous fait généré du code à partir de spécifications formelles ?

Grogro a déjà répondu avec son grand classique(que j'ai eu la flemme de googler). D'ailleurs, le SQL est du code, mais ça ne décrit jamais que le quoi, pas le comment, c'est un langage descriptif. Une spec formelle assez balaise pour se compiler(donc pour être transformée dans un code plus proche du langage machine) est elle-même du code. Descriptif, évidemment, pas prescriptif, mais le SQL n'est pas autre chose.

Et je n'ai d'ailleurs pas dit que c'était facile, ou que c'était une mauvaise idée. C'est juste une autre manière de coder. On code le quoi, pas le comment.

[TJ1985]

Les deux études sont intéressantes. Je rêverais de les voir croisées, afin d'obtenir une image de l'influence de la popularité d'un langage sur le niveau de salaire qu'il permet d'atteindre.
Sur le fond je m'interroge sur le langage comme critère d'engagement, et sur le niveau de maîtrise demandé. Lorsqu'on est à l'aise avec dans un paradigme il me semble assez aisé de maîtriser les langages qui l'appliquent.
Par contre l'omniprésence des frameworks et librairies complique le débat, car je pense qu'elles peuvent primer sur le choix du langage proprement dit.

[alama32]

Par contre je rêverais d'être un dev assembleur, le truc rare, voire trop rare.

Normal c'est du code presque machine, après, y a plus que le binaire.. lol Mais il est très simple, ce n'est jamais que jouer avec les registres du CPU ou GPU (comme AGAL), on peut faire des .exe et des .com il est souvent utilisé pour faire des drivers bien spécifique. Il n'est pas objet, il est séquentiel. Il est nécessaire d'avoir le set d'instruction de la puce à programmer, comme X86, cherche le logiciel MASM un vieux portable avec un DOS 6 sera largement suffisant. il y aura DEBUG qui est très utile. le point d'entrée des exe est l'adresse 100 si je me rappelle bien. Il existe des IDE qui te permettent de lire un code en hexadécimal, ce qui est une représentation comprimée des bytes.

Cherche sur le web. voici déjà un lien qui pourrait t’intéresser:
http://www.masm32.com/

[Kannagi]

Normal c'est du code presque machine, après, y a plus que le binaire.. lol Mais il est très simple, ce n'est jamais que jouer avec les registres du CPU ou GPU (comme AGAL), on peut faire des .exe et des .com il est souvent utilisé pour faire des drivers bien spécifique. Il n'est pas objet, il est séquentiel. Il est nécessaire d'avoir le set d'instruction de la puce à programmer, comme X86, cherche le logiciel MASM un vieux portable avec un DOS 6 sera largement suffisant. il y aura DEBUG qui est très utile. le point d'entrée des exe est l'adresse 100 si je me rappelle bien. Il existe des IDE qui te permettent de lire un code en hexadécimal, ce qui est une représentation comprimée des bytes.

Cherche sur le web. voici déjà un lien qui pourrait t’intéresser:
http://www.masm32.com/

Je trouve cela complètement inutile de faire de l'asm avec un OS , c'est quoi le but/intérêt de faire de l'asm en faisant appel a L'OS ou a d'autre lib C ?
Je ne vois pas forcément l’intérêt de faire des driver en asm , en terme d'optimisation un compilateur C fera mieux sur des plateforme comme le X86 ou l'ARM.

Bref pour ma part je le déconseille vivement du masm32 ou même du x86 (sauf si faire une appli avec une syntaxe assembleur vous plaît) , je conseillerai largement un micro contrôleur ou une vielle machine

Par contre je rêverais d'être un dev assembleur, le truc rare, voire trop rare.

J'ai envie de dire pourquoi ça serait un rêve ? pour impressionner les filles ? être un gourou du code ?
J'ai codais sur de l'assembleur sur plusieurs machine différente (grosso modo de la Nes a la PS2).
Mais le truc le plus important c'est l'algorithmique et la rigueur , si tu code en asm comme les pieds l’intérêt est proche de zéro.

[sarnikoff]

J'aimerais savoir dans quel langage est "écrit" développez. com.

Ici, je suis sur un magnifique éditeur, qui ressemble à un outil proposé en php .
Simplement :
Existe-t-il le même outil dans tous les langages cités ?

De plus compte tenu de la gestion de l' information,
dans quelle rubrique figure la comparaison des SGBD ou autre gestion de données ?