Discussion :

[koyosama]

Une vieille vidéo : Javapocalypse THE JAVA dooms day

J'avais déjà vu la vidéo. Ils ont pas réussi a tuer compleètement IE6 donc j'ai du mal à croire à Java. Je discute avec un Etudiant au Canada qui avait C# au collège. Et qu'il a dû arreter car tous ces amis faisaient du Java.
A chaque nouveau langage on me dit la même chose mais au final bof.

J'attends toujours le fameux MEAN remplace LAMP, hum hum. J'atttends ... En plus ici, on me bassine avec blockchain, GraphQL, RestQL, chatbot, AI et react alors que trois quarts alors que leur produits ne sont pas extraordinaires.

[RyzenOC]

J'avais déjà vu la vidéo. Ils ont pas réussi a tuer compleètement IE6 donc j'ai du mal à croire à Java. Je discute avec un Etudiant au Canada qui avait C# au collège. Et qu'il a dû arreter car tous ces amis faisaient du Java.

Sa me rappelle cette video

[kilroyFR]

Non. Le .net ou le PHP sont tout aussi efficace et beaucoup plus productif.

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# peche).

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).
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#).

[Jipété]

Sa me rappelle cette video

Ah non, tu vas pas recommencer, par pitié ! Pourtant il y a deux jours c'était parfait...

Ou alors vous êtes plusieurs sous ce pseudo ?

[Invité]

Ah non, tu ne vas pas recommencer, par pitié !

[grunk]

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).

Je connais pas un dev qui à pas oublié un free à un moment dans son code. T'as beau être un monstre du C++ ça arrive, c'est pas une question d'être fainéant ou pas.
Je pense d'ailleurs que c'est une très bonne chose que le C++ est introduit les smart pointer pour les usages "simples" qui ne nécessite pas d'optimisation particulière.

[ZenZiTone]

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# peche).

Attention a ne pas jeter la pierre sur les langages haut niveau non plus. Ils n'ont pas le même objectif.. C'est comme si on parlait d'une Zoé sur un circuit de formule 1 De là, il n'y a pas vraiment de débat dans le sens où les deux langages sont performants dans les domaines qui leur sont propre.

[EDIT] Après relecture, on dit la même chose !

[RyzenOC]

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).

Je ne suis pas d'accord. Au lieu de se concentrer sur ces choses, on peut se concentrer sur les besoins métier.
C'est de la folie de faire une app desktop/mobile avec IHM en C. On préféra utiliser un langage haut niveau qui gère automatiquement des structures complexe (liste, objet...)
Et s'il vous plait, ne me dite pas que C est un langage orienté objet. On peut faire des objets en C oui... mais c'est pas conçue pour.

Les langages haut niveau c'est d'autre paradigmes, comme la programmation fonctionnelle en scheme, la programmation objet en Java/Python (qui introduit pleins de concept comme les classes, sous-classe, l'héritage...)

et je ne parle pas des langages spécialisé comme le PHP, que dire de PHP alors ? c'est un langage pour les incapables de créer un serveur web en C ?

Et si je suis ton raisonnement, le C est un langage de fainéant. Car a la base C c'était justement pour les fainéant qui voulait pas coder en assembleur.

Et parlons de l'aspect sécurité aussi.... en C tu doit faire gaffe à la gestion de ta mémoire. Que PHP + un framework te facilite le travail.

[LordMacharius]

Ce qui ressort de toutes nos remarques c'est que le C et le C++ répondent à des besoins précis et que malgré des nouveaux langages créer pour les concurrencer ils restent les plus équilibrés en terme de performances/contraintes/maintenabilités.

Effectivement il y a des besoins où ils ne répondent pas présent et où la gestion de la mémoire est superflue ce qui les rend complètement inappropriés pour les taches de gestion entre autres, mais dès que les ressources sont limitées ils font le job mieux que les autres d'un point de vue global avec plus de documentations, de personnes formées ...

Le C et le C++ ont encore de beaux jours devant eux non pas à cause des nombreux projets qui dépendent de ces langages mais bien pour le besoin qu'ils comblent et qui fait que ces langages ne sont pas facilement remplaçable.
Bien entendu cela forme un tout donnant toute sa puissance au C et au C++ qui sont relativement stables comparés aux autres langages qui évoluent plus vite et qui rendent une maintenance et une évolution de version plus difficile le temps de mettre les personnes à jours sur les évolutions.

[jlliagre]

Et si je suis ton raisonnement, le C est un langage de fainéant. Car a la base C c'était justement pour les fainéant qui voulait pas coder en assembleur.

On peut voir les chose comme ça, mais la fainéantise se doit d'être l'une des qualités d'un bon développeur (mais pas la seule ), l'objectif étant d'être rapide et efficace quand on code et pas de brûler des calories.

C a bien été conçu pour éviter de coder en assembleur. L'objectif était d'apporter la plupart des capacités bas niveau de l'assembleur avec un langage portable, indépendant du processeur utilisé. Il ne fallait pas être obligé de réécrire tout ou partie d'Unix à chaque fois qu'un nouveau processeur voyait le jour.

Les trois premières versions d'Unix étaient écrites en assembleur et il fallait maintenir une version pour PDP/7 et une autre pour PDP/11-20.

En 1973, la version 4 a été réécrite en C et a permis de démontrer qu'il était possible d'écrire un système d'exploitation et surtout un noyau en autre chose que de l'assembleur, ce qui était révolutionnaire à l'époque alors que c'est une évidence aujourd'hui.

Sinon, je n'ai rien contre les langages à GC. Les algorithmes se sont améliorés au fil du temps. On surestime souvent leur impact sur les performances. Si on accepte une empreinte mémoire plus grande, le GC peut être compétitif par rapport aux malloc/free ou new/delete mais ce n'est bien sûr pas la meilleure solution partout et dans toutes les occasions.

[RyzenOC]

On peut voir les chose comme ça, mais la fainéantise se doit d'être l'une des qualités d'un bon développeur (mais pas la seule ), l'objectif étant d'être rapide et efficace quand on code et pas de brûler des calories.

donc paresseux pas fainéant (oui je sais je joue sur les mots )

[jlliagre]

Ca se discute, mais c'était bien sûr une boutade. J'aurais du écrire "partisan du moindre effort". Un développeur qui ne développe rien et/ou qui n'aime pas développer ne risque pas d'être un bon développeur.

[Aurelien.Regat-Barrel]

Sinon, je n'ai rien contre les langages à GC. Les algorithmes se sont améliorés au fil du temps. On surestime souvent leur impact sur les performances. Si on accepte une empreinte mémoire plus grande, le GC peut être compétitif par rapport aux malloc/free ou new/delete mais ce n'est bien sûr pas la meilleure solution partout et dans toutes les occasions.

Les GC sont des outils efficaces et performant (avec un nombre réduit de threads et moyennant le double de mémoire théoriquement nécessaire ce qui est ok de nos jours dans beaucoup de cas). Leur principal problème c'est qu'ils ne gèrent que la mémoire, qui est une ressource parmi d'autres. Les fichier, socket, mutex, etc... ne sont pas concernés et doivent être gérés correctement à la main comme les bon vieux malloc/free.

L'approche RAII (C++, D...) est une réponse élégante, robuste, performante et universelle au problème de la gestion des ressources. D'ailleurs, depuis C++14 (standardisation de make_unique), un code C++ moderne ne devrait pas contenir de delete explicite ni même de new (ils devraient être encapsulés dans des classes utilitaires). Un code C++ récent qui contient des malloc/free new/delete est aujourd'hui considéré comme médiocre.

[kilroyFR]

Et si je suis ton raisonnement, le C est un langage de fainéant. Car a la base C c'était justement pour les fainéant qui voulait pas coder en assembleur.

certainement pas ce que j'ai dit; pas un langage de faineant; C est un langage de productivité comparé a l'assembleur (taux d'expansion du code entre C et ASM : 1.1 donc tres proche mais pourtant beaucoup plus facile d'acces). J'ai commencé par l'assembleur pendant 2 ans alors le passage au C s'est fait ensuite avec tres grand plaisir et beaucoup de bonheur a l'epoque.

[jlliagre]

Les GC sont des outils efficaces et performant (avec un nombre réduit de threads et moyennant le double de mémoire théoriquement nécessaire ce qui est ok de nos jours dans beaucoup de cas). Leur principal problème c'est qu'ils ne gèrent que la mémoire, qui est une ressource parmi d'autres. Les fichier, socket, mutex, etc... ne sont pas concernés et doivent être gérés correctement à la main comme les bon vieux malloc/free.

Un langage qui me plait bien est le Go. Il dispose d'un GC avec des latences très faibles et dont personne ne se plaint, la priorité étant donnée au code de l'utilisateur par rapport à toute autre considération. Pour la libération de ressources autres que la mémoire, dispose de l'instruction "defer" qui permet de bien simplifier le problème. Dès qu'on crée avec succès quelque chose qui devra être libéré, comme un fichier, une socket, etc on défère tout de suite sa destruction et on n'a plus à se poser de questions. Le seul défaut est que la libération s'effectuera à la sortie de la fonction courante. On ne peut donc pas mettre le defer dans un "constructeur", c'est à l'appelant de le faire.

[AoCannaille]

C, C++, Java , Php, rust, python ou tout autre langage conventionnels vont disparaître à moyen terme (10 ans? 15 ans?) dés que les ordinateurs quantiques débarqueront massivement sur le marché. Ceux-ci se programment avec des logiques différentes et donc des langages différents sur des OS différents.

Aucun ne survivra à long terme.

[RyzenOC]

C, C++, Java , Php, rust, python ou tout autre langage conventionnels vont disparaître à moyen terme (10 ans? 15 ans?) dés que les ordinateurs quantiques débarqueront massivement sur le marché. Ceux-ci se programment avec des logiques différentes et donc des langages différents sur des OS différents.

Aucun ne survivra à long terme.

encore faudrait t'il que :
1) on arrive a faire des ordinateurs quantique de la taille des pc fixe d'aujourd'hui (le problème c'est qu'il faut le refroidir au 0 absolue donc -273°)
2) Qu'il y'ait un interet pour cette techno dans le dommaine du grand publique.

Car ce que tu dis c'est comme dire "Les gpu vont remplacer les cpu dans 15ans"
On sait aujourd'hui que ce n'est pas possible, il faut un cpu pour faire booter un os on peut pas faire sans.
Et mème si c’était possible, beaucoup de programme ne sont pas parallélisable, un jeu sans un bon cpu avec une bonne puissance monocoeur tourne très très mal.

Pour l'instant les ordinateur quantique ne peuvent faire tourner que des algorithme bien spécifiques. Tu peut pas programmer une IHM ou un navigateur web dessus.
A terme je les verrais plutôt comme des co-processeur venant prêter main forte pour certain algorithme en plus du CPU et du GPU, t'aura une troisième carte une "Quantum card"

[grunk]

C, C++, Java , Php, rust, python ou tout autre langage conventionnels vont disparaître à moyen terme (10 ans? 15 ans?) dés que les ordinateurs quantiques débarqueront massivement sur le marché. Ceux-ci se programment avec des logiques différentes et donc des langages différents sur des OS différents.

Aucun ne survivra à long terme.

Tu peux rajouter encore quelques dizaines d'années . Les ordinateurs quantique ne sont aujourd'hui pas en mesure de faire ce que fait un ordianteur "classique". Ils peuvent être extrêmement performant sur une tache données (avec une marge d'erreur) mais ne savent pas (encore) tout faire.
En revanche ce qu'il n'est pas exclu de voir apparaître dans un futur plus ou moins proche c'est des puces quantiques en plus des CPU classique pour par exemple gérer la cryptographie.
On pourrait alors travailler avec des niveaux très élevés de sécurité sans pour autant passer 2 jours à générer un hash par exemple.

[LordMacharius]

C, C++, Java , Php, rust, python ou tout autre langage conventionnels vont disparaître à moyen terme (10 ans? 15 ans?) dés que les ordinateurs quantiques débarqueront massivement sur le marché. Ceux-ci se programment avec des logiques différentes et donc des langages différents sur des OS différents.

Aucun ne survivra à long terme.

Je ne suis pas d'accord avec toi.
Le temps de l'adoption générale des ordinateurs purement quantique n'est pas venu. Je ne pense pas le voir de mon vivant vu les difficultés que cela pose.
Par contre avoir des modules/carte quantique spécialisé pour une utilisation c'est beaucoup plus réaliste, typiquement pour les cartes réseau ?

Une chose est certaine, nos connaissances en informatique seront bouleversées par la logique quantique et sa puissance.

[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 ...