Utile étant très subjectif…
J'avais à une époque ou je jouais beaucoup aux cartes Magic the gathering, créé un programme qui me permettait de calculer le nombre de terrains de chaque couleur que je devais mettre dans mon jeu pour optimiser mes chances de ne pas être handicapé par le fait de jouer plusieurs couleurs*.
Ca n'atteignait sûrement pas les 1000 lignes, considérant que la plupart du taf était faite via l'IHM, donc via une lib.
Je doute aussi que calc.exe ( proprio, certes, mais très utile ) fasse plus de quelques centaines de lignes, et pourtant, j'utilise souvent une calculette, peu importe mon OS. Celle de windows est mieux foutue que galculator sur certains aspects en plus.
J'ai aussi un script shell pour extraire les fichiers d'une archive jamendo dans une arborescence "artiste/album/*.???".
Ainsi qu'un outil pour générer une classe C++ en ligne de commande en fonction d'un nom que je lui passe, qui hérite automatiquement d'une liste de classes que je lui passe en paramètres ( fonctionnalité prévue: l'ajout automatique des prototypes des fonctions virtuelles des classes mères, avec le mot-clé override fournit gratos, entres autres ).
Je dois en citer d'autres, de petits utilitaires en dessous des 1000 lignes de code, ou tu as compris l'idée?
En fait, le mot est placé: utilitaire.
*: Ce qui me rappelle que le code source n'est pas "libre" ( surtout, pas diffusé ) mais j'avoue ne pas trop avoir imaginé qu'il puisse servir à quelqu'un… je dois encore l'avoir qui traîne sur un disque, je verrai p'tet pour le publier ce WE ^
Héhéhé, je n'ai pas dit mon dernier mot:
Pas bien de se laisser embrigader par les politiques commerciales et de favoriser ainsi la vente liée ( on est trolldi depuis 1H, ouf suis sauvé )
Merci bien, je me sentait désespéré à l'idée de devoir manipuler un langage non typé sans débogueur, j'allais même sûrement binder une combo de touches de vim pour insérer des print, vu que le taf m'obligera sûrement à toucher à ce langage… ( quoique le client avait l'air heureux quand j'ai dit que je préfère utiliser d'autres langages a titre perso… peut-être que… avec quelques TU pour assurer mon coup, il y a moyen de vendre une migration de langage sur ce code crado, histo et phpo… )
et « IDE » est un ensemble de fonctionnalités pas clairement défini, mais dont on peut être sur qu'il inclut « éditeur de texte ».
Faux.
Tu pars du principe que tout langage de dev n'est constitué que de caractères ascii, la, voire de caractères tout court.
Ce n'est pas le cas. Les logiciels permettant de créer des programmes pour des automates industriels ne sont pas nécessairement textuels. Je ne connais que peu ce type de techno ( en fait, que de nom ) mais mon frère à fait ce genre de choses en bts électrotechnique ( il me semble qu'il me parlait de graphset, ou un truc du genre ).
Ce qui est amusant, c'est que je te contredis pour apporter de l'eau à ton moulin: un IDE est loin d'être évident à définir précisément. Après tout, le logiciel qui lui permettait de créer ces diagrammes qui étaient le source d'un programmes, n'avaient rien à voir avec un éditeur de texte, et étaient pourtant ce que l'on appellerai des IDE.
Lors d'une formation de chef de projet ( merci le pseudo anonymat internet, je préfère ne pas en parler si on peut m'identifier, tellement ça m'emmerderait que ça arrive aux mauvaises oreilles ) j'ai aussi vu des outils générant des programmes sans une once de texte, à base de schémas ( gestion de process en entreprise, de flux, bref, des trucs chiants… mais ça marche ) .
Donc, il n'y a pas qu'en industrie, mais aussi en service. Vraiment, non, un IDE n'inclue pas nécessairement un éditeur de texte.
Ah, ne pas oublier de citer access, que tout le monde ici doit connaître et qui permet de créer une DB ainsi qu'une IHM sur cette DB sans taper de coder si on le souhaite.
Si je rappelle qu'il n'y a pas que les entreprises qui font du dev, je passe pour un abruti, je suis hors sujet, ou j'ai raison? ( notez que je suis plus habitué au 2 1ers qu'au 3ème, je pense même que j'aime ça :p )
Oui, c'est limite trollant, j'avoue, mais, pour me justifier, les gens confondent souvent moderne et ayant une valeur commerciale élevée.
Et moi, je me dis que vu qu'on pouvais dev il y a 20 ans, pourquoi ne le pourrait-on plus avec des machines de même puissance, maintenant?
Alors, bien entendu, je sais que, je cite Mr dupond ( et pas dupont ) "Les applications modernes ont besoin de machines modernes pour tourner!" sauf que la raison principale de cet état de fait, c'est qu'on ne sais plus faire autrement que faire des trucs lourds j'ai l'impression.
Allez, un exemple pour accompagner mon argument: combien d'utilisateurs de word utilisent des fonctionnalités coûteuses en terme de CPU qui n'existaient pas il y a, disons, 10 ans? En pourcentage estimé, hein, pas en chiffres bruts.
Moi, je gage qu'on est largement en dessous des 25%, autrement dit, que la puissance consommée par ce logiciel à l'heure actuelle pourrait être réduite drastiquement dans 75% des cas.
Et ça, je suis incapable d'estimer l'impact que ça aurait énergétiquement et économiquement parlant sur notre planète. Moins de gaspillage, c'est la seule chose dont je sois persuadé ( pas convaincu, je manque de preuves pour ça ).
Ca vaut pour toutes les suites bureautiques, d'ailleurs.
Et pour revenir au dev, et à des cas concrets, la machine sur laquelle j'ai le plus codé ces 3 dernières années est un netbook, 1Go de RAM, dual core dual thread cadencé à 1.5GHz. Je t'assure que sur cette machine, ça à un impact non négligeable. Et je ne vois pas pourquoi je devrais m'interdire de coder dessus sous prétexte qu'elle m'a coûté que 210€ il y a 4 ans.
PS: vu le smiley, j'imagine que c'était de l'humour ta réponse, mais je tenais malgré tout à saisir l'occasion pour exprimer mon ras-le-bol des bloatwares et l'énervement que m'a toujours causé les gens qui disent "ne vous occupez pas des perfs, le client rachètera du matos", genre de mots entendu de mes profs, il y a presque 10 ans… et qui m'enragent toujours autant… oups :)
Mais un outil spécialisé dans un langage particulier incluera probablement nombre d'automatismes particuliers à ce langages, de raccourcis pour ses idiotismes et que sais-je encore.
Dans le cas de C++, il serait même imaginable qu'un nouveau moteur d'autocomplétion spécialisé puisse être réellement efficace ( j'ai bien dit: nouveau ;) )
En soit ça ne me semble pas idiot, de spécialiser l'outil… jusqu'a ce que je me rappelle qu'en général, un développeur professionnel n'utilise pas qu'un seul langage, et que changer d'outil en fonction du langage est assez ennuyeux, voire pénible.
Permets-moi de t'avouer que tes distinctions sont, à mon humble avis, simplistes.
Un éditeur de texte, on lui demande juste de créer, lire, et modifier un série de caractères sur un disque dur.
D'afficher de la coloration syntaxique ou une liste de suggestions, à mon sens ce ne sont pas des choses qui ont trait à l'édition de texte, mais à l'édition de code, chose très différente.
Après tout, un éditeur de texte ne sert pas qu'a créer du code, il y a aussi les todolist, les readme, etc.
Pour prendre un exemple "théoriquement concret", imagines un éditeur de texte qui fonctionne sur le même principe que mpd/mpc/ncmpc, c'est à dire un démon ( mpd ) qui à le contrôle total sur le texte ( 1 démon, 1 fichier, pour prendre un truc simple ), et des clients, qui communiquent avec le démon. Ces clients pourraient très bien s'interfacer à un autre outil qui aurait, lui, le rôle de soumettre des suggestions ( auto-complétion ) et laisser la coloration syntaxique à leur IHM.
Comment pourrais-tu dans un tel cas classer cet éditeur de texte théorique dans une de tes cases? Il est capable de traiter plusieurs langages, puisqu'il ne s'agit que de texte, donc il est généraliste. Pourtant, il n'inclue pas lui-même de système de plug-in et encore moins de coloration syntaxique, choses qui ne seraient gérées que par les clients voire d'autres outils.
Ensuite, la notion d'IDE est, elle aussi, délicate à définir. Selon le langage, on ne compile pas forcément ( interprété ), ne débug pas forcément ( je ne sais pas si ça existe, un débuggueur php par exemple? ), n'utilise pas forcément de diagrammes ( pour du code LaTeX je doute qu'on puisse faire des diagrammes pour représenter le code par exemple ) etc.
J'ai aussi connu des IDE qui n'ont pas la notion de contexte, de projet ( turboC par exemple, que j'ai longtemps préféré a devcpp ou un truc du genre parce que c'était justement moins prise de tête pour compiler/debugguer avec, pas besoin de s'emmerder à créer un projet pour un code de 500 lignes… ).
Alors qu'un simple éditeur de texte, dans un environnement configuré correctement, offrira à son utilisateur ( probablement aguerris aux twm et lignes de commandes ) autant de facilité qu'un IDE.
Du coup, quelle différence entre IDE et "DE" spécialisé pour le dev?
Les seules choses qui permettent à mon avis de différencier un outil qui permets de gérer son code d'un autre, c'est:
_ à quel point il est efficace par défaut. Caractéristique des IDE, ils sont très efficaces out-of-the-box. Par contre, quand on commence a vouloir un truc plus à son goût, ça commence à bloquer comparé à la config totale de son environnement de bureau à coups de scripts et d'outils respectant la philosophie UNIX.
_ à quel point il pèse sur les performances de la machine. Genre, on ne peut pas comparé eclipse ou visual studio avec vim+i3+lxterminal+bash.
Ceci dit, je te remercie parce que j'ai bon espoir de lire des choses très intéressantes en réaction à ton billet :)
Sauf que ça crée des lignes, donc pas toujours idéal. Par exemple, imagines un code qui utilise "use namespace std;", et la convention de codage du projet dit que les "use namespace" sont interdits. Comment ajouter facilement le "std::" à chaque endroit du code ou il est nécessaire?
Bon, c'est assez limite comme cas, j'avoue, mais pour les autres auxquels je pense, on peut utiliser une combo entre la méthode que j'ai mise pour créer N lignes identiques et/ou le remplacement via des regex :)
J'ai un collègue qui utilise cet outil, ça à effectivement l'air intéressant ( ceci dit, je ne savais pas qu'il tourne sous nux, le collègue en question restant sous win ).
Maintenant, je dois t'avouer que ma tendance personnelle va de plus en plus à l'écriture de fichiers d'une très petite taille ( C++, donc 1 fichier par classe, et quand ça dépasse les 200 lignes, je divise pour envoyer le code dans le cpp. ), des classes ultra-spécialisées et sans me gêner pour utiliser des templates.
Du coup, je ne suis pas sûr d'avoir encore besoin d'un éditeur de code très évolué: une fois que j'ai la coloration syntaxique, une auto-complétion potable et un système modal ( sur ce point, vim à changé ma vie, c'est une évidence ) je suis heureux, et donc mon usage basic de vim me conviens plutôt pas mal.
Le tout combiné avec, en fait, un simple terminal pour naviguer dans les fichiers, est plus efficace que tout ce que j'ai pu voir avec des IDE classiques.
Dommage d'ailleurs qu'il n'y ait pas un éditeur de code simple ayant ces 3 fonctionnalités avec une toute petite base de code, nul doute que je l'adopterai :)
Le but de mon message était surtout d'argumenter sur le fait "oui, vim peut encore évoluer". Ces fonctionnalités, je m'en servirais de temps en temps, genre, 1 fois par mois. Rien d'important donc.
Et puis, sans être un maniaque de l'open source ( j'utilise opera après tout ) je suis plutôt réticent à l'idée d'utiliser du code fermé.
LA fonctionnalité qui pourrait me faire utiliser un nouveau logiciel fermé, ce serait d'être capable de générer des diagrammes à partir du code, et vice versa. Mais ce n'est pas le job d'un éditeur de code, ça.
XDG-directory ( ou un truc du genre ) n'a pas à être écouté par les dev d'OS, mais les dev d'application.
Tout OS ( shell, en fait ) qui est capable de gérer un système de fichier, un profil utilisateur et des variables d'environnement supporte cette norme, au final.
car c'est un langage qui intègre la possibilité de déclarer des grammaire BNF en natif.
Ha oui en effet! J'admets être parti à la déconnade ( j'ai essayé prolog… je n'ai pas vraiment réussi à faire grand chose avec malheureusement ), mais un langage qui intègre les bnf dans le langage à un potentiel évident.
Comme quoi, parfois c'est utile de déconner :)
Pas vraiment, mais ce n'est pas la même chose de sélectionner ( qui me sert surtout à copier/couper, je ne vois pas vraiment d'autres usages… ) ou de faire de l'édition en colonne. Ou alors j'ai mal compris ce que tu veux dire ( ce qui ne me surprendrais pas de ma part ).
Maintenant que j'y pense, on pourrait également mentionner les curseurs multiples, qui sont aussi un outil très sympa quand ça ne bug pas ( c'est implémenté par scintilla, mais le fait de faire un retour à la ligne fait perdre le multi-curseur, et certaines autres actions ne fonctionnent pas ou sont bugguées. Enfin, c'était le cas quand j'utilisais encore autre chose que vim. ).
Je doute que vim supporte ça. Mais je suis aussi persuadé que ce fork ne le supportera pas de sitôt, en admettant que la sauce prenne.
Les alternatives existent, même si ce n'est pas forcément mainstream.
Par exemple (je ne me suis pas amusé avec ce langage donc je ne sais pas ce qu'il vaut), Code::Blocks utilise squirrel.
Je suppose qu'un système permettant d'éditer un fichier à plusieurs serait utilisable. Problème, je doute que ce fork finisse par en être capable, il faudrait faire plus que découpler des modules et refactorer du code pour ça.
Pour ma part, probablement à cause du fait que je n'utilise vim que de façon basique, je trouve que la config est trop complexe à gérer ( j'avais regardé pour changer des bindings… les lignes de config m'ont fait penser "omg, usine à gaz spotted!" ). Mais la encore, je doute que ce fork fasse évoluer ça ( puisqu'il reste, naturellement, compatible avec l'original ).
J'ajouterai enfin l'édition verticale, plutôt qu'horizontale. C'est peut-être possible, je n'ai jamais cherché. Après avoir tapé le "case :" dupliqué 20 fois d'un switch, que le curseur évolue à la verticale plutôt qu'à l'horizontale s/est/serait/ utile. Enfin, ici aussi, je m'en fiche, j'ai commencé à prendre l'habitude d'utiliser des tableaux associatifs dans mon code, au lieu de switch à rallonge. En plus ça me permets de faire du switch sur string en C++ ( avec des lambda ou pointeurs de fonction en valeur, c'est assez sympa et me blesse moins à maintenir que les 20k lignes d'un switch classique. Mais j'imagine que niveau perf c'est un peu moins terrible… ).
Autrement dit, le fait de considérer vim comme fini dépend des gens :)
Non, ceci n'est pas un troll pour prouver une théorique supériorité de LaTeX.
Cependant, il m'a semblé croiser au fil de mes écumages de la toile, des outils permettant de compiler des fichiers .tex en documents web ( ainsi qu'en documents doc, d'ailleurs ) .
Ceci étant dit, vu que tu sembles apprécier les outils avec une GUI, je ne suis pas sûr que tu apprécies LaTeX, puisque c'est du code. Mais peut-être que cette piste pourra te plaire ( personnellement, j'aime bien pour le peu que j'en connait, mais je trouve que c'est quand même un peu la jungle.
En fait, j'ai la même sensation avec LaTeX que quand j'ai découvert Debian pour de bon… noyé par les alternatives et les informations. Vu que je ne suis pas un grand fan de beauté conceptuelle de mes documents ( choisir la police, la couleur, et la taille de mes lettres une par une… non merci, vraiment. ) , je n'ai pas cherché à apprendre à nager dans cet océan, contrairement à Debian ou je m'exerce doucement à la brasse coulée :p —nage lente, mais pas trop fatigante qui donne de jolis aperçus du monde sous-marin sans trop se mouiller—)
Intéressant.
Il s'agit d'un bug que je n'ai jamais rencontré, peut-être parce que j'utilise opera ( en revanche j'en ai d'autres, dont un exclusif à linuxfr. Faudra que je report, un de ces 4… allez, je vais me motiver et le faire de suite. ).
Au final, si je comprend bien, le souci vient du fait que certains browser aient un nombre de connexion limité par serveur, je suppose dans le but d'économiser de la BP tout en téléchargeant plus d'un élément par page ( et donc onglet ), mais la bride entre en conflit direct avec le fait d'utiliser des onglets multiples.
Je me demande si ces situations ( sont-elles résolues? le message que tu cites date de 2011, il y a 3 ans donc. ) se seraient également produites dans le cas de plusieurs instances de la même application lancée sur la même machine?
Pour ma part, je flaire l'application (le browser) qui cherche à deviner ce que l'utilisateur veut, et foire lamentablement. Comme souvent quand une application se mêle d'interpréter les intentions d'un humain.
Et des onglets ! Un navigateur sans onglets c'est devenu has been ;)
Hum… le seul problème des onglets que j'arrive à voir, c'est de les isoler pour pas qu'un bug de l'objet contenu par l'un d'eux fasse planter l'application entière, ou pire, ne puisse corrompre les autres.
Maintenant… si les applications ont besoin de gérer les onglets elles-mêmes, c'est pour une et une seule raison: les gestionnaires de fenêtre flottantes ne font pas leur boulot de façon assez évoluée. Cette fonctionnalité de séparation des processus/thread/affichages (en gros, que dans un même programme on ait de multiples instances de ce programme même qui ne puissent pas communiquer ni avoir d'effets de bord avec/sur les autres) ne devrait pas être dans le navigateur. Bien entendu, je pense la même chose au sujet des éditeurs de texte, notamment.
Gérer les priorité des processus, c'est le job du kernel. Gérer les fenêtres, celui du gestionnaire de fenêtre ( ou comment enfoncer une porte ouverte… ) et donc absolument pas celui du navigateur.
Je crois que le jour où les développeurs de nombreux outils ( wm inclues ) auront compris ça, ils en chieront nettement moins à développer les applis end-user.
Bon, je parle, mais je code pas non plus dans le bon sens, j'admets. Le problème de la séparation des rôles n'est pas simple non plus, par exemple, rien que définir qu'est-ce qui dans une application est de la gestion de fenêtre, et qu'est-ce qui est de l'ordre des contrôles ( et donc, lié au toolkit ) n'est pas simple. Dans les 2 cas, le terme fenêtre est utilisé de façon à peu près semblable, mais pas complètement.
Toujours est-il que je trouve ça assez débile de faire des onglets multiples sur un navigateur, qui est du coup à instance unique ( généralement ) histoire que quand ça plante, ben que ça fasse pas semblant ( le pire, c'est que j'ai été heureux à l'époque ou je suis passé à FF d'avoir des onglets… ).
Pour le reste, je suis globalement d'accord avec toi.
Désolé, mais utiliser un mélange d'espaces et de tabulations (parfois sur la même ligne !)
Je plussoie. D'ailleurs, c'est assez pénible d'aller lire l'implémentation de GNU de la STL, justement parce que c'est le foutoir de ce point de vue ( et comme j'utilise des tab à 2, et non 4 comme la majeure partie des gens… ).
Quand on se dit qu'un simple hook sur l'action de commit du VCS suffirait à coller un coup d'astyle et donc avoir un code propret, c'est tout de même dommage.
[^] # Re: Evolution
Posté par freem . En réponse au journal Neovim : vim's rebirth for the 21st century. Évalué à 2.
Utile étant très subjectif…
J'avais à une époque ou je jouais beaucoup aux cartes Magic the gathering, créé un programme qui me permettait de calculer le nombre de terrains de chaque couleur que je devais mettre dans mon jeu pour optimiser mes chances de ne pas être handicapé par le fait de jouer plusieurs couleurs*.
Ca n'atteignait sûrement pas les 1000 lignes, considérant que la plupart du taf était faite via l'IHM, donc via une lib.
Je doute aussi que calc.exe ( proprio, certes, mais très utile ) fasse plus de quelques centaines de lignes, et pourtant, j'utilise souvent une calculette, peu importe mon OS. Celle de windows est mieux foutue que galculator sur certains aspects en plus.
J'ai aussi un script shell pour extraire les fichiers d'une archive jamendo dans une arborescence "artiste/album/*.???".
Ainsi qu'un outil pour générer une classe C++ en ligne de commande en fonction d'un nom que je lui passe, qui hérite automatiquement d'une liste de classes que je lui passe en paramètres ( fonctionnalité prévue: l'ajout automatique des prototypes des fonctions virtuelles des classes mères, avec le mot-clé override fournit gratos, entres autres ).
Je dois en citer d'autres, de petits utilitaires en dessous des 1000 lignes de code, ou tu as compris l'idée?
En fait, le mot est placé: utilitaire.
*: Ce qui me rappelle que le code source n'est pas "libre" ( surtout, pas diffusé ) mais j'avoue ne pas trop avoir imaginé qu'il puisse servir à quelqu'un… je dois encore l'avoir qui traîne sur un disque, je verrai p'tet pour le publier ce WE ^
[^] # Re: Exemple
Posté par freem . En réponse au journal {éditeurs de texte, IDE} × {généralistes, spécialisés}. Évalué à 1.
Héhéhé, je n'ai pas dit mon dernier mot:
Pas bien de se laisser embrigader par les politiques commerciales et de favoriser ainsi la vente liée ( on est trolldi depuis 1H, ouf suis sauvé )
[^] # Re: vision simpliste
Posté par freem . En réponse au journal {éditeurs de texte, IDE} × {généralistes, spécialisés}. Évalué à 1.
Merci bien, je me sentait désespéré à l'idée de devoir manipuler un langage non typé sans débogueur, j'allais même sûrement binder une combo de touches de vim pour insérer des print, vu que le taf m'obligera sûrement à toucher à ce langage… ( quoique le client avait l'air heureux quand j'ai dit que je préfère utiliser d'autres langages a titre perso… peut-être que… avec quelques TU pour assurer mon coup, il y a moyen de vendre une migration de langage sur ce code crado, histo et phpo… )
[^] # Re: Euh… ?
Posté par freem . En réponse au journal {éditeurs de texte, IDE} × {généralistes, spécialisés}. Évalué à 1.
Faux.
Tu pars du principe que tout langage de dev n'est constitué que de caractères ascii, la, voire de caractères tout court.
Ce n'est pas le cas. Les logiciels permettant de créer des programmes pour des automates industriels ne sont pas nécessairement textuels. Je ne connais que peu ce type de techno ( en fait, que de nom ) mais mon frère à fait ce genre de choses en bts électrotechnique ( il me semble qu'il me parlait de graphset, ou un truc du genre ).
Ce qui est amusant, c'est que je te contredis pour apporter de l'eau à ton moulin: un IDE est loin d'être évident à définir précisément. Après tout, le logiciel qui lui permettait de créer ces diagrammes qui étaient le source d'un programmes, n'avaient rien à voir avec un éditeur de texte, et étaient pourtant ce que l'on appellerai des IDE.
Lors d'une formation de chef de projet ( merci le pseudo anonymat internet, je préfère ne pas en parler si on peut m'identifier, tellement ça m'emmerderait que ça arrive aux mauvaises oreilles ) j'ai aussi vu des outils générant des programmes sans une once de texte, à base de schémas ( gestion de process en entreprise, de flux, bref, des trucs chiants… mais ça marche ) .
Donc, il n'y a pas qu'en industrie, mais aussi en service. Vraiment, non, un IDE n'inclue pas nécessairement un éditeur de texte.
Ah, ne pas oublier de citer access, que tout le monde ici doit connaître et qui permet de créer une DB ainsi qu'une IHM sur cette DB sans taper de coder si on le souhaite.
[^] # Re: vision simpliste
Posté par freem . En réponse au journal {éditeurs de texte, IDE} × {généralistes, spécialisés}. Évalué à 5.
Si je rappelle qu'il n'y a pas que les entreprises qui font du dev, je passe pour un abruti, je suis hors sujet, ou j'ai raison? ( notez que je suis plus habitué au 2 1ers qu'au 3ème, je pense même que j'aime ça :p )
[^] # Re: vision simpliste
Posté par freem . En réponse au journal {éditeurs de texte, IDE} × {généralistes, spécialisés}. Évalué à 8.
Le rPI, c'est moderne ou pas?
Oui, c'est limite trollant, j'avoue, mais, pour me justifier, les gens confondent souvent moderne et ayant une valeur commerciale élevée.
Et moi, je me dis que vu qu'on pouvais dev il y a 20 ans, pourquoi ne le pourrait-on plus avec des machines de même puissance, maintenant?
Alors, bien entendu, je sais que, je cite Mr dupond ( et pas dupont ) "Les applications modernes ont besoin de machines modernes pour tourner!" sauf que la raison principale de cet état de fait, c'est qu'on ne sais plus faire autrement que faire des trucs lourds j'ai l'impression.
Allez, un exemple pour accompagner mon argument: combien d'utilisateurs de word utilisent des fonctionnalités coûteuses en terme de CPU qui n'existaient pas il y a, disons, 10 ans? En pourcentage estimé, hein, pas en chiffres bruts.
Moi, je gage qu'on est largement en dessous des 25%, autrement dit, que la puissance consommée par ce logiciel à l'heure actuelle pourrait être réduite drastiquement dans 75% des cas.
Et ça, je suis incapable d'estimer l'impact que ça aurait énergétiquement et économiquement parlant sur notre planète. Moins de gaspillage, c'est la seule chose dont je sois persuadé ( pas convaincu, je manque de preuves pour ça ).
Ca vaut pour toutes les suites bureautiques, d'ailleurs.
Et pour revenir au dev, et à des cas concrets, la machine sur laquelle j'ai le plus codé ces 3 dernières années est un netbook, 1Go de RAM, dual core dual thread cadencé à 1.5GHz. Je t'assure que sur cette machine, ça à un impact non négligeable. Et je ne vois pas pourquoi je devrais m'interdire de coder dessus sous prétexte qu'elle m'a coûté que 210€ il y a 4 ans.
PS: vu le smiley, j'imagine que c'était de l'humour ta réponse, mais je tenais malgré tout à saisir l'occasion pour exprimer mon ras-le-bol des bloatwares et l'énervement que m'a toujours causé les gens qui disent "ne vous occupez pas des perfs, le client rachètera du matos", genre de mots entendu de mes profs, il y a presque 10 ans… et qui m'enragent toujours autant… oups :)
[^] # Re: Euh… ?
Posté par freem . En réponse au journal {éditeurs de texte, IDE} × {généralistes, spécialisés}. Évalué à 1.
Mais un outil spécialisé dans un langage particulier incluera probablement nombre d'automatismes particuliers à ce langages, de raccourcis pour ses idiotismes et que sais-je encore.
Dans le cas de C++, il serait même imaginable qu'un nouveau moteur d'autocomplétion spécialisé puisse être réellement efficace ( j'ai bien dit: nouveau ;) )
En soit ça ne me semble pas idiot, de spécialiser l'outil… jusqu'a ce que je me rappelle qu'en général, un développeur professionnel n'utilise pas qu'un seul langage, et que changer d'outil en fonction du langage est assez ennuyeux, voire pénible.
[^] # Re: À propos des éditeurs de texte généralistes
Posté par freem . En réponse au journal {éditeurs de texte, IDE} × {généralistes, spécialisés}. Évalué à -2.
Ça dépend, est-ce que emacs inclue un éditeur de texte?
# vision simpliste
Posté par freem . En réponse au journal {éditeurs de texte, IDE} × {généralistes, spécialisés}. Évalué à 2. Dernière modification le 27 février 2014 à 00:19.
Permets-moi de t'avouer que tes distinctions sont, à mon humble avis, simplistes.
Un éditeur de texte, on lui demande juste de créer, lire, et modifier un série de caractères sur un disque dur.
D'afficher de la coloration syntaxique ou une liste de suggestions, à mon sens ce ne sont pas des choses qui ont trait à l'édition de texte, mais à l'édition de code, chose très différente.
Après tout, un éditeur de texte ne sert pas qu'a créer du code, il y a aussi les todolist, les readme, etc.
Pour prendre un exemple "théoriquement concret", imagines un éditeur de texte qui fonctionne sur le même principe que mpd/mpc/ncmpc, c'est à dire un démon ( mpd ) qui à le contrôle total sur le texte ( 1 démon, 1 fichier, pour prendre un truc simple ), et des clients, qui communiquent avec le démon. Ces clients pourraient très bien s'interfacer à un autre outil qui aurait, lui, le rôle de soumettre des suggestions ( auto-complétion ) et laisser la coloration syntaxique à leur IHM.
Comment pourrais-tu dans un tel cas classer cet éditeur de texte théorique dans une de tes cases? Il est capable de traiter plusieurs langages, puisqu'il ne s'agit que de texte, donc il est généraliste. Pourtant, il n'inclue pas lui-même de système de plug-in et encore moins de coloration syntaxique, choses qui ne seraient gérées que par les clients voire d'autres outils.
Ensuite, la notion d'IDE est, elle aussi, délicate à définir. Selon le langage, on ne compile pas forcément ( interprété ), ne débug pas forcément ( je ne sais pas si ça existe, un débuggueur php par exemple? ), n'utilise pas forcément de diagrammes ( pour du code LaTeX je doute qu'on puisse faire des diagrammes pour représenter le code par exemple ) etc.
J'ai aussi connu des IDE qui n'ont pas la notion de contexte, de projet ( turboC par exemple, que j'ai longtemps préféré a devcpp ou un truc du genre parce que c'était justement moins prise de tête pour compiler/debugguer avec, pas besoin de s'emmerder à créer un projet pour un code de 500 lignes… ).
Alors qu'un simple éditeur de texte, dans un environnement configuré correctement, offrira à son utilisateur ( probablement aguerris aux twm et lignes de commandes ) autant de facilité qu'un IDE.
Du coup, quelle différence entre IDE et "DE" spécialisé pour le dev?
Les seules choses qui permettent à mon avis de différencier un outil qui permets de gérer son code d'un autre, c'est:
_ à quel point il est efficace par défaut. Caractéristique des IDE, ils sont très efficaces out-of-the-box. Par contre, quand on commence a vouloir un truc plus à son goût, ça commence à bloquer comparé à la config totale de son environnement de bureau à coups de scripts et d'outils respectant la philosophie UNIX.
_ à quel point il pèse sur les performances de la machine. Genre, on ne peut pas comparé eclipse ou visual studio avec vim+i3+lxterminal+bash.
Ceci dit, je te remercie parce que j'ai bon espoir de lire des choses très intéressantes en réaction à ton billet :)
[^] # Re: Exemple
Posté par freem . En réponse au journal {éditeurs de texte, IDE} × {généralistes, spécialisés}. Évalué à 4.
Pas bien d'utiliser VS sans licence !
[^] # Re: Evolution
Posté par freem . En réponse au journal Neovim : vim's rebirth for the 21st century. Évalué à 1.
Bof, si c'est juste créer des lignes avec le même contenu, c'est facile:
:5oblablabla[esc]
écrira:
blablabla
blablabla
blablabla
blablabla
blablabla
Sauf que ça crée des lignes, donc pas toujours idéal. Par exemple, imagines un code qui utilise "use namespace std;", et la convention de codage du projet dit que les "use namespace" sont interdits. Comment ajouter facilement le "std::" à chaque endroit du code ou il est nécessaire?
Bon, c'est assez limite comme cas, j'avoue, mais pour les autres auxquels je pense, on peut utiliser une combo entre la méthode que j'ai mise pour créer N lignes identiques et/ou le remplacement via des regex :)
[^] # Re: Evolution
Posté par freem . En réponse au journal Neovim : vim's rebirth for the 21st century. Évalué à 1. Dernière modification le 26 février 2014 à 23:52.
J'ai un collègue qui utilise cet outil, ça à effectivement l'air intéressant ( ceci dit, je ne savais pas qu'il tourne sous nux, le collègue en question restant sous win ).
Maintenant, je dois t'avouer que ma tendance personnelle va de plus en plus à l'écriture de fichiers d'une très petite taille ( C++, donc 1 fichier par classe, et quand ça dépasse les 200 lignes, je divise pour envoyer le code dans le cpp. ), des classes ultra-spécialisées et sans me gêner pour utiliser des templates.
Du coup, je ne suis pas sûr d'avoir encore besoin d'un éditeur de code très évolué: une fois que j'ai la coloration syntaxique, une auto-complétion potable et un système modal ( sur ce point, vim à changé ma vie, c'est une évidence ) je suis heureux, et donc mon usage basic de vim me conviens plutôt pas mal.
Le tout combiné avec, en fait, un simple terminal pour naviguer dans les fichiers, est plus efficace que tout ce que j'ai pu voir avec des IDE classiques.
Dommage d'ailleurs qu'il n'y ait pas un éditeur de code simple ayant ces 3 fonctionnalités avec une toute petite base de code, nul doute que je l'adopterai :)
Le but de mon message était surtout d'argumenter sur le fait "oui, vim peut encore évoluer". Ces fonctionnalités, je m'en servirais de temps en temps, genre, 1 fois par mois. Rien d'important donc.
Et puis, sans être un maniaque de l'open source ( j'utilise opera après tout ) je suis plutôt réticent à l'idée d'utiliser du code fermé.
LA fonctionnalité qui pourrait me faire utiliser un nouveau logiciel fermé, ce serait d'être capable de générer des diagrammes à partir du code, et vice versa. Mais ce n'est pas le job d'un éditeur de code, ça.
[^] # Re: Un nouveau Gnome ?
Posté par freem . En réponse au journal Neovim : vim's rebirth for the 21st century. Évalué à 5.
XDG-directory ( ou un truc du genre ) n'a pas à être écouté par les dev d'OS, mais les dev d'application.
Tout OS ( shell, en fait ) qui est capable de gérer un système de fichier, un profil utilisateur et des variables d'environnement supporte cette norme, au final.
[^] # Re: Evolution
Posté par freem . En réponse au journal Neovim : vim's rebirth for the 21st century. Évalué à 2.
La configuration de vim est clairement l'un des plus gros points noirs de cet outil.
[^] # Re: La réponse de Bram Moolenaar
Posté par freem . En réponse au journal Neovim : vim's rebirth for the 21st century. Évalué à 2.
Ha oui en effet! J'admets être parti à la déconnade ( j'ai essayé prolog… je n'ai pas vraiment réussi à faire grand chose avec malheureusement ), mais un langage qui intègre les bnf dans le langage à un potentiel évident.
Comme quoi, parfois c'est utile de déconner :)
[^] # Re: Evolution
Posté par freem . En réponse au journal Neovim : vim's rebirth for the 21st century. Évalué à 1.
Pas vraiment, mais ce n'est pas la même chose de sélectionner ( qui me sert surtout à copier/couper, je ne vois pas vraiment d'autres usages… ) ou de faire de l'édition en colonne. Ou alors j'ai mal compris ce que tu veux dire ( ce qui ne me surprendrais pas de ma part ).
Maintenant que j'y pense, on pourrait également mentionner les curseurs multiples, qui sont aussi un outil très sympa quand ça ne bug pas ( c'est implémenté par scintilla, mais le fait de faire un retour à la ligne fait perdre le multi-curseur, et certaines autres actions ne fonctionnent pas ou sont bugguées. Enfin, c'était le cas quand j'utilisais encore autre chose que vim. ).
Je doute que vim supporte ça. Mais je suis aussi persuadé que ce fork ne le supportera pas de sitôt, en admettant que la sauce prenne.
[^] # Re: La réponse de Bram Moolenaar
Posté par freem . En réponse au journal Neovim : vim's rebirth for the 21st century. Évalué à 1.
Considérant que prolog est fait pour les linguistes, j'imagine que ce serait le genre de langages que tu aimerais voir? xD
[^] # Re: La réponse de Bram Moolenaar
Posté par freem . En réponse au journal Neovim : vim's rebirth for the 21st century. Évalué à 1.
Les alternatives existent, même si ce n'est pas forcément mainstream.
Par exemple (je ne me suis pas amusé avec ce langage donc je ne sais pas ce qu'il vaut), Code::Blocks utilise squirrel.
[^] # Re: Evolution
Posté par freem . En réponse au journal Neovim : vim's rebirth for the 21st century. Évalué à 1.
Je suppose qu'un système permettant d'éditer un fichier à plusieurs serait utilisable. Problème, je doute que ce fork finisse par en être capable, il faudrait faire plus que découpler des modules et refactorer du code pour ça.
Pour ma part, probablement à cause du fait que je n'utilise vim que de façon basique, je trouve que la config est trop complexe à gérer ( j'avais regardé pour changer des bindings… les lignes de config m'ont fait penser "omg, usine à gaz spotted!" ). Mais la encore, je doute que ce fork fasse évoluer ça ( puisqu'il reste, naturellement, compatible avec l'original ).
J'ajouterai enfin l'édition verticale, plutôt qu'horizontale. C'est peut-être possible, je n'ai jamais cherché. Après avoir tapé le "case :" dupliqué 20 fois d'un switch, que le curseur évolue à la verticale plutôt qu'à l'horizontale s/est/serait/ utile. Enfin, ici aussi, je m'en fiche, j'ai commencé à prendre l'habitude d'utiliser des tableaux associatifs dans mon code, au lieu de switch à rallonge. En plus ça me permets de faire du switch sur string en C++ ( avec des lambda ou pointeurs de fonction en valeur, c'est assez sympa et me blesse moins à maintenir que les 20k lignes d'un switch classique. Mais j'imagine que niveau perf c'est un peu moins terrible… ).
Autrement dit, le fait de considérer vim comme fini dépend des gens :)
[^] # Re: LaTeX
Posté par freem . En réponse au message Faire une présentation en html/css/js ; quel outil utiliser ?. Évalué à 1.
Je n'ai pas eu l'impression que la demande de base se limitait à fontawesome, mais je me suis peut-être trompé :)
# LaTeX
Posté par freem . En réponse au message Faire une présentation en html/css/js ; quel outil utiliser ?. Évalué à 1.
Non, ceci n'est pas un troll pour prouver une théorique supériorité de LaTeX.
Cependant, il m'a semblé croiser au fil de mes écumages de la toile, des outils permettant de compiler des fichiers .tex en documents web ( ainsi qu'en documents doc, d'ailleurs ) .
Ceci étant dit, vu que tu sembles apprécier les outils avec une GUI, je ne suis pas sûr que tu apprécies LaTeX, puisque c'est du code. Mais peut-être que cette piste pourra te plaire ( personnellement, j'aime bien pour le peu que j'en connait, mais je trouve que c'est quand même un peu la jungle.
En fait, j'ai la même sensation avec LaTeX que quand j'ai découvert Debian pour de bon… noyé par les alternatives et les informations. Vu que je ne suis pas un grand fan de beauté conceptuelle de mes documents ( choisir la police, la couleur, et la taille de mes lettres une par une… non merci, vraiment. ) , je n'ai pas cherché à apprendre à nager dans cet océan, contrairement à Debian ou je m'exerce doucement à la brasse coulée :p —nage lente, mais pas trop fatigante qui donne de jolis aperçus du monde sous-marin sans trop se mouiller—)
[^] # Re: Euh... tu déconnes ?
Posté par freem . En réponse au message Pourquoi c'est dur de coder un navigateur Internet ?. Évalué à 1.
Intéressant.
Il s'agit d'un bug que je n'ai jamais rencontré, peut-être parce que j'utilise opera ( en revanche j'en ai d'autres, dont un exclusif à linuxfr. Faudra que je report, un de ces 4… allez, je vais me motiver et le faire de suite. ).
Au final, si je comprend bien, le souci vient du fait que certains browser aient un nombre de connexion limité par serveur, je suppose dans le but d'économiser de la BP tout en téléchargeant plus d'un élément par page ( et donc onglet ), mais la bride entre en conflit direct avec le fait d'utiliser des onglets multiples.
Je me demande si ces situations ( sont-elles résolues? le message que tu cites date de 2011, il y a 3 ans donc. ) se seraient également produites dans le cas de plusieurs instances de la même application lancée sur la même machine?
Pour ma part, je flaire l'application (le browser) qui cherche à deviner ce que l'utilisateur veut, et foire lamentablement. Comme souvent quand une application se mêle d'interpréter les intentions d'un humain.
[^] # Re: Euh... tu déconnes ?
Posté par freem . En réponse au message Pourquoi c'est dur de coder un navigateur Internet ?. Évalué à 1.
Hum… le seul problème des onglets que j'arrive à voir, c'est de les isoler pour pas qu'un bug de l'objet contenu par l'un d'eux fasse planter l'application entière, ou pire, ne puisse corrompre les autres.
Maintenant… si les applications ont besoin de gérer les onglets elles-mêmes, c'est pour une et une seule raison: les gestionnaires de fenêtre flottantes ne font pas leur boulot de façon assez évoluée. Cette fonctionnalité de séparation des processus/thread/affichages (en gros, que dans un même programme on ait de multiples instances de ce programme même qui ne puissent pas communiquer ni avoir d'effets de bord avec/sur les autres) ne devrait pas être dans le navigateur. Bien entendu, je pense la même chose au sujet des éditeurs de texte, notamment.
Gérer les priorité des processus, c'est le job du kernel. Gérer les fenêtres, celui du gestionnaire de fenêtre ( ou comment enfoncer une porte ouverte… ) et donc absolument pas celui du navigateur.
Je crois que le jour où les développeurs de nombreux outils ( wm inclues ) auront compris ça, ils en chieront nettement moins à développer les applis end-user.
Bon, je parle, mais je code pas non plus dans le bon sens, j'admets. Le problème de la séparation des rôles n'est pas simple non plus, par exemple, rien que définir qu'est-ce qui dans une application est de la gestion de fenêtre, et qu'est-ce qui est de l'ordre des contrôles ( et donc, lié au toolkit ) n'est pas simple. Dans les 2 cas, le terme fenêtre est utilisé de façon à peu près semblable, mais pas complètement.
Toujours est-il que je trouve ça assez débile de faire des onglets multiples sur un navigateur, qui est du coup à instance unique ( généralement ) histoire que quand ça plante, ben que ça fasse pas semblant ( le pire, c'est que j'ai été heureux à l'époque ou je suis passé à FF d'avoir des onglets… ).
Pour le reste, je suis globalement d'accord avec toi.
[^] # Re: Code défensif
Posté par freem . En réponse au journal Apple, le SSL les goto et les accolades. Évalué à 2.
Je plussoie. D'ailleurs, c'est assez pénible d'aller lire l'implémentation de GNU de la STL, justement parce que c'est le foutoir de ce point de vue ( et comme j'utilise des tab à 2, et non 4 comme la majeure partie des gens… ).
Quand on se dit qu'un simple hook sur l'action de commit du VCS suffirait à coller un coup d'astyle et donc avoir un code propret, c'est tout de même dommage.
[^] # Re: fin de l'histoire ?
Posté par freem . En réponse au journal Ubuntu passera lui aussi sur systemd. Évalué à 1.
Merci bien. Ca m'ennuyait de citer sans mettre le nom, et pire, sans mettre la citation exacte :S