Discussion :

[Uther]

Au contraire, le rendre visuellement ressemblant aux autres langages permet d'en faciliter la lecture sans nécessiter de temps d'adaptation.
Les parenthèses servent à repérer bien plus facilement le contenu des conditions, c'est une sorte de motif, qui nous permet de repérer les éléments bien plus facilement.

Il faut arrêter la mauvaise fois à un moment, il n'y a pas de problème de lisibilité pour repérer une condition entre un if et une accolade ouvrante. Par contre des problèmes de lisibilité liés a l'absence d'accolade dans les langage avec une syntaxe héritée du C sont légion.

Tous les langages qui n'ont pas hérité leur syntaxe du C font leur "if" sans parenthèses, ça ne dérange personne.

Sauf que lorsque tu vas choisir un langage parmi des milliers, la syntaxe de surface est ce que tu vas voir en premier et va être ton premier critère de pré-sélection. Tu regardes la gueule que ça a, et puis tu rentres plus en profondeur si t'as un bon feeling.

Oui sauf que le feeling c'est on ne peu plus subjectif, et j'ai un peu l'impression que tu prend ton feeling personnel qui ce résume a peu de chose près à "tout ce qui n'est pas comme C++ est contre-intuitif" alors que le C++, à la base, n'a pas une syntaxe super intuitive.

Par exemple, pour les macro, le "!" complexifie inutilement le code. Que ce soit pour la lecture, voire même pour l'apprentissage des langages. L'affichage est l'une des premières fonctions à utiliser, or, on ne va peut-être pas introduire aux étudiants la notion de macro tout de suite.

Pour le coup, au contraire, je dirais que c'est un énorme avantage de lisibilité par rapport à C++ ou les macros peuvent rajouter des effets qui paraissent totalement magiques dans le code sans que l'on comprenne rapidement d’où cela peut venir. Les macros pouvant avoir des effets de bord importants par rapport aux fonctions, c'est logique qu'elles soient clairement identifiables.

Expliquer a un débutant que la macro peut être considérée comme une fonction pour le moment même si ça relève techniquement d'une mécanique un peu plus avancée que l'on détaillera plus tard, ça prend 30 secondes et ça évite des surprises.

[Neckara]

Il faut arrêter la mauvaise fois à un moment, il n'y a pas de problème de lisibilité pour repérer une condition entre un if et une accolade ouvrante.

Si t'as des parenthèses ça se voit en un demi-coup d’œil, sans parenthèses ça demande un peu plus d'efforts conscient. Ce n'est en rien de la mauvaise foi, je l'ai d'ailleurs bien vu lorsque j'ai commencé à regarder des exemples de code en Rust...

Par contre des problèmes de lisibilité liés a l'absence d'accolade dans les langage avec une syntaxe héritée du C sont légion.

Non, si c'est bien indenté, ça se lit très facilement.

Tous les langages qui n'ont pas hérité leur syntaxe du C font leur "if" sans parenthèses, ça ne dérange personne.

Oui, comme python, où tu as le ":" qui va servir de marqueurs, avec une forte indentation, sans marqueur de bloc commençait à la même ligne du if.

Oui sauf que le feeling c'est on ne peu plus subjectif, et j'ai un peu l'impression que tu prend ton feeling personnel qui ce résume a peu de chose près à "tout ce qui n'est pas comme C++ est contre-intuitif" alors que le C++, à la base, n'a pas une syntaxe super intuitive.

Ce n'est pas vrai, vu que je préfère la syntaxe de Python à celui du C++.

Pour le coup, au contraire, je dirais que c'est un énorme avantage de lisibilité par rapport à C++ ou les macros peuvent rajouter des effets qui paraissent totalement magiques dans le code sans que l'on comprenne rapidement d’où cela peut venir. Les macros pouvant avoir des effets de bord importants par rapport aux fonctions, c'est logique qu'elles soient clairement identifiables.

Justement en C++ on a un peu abandonné les macro au profit des fonctions inline, des constantes, et constexpr.

Expliquer a un débutant que la macro peut être considérée comme une fonction pour le moment même si ça relève techniquement d'une mécanique un peu plus avancée que l'on détaillera plus tard, ça prend 30 secondes et ça évite des surprises.

Ouais, et t'en auras toujours 1 ou 2 qui ne sauront jamais quand mettre les "!" ou pas.

[Invité]

Pour le coup, au contraire, je dirais que c'est un énorme avantage de lisibilité par rapport à C++ ou les macros peuvent rajouter des effets qui paraissent totalement magiques dans le code sans que l'on comprenne rapidement d’où cela peut venir. Les macros pouvant avoir des effets de bord importants par rapport aux fonctions, c'est logique qu'elles soient clairement identifiables.

Expliquer a un débutant que la macro peut être considérée comme une fonction pour le moment même si ça relève techniquement d'une mécanique un peu plus avancée que l'on détaillera plus tard, ça prend 30 secondes et ça évite des surprises.

Je trouve également que ça améliore beaucoup la lisibilité. D'ailleurs en Julia les macros ont également un caractère spécial : https://docs.julialang.org/en/v1/man.../#man-macros-1

[walfrat]

Si t'as des parenthèses ça se voit en un demi-coup d’œil, sans parenthèses ça demande un peu plus d'efforts conscient. Ce n'est en rien de la mauvaise foi, je l'ai d'ailleurs bien vu lorsque j'ai commencé à regarder des exemples de code en Rust...


Non, si c'est bien indenté, ça se lit très facilement.


Oui, comme python, où tu as le ":" qui va servir de marqueurs, avec une forte indentation, sans marqueur de bloc commençait à la même ligne du if.


Ce n'est pas vrai, vu que je préfère la syntaxe de Python à celui du C++.


Justement en C++ on a un peu abandonné les macro au profit des fonctions inline, des constantes, et constexpr.


Ouais, et t'en auras toujours 1 ou 2 qui ne sauront jamais quand mettre les "!" ou pas.

J'imagine que certaines personnes sont plus sensibles à certaines choses que d'autres. En outre ton vécu n'est pas une preuve que lo'n peut généraliser en soi.

A défaut je préfère avec parenthèse et accolade, avec ou sans espacement, accolade en fin de ligne.

Cependant la chose qui me gênes le plus, c'est plutôt quand je me retrouve sans coloration syntaxique. Tant que je l'ai et que j'ai l'indentation, les parenthèses et accolades feront peu de différence.
Par contre si tu me met sur du noir et blanc sans parenthèses et accolade, je vais ramer sévère, les parenthèses et accolade vont aider, mais je serais quand même ralenti.

[tom_bdp]

Merci pour le lien, il a l'air intéressant. Concernant les modéles économiques, il y a une page wikipedia spécifique : https://en.wikipedia.org/wiki/Busine...ource_software

Merci aussi pour le lien, qui a l'air très intéressant également.

Ca existe déjà un noyau en Rust : https://www.redox-os.org/
Pour les outils GNU, je pense qu'il serait justement intéressant de les recoder en Rust (si ce n'est pas déjà fait). Pour la libc, c'est effectivement une bonne question...

edit: pour la libc dans redox "Custom libc written in Rust (relibc)"

Intéressant aussi, merci. Récemment je regardais sur le site Android Open Source Project (*) comment le projet était construit, le Kernel Linux, puis le HAL pour Hardware Abstraction Layer si ma mémoire est bonne, qui permet de "faire abstraction" justement des différences matérielles des nombreux constructeurs de matériel. Je serais curieux de savoir si l'équipe de développement de Rust / Redox OS envisage aussi une intégration dans ce sens: HAL Android -> Redox OS. Si oui on aura peut-être un jour des téléphones fonctionnant avec un Kernel Rust (edit: et Mozilla Firefox en browser bien sûr )

https://source.android.com/

[Uther]

Non, je ne crois pas : le RAII avec la move semantic, c'est vérifié à la compilation. Ou alors on ne parle pas de la même chose.

Je n'ai peut être pas utilisé les bons termes, mais ce que je voulais dire c'est que dans ce genre de cas :

Code :

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

1
2
3
4
5
6
7
8
9
// En C++
auto x = make_unique<uint32_t>(5);
auto y = move(x);
cout << "Hello " << *x << endl;
 
// En Rust
let x = Box::new(5);
let y = x;
println!("Hello, {}", x);

En C++ on a une erreur à l’exécution car on utilise le pointeur "x" qui a été invalidé au moment de l'affectation de "y". En Rust, où la notion de ownership est intégrée au cœur du langage, on a une erreur dès la compilation.
De plus le move est le comportement par défaut en Rust alors qu'il doit être mis en place via un constructeur de déplacement en C++.

Par contre on n'est d'accord que le modèle mémoire complet de Rust (ownership + borrowing + lifetime) est assez remarquable et spécifique à Rust (à ma connaissance du moins).

Pour les lifetime, il semblerait que l'idée vienne d'un langage expérimental : Cyclone, mais Rust est en effet le premier langage grand public a utiliser le concept. Il semblerait que Ada et Swift sont en train d'intégrer le concept.

[Invité]

...
C++ a une erreur à l’exécution car on utilise le pointeur "x" qui a été invalidé au moment de l'affectation de "y".
...

Ah oui, effectivement. L'idée du move en C++ c'est plutôt d'optimiser les copies mémoires et juste de "réinitialiser" la variable source donc Rust fait effectivement plus de vérification à ce niveau.

[codec_abc]

Merci aussi pour le lien, qui a l'air très intéressant également.

IJe serais curieux de savoir si l'équipe de développement de Rust / Redox OS envisage aussi une intégration dans ce sens: HAL Android -> Redox OS. Si oui on aura peut-être un jour des téléphones fonctionnant avec un Kernel Rust (edit: et Mozilla Firefox en browser bien sûr )

https://source.android.com/

Rust et Redox sont 2 choses différents. L’équipe qui s'occupe du langage ne participe pas à l'OS et vice versa. Autrement développer un kernel from scratch c'est un gros boulot et Redox n'a pas vocation à remplacer les existants. Hormis Linux et Windows ou Rust pourraient faire son apparition (car Rust a tapé dans l'oeil de certaines personnes la-bàs), Fuchsia (l'OS maison de Google) est aussi un candidat. Il contient des morceaux de Rust (je ne sais plus si c'est pour le kernel ou plutôt les libs système).

[Uther]

@Neckara> je vais passer sur les points subjectifs, vu qu'on a tout simplement pas la même vision de ce qui est élégant et lisible, et que c'est pas vraiment discutable.

Non, si c'est bien indenté, ça se lit très facilement.

C'est bien tout le problème. Comme en C++ l'indentation n'est pas significative, rien ne garantit qu'elle ne soit pas trompeuse. C'est une erreur récurrente connue, dont on connait plusieurs cas pratiques qui ont finis en faille critique. C'est pour ça que les accolades sont requises dans quasiment toute les recommandations.

Justement en C++ on a un peu abandonné les macro au profit des fonctions inline, des constantes, et constexpr.

Utiliser les constexpr et les inline quand c'est possible, c'est en effet beaucoup mieux et c'est pour ça que ça existe aussi en Rust (même si les const ne sont pas encore totalement terminées). Mais les macros permettent de faire des choses bien plus avancées que ça.

Ouais, et t'en auras toujours 1 ou 2 qui ne sauront jamais quand mettre les "!" ou pas.

Le compilateur leur indiquera clairement le problème, c'est vraiment pas un soucis, d'autant plus avec un IDE correct qui t'indique le problème à la volée.
Éviter les mauvaises surprises sur les effets réel du code est clairement bien plus important pour moi que gagner quelque secondes durant la phase d'apprentissage.

Et si ces quelque secondes rebutent de potentiels utilisateurs, ce n'est probablement pas bien grave, ça leur évitera de perdre encore plus de temps quand il leur faudra apprendre les lifetimes. Ils seront certainement mieux avec un langage comme le Go qui est justement fait pour faciliter au plus l'apprentissage. Rust est clairement un langage qui fait passer la robustesse et les performance avant la facilité d'apprentissage.

Rust et Redox sont 2 choses différents. L’équipe qui s'occupe du langage ne participe pas à l'OS et vice versa. Autrement développer un kernel from scratch c'est un gros boulot et Redox n'a pas vocation à remplacer les existants. Hormis Linux et Windows ou Rust pourraient faire son apparition (car Rust a tapé dans l'oeil de certaines personnes la-bàs), Fuchsia (l'OS maison de Google) est aussi un candidat. Il contient des morceaux de Rust (je ne sais plus si c'est pour le kernel ou plutôt les libs système).

L'OS Fucshia contient du Rust, mais pas dans la partie noyau qui est en C++. Rust semble en effet plaire a Microsoft, et je pense qu'on le verra très bientôt dans les composants bas niveau de l'OS qui ont besoin d'être refondu, mais là encore je ne le vois pas arriver dans le noyau Windows avant un moment. On ne réécrit une pièce de code complexe et qui marche bien sans une excellente raison, et Rust malgré ses qualités n'est certainement pas une raison suffisante.

[walfrat]

Au contraire, le rendre visuellement ressemblant aux autres langages permet d'en faciliter la lecture sans nécessiter de temps d'adaptation.

Les parenthèses servent à repérer bien plus facilement le contenu des conditions, c'est une sorte de motif, qui nous permet de repérer les éléments bien plus facilement.



Sauf que lorsque tu vas choisir un langage parmi des milliers, la syntaxe de surface est ce que tu vas voir en premier et va être ton premier critère de pré-sélection. Tu regardes la gueule que ça a, et puis tu rentres plus en profondeur si t'as un bon feeling.

Par exemple, pour les macro, le "!" complexifie inutilement le code. Que ce soit pour la lecture, voire même pour l'apprentissage des langages. L'affichage est l'une des premières fonctions à utiliser, or, on ne va peut-être pas introduire aux étudiants la notion de macro tout de suite.

Cela risque plus de perturber certains étudiants qu'autre chose, pour un gain assez anecdotique.

Personnellement je ne suis pas d'accord.

Si on prend la moyenne des "développeurs" (toute personne qui a au moins dans sa vie assembler du code a coup de c/c depuis stackoverflow), oui le critère de choix d'un grand nombre sont l'enthousiasme généré par l'effet de mode et un changement de la syntaxe de surface. Encore une fois, dans cet article, on parle de professionnels de l'informatique, ces personnes là ne font pas leur choix sur ces critères seulement.

Cependant ce n'est pas parce qu'ils sont nombreux à faire ça qu'ils ont raison. Si tu changes de langages ou que tu en ajoutes un dans ton travail, tu dois avoir une vrai raison professionnel de le faire. Beaucoup ne l'ont pas et se laisse bien trop influencer par "marre du c/c++/java ? Ces langages sont morts viens chez nous l'herbe est plus verte, l'air est plus frais et on a des cookies".

Ton argument pour le "!" je pourrais le reprendre, la première fois que j'ai fais du C++ j'ai vu la syntaxe de cin/cout, oui ça fait bizarre mais sérieusement au bout du troisième TP à l'école on s'y fait.

Et je trouve qu'en effet, beaucoup trop de personnes ne veulent pas se poser en équipe et discuter de façon réfléchis des choix techniques qu'ils font, et ça, ce n'est pas la faute aux langages. Parce qu'on pourrait reprendre le même argument pour les librairies, les frameworks, les SGBD, les OS,...

On peut comparer avec la vraie vie, prend une voiture volant+pédales vs clavier/souris c'est le même combat. De plus as-tu une idée du nombre de sociétés différente qui sont intervenus pour chaque pièce de ta voiture ? As-tu une idée pour chacune d'entres elles combien il y en a sur le marché qui font la même chose, potentiellement avec différentes technique de fabrication (le // avec les langages il est là) ? A moins que tu ne sois vraiment à fond dans le sujet je ne pense pas. Une voiture c'est un assemblage ou tout a déjà été choisis pour toi. C'est comme une distribution Ubuntu ou Windows ou tu as déjà bien des trucs de fournis. La différence avec la voiture est que tu peux continuer à en rajouter.

On peut aussi reprendre ce que tu disais sur les standards. Mon point de vue sur le standard c'est qu'il ne permet pas de se débarrasser de la fragmentation mais de la masquer. Ainsi toutes les voitures on un volant et des pédales, mais ça ne veut pas dire que derrière le volant et la pédale tout marche pareil d'une voiture à l'autre. Et bien c'est pareil, quand tu es dans le code, tu n'es pas le conducteur et ce n'est évidemment pas aussi facile. Car a chaque fois tu vas changer de voiture (ou de projet) tu as des chances qu'en interne ça ressemble beaucoup à ce qui se passe dans l'ancienne, ou pas.

Dernier élément : sur la syntaxe de surface et les premiers élément de langages ou plutôt sur ce qui sous-tend véritablement : la facilité d'accès à un langage. Oui le succès de certains langages ont fait qu'ils ont explosés et sont massivement utilisés, le pendant à cela est que le niveau moyen du développeur en la matière a été sévèrement tiré vers le bas, et même a attiré des gens qui pour eux "paye = pisser du code pour que mon ticket ma, le reste, pas mon problème", et qu'un grand nombre de projet écris dans ces langages enchaînent des erreurs élémentaire les une sur les autres (gestion des I/O, mauvaise utilisation basique de la base de données, réécriture de fonction fournis de base,...).

[Neckara]

C'est bien tout le problème. Comme en C++ l'indentation n'est pas significative, rien ne garantit qu'elle ne soit pas trompeuse. C'est une erreur récurrente connue, dont on connait plusieurs cas pratiques qui ont finis en faille critique. C'est pour ça que les accolades sont requises dans quasiment toute les recommandations.

Tu as quand même des logiciels te permettant de reformater correctement ton code en fonction des préférences de ton entreprise que tu peux exécuter, e.g. dans la pipeline CI/CD à chaque commits, ou même de balancer des warnings.

Cependant ce n'est pas parce qu'ils sont nombreux à faire ça qu'ils ont raison. Si tu changes de langages ou que tu en ajoutes un dans ton travail, tu dois avoir une vrai raison professionnel de le faire.

Tout à fait d'accord, mais le problème, c'est que pour en ajouter un, faut déjà connaître un peu le langage, et pour le connaître... t'en a des milliers... donc t'es bien obligé de faire des préselections au feeling.

Et je trouve qu'en effet, beaucoup trop de personnes ne veulent pas se poser en équipe et discuter de façon réfléchis des choix techniques qu'ils font, et ça, ce n'est pas la faute aux langages. Parce qu'on pourrait reprendre le même argument pour les librairies, les frameworks, les SGBD, les OS,...

D'ailleurs j'ai créé mon propre Framework JS.

On peut comparer avec la vraie vie, prend une voiture volant+pédales vs clavier/souris c'est le même combat. De plus as-tu une idée du nombre de sociétés différente qui sont intervenus pour chaque pièce de ta voiture ? As-tu une idée pour chacune d'entres elles combien il y en a sur le marché qui font la même chose, potentiellement avec différentes technique de fabrication (le // avec les langages il est là) ? A moins que tu ne sois vraiment à fond dans le sujet je ne pense pas. Une voiture c'est un assemblage ou tout a déjà été choisis pour toi. C'est comme une distribution Ubuntu ou Windows ou tu as déjà bien des trucs de fournis. La différence avec la voiture est que tu peux continuer à en rajouter.

Ta comparaison n'est pas juste. Tes différentes pièces, on peut dire que ce sont des fichiers écrits par des développeurs différents, dans le même langage. Et parce qu'il y a la même norme (langage/interfaces), ça s'agence tout bien comme il faut.

En revanche, va utiliser un logiciel écrit dans autant de langages qu'il y a de fichiers... Pour le maintenir ça va être une vraie catastrophe.

Des souris, y'en a une infinité de fabriquant. Mais heureusement, elles fonctionnent toutes plus ou moins pareilles, t'as un port USB tu branche, t'as une roulette, deux boutons, tout va bien.


Pour reprendre ta voiture, ton mécanicien s'arracherait les cheveux si chaque constructeur avait sa propre logique de voitures. Si e.g. l'essence à utiliser était unique à chaque modèle de voiture. Si chaque moteur avait une logique qui lui est propre. Il fait comment ton mécanicien quand il se retrouve face à un moteur qui ne connaît pas ?

S'il y a des constructeurs différents, le fait est qu'ils construisent des éléments similaires compatibles entre eux répondant à des normes et des exigences communes.

On peut aussi reprendre ce que tu disais sur les standards. Mon point de vue sur le standard c'est qu'il ne permet pas de se débarrasser de la fragmentation mais de la masquer. Ainsi toutes les voitures on un volant et des pédales, mais ça ne veut pas dire que derrière le volant et la pédale tout marche pareil d'une voiture à l'autre.

Déjà le fait d'avoir une interface commune, ça aide énormément pour passer d'une voiture à l'autre... imagine d'être sur une voiture non-familière et d'appuyer par réflexe sur le frein au lieu de débrailler en passant ta vitesse...

Et derrière ton volant, tu peux avoir d'autres normes. Et heureusement.

[Invité]

Pour reprendre ta voiture, ton mécanicien s'arracherait les cheveux si chaque constructeur avait sa propre logique de voitures.
...

Ben c'est le cas. Aujourd'hui un garagiste ne fait pas grand chose sur une voiture s'il n'a pas la valise de diagnostique du constructeur.

Déjà le fait d'avoir une interface commune, ça aide énormément pour passer d'une voiture à l'autre...

Oui, d'ailleurs il suffit de prendre le tunnel sous la manche pour bien se rendre compte de la merveilleuse "interface commune" de la voiture...

[Uther]

Tu as quand même des logiciels te permettant de reformater correctement ton code en fonction des préférences de ton entreprise que tu peux exécuter, e.g. dans la pipeline CI/CD à chaque commits, ou même de balancer des warnings.

En effet, et Rust fournit de base un outil de reformatage du code. Mais ça reste quand même un outillage supplémentaire qui ne doit pas être pris pour acquis. Quand on a un problème que l'on peut éviter de base, sans outil complémentaire, c'est quand même mieux.

Tout à fait d'accord, mais le problème, c'est que pour en ajouter un, faut déjà connaître un peu le langage, et pour le connaître... t'en a des milliers... donc t'es bien obligé de faire des préselections au feeling.

Devoir faire un tri, ok, mais la méthode que tu appliques me parait pas fabuleuse. Ce qu'il faut surtout regarder, c'est les besoins que le langage couvre. S’arrêter "au feeling" sur des détails et en ignorant totalement le fond, comme tu le fais, ça me parait clairement pas une bonne méthode.

[plegat]

Il fait comment ton mécanicien quand il se retrouve face à un moteur qui ne connaît pas ?

Bah il prend le manuel technique et il potasse!
Un bon mécanicien (ou plutôt une bonne équipe de mécaniciens) a de l'expérience et connait à peu près tous les modèles "courants" du coin. Et il existe toujours un modèle peu courant sur lequel il sera moins à l'aise.

Mais ce n'est pas pour autant qu'on demande à tout le monde de rouler en Clio!

S'il y a des constructeurs différents, le fait est qu'ils construisent des éléments similaires compatibles entre eux répondant à des normes et des exigences communes.

Ouaip, c'est vrai que c'est super simple de monter un embrayage Toyota sur une Tesla... à part l'allume cigare (banni depuis pas mal de temps sur les voitures, il ne reste que la prise, et encore...) et les loupiottes, je ne vois pas trop ce qui est "standard" sur une voiture... ou sur plusieurs modèles de voitures... si, les fusibles? Mêmes les essuies-glaces ne sont pas standard, y'a 50 modèles différents avec des attaches différentes... les pneus n'en parlont pas...

La pédale de frein n'est pas au milieu sur toutes les voitures d'ailleurs... sur celles à boite auto, elle est à gauche!

Et sinon, pour parler un peu plus info, je me suis mis à Rust depuis un mois (à la base je suis plutôt Python/Java, et je me suis même remis à Free Pascal/Lazarus durant le confinement, et on peut aussi rajouter du VBA pour le boulot sous Excel).
Il est chiant ce langage à apprendre, pas au niveau syntaxique (les histoires de parenthèses sur les conditions de test c'est limite du domaine du troll), mais plutôt dans la relation avec le compilateur qui ne laisse pas passer les boulettes... et punaise que c'est gratifiant d'avoir un compilateur qui te débuggue ton programme à 90% avant d'avoir un exécutable qui tourne! (et de devoir gérer les derniers 10% où tu t'aperçois que tu as codé ta formule de travers...)

[walfrat]

Ben c'est le cas. Aujourd'hui un garagiste ne fait pas grand chose sur une voiture s'il n'a pas la valise de diagnostique du constructeur.

C'était effectivement un petit appât de ma part pour Neckara, toute la partie électronique des bagnoles chaque constructeur à son propre outil de diagnostic

Tout à fait d'accord, mais le problème, c'est que pour en ajouter un, faut déjà connaître un peu le langage, et pour le connaître... t'en a des milliers... donc t'es bien obligé de faire des préselections au feeling.

C'est là qu'on est absolument pas d'accord. Tu parlais justement de standard, pourquoi ne pas appliquer cette logique aussi ici ? Certain langages sont pour ainsi dire standard dans leur domaines respectifs et ce parce qu'il sont là depuis suffisamment longtemps et ils ont prouvé qu'ils faisaient le taf correctement.

• Gestion de données dans un SI complexe : Java/C# + eventuellement Web
• Recherche ? Suffit de regarder les outils appropriés Matlab/Scilab/R/Python on chacun leur avantages pour leur domaines selon ce que tu veux faire exactement.
• Système/Temps réel : C/C++

A moins que tu veux jouer les explorateurs, un certain nombre d'outils ont fait leur preuves depuis 10ans et plus et continue de le faire aujourd'hui.

Remarque supplémentaire sur la partie Recherche : ce sont des outils effectivement relativement pour personnes spécialisés du domaine, même si le code et la doc était impec, plongé dedans resterait difficile : entre la complexité mathématique + la couche informatique d'optimisation c'est obligé que ce soit difficile à appréhender même avec un haut niveau de qualité. La seule chose que tu peux faire c'est t'assurer que les gens ont le bagage approprié (ou puisse le compléter rapidement). L'informatique dans les satellite c'est 15ans d'expérience le ticket d'entrée de ce que l'on a m'a dit.

** : ceci est une liste à titre d'exemple, merci de ne pas lancer un débat là dessus

La seule chose qui peut être difficile c'est si tu veux effectivement t'intéresser aux nouveautés, juger de cela correctement est difficile et je laisse ça volontiers à d'autres personnes.

[Neckara]

C'est là qu'on est absolument pas d'accord. Tu parlais justement de standard, pourquoi ne pas appliquer cette logique aussi ici ? Certain langages sont pour ainsi dire standard dans leur domaines respectifs et ce parce qu'il sont là depuis suffisamment longtemps et ils ont prouvé qu'ils faisaient le taf correctement.

• Gestion de données dans un SI complexe : Java/C# + eventuellement Web
• Recherche ? Suffit de regarder les outils appropriés Matlab/Scilab/R/Python on chacun leur avantages pour leur domaines selon ce que tu veux faire exactement.
• Système/Temps réel : C/C++

Bah oui, bien bien sûr.

Dans la recherche, tu vas jongler entre Matlab (), Scilab (pas si connu que ça), R (qui n'apporte rien de plus que Python), et Python... oui mais ton collègue il fait plein de calcul en parallèle, donc il va utiliser Go, l'autre il bosse avec l'industrie donc c'est du C#/Java, un autre il fait ceci, il utilisera cela, etc. etc.

L'outil "approprié" est une vaste blague. Tu prends Python, tu peux faire tout ce que tu veux avec, t'y ajoutes du C++ pour quelques modules critiques, et tu couvres 99.99% de tes besoins. De même que si tu prends e.g. Lua avec Rust, ou tout autre couple de langage compilé et interprété.


C'est plus un problème de bibliothèque que de réellement de langage. Je te fais des gros calculs en JavaScript, en JavaScript ! Tu crois que ce langage est fait pour ça ? Absolument pas. Est-ce que cela m'arrête ? Non. Suffit juste d'avoir les bonnes bibliothèques, et ça s'utilise comme n'importe quel langage.

Quand je commençais mes études, j'ai pas mal bidouillé. Tu crois que C++ est fait pour créer des jeu web ? Absolument pas, ça ne m'a pas empêché de l'utiliser avec emscriptem et SDL/SFML (je ne sais plus lequel). Tu crois que XSLT est fait pour créer des sites Webs ? Pas du tout, ça n'empêche pas des abrutis comme moi de nous y amuser.


Par contre, la seule chose qui est gênant c'est de :

• commencer avec une base en JS pour un environnent Web ;
• passer par R pour certaines fonctions mathématiques avancées ;
• devoir passer par Python pour des calculs sur GPU avec TensorFlow ;
• devoir passer par C#/Java parce que t'as un industriel qui veut une lib dans son langage ;
• intégrer du Matlab parce que t'as un collègue qui a écrit 2-3 trucs dans ce langage.
• un peu de C/C++ pour la forme et pour comparer les perfs avec le Python.
• etc.

Rien que pour un seul projet tu te retrouves avec un monstre de Frankenstein. Pourtant ultimement tu n'aurais besoin que de Python et C++ si le monde était bien fait (ou du Python avec du Rust, ou autre). Si j'avais les bonnes libs en JS, j'aurais ni besoin de R, ni de Python, c'est un problème de libs, plus que de langage.

Et mon métier c'est chercheur, pas développeur.

A moins que tu veux jouer les explorateurs, un certain nombre d'outils ont fait leur preuves depuis 10ans et plus et continue de le faire aujourd'hui.

Ça c'est un argument pour ne pas utiliser Rust, et contre l'utilisation de nouveaux langages (donc réduisant la fragmentation).

Rhâaaaa Rust a 10 ans depuis quelques semaines ><.

** : ceci est une liste à titre d'exemple, merci de ne pas lancer un débat là dessus

? T'as oublié de mettre les ^** dans ton message pour montrer à quoi se rapporte ta note.

La seule chose qui peut être difficile c'est si tu veux effectivement t'intéresser aux nouveautés, juger de cela correctement est difficile et je laisse ça volontiers à d'autres personnes.

Le problème, c'est comment juger des personnes qui te diront les nouveautés à utiliser ?

Parce que Apple me dit blanc, M$ me dit noir, Google me dit vert à poids roses, comment je m'y retrouves là-dedans ?

[walfrat]

Oui enfin a ce compte là va jusqu'au bout.

Matlab repose sur la librairie LAPACK en C donc tu peux le faire directement en C aussi.

Python lui-même repose sur du C (ou C++ je sais plus) donc tu peux aussi faire en C++.

Bref tu peux tout faire en C/C++ en fait.

Parce que Apple me dit blanc, M$ me dit noir, Google me dit vert à poids roses, comment je m'y retrouves là-dedans ?

Ben déjà attends des avis plus neutre, et tu peux attendre et regarder aussi.

Après le monde de la recherche je dis pas, déjà qu'en industrie c'est pas souvent ça l'harmonisation des technos alors en recherche

[Uther]

Ça c'est un argument pour ne pas utiliser Rust, et contre l'utilisation de nouveaux langages (donc réduisant la fragmentation).

Se jeter sur tout ce qui est nouveau sans réfléchir est tout aussi idiot que refuser toute évolution, il y a évidement un équilibre a trouver entre les deux.

Rhâaaaa Rust a 10 ans depuis quelques semaines ><.

Officiellement le Rust n'a pas 10ans, mais 5 ans. Certes, une première ébauche a été présenté au public il y a 10 ans, et son créateur y avait déjà travaillé seul pendant 4 ans.

Mais ce qui a été présenté il y a 10 ans était encore très très loin, du Rust sorti en 2015. Le Rust présenté a l'époque était encore a l'état expérimental, absolument pas utilisable en situation réelle. Par curiosité j'ai regardé à quoi ça ressemblait : syntaxiquement comme au niveau de pas mal de mécaniques fondamentales(garbage collector, pas de lifetime, ...), c'était un langage complètement différent.

Le problème, c'est comment juger des personnes qui te diront les nouveautés à utiliser ?
Parce que Apple me dit blanc, M$ me dit noir, Google me dit vert à poids roses, comment je m'y retrouves là-dedans ?

C'est en effet une bonne question.
Déjà des personnes qui te vende leur solution maison, ne sont clairement pas des personnes a qui faire confiance. En général dans les entreprises il y a des gens qui font de la veille pour évaluer les technologies intéressantes, c'est souvent un bon point de conseil. Vu que tu es dans la recherche, un domaine que je ne connais pas trop, je ne sais pas vraiment si vous avez de interlocuteurs similaires.

De ce que j'ai compris du genre d'informatique pratiquée dans le domaine de la recherche, Rust a pas mal de potentiel mais tous les outils pour faire du calcul scientifique ne sont pas encore optimaux. Il manque encore certaines fonctionnalités qui sont en cours d'implémentation (générique constants, spécialisation, ...) pour vraiment débloquer tout le potentiel. Si tu fait beaucoup de calcul numérique, ça vaudrait peut-être le coup pour toi d'attendre encore un peu avant d'envisager Rust.

[Neckara]

Oui enfin a ce compte là va jusqu'au bout.

Matlab repose sur la librairie LAPACK en C donc tu peux le faire directement en C aussi.

Python lui-même repose sur du C (ou C++ je sais plus) donc tu peux aussi faire en C++.

Bref tu peux tout faire en C/C++ en fait.

Je garde quand même un langage interprété. Par exemple si tu veux pouvoir ajouter des fonctionnalités sans recompiler et donc d'avoir le compilateur d'installé sur la machine (e.g. scripts pour des monstres dans un jeu).

Tu as aussi 2-3 trucs qui ne sont pas possibles dans un vrai langage compilé, comme appeler une méthode arbitraire par son nom (chaîne de caractère). Le seul moyen serait de se construire une table de correspondance, en ayant un logiciel qui irait parser automatiquement le code...

[Invité]

...De ce que j'ai compris du genre d'informatique pratiquée dans le domaine de la recherche...

C'est quoi "le domaine de la recherche" ? Par exemple, les chercheurs en statistiques, en physique ou en math font de l'informatique mais pas du tout avec les mêmes langages de programmation. Et même en "informatique", la recherche en langage de programmation, en système d'exploitation, en HPC, en machine learning, etc, ça n'a pas grand chose à voir.

En ce qui concerne les algo d'algébre linéaire (BLAS, LAPACK...), les implémentations généralement utilisées aujourd'hui sont en C ou en Fortran et existent depuis des décennies. Ou alors ce sont des implémentations sur GPU en Cuda. Donc les réimplémenter en Rust, ça peut être intéressant "pour tout avoir en Rust, avec une interface propre" mais sinon les utilisateurs s'en fichent pas mal que ce soit du pur Rust ou un binding vers du Fortran.