Pourquoi les langages C et C++ auraient-ils encore de nombreuses années devant eux ?

Version imprimable

Voir 40 message(s) de cette discussion en une page

16/01/2018, 16h16
RyzenOC

Citation:

Envoyé par jlliagre

Ouais... pourquoi pas, mais quand j'étais petit, on disait aussi qu'en l'an 2000, on se déplacerait en voiture volante et qu'on irait en vacances sur la Lune et sur Mars ...

c'est marrant, moi j'ai pas entendu la même chose quand j'étais petit :mrgreen:
l'accumulation des déchets et la raréfaction des ressources en 2000 allait pousser les digients a en finir avec l'arme atomique
https://www.youtube.com/watch?v=kfNVzHcgvqo

et en 2150 : le peu d’humain survivant (au moins y'a des survivant) vive en orbite autour de la terre en attendant que les radiations baissent.

par contre j'ai pas vu d'ordinateur quantique.
16/01/2018, 16h53
el_slapper

Citation:

Envoyé par wolinn

(.../...)
Il me semble avoir lu que el_slapper avait rénové des programmes Cobol écrits au début des années 70. A priori, ce n'est pas pour les jeter l'année prochaine au profit du langage à la mode du moment, ces programmes sont plutôt destinés à fonctionner pendant encore des décennies.

En effet. Pour être précis, refonte en 2008 en cobol-85 d'un code écrit en 1972 en cobol-1(mais qui était passé en COBOL-85 avec le temps). En 2013, j'ai eu des nouvelles, ça tournait du feu de Dieu(pas que grâce à moi, hein, d'autres sont passés dessus depuis). Évidemment, ce n'est pas pour de l'interface. Tous ces vieux langages sont condamnés à ne faire que du serveur central, pendant que les jolis trucs pour les utilisateurs seront faits avec des frameworks javascript ou autre remplacés tous les deux ans.

Mais pour du serveur central(ou de l'embarqué, ou tout ce qui n'est pas directement au contact de l'utilisateur final), c'est hautement débuggué, c'est performant, les gens savent faire, l'existant est énorme et fonctionne nickel, pourquoi changer?
16/01/2018, 17h30
RyzenOC

Citation:

Envoyé par el_slapper

Mais pour du serveur central(ou de l'embarqué, ou tout ce qui n'est pas directement au contact de l'utilisateur final), c'est hautement débuggué, c'est performant, les gens savent faire, l'existant est énorme et fonctionne nickel, pourquoi changer?

Exactement, on ne change pas quelque chose qui tourne, on le maintient.
Mais si on te demande de faire un nouveau projet, le fera tu en cobol ? je pense que non.
Les nouveaux projets se font sur des technos "moderne" (pas la dernière techno du moment sur la dernière version fraîchement sortie hier, mais pas trop vielle non plus). Les nouveau projet se font en Java8/9, python 3.4/3.5/3.6, C++ > 11...etc des trucs sortie après 2010 au moins.

en 2018 plus personne ne fait un nouveau projet en python2.7 par exemple, mais il arrive de devoir maintenir du vieux code python2.7 parce que la migration est trop coûteuse.
16/01/2018, 17h41
Invité

Citation:

Envoyé par RyzenOC

en 2018 plus personne ne fait un nouveau projet en python2.7 par exemple

ça a changé par rapport à l'année dernière alors...
https://www.developpez.com/actu/1671...-Semaphore-CI/
16/01/2018, 17h54
ZenZiTone

Citation:

Envoyé par el_slapper

l'existant est énorme et fonctionne nickel, pourquoi changer?

Le seul point noir dans tout ça est que les anciennes technos réclament des compétences qui ne se renouvelles pas (ou pas suffisamment), ce qui entraîne dans le meilleur des cas à un surcoût en cas de maintenance.
16/01/2018, 18h08
liberal1

Citation:

À la fois C et C ++ vous permettent d'avoir (plus ou moins) le contrôle total du matériel

En quoi?
16/01/2018, 18h26
el_slapper

Citation:

Envoyé par RyzenOC

(.../...)Mais si on te demande de faire un nouveau projet, le fera tu en cobol ? je pense que non.(.../...)

ça dépend. Évidemment, si c'est une page blanche, la probabilité de partir sur autre chose est très forte. Mais si c'est un projet pour se brancher sur un existant en COBOL..... J'ai vu beaucoup plus de conversions JAVA ratées que réussies. Et pas mal de nouveaux projets en COBOL pour rajouter au COBOL existant, tous réussis. Le dernier en 2012, avant de changer de métier(et de partir au soleil).

Et pour l'avant dernier, en 2011, il s'agissait de données qui venaient du serveur JAVA, que je toutouillais, et que je renvoyais. en fion de projet, j'ai naïvement demandé si ça n'aurait pas été plus simple pour la maintenance de faire ça en JAVA , au lieu de se taper les transferts LINUX==>MVS==>LINUX. Réponse de la MOA : "vous étiez deux fois moins chers à l'estimation! et en plus, sur votre partie, vous n'avez dépassé que de 5%, les gens du JAVA ont tendance à dépasser de 30%". J'ai vérifié ses chiffres, ils étaient presque exacts. Sur un autre projet, plus petit, j'avais chiffré 15 jours, les Javaistes 25.

Je suis sur que des gens faisant du C ou du C++ auraient été très performants aussi. Mais, comme dit par ZenZiTone, ça ne se trouve pas facilement.
17/01/2018, 07h35
liberal1

Citation:

Envoyé par 23JFK

L'informatique est incrémentale, le type qui croit pouvoir bricoler en trois semaines un concurrent crédible à des logiciels cumulant trente à quarante ans d'améliorations continues opérées par des dizaines de milliers de personnes expertes va en être pour ses frais. En plus, le design C/C++ à quelque chose de vraiment efficace rendant le code plaisant à parcourir.

L'information est incrémentale : les inepties récentes du C++ s'ajoutent à celles plus anciennes et à celles du C.

Le type "en trois semaines" connait tous ces erreurs et s'il n'est pas totalement con ne va pas les refaire (mais certains concepteurs de langages semblent totalement cons).

C/C++ n'existe même pas, le sous ensemble commun des programmes valides dans les deux langages n'est pas intéressant. Déjà C n'existe pas, personne n'étant capable de dire quels usages d'une union sont valides. C++ encore moins.
17/01/2018, 13h58
gangsoleil

Citation:

Envoyé par RyzenOC

Les nouveaux projets se font sur des technos "moderne" (pas la dernière techno du moment sur la dernière version fraîchement sortie hier, mais pas trop vielle non plus). Les nouveau projet se font en Java8/9, python 3.4/3.5/3.6, C++ > 11...etc des trucs sortie après 2010 au moins.

You made my day.

Les OS qu'utilisent nos clients ne gèrent pas le C99, donc nous sommes obligés de compiler explicitement en C89.

Tu crois franchement que si on a un nouveau développement on va se demander s'il y a moyen d'utiliser les super-nouveaux langages à la mode qui changent de version tous les 3 mois ? Ou bien on reprend ce qui fonctionne et qui ne contient que les bugs que l'on fait (et donc pas ceux du compilateur/de la machine virtuelle/autre) ?
17/01/2018, 15h18
RyzenOC

Citation:

Envoyé par gangsoleil

You made my day.

Les OS qu'utilisent nos clients ne gèrent pas le C99, donc nous sommes obligés de compiler explicitement en C89.

Tu crois franchement que si on a un nouveau développement on va se demander s'il y a moyen d'utiliser les super-nouveaux langages à la mode qui changent de version tous les 3 mois ? Ou bien on reprend ce qui fonctionne et qui ne contient que les bugs que l'on fait (et donc pas ceux du compilateur/de la machine virtuelle/autre) ?

relis mon message :

Citation:

Les nouveaux projets se font sur des technos "moderne" (pas la dernière techno du moment sur la dernière version fraîchement sortie hier, mais pas trop vielle non plus).

Utiliser une techno un peu près à jour c'est des failles de sécurité corrigé et un support toujours valide.

Citation:

Les OS qu'utilisent nos clients ne gèrent pas le C99

le problème est peut être la.

Comme tous dans la vie faut évoluer à un moment donné.

Je ne suis pas partisan des framework web js qui change tous les mois. Mais je ne suis pas partisans non plus à rester dans du C89, il vaut mieu se diriger sur du C11

Honnêtement sa t'apporte quoi de coder en C89 ? tu sait que tes clients devrons (assez vite) changer d'os, car un truc qui a plus de 20ans a un moment il sera remplacé. Et quand ce jour arrivera ton client devra repasser à la caisse parceque le code en C89 de gangsoleil ne sera pas fonctionnel sur des systèmes récents.
Il faut faire le calcule entre maintenir un vieux truc ou le remplacer, a un moment donné il faut remplacer c'est moins cher.

J'ai eu un problème similaire récemment, une machine Linux avec que python2.7 d'installé. Je l'ai forcé à rajouté python 3.5 et j'ai codé le programme en python3.
Il a compris que le support python2.7 se termine en 2020 et que si il ne voulait pas devoir refaire mon code dans 3-4ans il avait intérêt à installer python3 (qui fonctionne en parallèle de 2.7)
Il est important de faire comprendre au client l'importance d'utiliser les dernières/avant dernière versions quand on développe un nouveau projet.
17/01/2018, 15h57
foetus

Citation:

Envoyé par RyzenOC

Et quand ce jour arrivera ton client devra repasser à la caisse parceque le code en C89 de gangsoleil ne sera pas fonctionnel sur des systèmes récents.

Justement, C/ C++ produit du binaire et n'a rien à faire du système d'exploitation/ de l'environnement dans lequel l'exécutable travaille.
Donc le méga pire scénario, tu auras toujours un exécutable qui fonctionnera quelque part :mrgreen:

Et ensuite, coder "aussi vieux" permet d'être compatible avec la majorité des compilateurs qui existent.

Python 2.7 sera mort lorsque la V.M. 2.7 sera retirée des dépôts :mrgreen:
17/01/2018, 16h08
Invité

Citation:

Envoyé par foetus

Python 2.7 sera mort lorsque la V.M. 2.7 sera retirée des dépôts :mrgreen:

Même pas car on pourra toujours le télécharger et l'installer à la main.
D'ailleurs, c'est encore le cas pour Python 1.6 : https://www.python.org/download/releases/1.6.1/
17/01/2018, 16h55
gangsoleil

Citation:

Envoyé par RyzenOC

Honnêtement sa t'apporte quoi de coder en C89 ?

Ce que ça m'apporte ? Le fait que les clients puissent l'installer... Donc en gros, ça nous apporte des clients (et pas des petits pour info).

Citation:

Envoyé par RyzenOC

tu sait que tes clients devrons (assez vite) changer d'os, car un truc qui a plus de 20ans a un moment il sera remplacé.

OS mis à jour régulièrement, pas de soucis. Supporté par IBM, avec des évolutions régulières.

Citation:

Envoyé par RyzenOC

Et quand ce jour arrivera ton client devra repasser à la caisse parceque le code en C89 de gangsoleil ne sera pas fonctionnel sur des systèmes récents.
Il faut faire le calcule entre maintenir un vieux truc ou le remplacer, a un moment donné il faut remplacer c'est moins cher.

Tu prends le truc à l'envers : le code C89 fonctionne sur les anciens systèmes comme sur les plus récents, contrairement au C11 qui n'est pas compatible avec certains OS.

C'est bien là mon soucis : entre python 2.7 et 3.2, il y a eu une rupture d'interface qui fait que les programmes utilisant certaines fonctionnalités de la 2.7 doivent être ré-écrits en 3.2 (ou supérieure). Mais pourquoi faire, volontairement, une telle rupture ? Apporter de nouvelles choses à un langage, c'est bien, mais supprimer les "anciennes" fonctionnalités utilisées dans beaucoup de programmes, vraiment, je ne vois pas de raison.
17/01/2018, 17h26
Lyons

Citation:

Mais pourquoi faire, volontairement, une telle rupture ? Apporter de nouvelles choses à un langage, c'est bien, mais supprimer les "anciennes" fonctionnalités utilisées dans beaucoup de programmes, vraiment, je ne vois pas de raison.

Parce que l'Histoire nous a appris qu'essayer de conserver la rétrocompatibilité sur 30 ans donne des software / langages inutilement lourds et complexes? c.f Windows ou C++.
17/01/2018, 17h50
Invité

Citation:

Envoyé par Lyons

Parce que l'Histoire nous a appris qu'essayer de conserver la rétrocompatibilité sur 30 ans donne des software / langages inutilement lourds et complexes? c.f Windows ou C++.

Dommage que ça ne s'applique pas au hardware (amd64 est compatible avec x86, qui date de 1978), ça nous aurait peut-être évité spectre et meltdown...
17/01/2018, 18h22
jpouly

Citation:

Envoyé par SimonDecoline

... mais sur les projets d'électronique ou informatique industriel si.

C'est bien ce que je dis.

Citation:

Envoyé par SimonDecoline

D'ailleurs tous les supercalculateurs, les moteurs de jeu, les systèmes temps-réel etc sont en train de passer à PHP... et ça ne m'étonnerait pas que Mozilla laisse tomber rust pour redévelopper firefox en PHP...

On fait un concours. Tu prend ton C++ et tu me fait une appli de gestion avec une base de données de ton choix, avec une IHM web ou Windows/Linux. Prêt. Partez!
... Fini :ptdr:

Citation:

Envoyé par SimonDecoline

Oui c'est bien connu que le C n'est pas portable en pratique.. c'est même pour ça que netbsd, qui tourne sur à peu près tous les cpu du monde, est codé en swift...

Il ne faut pas confondre portabilité et cross-compilation : essaye de compiler netBSD avec le compilateur C d'HP-UX et on en reparle :aie:.

La portabilité d'un code ne se définit pas par l'utilisation de GCC :ptdr:.
17/01/2018, 18h45
jpouly

Citation:

Envoyé par kilroyFR

Productif certes car on en a fait des langages au niveau du Visual Basic en simplifiant tout ce qui etait jugé "complexe".
La seule chose pour laquelle je suis d'accord avec toi c'est que le GC est la plus grosse abomination (pour simplifier le boulot des devs faineants qui ne savent pas maitriser un malloc/free).
Pour le reste si tu fais que des applis de gestion effectivement tu peux considerer que le C# est suffisant.
Par contre des que tu fais des applis embarquées necessairement le C/C++ s'impose naturellement. On le vit tous les jours dans ma boite. Le seul endroit ou on a mis du C# c'est sur l'IHM; tout le reste on a laissé tombé car trop lent (c'est tout relatif mais sur un equipement qui doit repondre a tout moment en quelques millisecondes le C# pèche).

Les applis embarqués sont effectivement un des domaines de prédilection du C/C++.

Citation:

Envoyé par kilroyFR

Ce que je constate dans ma boite c'est que c'est facile de sous traiter en offshore (inde) tous les devpts Serveur/frontend mais tout ce qui touche a l'embarqué c'est beaucoup plus difficile. Du coup ca reste chez nous. Aujourd'hui pour faire du devpt standard (appli gestion) sur PC, c'est a la portee de n'importe qui (meme les debutants en informatique puisqu'ils ont l'impression d'etre les rois du monde en ne maitrisant pourtant pas grand chose).

Non, Développer des applications de gestions n'est pas à la portée de n'importe qui ! Il faut concevoir la base de données, étudier la volumétrie et son évolution dans le temps, optimiser les requêtes, définir les couches logiciels, les développer, ...

Certes, il y a des outils pour automatiser et simplifier tout ça. Mais quand tu te retrouve avec une base de plusieurs gigas en production avec des utilisateurs qui t'incendient en permanence parce que ton appli est trop lente, et bien tu jette ces outils merveilleux et tu reprend à la base.

Citation:

Envoyé par kilroyFR

Quand je vois le niveau des devs C# (je viens du ASM/C/C++ a la base), ca en est risible quand je vois le niveau de comprehension de ce qu'il font.
Heureusement pour nous ces devpts sont de plus en plus sous traités en offshore car ont tres peu de valeur ajouté face a des devps C/C++ qui sont proches du hardware et sont necessairement obligé de comprendre ce qu'ils font (programmation avec fortes contraintes perf/optimisation etc cad tout le contraire de ce que je vois usr les nouveaux devpt C#).

C'est simplement que le niveau de tes sous-traitants est mauvais. La maintenance des applications va en prendre un coup :aie:.
17/01/2018, 20h13
kilroyFR

Citation:

Envoyé par jpouly

C'est simplement que le niveau de tes sous-traitants est mauvais. La maintenance des applications va en prendre un coup :aie:.

Je ne crois pas qu'ils soient plus mauvais que la moyenne. D'ailleurs ils reprennent leur soft quand ca chie; dans tous les cas ils coutent toujours moins cher qu'un dev en metropole (salire /4 au minimum pour nos sous traitants a l'ile maurice, beaucoup plus pour les indiens qui ne sont pas reputés pour etre les plus mauvais en dev sur PC).
Et des devs avec un ego surdimensionné qui se croient des super developpeurs on en a vu passer des tonnes (WPF, SL etc) et la maintenance logiciel derriere les usines a gaz fabriquées ne valent pas mieux.
18/01/2018, 08h35
el_slapper

Citation:

Envoyé par gangsoleil

(.../...), mais supprimer les "anciennes" fonctionnalités utilisées dans beaucoup de programmes, vraiment, je ne vois pas de raison.

Ben, en COBOL, dans les temps anciens, il y avait une syntaxe qui s'appellait ALTER PROCEED, et dont la fonction était de modifier la cible d'un GO TO. Est-ce que tu comprends pourquoi ça a été banni, malgré les problèmes de rétro-compatibilité que cela a entrainé?
18/01/2018, 10h24
LordMacharius

Citation:

Envoyé par liberal1

L'information est incrémentale : les inepties récentes du C++ s'ajoutent à celles plus anciennes et à celles du C.

Le type "en trois semaines" connait tous ces erreurs et s'il n'est pas totalement con ne va pas les refaire (mais certains concepteurs de langages semblent totalement cons).

C/C++ n'existe même pas, le sous ensemble commun des programmes valides dans les deux langages n'est pas intéressant. Déjà C n'existe pas, personne n'étant capable de dire quels usages d'une union sont valides. C++ encore moins.

Liberal1, tu sembles oublier que beaucoup de ces langages modernes héritent du C. PHP, C++ etc ont été développé en C puis lorsque des technos plus intéressantes sont apparus ils ont été migré dessus.
Dire que C/C++ n'a pas de sous-ensemble commun me fait dire que tu n'as pas beaucoup développer avec. La syntaxe est très proche, le typage de base aussi etc.

Le C et le C++ ne sont pas parfaits mais les autres langages aussi. Encore une fois tout dépend de ton cas d'utilisation.

De quelles inepties parles-tu ? Dans quel contexte ?

Voir 40 message(s) de cette discussion en une page