Je n'utilise pas VSCode. Je lui préfère Codium quand je n'ai pas le choix, c'est à dire rarement. La dernière fois, c'était pour jeter un coup d'œil rapide sur Flutter ou ré-essayer de faire le tuto Rust (pas facile quand on vient du C/C++, la syntaxe et les concept sont déroutant. Mais je m'égare encore). C'était un peu bizarre, en particulier côté ergonomie : devoir entrer des "commandes" pour rechercher la bonne fonction du bon plugin (pardon pour le vocabulaire à côté de la plaque peut-être).
Globalement, je trouve que VSCode ou Codium sont des usines à gaz, quasi inutiles sans plugins, et où l'accumulation de ceux-ci rend fragile les fondations d'un projet. Comment reconstruire son environnement à l'identique, après un crash disque par exemple ? Comment maintenir la cohérence dans une équipe de dév si chacun y va de sa propre collection de plugins ?
Bon, après, j'imagine que l'usage de VSCodium est plus répandu dans d'autres domaines que le mien : plutôt embarqué ou "exotique". Je suis même passé par une mission où un PC de dév était mis au coffre pour assurer la maintenance pendant plus de dix ans. Alors avec un éditeur/couteau suisse qui nécessite probablement une connexion internet pour accéder à des sites qui n'existeront peut-être plus dans quelques années, ça laisse perplexe.
Comment maintenir la cohérence dans une équipe de dév si chacun y va de sa propre collection de plugins ?
Opinion impopulaire : la cohérence des outils de dev dans une équipe ne devrait pas être un sujet. Chaque dev devrait pouvoir utiliser les outils avec lesquels il est le plus efficace et confortable, quels que soient ceux utilisés dans l’équipe. Un projet bien conçu devrait fonctionner sans problème quels que soient les outils et IDE utilisés ; d’ailleurs, de la diversité dans l’équipe de développement évite certains comportement nuisibles (chemins en dur, dépendance forte à un outil de développement particulier…).
Les outils projets par contre devraient être standards et cohérents au sein d’une équipe (par exemple : toujours utiliser NPM + Vue pour les projets JS front, Gradle + Spring Boot + PostgreSQL pour les projets back, etc).
J’espère avoir le temps de faire un billet plus détaillé sur ce point un de ces quatre.
Il y a là le révélateur de la fraction entre entreprise "traditionnelle" et vision plus moderne (pour ne pas dire Open-Source).
Une entreprise moderne fonctionne très bien en laissant libre le choix du poste de travail (dont du télétravail). Les projets Open-Sources comme Linux, sont développés ainsi.
Je ne vois pas tellement le rapport entre l’open-source et la possibilité d’installer ses outils de dev sur son poste de travail pro ?
Je pense avoir vu à peu près toutes les situations en entreprise (du « ce projet ne fonctionne que dans une VM avec les outils dédiés et les chemins fixes, merci IBM » à « installez ce que vous voulez, vous êtes responsables de votre poste ») sans jamais que la notion d’open-source ne rentre en compte.
Idem pour le lien entre le télétravail et la liberté d’installer quelque chose sur son poste. D’ailleurs, l’entreprise la plus anti-télétravail que j’ai fait (avant le covid) nous laissait tous admins de nos postes sans la moindre forme de contrôle. Tout comme j’ai fait une entreprise avec 3 jours/semaine de télétravail mais impossibilité d’installer la moindre chose sans passer par l’IT.
Posté par abriotde .
Évalué à 1.
Dernière modification le 17 mai 2023 à 21:49.
Linux est développé par des milliers de personnes qui pour la pluspart ne se sont jamais vus, ils s'agit donc bien de télétravail, chacun avec son environnement sous tous les IDE. Les puristent utilisent VIM ou son fraternel ennemi EMACS des IDE comme Netbeans ou Eclipse ou encore les modernes VSCodium et Cie. Et chez Windows je parie qu'ils vont même jusqu'à développer Linux avec Windows et Visual Studio.
Bref effectivement, il existe aussi des logiciels open-source développés en interne sans télétravail, tous sous le même environnement, mais même parmi eux je doute qu'ils refusent les contributions faites avec un autre environnement de travail :D
Petite indice : eclipse possède pleins dont un compilateur et un builder (pour le compilateur je ne sais pas, mais NetBeans et Intellij ont aussi un builder).
Pas que, c'est ça le soucis. J'ai plus les détails en tête, mais un collègue est déjà arrivé sur un projet où la petite équipe buildait tout sous Eclipse, les jars étaient ensuite push à la main. Et bien sur, mvn compile plantait. "Mais ne t'inquiète pas, les fichiers eclipse sont sur le repo pour tout configurer correctement".
je plussois et je rajoute un mais …
Parce qu'on ne parle pas du même contexte.
[Ce qui suit n'est pas méchant, juste caricatural pour aller plus vite !]
Les "gens comme moi" pensent que les "gens comme vous" se moquent d'empiler tout un tas de toolkit & cie, et en plus, ne pensent qu'à en changer tout les six mois.
Mais dans le cas des "gens comme moi", j'évoquais un cas extrême où il faudrait être capable de ressortir le PC du coffre, pointer une version précise du code, et généré exactement le même binaire que dix ans auparavant.
Après, c'est beau sur le papier, assez rare (ferroviaire, militaire, et même pas dans tout le temps), et en pratique, ultra difficile à réaliser.
Et j'y pense 20 ans après en l'écrivant : il aurait aussi était nécessaire de mettre au coffre le serveur ClearCase, parce que sans lui, impossible de ressortir un label ou une branche particulière (git n'existait pas à l'époque). C'est ballot.
Et j'y pense 20 ans après en l'écrivant : il aurait aussi était nécessaire de mettre au coffre le serveur ClearCase, parce que sans lui, impossible de ressortir un label ou une branche particulière (git n'existait pas à l'époque). C'est ballot.
Est-ce qu'il est plus résilient de tenter de figer tout (l'ordinateur enfin les ordinateurs dans des pièces inifugées séparés suffisamment pour ne pas courir les même risque avec le les serveurs qui vont avec etc) ou de changer de machine suffisamment régulièrement pour avoir une vision complète de ce dont il a besoin pour fonctionner ?
Je ne comprends pas bien, tu parles de quelles machines ? Celles des dévs ? C'est la théorie, dév ou dév+serveur, peu importe, il faut (faudrait; théorie vs pratique) pouvoir ressortir un contexte de dév à l'identique.
Quand ton soft roule aux quatre coins d'un pays, et que 5 ou 10 après, on te dit qu'il y a un bug …
Et pendant ces 5 ou 10, tu as fais autre chose, d'autres projets qui n'ont rien à voir.
À aucun moment, il n'est question de toucher au soft, encore moins de faire des mises à jour au rythme d'un windows/linux ou d'un serveur en prod.
Il a était développé ce logiciel, si pendant ça phase de développement il avait été déterminé qu'il fonctionne sur telle architecture avec tel version de tel langage, c'est différent que de dire que la spécification c'est la machine elle même.
Pour moi c'est de la dette technique. C'est un coût que l'on remet à plus tard. On peut décider de me faire pour de bonnes raisons, mais je ne l'éleverai pas à dire que c'est une bonne pratique ou la meilleure façon de faire.
Chaque dev devrait pouvoir utiliser les outils avec lesquels il est le plus efficace et confortable, quels que soient ceux utilisés dans l’équipe. Un projet bien conçu devrait fonctionner sans problème quels que soient les outils et IDE utilisés ;
Oulah… tu vas être fâché avec bon nombre de boîtes que j'ai connues et où genre 1 dev demande Atom et on lui dit qu'il y a VSC et Notepad++ et pas d'autre choix possibles… ;(
J'ai aussi vu des projets dépendre d'un outil (une fois un éditeur particulier) sans que cela choque quiconque. C'est là que je me dis que j'ai de la chance de plus faire dev.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
C'est là que je me dis que j'ai de la chance de plus faire dev.
En ce qui me concerne, c’est pas « de la chance ». C’est des points que j’aborde aux entretiens techniques d’embauche. On a une profession où on peut souvent se permettre de ne pas prendre n’importe quelle entreprise parce que c’est la seule à proposer du boulot, autant en profiter – et ça ne passe pas que par le salaire.
Posté par GwenLg .
Évalué à 5.
Dernière modification le 17 mai 2023 à 14:56.
Petite note d'encouragement concernant Rust.
J'étais moi aussi un programmeur C/C++, et je me suis mis à apprendre Rust il y a un peu moins de deux ans.
Effectivement la transition n'est pas toujours facile, et je conseillerais d'avoir une personne qui peux nous débloquer en cas de besoin et/ou de suivre une petite formation.
Mais je trouve que ça vaut largement l'effort. Il y a tellement de progrès par rapport à C/C++.
Un exemple:
Il y a quelques jours j'ai voulu utiliser réutiliser un projet Rust, et le code actuel avait un warning sur un bout de code.
Ce code construisait, à partir d'un array (tableau static) un autre array de même taille. C'était fait à la méthode C++, avec un for.
Mais pour être certain que toutes les valeurs de l'array de sortie soit bien initialisé, il fallait avant de faire la boucle for, initialiser le tableau avec des valeurs par défaut, sinon le compilateur n'est pas content, car il n'est pas capable de vérifier que le code dans le for initialise bien tout l'array.
La limite de ça, c'est que du coup le compilateur ne nous aide pas à vérifier que la boucle for initialise bien toutes les valeurs, et que du coup on n'a pas des valeurs par défaut qui pourraient traîner dans le tableau.
// Generate an array from another, C++ way.
fn array_from_another(input: &[f32; 16]) -> [f32; 16] {
let mut output: [f32; 16] = Default::default();
for (i, x) in input.iter().enumerate() {
let a = value_convertion(x[0]);
let b = value_convertion(x[1]);
let c = value_convertion(x[2]);
output[i] = 0.2126 * a + 0.7152 * b + 0.0722 * c;
}
return output;
}
Je trouvais ça dommage, et en cherchant comment améliorer le code j'ai découvert que la primitive array possédait une méthode map. J'ai pu donc réécrire le passage en question en code 'fonctionnel'. Le nouveau code :
- évite une double initialisation du tableau (même s'il n'y avait pas de problème de performance dans ce cas)
- est plus concis et évite toute une partie "glu"
- permet d'être plus explicite sur les intentions du code, ce qui permet au compilateur de vérifier plus de chose, mais aussi d'être plus facilement lisible par les humains (quand on s'y est habitué)
// Generate an array from another Rust way.
fn array_from_another(input: &[f32; 16]) -> [f32; 16] {
input.map(|x| {
let a = value_convertion(x[0]);
let b = value_convertion(x[1]);
let c = value_convertion(x[2]);
0.2126 * a + 0.7152 * b + 0.0722 * c
})
}
Note: Bien sur, ce n'est pas forcément exceptionnel, ça doit exister ailleurs, mais quand on vient du C++ et combiné avec toutes les autres fonctionnalités de Rust ça en fait un langage qui mérite qu'on s'y intéresse
Donc @AncalagonTotof je te conseille de continuer d'essayer de faire le tuto Rust. Avec Codium et le plugin Rust qui va bien ;)
Merci pour l'info, je ne connaissais pas.
En même temps les projets C++ sur lequel j'ai bossé utilisais pas trop la std, et avaient l'autorisation qu'a certain morceau de C++11 :p.
autoisOdd=[](autoi){returni%2;};autosquare=[](autoi){returni*i;};std::vector<int>tableau={1,3,4,6,8,10,5};std::cout<<tableau.size()<<std::endl;autoplop=tableau|std::views::filter(isOdd)|std::views::transform(square);// a noter qu'ici on a encore rien filtré ni mis au carré for(autoi:plop){std::cout<<i<<std::endl;}
a noter que les lambda nommée (oui c'est drôle) peuvent se mettre à la place de leur utilisation, mais ça rends le code potentiellement moins lisible
on peut aussi faire un using std::views::filter et using std::view::transform pour avoir tableau| filter(…) | transform(…)
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
C'est la problématique de C++, pas mal de monde le critique en comparant un nouveau langage à la mode à C++ d'il y a 20 ans (je serai tenté de dire un C++ rouillé mais après on avoir 2 "rust" en compétition :) ) et non pas C++20.
C++ a plein de défauts (et Rust répond à certains problème comme le multithread et met la sécurité par défaut la où il faut penser à "at" et pas "[]" si on veut la sécurité en C++), mais la majorité des critiques montrent surtout un manque de connaissances.
C'est bien dommage, mais C++ continue son bonhomme de chemin malgré tout.
Et du coup, quand on compare Rust à C++20, on a surtout l'impression d'un concours d'illisibilité de code mais quand même sans jamais dépasser Perl :-D.
en fait pas rouillé, simplement mal/pas appris. avant les lambda on pouvait faire l'équivalent avec des struct avec operator() et faire ce qu'il fallait pour les variables (référence, copie…) j'ai appris le c++ après 2000, et ces trucs on me l'a jamais appris, c'est après la sortie du c++11, et des années à pester contre le choix de rester à celui de 2003 que j'ai trouvé comment faire avec.
Et du coup, quand on compare Rust à C++20, on a surtout l'impression d'un concours d'illisibilité de code mais quand même sans jamais dépasser Perl :-D.
En fait le C++ peut être parfaitement lisible; tout comme le Perl ; de même il est tout à fait possible de faire un texte syntaxiquement exact en Français, tout en étant parfaitement incompréhensible, voire même ambigu; à cela on peut ajouter le ton ou le contexte et no peut avoir des sens radicalement différent; est-ce une raison de vouloir l'appauvrir? Je ne pense pas.
La relecture de code se répand; et c'est une bonne chose; si le relecteur ne comprend rien (quel que soit le langage), y'a probablement un effort à faire, sinon on récupère une boite noire.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
C'est fait de manière impérative à un endroit où on gagne à utiliser un style fonctionnel. L'inverse existe aussi (par exemple avec des filter() ou transform() qui ont des effets de bord). Et ces cas inverses apparaissent d'autant plus que l'on présente comme vieux la façon la plus simple de faire (parce que oui tu peux utiliser des monades aussi, mais c'est pas forcément le plus simple surtout quand le langage ne t'aide pas particulièrement).
C'était une boutade; je soulignais juste que la façon de faire des langages 'modernes' avec map ou filter; se faisaient déjà y'a 20 ans; pas forcément avec une syntaxe 'sexy', mais y'avait déjà des équivalents (au pire on utilisait boost).
Surtout que maintenant les jeunes en sortie d'école se mettent à remplacer des morceau de code parfaitement fonctionnel et lisible par leur équivalent en stream. J'ai pas mis la référence journalien d'un désabusé disant qu'après 20 ans de carrière tout ce qu'il laissait c'était de la dette technique, mais j'y pensais fortement en écrivant le commentaire.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
lisp le faisais… en 58. Je le fais remarquer parce que la perception de « moderne » est tout à fait relatif. Utiliser le bon outil au bon moment devrait être mieux valoriser qu'utiliser l'outil qui plait autant que possible.
Merci pour les encouragements ! Je fais parti des vieux croulants mentionnés juste après …
Je n'ai jamais aimé les templates du C++, je trouve que ça rend le code illisible très vite, et les erreurs de compilation peuvent devenir très absconses.
J'admets avoir d'énorme lacunes sur ce point, et je les mesures d'autant plus depuis que j'ai découvert la chaîne de Jason Turner.
Rust a cet aspect qui est séduisant : c'est plus propre.
Après, le temps que je m'y mettes, tout le monde sera passé à Zig non ?…
J'étais moi aussi un programmeur C/C++, et je me suis mis à apprendre Rust il y a un peu moins de deux ans.
Effectivement la transition n'est pas toujours facile, et je conseillerais d'avoir une personne qui peux nous débloquer en cas de besoin et/ou de suivre une petite formation.
Mais je trouve que ça vaut largement l'effort.
OK, il faut plus de deux ans avec un tuteur jedi et on est récompensé de l'effort herculéen. Heureusement qu'on a toute la vie devant soi et rien d'autre d'intéressant à faire.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
Posté par GwenLg .
Évalué à 0.
Dernière modification le 18 mai 2023 à 01:13.
OK, il faut plus de deux ans avec un tuteur jedi et on est récompensé de l'effort herculéen. Heureusement qu'on a toute la vie devant soi et rien d'autre d'intéressant à faire.
Joli détournement de propos (ou incompréhension ?).
Pour préciser :
J'ai dit "près de deux ans" et pas "plus de deux ans" …
L'effort n'est pas herculéen, et si apprendre Rust nécessite des efforts. Rust permet également d'éviter certain efforts qu'il faudrait faire avec d'autres langages (notamment C++).
Justement je n'avais pas de tuteur, encore moins jedi, donc j'ai appris moins vite que je n'aurais pu.
Il n'a pas fallu attendre "presque deux ans" pour être "récompensé".
Tu es libre d'avoir d'autres choses "plus intéressante" à faire, mais ne présume pas pour les autres ;)
J'ai bien lu "presque" deux ans et cru comprendre que ce n'était pas fini, d'où ma déduction qu'il fallait "au moins" deux ans.
Pour les choses intéressantes, ce n'est pas que apprendre un langage ne l'est pas. C'était pour souligner que je trouve c'est un énorme investissement de temps pour des langages qui disent apporter facilité et confort etc. La même remarque s'applique à C++ hein : on peut certes s'initier en deux ou trois mois, mais j'ai l'impression qu'il faut bien deux ans pour commencer à être à l'aise avec et éviter certains pièges, et on ne parle pas encore de maitriser le langage.
En tout cas, cela me conforte quelque part d'avoir lâché l'affaire au bout de quatre ou cinq mois : je n'arrive pas à penser et ressentir rust… et je peine encore à rattraper tout ce que j'avais mis en standby.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
Effectivement, ce n'est pas fini, mais apprendre un langage ce n'est jamais fini .
Et puis il y a le langage, l'écosystème, les librairies/framworks, etc
Pour le "penser Rust", quand on vient du C/C++ effectivement ça peut prendre du temps.
Quelqu'un qui a déjà fait de la programmation fonctionnelle, ça peut-être plus rapide.
Par contre, créer et configurer un nouveau projet, chercher des librairies pour réutiliser le code, gérer les dépendances, comprendre comment utiliser une librairie, faire fonctionner ensemble différentes librairie, … tous ça me semble plus facile, rapide et reposant qu'en C++ par exemple.
Même contribuer à un projet, je trouve ça plus "facile", j'ai moins peur de mal faire un truc.
En tout cas, cela me conforte quelque part d'avoir lâché l'affaire au bout de quatre ou cinq mois
Dans un sens, je trouve ça dommage que tu n'es pas pu aller au bout, alors que tu avais envie d'apprendre Rust.
De l'autre, je ne connais pas le contexte pour commenter plus.
L'idéal c'est de pouvoir faire l'apprentissage dans le cadre du (temps de) travail ^
Comment reconstruire son environnement à l'identique, après un crash disque par exemple ? Comment maintenir la cohérence dans une équipe de dév si chacun y va de sa propre collection de plugins ?
Il y a la notion de Recommended plugins qu'on peut mettre dans un fichier à commiter dans son code source. Ça permet de mettre quelqu'un sur un nouveau projet très rapidement.
De même, un grand nombre de paramètres peuvent être enregistrés dans le projet lui-même (je pense aux paramètres de formatage, entre autres), qui va avec le code source.
Je n'ai qu'un seul avis concernant les IDE : laisser les gens utiliser celui qu'ils veulent. Des fois, le choix est réduit (faire du Vue.js, c'est presque obligatoirement par VSCode/Codium, bien que des LSP soient pris en charge dans d'autres éditeurs (https://github.com/vuejs/language-tools) mais c'est quand même beaucoup plus facile.
Dans mon bureau, on est 5 développeurs, on utilise 4 IDE différents. Parfois sur le même projet. On est grand, ça marche, on se sent bien dans ses pantoufles, c'est cool.
Comment maintenir la cohérence dans une équipe de dév si chacun y va de sa propre collection de plugins ?
D'un autre côté, à moins d'être des clones sans personnalité distincte, tout le monde ne peut pas avoir les mêmes besoins… Et cela ne devrait pas influencer sur le travail en lui-même : il y a normalement des règles/conventions de codage/commit/arborescence/docs/etc, sinon le projet a d'autres soucis à se faire àmha.
Je suis même passé par une mission où un PC de dév était mis au coffre pour assurer la maintenance pendant plus de dix ans.
Quelle brillante idée… :D Parce-que j'espère qu'il a été prévu qu'il peut y avoir des défaillances mécaniques (le disque qui lâche par exemple) et que les pièces de rechange n'existeront plus… Plus les problèmes logiciels (je n'irai pas jusqu'à envisager le bsod mais un fichier corrompu par exemple, ou une licence expirée, ah oui y a les mises à jour ou pas ?) Bref, on va rigoler (ou pleurer toutes les larmes de son corps ?)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
A noter qu'il vaut mieux lire la source https://ghuntley.com/fracture/ (en Anglais, de 2022) qui parle un minimum de VSCodium.
Mais sinon, je me demande bien qui fracture le plus entre une entité qui ouvre partiellement et donc fait un pas vers le libre à défaut d'y aller à 100%, et une personne qui rejette tout ce qui n'est pas 100% du code libre.
VSCodium (la version sans ajout non libre) est libre et utilisable, mais ce n'est pas assez pour lui, OK, ben désolé je vois plus cette personne comme une personne qui cherche à fracturer une communauté parce que cette communauté ne serait pas assez pure, que d'accepter tout le monde y compris ceux qui font "que" un (gros, quand même) pas vers le libre. Et ça serait bien mieux, si on veut du 100% libre, ben de remplacer le code non libre par du libre, mais bon c'est plus d'effort, faut coder et attirer du monde, convaincre de l'utilité, plutôt que de râler.
Et le FUD légal est dans ce texte, pas ailleurs, sans argument concret. ha oui si tu joues à violer la licence non libre des plugins ça peut être chaud, mais c'est quoi le rapport avec le libre? Aucune obligation d'aller taquiner le non libre.
Et si VSCodium n'est pas assez bien sans plugin, pourquoi donc cette communauté qui ne veut pas de non libre ne se bouge pas les fesses pour coder les plugins dont les gens ont besoin plutôt que de râler?
Je note une phrase non reprise dans le résumé en français :
Maybe we need a new movement
Donc le mouvement actuel pue car pas assez comme il veut, et il faudrait donc peut-être créer un schisme dans le libre pour y mettre sa morale, pas nouveau et pas le premier à ne pas aimer la liberté du libre, mais sérieux, après cette phrase il critique Microsoft de vouloir fracturer? Ha ha ha.
Au final, j'ai l'impression que c'est pour flatter une partie des libristes qui n'aime pas la direction que prend la communauté du libre dans son ensemble (qui accepte des ponts entre libre et non libre et voit le libre comme un moyen plutôt qu'un but) qu'autre chose, et tant pis pour le dommage collatéral qui serait pousser à… une fracture de la communauté du libre.
Si vous pensez pouvoir faire mieux, faites et montrez que votre modèle est mieux plutôt que d'accuser les autres de ne pas faire comme vous voulez, arrêtez d'accuser les autres de fracture ou que sais-je juste parce qu'ils ne sont pas d'accord avec vous mais que eux réussissent (il y a d'autres outils pour coder, 100% libres… Mais pas utilisés par les gens, il faut peut-être se demander pourquoi).
Ce n'est pas un piège, c'est connu et accepté.
PS : je code principalement sous Visual Studio, 100% non libre sur un OS 100% non libre, et ça ne m’empêche aucunement de faire du 100% libre et même du 100% compilable sous tout OS libre avec tout compilo libre. La licence de mon outil pour coder n'a aucun impact sur la liberté de mon code, elle n'a pas non plus d'impact sur mes collègues qui n'aiment pas le non libre et utilisent que du libre pour coder sur mon projet, n'en déplaise à certains pour qui si on n'est pas pur on fracturerait à utiliser les meilleurs outils pour soit y compris ceux non libres. Liberté!
Plutôt d'accord avec ton point de vu, j'ai mis l'article en lien sans vraiment apprécier ni son contenu, ni son écriture. Cela dit, je n'ai jamais autant observé de prosélytisme pour un IDE que pour VSCode (et pour VSCodium) au détriment d'autres solutions. Et c'est là qu'est le problème.
Je n'ai essayé qu'une fois sérieusement VSCodium, mais j'en ai perçu certaines limites qui me gênent beaucoup. Selon ma compréhension, les bonnes idées de VSCodium, c'est d'utiliser du JS/TS, ce qui le rend de facto populaire et le LSP (le Language Serveur Protocole).
Si il y a d'autres avantages techniques, je suis preneur.
(il y a d'autres outils pour coder, 100% libres… Mais pas utilisés par les gens, il faut peut-être se demander pourquoi).
Tu es aussi biaisé que lui : tu penses que parce-que tu as fait un choix (le PS) que c'est le cas de tous. Perso, je n'ai pas encore rencontré de personne, en salariat dans les moyennes et grosses structures que j'ai connu, qui ai eu le choix de ses outils pour coder cf. mon autre commentaire ; donc y a pas à se demander pourquoi on ne retrouve que certains outils imposés…
Tu suis le même travers que lui : tu l'accuses de ne pas faire comme toi, et donc d'avoir tort. Et défendre votre modèle bec et ongle semble trop vous tenir à cœur, comme si l'avenir de l'humanité en dépendait …alors qu'en vrai la grosse majorité me semble s'en ficher pas mal.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
You cannot directly launch Theia as it is a platform. You can create and launch products based on Theia. The project provides one example tool called Eclipse Blueprint that you can directly download and use.
Eclipse Theia Blueprint is not a production-ready product. Therefore, it is also not meant to be a replacement for Visual Studio Code or any other IDE.
# Codium ?
Posté par AncalagonTotof . Évalué à 6.
Je n'utilise pas VSCode. Je lui préfère Codium quand je n'ai pas le choix, c'est à dire rarement. La dernière fois, c'était pour jeter un coup d'œil rapide sur Flutter ou ré-essayer de faire le tuto Rust (pas facile quand on vient du C/C++, la syntaxe et les concept sont déroutant. Mais je m'égare encore). C'était un peu bizarre, en particulier côté ergonomie : devoir entrer des "commandes" pour rechercher la bonne fonction du bon plugin (pardon pour le vocabulaire à côté de la plaque peut-être).
Globalement, je trouve que VSCode ou Codium sont des usines à gaz, quasi inutiles sans plugins, et où l'accumulation de ceux-ci rend fragile les fondations d'un projet. Comment reconstruire son environnement à l'identique, après un crash disque par exemple ? Comment maintenir la cohérence dans une équipe de dév si chacun y va de sa propre collection de plugins ?
Bon, après, j'imagine que l'usage de VSCodium est plus répandu dans d'autres domaines que le mien : plutôt embarqué ou "exotique". Je suis même passé par une mission où un PC de dév était mis au coffre pour assurer la maintenance pendant plus de dix ans. Alors avec un éditeur/couteau suisse qui nécessite probablement une connexion internet pour accéder à des sites qui n'existeront peut-être plus dans quelques années, ça laisse perplexe.
[^] # Re: Codium ?
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 10. Dernière modification le 17 mai 2023 à 14:51.
Opinion impopulaire : la cohérence des outils de dev dans une équipe ne devrait pas être un sujet. Chaque dev devrait pouvoir utiliser les outils avec lesquels il est le plus efficace et confortable, quels que soient ceux utilisés dans l’équipe. Un projet bien conçu devrait fonctionner sans problème quels que soient les outils et IDE utilisés ; d’ailleurs, de la diversité dans l’équipe de développement évite certains comportement nuisibles (chemins en dur, dépendance forte à un outil de développement particulier…).
Les outils projets par contre devraient être standards et cohérents au sein d’une équipe (par exemple : toujours utiliser NPM + Vue pour les projets JS front, Gradle + Spring Boot + PostgreSQL pour les projets back, etc).
J’espère avoir le temps de faire un billet plus détaillé sur ce point un de ces quatre.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Codium ?
Posté par abriotde . Évalué à 3.
Il y a là le révélateur de la fraction entre entreprise "traditionnelle" et vision plus moderne (pour ne pas dire Open-Source).
Une entreprise moderne fonctionne très bien en laissant libre le choix du poste de travail (dont du télétravail). Les projets Open-Sources comme Linux, sont développés ainsi.
[^] # Re: Codium ?
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 3.
Je ne vois pas tellement le rapport entre l’open-source et la possibilité d’installer ses outils de dev sur son poste de travail pro ?
Je pense avoir vu à peu près toutes les situations en entreprise (du « ce projet ne fonctionne que dans une VM avec les outils dédiés et les chemins fixes, merci IBM » à « installez ce que vous voulez, vous êtes responsables de votre poste ») sans jamais que la notion d’open-source ne rentre en compte.
Idem pour le lien entre le télétravail et la liberté d’installer quelque chose sur son poste. D’ailleurs, l’entreprise la plus anti-télétravail que j’ai fait (avant le covid) nous laissait tous admins de nos postes sans la moindre forme de contrôle. Tout comme j’ai fait une entreprise avec 3 jours/semaine de télétravail mais impossibilité d’installer la moindre chose sans passer par l’IT.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Codium ?
Posté par abriotde . Évalué à 1. Dernière modification le 17 mai 2023 à 21:49.
Linux est développé par des milliers de personnes qui pour la pluspart ne se sont jamais vus, ils s'agit donc bien de télétravail, chacun avec son environnement sous tous les IDE. Les puristent utilisent VIM ou son fraternel ennemi EMACS des IDE comme Netbeans ou Eclipse ou encore les modernes VSCodium et Cie. Et chez Windows je parie qu'ils vont même jusqu'à développer Linux avec Windows et Visual Studio.
Bref effectivement, il existe aussi des logiciels open-source développés en interne sans télétravail, tous sous le même environnement, mais même parmi eux je doute qu'ils refusent les contributions faites avec un autre environnement de travail :D
[^] # Re: Codium ?
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 4.
Oui, donc je confirme, ça n’a à peu près aucun rapport avec ce que je disais.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Codium ?
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
Pour les projets Java, le standard et le choix des Lead Senior Java Architect est Maven, pas Gradle :-)
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Codium ?
Posté par Elfir3 . Évalué à 3.
ça dépend, pour certains c'est toujours Eclipse..
[^] # Re: Codium ?
Posté par steph1978 . Évalué à 3.
Il dit qu'il a plus de genou
Il dit qu'il voit pas le rapport
Maven / graddle sont des outils de build.
Eclipse est un IDE. Donc l'un n'empêche pas les autres.
[^] # Re: Codium ?
Posté par barmic 🦦 . Évalué à 2.
Petite indice : eclipse possède pleins dont un compilateur et un builder (pour le compilateur je ne sais pas, mais NetBeans et Intellij ont aussi un builder).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Codium ?
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
J'ai eu tellement de souci avec ces builders que je préfère les désactiver et faire confiance entièrement à Maven.
Cela oblige aussi à optimiser pour le projet pour une construction simple et rapide.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Codium ?
Posté par barmic 🦦 . Évalué à 2.
Ben c'est ce que tout le monde fait. Seul les étudiants se font avoir.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Codium ?
Posté par Elfir3 . Évalué à 4.
Pas que, c'est ça le soucis. J'ai plus les détails en tête, mais un collègue est déjà arrivé sur un projet où la petite équipe buildait tout sous Eclipse, les jars étaient ensuite push à la main. Et bien sur, mvn compile plantait. "Mais ne t'inquiète pas, les fichiers eclipse sont sur le repo pour tout configurer correctement".
[^] # Re: Codium ?
Posté par steph1978 . Évalué à 2. Dernière modification le 20 mai 2023 à 08:47.
Plein de … plugins / addons / extensions / greffons ?
[^] # Re: Codium ?
Posté par barmic 🦦 . Évalué à 1.
D'outils pardon. Il possède énormément de plugins mais c'est pas le sujet.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Codium ?
Posté par AncalagonTotof . Évalué à 2.
je plussois et je rajoute un mais …
Parce qu'on ne parle pas du même contexte.
[Ce qui suit n'est pas méchant, juste caricatural pour aller plus vite !]
Les "gens comme moi" pensent que les "gens comme vous" se moquent d'empiler tout un tas de toolkit & cie, et en plus, ne pensent qu'à en changer tout les six mois.
Mais dans le cas des "gens comme moi", j'évoquais un cas extrême où il faudrait être capable de ressortir le PC du coffre, pointer une version précise du code, et généré exactement le même binaire que dix ans auparavant.
Après, c'est beau sur le papier, assez rare (ferroviaire, militaire, et même pas dans tout le temps), et en pratique, ultra difficile à réaliser.
Et j'y pense 20 ans après en l'écrivant : il aurait aussi était nécessaire de mettre au coffre le serveur ClearCase, parce que sans lui, impossible de ressortir un label ou une branche particulière (git n'existait pas à l'époque). C'est ballot.
[^] # Re: Codium ?
Posté par barmic 🦦 . Évalué à 3.
Est-ce qu'il est plus résilient de tenter de figer tout (l'ordinateur enfin les ordinateurs dans des pièces inifugées séparés suffisamment pour ne pas courir les même risque avec
leles serveurs qui vont avec etc) ou de changer de machine suffisamment régulièrement pour avoir une vision complète de ce dont il a besoin pour fonctionner ?https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Codium ?
Posté par AncalagonTotof . Évalué à 1.
Je ne comprends pas bien, tu parles de quelles machines ? Celles des dévs ? C'est la théorie, dév ou dév+serveur, peu importe, il faut (faudrait; théorie vs pratique) pouvoir ressortir un contexte de dév à l'identique.
Quand ton soft roule aux quatre coins d'un pays, et que 5 ou 10 après, on te dit qu'il y a un bug …
Et pendant ces 5 ou 10, tu as fais autre chose, d'autres projets qui n'ont rien à voir.
À aucun moment, il n'est question de toucher au soft, encore moins de faire des mises à jour au rythme d'un windows/linux ou d'un serveur en prod.
[^] # Re: Codium ?
Posté par barmic 🦦 . Évalué à 2.
Il a était développé ce logiciel, si pendant ça phase de développement il avait été déterminé qu'il fonctionne sur telle architecture avec tel version de tel langage, c'est différent que de dire que la spécification c'est la machine elle même.
Pour moi c'est de la dette technique. C'est un coût que l'on remet à plus tard. On peut décider de me faire pour de bonnes raisons, mais je ne l'éleverai pas à dire que c'est une bonne pratique ou la meilleure façon de faire.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Codium ?
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
Oulah… tu vas être fâché avec bon nombre de boîtes que j'ai connues et où genre 1 dev demande Atom et on lui dit qu'il y a VSC et Notepad++ et pas d'autre choix possibles… ;(
J'ai aussi vu des projets dépendre d'un outil (une fois un éditeur particulier) sans que cela choque quiconque. C'est là que je me dis que j'ai de la chance de plus faire dev.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Codium ?
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 7.
En ce qui me concerne, c’est pas « de la chance ». C’est des points que j’aborde aux entretiens techniques d’embauche. On a une profession où on peut souvent se permettre de ne pas prendre n’importe quelle entreprise parce que c’est la seule à proposer du boulot, autant en profiter – et ça ne passe pas que par le salaire.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Rust
Posté par GwenLg . Évalué à 5. Dernière modification le 17 mai 2023 à 14:56.
Petite note d'encouragement concernant Rust.
J'étais moi aussi un programmeur C/C++, et je me suis mis à apprendre Rust il y a un peu moins de deux ans.
Effectivement la transition n'est pas toujours facile, et je conseillerais d'avoir une personne qui peux nous débloquer en cas de besoin et/ou de suivre une petite formation.
Mais je trouve que ça vaut largement l'effort. Il y a tellement de progrès par rapport à C/C++.
Un exemple:
Il y a quelques jours j'ai voulu utiliser réutiliser un projet Rust, et le code actuel avait un warning sur un bout de code.
Ce code construisait, à partir d'un array (tableau static) un autre array de même taille. C'était fait à la méthode C++, avec un for.
Mais pour être certain que toutes les valeurs de l'array de sortie soit bien initialisé, il fallait avant de faire la boucle for, initialiser le tableau avec des valeurs par défaut, sinon le compilateur n'est pas content, car il n'est pas capable de vérifier que le code dans le for initialise bien tout l'array.
La limite de ça, c'est que du coup le compilateur ne nous aide pas à vérifier que la boucle for initialise bien toutes les valeurs, et que du coup on n'a pas des valeurs par défaut qui pourraient traîner dans le tableau.
Je trouvais ça dommage, et en cherchant comment améliorer le code j'ai découvert que la primitive array possédait une méthode map. J'ai pu donc réécrire le passage en question en code 'fonctionnel'. Le nouveau code :
- évite une double initialisation du tableau (même s'il n'y avait pas de problème de performance dans ce cas)
- est plus concis et évite toute une partie "glu"
- permet d'être plus explicite sur les intentions du code, ce qui permet au compilateur de vérifier plus de chose, mais aussi d'être plus facilement lisible par les humains (quand on s'y est habitué)
le diff est visible ici
Note: Bien sur, ce n'est pas forcément exceptionnel, ça doit exister ailleurs, mais quand on vient du C++ et combiné avec toutes les autres fonctionnalités de Rust ça en fait un langage qui mérite qu'on s'y intéresse
Donc @AncalagonTotof je te conseille de continuer d'essayer de faire le tuto Rust. Avec Codium et le plugin Rust qui va bien ;)
[^] # Re: Rust
Posté par fearan . Évalué à 6.
non c'est fait à la méthode vieux croulant \o/
quelqu'un de moins vieux, utiliserait std::transform.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Rust
Posté par GwenLg . Évalué à 1.
Merci pour l'info, je ne connaissais pas.
En même temps les projets C++ sur lequel j'ai bossé utilisais pas trop la std, et avaient l'autorisation qu'a certain morceau de C++11 :p.
[^] # Re: Rust
Posté par fearan . Évalué à 6.
et pour les modernes, on a les ranges/views
https://en.cppreference.com/w/cpp/ranges
ce qui permet des syntaxe plus élégantes
a noter que les lambda nommée (oui c'est drôle) peuvent se mettre à la place de leur utilisation, mais ça rends le code potentiellement moins lisible
on peut aussi faire un using std::views::filter et using std::view::transform pour avoir tableau| filter(…) | transform(…)
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Rust
Posté par Zenitram (site web personnel) . Évalué à 10. Dernière modification le 17 mai 2023 à 18:14.
C'est la problématique de C++, pas mal de monde le critique en comparant un nouveau langage à la mode à C++ d'il y a 20 ans (je serai tenté de dire un C++ rouillé mais après on avoir 2 "rust" en compétition :) ) et non pas C++20.
C++ a plein de défauts (et Rust répond à certains problème comme le multithread et met la sécurité par défaut la où il faut penser à "at" et pas "[]" si on veut la sécurité en C++), mais la majorité des critiques montrent surtout un manque de connaissances.
C'est bien dommage, mais C++ continue son bonhomme de chemin malgré tout.
Et du coup, quand on compare Rust à C++20, on a surtout l'impression d'un concours d'illisibilité de code mais quand même sans jamais dépasser Perl :-D.
[^] # Re: Rust
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 6. Dernière modification le 17 mai 2023 à 19:05.
La remarque est valable pour tous les langages qui évoluent, surtout ceux qui partent de loin. Pour ceux qui me viennent en tête : C++, Java, PHP…
Et les problèmes historiques ont la vie dure, cf les deux commentaires sur Java sous ce lien.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Rust
Posté par fearan . Évalué à 3.
en fait pas rouillé, simplement mal/pas appris. avant les lambda on pouvait faire l'équivalent avec des struct avec operator() et faire ce qu'il fallait pour les variables (référence, copie…) j'ai appris le c++ après 2000, et ces trucs on me l'a jamais appris, c'est après la sortie du c++11, et des années à pester contre le choix de rester à celui de 2003 que j'ai trouvé comment faire avec.
En fait le C++ peut être parfaitement lisible; tout comme le Perl ; de même il est tout à fait possible de faire un texte syntaxiquement exact en Français, tout en étant parfaitement incompréhensible, voire même ambigu; à cela on peut ajouter le ton ou le contexte et no peut avoir des sens radicalement différent; est-ce une raison de vouloir l'appauvrir? Je ne pense pas.
La relecture de code se répand; et c'est une bonne chose; si le relecteur ne comprend rien (quel que soit le langage), y'a probablement un effort à faire, sinon on récupère une boite noire.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Rust
Posté par barmic 🦦 . Évalué à 4.
C'est fait de manière impérative à un endroit où on gagne à utiliser un style fonctionnel. L'inverse existe aussi (par exemple avec des
filter()outransform()qui ont des effets de bord). Et ces cas inverses apparaissent d'autant plus que l'on présente comme vieux la façon la plus simple de faire (parce que oui tu peux utiliser des monades aussi, mais c'est pas forcément le plus simple surtout quand le langage ne t'aide pas particulièrement).https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Rust
Posté par fearan . Évalué à 3.
C'était une boutade; je soulignais juste que la façon de faire des langages 'modernes' avec map ou filter; se faisaient déjà y'a 20 ans; pas forcément avec une syntaxe 'sexy', mais y'avait déjà des équivalents (au pire on utilisait boost).
Surtout que maintenant les jeunes en sortie d'école se mettent à remplacer des morceau de code parfaitement fonctionnel et lisible par leur équivalent en stream. J'ai pas mis la référence journalien d'un désabusé disant qu'après 20 ans de carrière tout ce qu'il laissait c'était de la dette technique, mais j'y pensais fortement en écrivant le commentaire.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Rust
Posté par barmic 🦦 . Évalué à 5.
lisp le faisais… en 58. Je le fais remarquer parce que la perception de « moderne » est tout à fait relatif. Utiliser le bon outil au bon moment devrait être mieux valoriser qu'utiliser l'outil qui plait autant que possible.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Rust
Posté par AncalagonTotof . Évalué à 3.
Merci pour les encouragements ! Je fais parti des vieux croulants mentionnés juste après …
Je n'ai jamais aimé les templates du C++, je trouve que ça rend le code illisible très vite, et les erreurs de compilation peuvent devenir très absconses.
J'admets avoir d'énorme lacunes sur ce point, et je les mesures d'autant plus depuis que j'ai découvert la chaîne de Jason Turner.
Rust a cet aspect qui est séduisant : c'est plus propre.
Après, le temps que je m'y mettes, tout le monde sera passé à Zig non ?…
[^] # Re: Rust
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à -2.
OK, il faut plus de deux ans avec un tuteur jedi et on est récompensé de l'effort herculéen. Heureusement qu'on a toute la vie devant soi et rien d'autre d'intéressant à faire.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Rust
Posté par GwenLg . Évalué à 0. Dernière modification le 18 mai 2023 à 01:13.
Joli détournement de propos (ou incompréhension ?).
Pour préciser :
J'ai dit "près de deux ans" et pas "plus de deux ans" …
L'effort n'est pas herculéen, et si apprendre Rust nécessite des efforts. Rust permet également d'éviter certain efforts qu'il faudrait faire avec d'autres langages (notamment C++).
Justement je n'avais pas de tuteur, encore moins jedi, donc j'ai appris moins vite que je n'aurais pu.
Il n'a pas fallu attendre "presque deux ans" pour être "récompensé".
Tu es libre d'avoir d'autres choses "plus intéressante" à faire, mais ne présume pas pour les autres ;)
[^] # Re: Rust
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3.
J'ai bien lu "presque" deux ans et cru comprendre que ce n'était pas fini, d'où ma déduction qu'il fallait "au moins" deux ans.
Pour les choses intéressantes, ce n'est pas que apprendre un langage ne l'est pas. C'était pour souligner que je trouve c'est un énorme investissement de temps pour des langages qui disent apporter facilité et confort etc. La même remarque s'applique à C++ hein : on peut certes s'initier en deux ou trois mois, mais j'ai l'impression qu'il faut bien deux ans pour commencer à être à l'aise avec et éviter certains pièges, et on ne parle pas encore de maitriser le langage.
En tout cas, cela me conforte quelque part d'avoir lâché l'affaire au bout de quatre ou cinq mois : je n'arrive pas à penser et ressentir rust… et je peine encore à rattraper tout ce que j'avais mis en standby.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Rust
Posté par GwenLg . Évalué à 1.
Effectivement, ce n'est pas fini, mais apprendre un langage ce n'est jamais fini .
Et puis il y a le langage, l'écosystème, les librairies/framworks, etc
Pour le "penser Rust", quand on vient du C/C++ effectivement ça peut prendre du temps.
Quelqu'un qui a déjà fait de la programmation fonctionnelle, ça peut-être plus rapide.
Par contre, créer et configurer un nouveau projet, chercher des librairies pour réutiliser le code, gérer les dépendances, comprendre comment utiliser une librairie, faire fonctionner ensemble différentes librairie, … tous ça me semble plus facile, rapide et reposant qu'en C++ par exemple.
Même contribuer à un projet, je trouve ça plus "facile", j'ai moins peur de mal faire un truc.
[^] # Re: Codium ?
Posté par Glandos . Évalué à 3.
Il y a la notion de Recommended plugins qu'on peut mettre dans un fichier à commiter dans son code source. Ça permet de mettre quelqu'un sur un nouveau projet très rapidement.
De même, un grand nombre de paramètres peuvent être enregistrés dans le projet lui-même (je pense aux paramètres de formatage, entre autres), qui va avec le code source.
Je n'ai qu'un seul avis concernant les IDE : laisser les gens utiliser celui qu'ils veulent. Des fois, le choix est réduit (faire du Vue.js, c'est presque obligatoirement par VSCode/Codium, bien que des LSP soient pris en charge dans d'autres éditeurs (https://github.com/vuejs/language-tools) mais c'est quand même beaucoup plus facile.
Dans mon bureau, on est 5 développeurs, on utilise 4 IDE différents. Parfois sur le même projet. On est grand, ça marche, on se sent bien dans ses pantoufles, c'est cool.
[^] # Re: Codium ?
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
Comme je n'utilise pas, je ne sais pas si je dis une bêtise en disant de sauvegarder le dotfile ou dotdir qui va bien ? J'avais vu une question similaire fin octobre, et cela a débouché sur :
https://code.visualstudio.com/docs/editor/settings-sync
D'un autre côté, à moins d'être des clones sans personnalité distincte, tout le monde ne peut pas avoir les mêmes besoins… Et cela ne devrait pas influencer sur le travail en lui-même : il y a normalement des règles/conventions de codage/commit/arborescence/docs/etc, sinon le projet a d'autres soucis à se faire àmha.
Quelle brillante idée… :D Parce-que j'espère qu'il a été prévu qu'il peut y avoir des défaillances mécaniques (le disque qui lâche par exemple) et que les pièces de rechange n'existeront plus… Plus les problèmes logiciels (je n'irai pas jusqu'à envisager le bsod mais un fichier corrompu par exemple, ou une licence expirée, ah oui y a les mises à jour ou pas ?) Bref, on va rigoler (ou pleurer toutes les larmes de son corps ?)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
# Ne convaincra que les convaincus, et fracture lui-même
Posté par Zenitram (site web personnel) . Évalué à 2. Dernière modification le 17 mai 2023 à 13:43.
A noter qu'il vaut mieux lire la source https://ghuntley.com/fracture/ (en Anglais, de 2022) qui parle un minimum de VSCodium.
Mais sinon, je me demande bien qui fracture le plus entre une entité qui ouvre partiellement et donc fait un pas vers le libre à défaut d'y aller à 100%, et une personne qui rejette tout ce qui n'est pas 100% du code libre.
VSCodium (la version sans ajout non libre) est libre et utilisable, mais ce n'est pas assez pour lui, OK, ben désolé je vois plus cette personne comme une personne qui cherche à fracturer une communauté parce que cette communauté ne serait pas assez pure, que d'accepter tout le monde y compris ceux qui font "que" un (gros, quand même) pas vers le libre. Et ça serait bien mieux, si on veut du 100% libre, ben de remplacer le code non libre par du libre, mais bon c'est plus d'effort, faut coder et attirer du monde, convaincre de l'utilité, plutôt que de râler.
Et le FUD légal est dans ce texte, pas ailleurs, sans argument concret. ha oui si tu joues à violer la licence non libre des plugins ça peut être chaud, mais c'est quoi le rapport avec le libre? Aucune obligation d'aller taquiner le non libre.
Et si VSCodium n'est pas assez bien sans plugin, pourquoi donc cette communauté qui ne veut pas de non libre ne se bouge pas les fesses pour coder les plugins dont les gens ont besoin plutôt que de râler?
Je note une phrase non reprise dans le résumé en français :
Donc le mouvement actuel pue car pas assez comme il veut, et il faudrait donc peut-être créer un schisme dans le libre pour y mettre sa morale, pas nouveau et pas le premier à ne pas aimer la liberté du libre, mais sérieux, après cette phrase il critique Microsoft de vouloir fracturer? Ha ha ha.
Au final, j'ai l'impression que c'est pour flatter une partie des libristes qui n'aime pas la direction que prend la communauté du libre dans son ensemble (qui accepte des ponts entre libre et non libre et voit le libre comme un moyen plutôt qu'un but) qu'autre chose, et tant pis pour le dommage collatéral qui serait pousser à… une fracture de la communauté du libre.
Si vous pensez pouvoir faire mieux, faites et montrez que votre modèle est mieux plutôt que d'accuser les autres de ne pas faire comme vous voulez, arrêtez d'accuser les autres de fracture ou que sais-je juste parce qu'ils ne sont pas d'accord avec vous mais que eux réussissent (il y a d'autres outils pour coder, 100% libres… Mais pas utilisés par les gens, il faut peut-être se demander pourquoi).
Ce n'est pas un piège, c'est connu et accepté.
PS : je code principalement sous Visual Studio, 100% non libre sur un OS 100% non libre, et ça ne m’empêche aucunement de faire du 100% libre et même du 100% compilable sous tout OS libre avec tout compilo libre. La licence de mon outil pour coder n'a aucun impact sur la liberté de mon code, elle n'a pas non plus d'impact sur mes collègues qui n'aiment pas le non libre et utilisent que du libre pour coder sur mon projet, n'en déplaise à certains pour qui si on n'est pas pur on fracturerait à utiliser les meilleurs outils pour soit y compris ceux non libres. Liberté!
[^] # Re: Ne convaincra que les convaincus, et fracture lui-même
Posté par corentin38 (site web personnel) . Évalué à 1. Dernière modification le 17 mai 2023 à 14:43.
<Hors sujet>
Je compatis pour Visual Studio. C'est vraiment la plaie, cet IDE.
</Hors sujet>
[^] # Re: Ne convaincra que les convaincus, et fracture lui-même
Posté par xcomcmdr . Évalué à 3. Dernière modification le 19 mai 2023 à 17:48.
Non, la plaie c'est l'éditeur de texte lent car il embarque un navigateur complet (!).
Je garde mon paquet d'IDE 64 bit ultra rapide, même contre deux barils d'application Electron basique et lourde.
Puis t'façon j'suis perché, j'utilise JetBrains Rider sous Fedora.
VSCODE = CACA !1one
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Ne convaincra que les convaincus, et fracture lui-même
Posté par YBoy360 (site web personnel) . Évalué à 3.
Plutôt d'accord avec ton point de vu, j'ai mis l'article en lien sans vraiment apprécier ni son contenu, ni son écriture. Cela dit, je n'ai jamais autant observé de prosélytisme pour un IDE que pour VSCode (et pour VSCodium) au détriment d'autres solutions. Et c'est là qu'est le problème.
Je n'ai essayé qu'une fois sérieusement VSCodium, mais j'en ai perçu certaines limites qui me gênent beaucoup. Selon ma compréhension, les bonnes idées de VSCodium, c'est d'utiliser du JS/TS, ce qui le rend de facto populaire et le LSP (le Language Serveur Protocole).
Si il y a d'autres avantages techniques, je suis preneur.
[^] # Re: Ne convaincra que les convaincus, et fracture lui-même
Posté par Adrien Dorsaz (site web personnel, Mastodon) . Évalué à 5.
Il y a aussi le protocol DAP qui uniformise les debuggers (de la même manière aue LSP uniformise l'aide au développement).
Grâce à LSP et DAP, j'ai par exemple pu transformer vim en IDE: https://linuxfr.org/users/trim/journaux/transformer-vim-en-ide-avec-lsp-et-dap
[^] # Re: Ne convaincra que les convaincus, et fracture lui-même
Posté par YBoy360 (site web personnel) . Évalué à 2.
Oui, j'avais lu ton journal :)
Merci beaucoup.
[^] # Re: Ne convaincra que les convaincus, et fracture lui-même
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
Tu es aussi biaisé que lui : tu penses que parce-que tu as fait un choix (le PS) que c'est le cas de tous. Perso, je n'ai pas encore rencontré de personne, en salariat dans les moyennes et grosses structures que j'ai connu, qui ai eu le choix de ses outils pour coder cf. mon autre commentaire ; donc y a pas à se demander pourquoi on ne retrouve que certains outils imposés…
Tu suis le même travers que lui : tu l'accuses de ne pas faire comme toi, et donc d'avoir tort. Et défendre votre modèle bec et ongle semble trop vous tenir à cœur, comme si l'avenir de l'humanité en dépendait …alors qu'en vrai la grosse majorité me semble s'en ficher pas mal.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
# Alternative ?
Posté par devnewton 🍺 (site web personnel) . Évalué à 4.
J'utilise Codium pour les projets en Go + html/css/javascript. Quelles alternatives plus libres et sans Microsofterie dedans ?
Pour Java, je garde mon baril de Netbeans, mais il a du mal à se remettre de son abandon lors du rachat de Sun par Oracle.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Alternative ?
Posté par wilk . Évalué à 3.
Vim
[^] # Re: Alternative ?
Posté par Dr BG (site web personnel) . Évalué à 2.
Eclipse Theia ? https://theia-ide.org/
Comme VSCode mais indépendant.
[^] # Re: Alternative ?
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
C'est intéressant, mais ni clair, ni très abouti.
https://theia-ide.org/docs/getting_started/
https://theia-ide.org/docs/blueprint_download
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.