Discussion :

[walfrat]

Ma pensée sur le sujet :

https://xkcd.com/927/

[23JFK]

Ça à l'air d'être un beau baratin commercial affirmant tout et son contraire.

[Invité]

Rust est un substitut au C et pas vraiment au C++. Par ailleurs, le gros intérêt du C++ est son support natif du C. De fait, je ne vois pas bien l'intérêt d'un nouveau langage objet qui ne serait pas compatible avec Rust.

[progz_du_dimanche]

Kotlin à vraiement remplacer Java ?

[smarties]

Kotlin à vraiement remplacer Java ?

Sur Android en partie
En Web, je dirais que c'est plutôt Go

Mais JAVA est encore énormément utilisé

Il aurait peut été été plus judicieux d'enrichir RUST (langage, bibliothèques, documentation, best practices, exemples) plutôt que de créer un autre langage

[dourouc05]

Il aurait peut été été plus judicieux d'enrichir RUST (langage, bibliothèques, documentation, best practices, exemples) plutôt que de créer un autre langage

Cette option a aussi été étudiée (et continue à l'être, vu que Google s'investit de plus en plus dans Rust : https://opensource.googleblog.com/20...oundation.html, par exemple). D'ailleurs, ils déconseillent Carbon si tu peux utiliser Rust : https://github.com/carbon-language/c...d#why-not-rust. Vu que Carbon est expérimental, il fera peut-être long feu et sera abandonné au profit de Rust.

[jpouly]

Je ne comprend pas cette obstination à vouloir remplacer le C/C++ par un autre langage.

Je ne comprend pas l’intérêt de trop modifier la philosophie des langages d'ailleurs (ex du .net avec les référence non-nullable ).

J'ai l'impression que c'est une fuite en avant ,et qu'il faut innover pour innover.

ça me rappel les requins, qui continuent à nager en dormant, sinon il s’étouffent.

[smarties]

Je ne comprend pas cette obstination à vouloir remplacer le C/C++ par un autre langage.

Pour avoir fait un peu de C et de C++ il y a eu des problèmes très agaçants :
- les bibliothèques non portées sur différents OS et une compilation pas toujours facile, sur RUST c'est beaucoup moins le cas
- une syntaxe pas toujours lisible, avec RUST il faut plutôt comprendre certains concepts
- des fuites mémoires pas toujours facile à trouver
- un manque d'industrialisation, quand je vois Cargo et la facilité d'écrire des tests unitaires en RUST, je me demande si les autres langages ont pensé à mettre ça dans leur feuille de route (OK pour les dépendances, JAVA a Maven, Go a quelque chose de similaire, Python a pip, ...)

PS : je suis développeur python

[Madmac]

Je ne comprend pas cette obstination à vouloir remplacer le C/C++ par un autre langage.

J'ai l'impression que c'est une fuite en avant ,et qu'il faut innover pour innover.

Parce que C++, ressemble de plus en plus à un amalgame de langage, qu'à un seul langage. Et c'est devenu plus qu'évident avec les templates.

Moi ce qui me dérange le plus est qu'ils me semble pas avoir une idée très clair de la direction de l'évolution. Plutôt que de tenter de modifier le language, il devrait développer un surchose pour rendre le langage plus accessible et moins sujet aux fuites. J'ai jamais compris la raison pour laquelle, personne n'a développer une librairie pour faire du pure objet en C++. En pratique, la programmation avec de tel outil ne représenterait un niveau de difficulté plus élévé que de programmer en Python ou Ruby.

[grunk]

Moi ce qui me dérange le plus est qu'ils me semble pas avoir une idée très clair de la direction de l'évolution. Plutôt que de tenter de modifier le language, il devrait développer un surchose pour rendre le langage plus accessible et moins sujet aux fuites. J'ai jamais compris la raison pour laquelle, personne n'a développer une librairie pour faire du pure objet en C++..

Depuis C++11 tu as les smartpointer qui permettent dans la grande majorité des cas de ne pas faire de fuite mémoire puisqu'on à plus gérer la désallocation
Et au contraire je trouve que la direction de C++ est très claire => faciliter son utilisation et se rapprocher des langages de plus haut niveau dans l'utilisation tout en gardant les performances qui font le succès de C++.

Entre du C++98 et du C++20 c'est le jour et la nuit.

Pour moi le gros défaut de C++ c'est qu'il y'a des dizaines de façon différentes de faire la même chose en fonction du niveau d'optimisation qu'on veux atteindre. Ca rend les choses extrêmement compliqué et la courbe d'apprentissage plutôt raide.
Je me débrouille en C++ et parfois je me mets à lire le code de certaines lib (genre boost) et je me rend compte que je suis une sous merde parce que je ne comprend pas la moindre ligne de ce que je lis

[AoCannaille]

Je me débrouille en C++ et parfois je me mets à lire le code de certaines lib (genre boost) et je me rend compte que je suis une sous merde parce que je ne comprend pas la moindre ligne de ce que je lis

ça me fait plaisir de lire ça, je suis exactement dans le même cas ^^' ça soulage un peu mon syndrome de l'imposteur

[Fagus]

Pour moi le gros défaut de C++ c'est qu'il y'a des dizaines de façon différentes de faire la même chose en fonction du niveau d'optimisation qu'on veux atteindre. Ca rend les choses extrêmement compliqué

C'est peut être justement pour ça que google a lancé des langages neufs simplifiés comme go. Justement pour que les gens arrêtent d'être créatifs en écrivant un code génial que personne d'autre n'arrive à comprendre, ce qui arrive assez vite grâce à 50 ans d'héritage, sans compter les concepts qui cachent du code comme la surcharge...

Plus haut quelqu'un a dit que c'est dommage d'avoir retiré l'héritage multiple. Ben oui, ça sert, mais quand on se retrouve avec un objet qui hérite de 25 autres classes avec des schémas tordus, ça augmente les chances d'avoir un comportement différent de ce qu'on avait imaginé.
J'imagine que c'est dans ce but qu'ils l'ont enlevé.

There should be one– and preferably only one –obvious way to do it.

ça, c'était dans le zen de python. Je ne suis pas sûr que c'était vrai un jour, mais avec le temps et l'accumulation d'améliorations, c'est forcément de moins en moins vrai (juste pour dire que c'est sans doute une sorte de cycle. Devant un vieux langage complexe plein d'héritage, des gens créent un nouveau langage plus simple, mais finalement empilent des améliorations et tout recommence. C'est pour ça qu'il ne faut écrire qu'avec deux instructions : if et goto )

[Madmac]

Depuis C++11 tu as les smartpointer qui permettent dans la grande majorité des cas de ne pas faire de fuite mémoire puisqu'on à plus gérer la désallocation
Et au contraire je trouve que la direction de C++ est très claire => faciliter son utilisation et se rapprocher des langages de plus haut niveau dans l'utilisation tout en gardant les performances qui font le succès de C++.

Si cela introduit un ramasse-miette comme je le suppose, ce n'est pas un progrès pour le langage. Mais un handicap.

Quand je parle d'absence de vision. Je fais référence que rien n'est pensé pour rendre le langage plus simple à programmer. Plus élégant et plus facile à comprendre. Par exemple, le type auto aurait être du introduit depuis le début de son existence. La déclaration de type pour les variables est une redondance qui rend l'écriture plus lente et beaucoup moins organique.

Par exemple

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

 len := "bonjour".size

À l'intérieur d'un langage pur objet, la déclaration de type est inutile. L'information nécessaire pour l'analyseur syntaxique se trouve à la droite du ':='. Mais ce qui complique les choses en C++ est la présence des types de base (int , char, double, etc) et des objets.

Étant donné qu'un objet est toujours accédé par un pointeur, le compilateur n'a pas besoin d'avoir d'information sur la taille de la variable. Tous ce qu'il a besoin de savoir est que la variable va contenir un objet (en pratique, un pointeur).

Je pourrais déclarer le type de len, mais cela nous amène au deuxième problème, l'aspect inorganique des types. En principe, len serait un "long int". Mais imaginons que le type "long int" disparaissent pour simplifier les CPUs. Cette ligne de code cesse d'être compilable.

Maintenant imaginons que len est de type auto, la ligne de code reste compilable. Mais si on utilise à profusion "auto" , la fabrication d'un débogueur devient un cauchemar, car les types de base ne contiennent pas de descripteur. Et pour le débogueur, il est essentiel de savoir si la variable est un nombre ou une chaîne de caractères pour pouvoir représenter l'information.

Donc le type auto est une solution qui apporte également beaucoup de problèmes. Il y a un langage préhistorique qui avait solutionné ce problème; Le Basic !

L'analyseur syntaxique a besoin d'une déclaration de type pour fonctionner. Mais on pourrait tricher sans changer radicalement l'analyseur en ajoutant des variables typés par la syntaxe. Par exemple: la notation %len indiquerait une variable numérique, $name une chaîne, ^monObj un objet. La notation pourrait-être différente, mais je crois que tu saisies l'idée générale.

Ruby a développé plusieurs nouvelles avenues pour rendre le code organique qui pourrait-être intégré à C++:

Impression d'un tableau en C++

Code C++ :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
void printArray(int* arr, int n)
{
    int i;
 
    cout << "Array: ";
    for (i = 0; i < n; i++)
    {
        cout << arr[i] << "  ";
    }
}

En Ruby 3 avec un For

Code Ruby :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
def printArray(arr)
   puts 'Array'
   for i in (0...)
    puts arr[i]
   end
end

Ce qui est révolutionnaire est cette ligne:

Code Ruby :

Sélectionner tout - Visualiser dans une fenêtre à part

 for i in (0...)

Car elle fait en sorte que la fonction en Ruby printArray(arr) n'a pas besoin de la variable de paramètre n, est beaucoup plus compacte (pas d'itérateur), et plus rapide à écrire, grâce à l'utilisation d'intervalle.

Je pourrais aborder la syntaxe tordue pour faire des fonctions lambda, qui est une autre horreur syntaxique, tout comme les templates. Mais cela pourrait troubler mon estomac.

Mais je crois que le langage pourrait faire un saut en avant en adoptant comme convention, l'abandon des types base pour les variables. Et l'abandon de la librairie Boost et le remplacement par une classe interne String pour gérer les incompatibilités entre OS et ajouter un support implicite pour unicode. Dans le lingo des experts: Rendre le langage horizontalement et verticalement compatible (horizontalement: MacOs,Win, Linux) (verticalement: serveur, ordinateur de bureau)

Quand je parle d'absence de vision, je crois que j'aurais dû plutôt mentionner une étroitesse de vision qui ignore les nouvelles idées introduites par d'autre langages.
C++ est probablement un des rares langages de programmation où le programmeur a encore à se soucier du type de fin de ligne. Les langages objets excellent à solutionner ce genre de problème par l'utilisation d'abstraction. Mais ce problème existe depuis sa création !

[mintho carmo]

En fait, tu ne connais pas le C++. Beaucoup trop d'erreurs et tu ne comprends pas les problématiques du typage. Ni celles de la standardisation ISO.

Et pour info :

Code C++ :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
void printArray(auto arr) // bof auto ici, mais c'est pas l'important
{
    cout << "Array: ";
    for (auto i: arr)
    {
        cout << i << "  ";
    }
}

[grunk]

Si cela introduit un ramasse-miette comme je le suppose, ce n'est pas un progrès pour le langage. Mais un handicap.

Ce n'est pas un ramasse miette comme on peut en trouver en java mais simplement une comptge de référence par chaque pointer. Quand le nombre de référence tombe à 0 le pointer s'auto détruit. Ca ajoute un léger overhead par rapport à un pointer normal (en terme de taille) mais dans la majorité des cas c'est acceptable. Les situation cible ou ca peut être un problème sont de toute manière généralement développées en C.

Quand je parle d'absence de vision. Je fais référence que rien n'est pensé pour rendre le langage plus simple à programmer. Plus élégant et plus facile à comprendre. Par exemple, le type auto aurait être du introduit depuis le début de son existence. La déclaration de type pour les variables est une redondance qui rend l'écriture plus lente et beaucoup moins organique.

A la vue de tes exemples je pense que tu ne pratique pas suffisamment le C++ ou en tout cas pas du C++ dit moderne.
Oui clairement C++ ne deviendra pas Python,Ruby ou un langage fonctionnel en terme de syntaxe (et tant mieux j'ai envie de dire) , mais on est bien loin de ce qu'il a pu être.

[helix_tp]

Pourquoi pas s'investir dans un trans compilateur C++ vers Rust, plutôt que d'un ème langage.

[selmanjo]

Le C/C++ toujours difficile à compiler, je préfère et suggère qu'on mette en place un excellent gestionnaire de dépendances pour que nos programmes puissent compiler à tous moments.

Car Carbon, n'est pas encore bon. Les langages ultra modernes et nouveaux se ressemblent de plus en plus syntaxiquement, surtout venant de Google.
Le mieux est d'enrichir Rust, et Carbon suivra.

[Madmac]

Ce n'est pas un ramasse miette comme on peut en trouver en java mais simplement une comptge de référence par chaque pointer. Quand le nombre de référence tombe à 0 le pointer s'auto détruit. Ca ajoute un léger overhead par rapport à un pointer normal (en terme de taille) mais dans la majorité des cas c'est acceptable. Les situation cible ou ca peut être un problème sont de toute manière généralement développées en C.

Non c'est un des plus anciens type de ramasse miette
https://www.geeksforgeeks.org/mark-a...ion-algorithm/

Et l'overhead n'est pas négligable. Il faut faire un mark and sweep à la sortie de chaque fonction pour réduire la fragmentation de mémoire.

A la vue de tes exemples je pense que tu ne pratique pas suffisamment le C++ ou en tout cas pas du C++ dit moderne.
Oui clairement C++ ne deviendra pas Python,Ruby ou un langage fonctionnel en terme de syntaxe (et tant mieux j'ai envie de dire) , mais on est bien loin de ce qu'il a pu être.

Honnêtement, je n'utilise pas les nouvelles fonctionnalités du C++, car j'ai continué à programmer comme un programmeur d'Object-Pascal. Avec un minimum d'accesseur.
Je ne dis pas que le langage doit devenir un langage pure objet. Mais si on donnais une bibliothèque standard qui permettait d'avoir 95% des performances habituelles pour un niveau de complexité comparable à Ruby ou Python, les programmeurs perdraient beaucoup moins de temps à apprendre de nouveaux langages inutilement. Et personne n'aurait eu à inventé le Objective C. Je suis arrivé au C++ après avoir programmer en Object-Pascal. Et j'ai trouvé l'apprentissage ardu car pour pouvoir adapter mes programmes, j'ai du me taper cet exercice.

Après tout il y a peu de chose qui ne peuvent-être fait en C++. Et s'il existe des cas, c'est à ce niveau que la réforme du langage devrait apporté de solution. Parce contre, il n'existe aucune raison valable pour expliquer que l'on ne puisse faire en C++ ce que peut-être fait en SmallTalk. La bibliothèque de Smalltalk existe depuis les années 80.
Le support pour la sérialisation n'existe toujours pas en bibliothèque standard ...

Linux Torvals a déjà déclaré qu'il ne pourrait pas écrire du code aussi rapide en C++ qu'en C. Est-ce que ces réformes ont réglé ce problème? Probablement pas.
J'ai regardé plusieurs vidéos sur la réforme du langage. J'ai rien vu d'excitant comme Erlang. Conclusion pas de gain sensible en terme de vitesse et ou de confort de programmation depuis les années 70. Le langage est stagnant, Ce qui ne serait pas le cas, s'ils avaient développé le volet orienté-objet du langage.

Honnêtement , je trouve qu'il est ridicule de programmer dans le langage casse-bonbon si le résultat final va finir par tourné sur un CPU virtuel.

[Madmac]

En fait, tu ne connais pas le C++. Beaucoup trop d'erreurs et tu ne comprends pas les problématiques du typage. Ni celles de la standardisation ISO.

Alors si c'est le cas, je suis sûr que tu va pouvoir nous expliqué comment écrire un débuggeur qui va pouvoir afficher les valeurs auto. Le type auto est un concept débile qui aurait du être remplacer par une par une fonction auto qui aurait permit au programmeur d'instruire le compilateur à la volée.

Et pour info :

Code C++ :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
void printArray(auto arr) // bof auto ici, mais c'est pas l'important
{
    cout << "Array: ";
    for (auto i: arr)
    {
        cout << i << "  ";
    }
}

Et pour la moitié du tableau, est-ce qu'il existe une notation aussi élégante qu'en Ruby? Mon point était: S'il est possible d'avoir cette notation en Ruby pourquoi ce n'est pas possible en C++?

[mintho carmo]

Alors si c'est le cas, je suis sûr que tu va pouvoir nous expliqué comment écrire un débuggeur qui va pouvoir afficher les valeurs auto.

Qu'est-ce que tu racontes ? Les debuggeurs n'ont aucun problème à afficher le type et la valeur d'une variable déclarée avec auto. Pour au moins ce que j'utilise : MSVC, QtCreator, XCode.

Et pour la moitié du tableau, est-ce qu'il existe une notation aussi élégante qu'en Ruby? Mon point était: S'il est possible d'avoir cette notation en Ruby pourquoi ce n'est pas possible en C++?

C'est possible selon les cas. Slice existe depuis longtemps en C++. Et pleins de libs proposent cette fonctionnalité. Et les ranges aussi. Mais c'est pas parce que les devs Ruby trouvent ça élégant que les devs C++ aussi. Ou que c'est souhaitable d'avoir ça en C++. Si les devs C++ étaient intéressé, ça aurait été au moins proposé.

Linux Torvals...

Tout le monde s'en tape de Linus. C'est un dev C, son opinion sur le C++ a autant de valeur que celle de mon boulanger.

Honnêtement , je trouve qu'il est ridicule de programmer dans le langage casse-bonbon si le résultat final va finir par tourné sur un CPU virtuel.

Hein ???