Chacun ses goûts.
Perso, c'est i3, dmenu et lxterminal.
Pas "joli" à voir (quoiqu'avec quelques vim ça deviens vite coloré :)), mais difficile de faire plus fonctionnel. Et les fonctionnalité dont tu me parles me sont plus que communes (et je sais que je n'utilise même pas toute la puissance d'i3, par exemple je n'utilise pas les label/goto, et je ne me suis jamais amusé à jouer avec son IPC non plus).
Et pour la musique, ce bon vieux mpd, histoire de piloter via le wm volume et playlists :p
Sur un petit écran, l'absence de fioritures fait que ça reste agréable à utiliser (pas de place perdue), et sur des grands écrans, ma foi, les tuiles permettent de se balader d'un écran à l'autre instantanément.
Mais bon, chacun son truc. Ceci dit, je ressors de temps en temps compiz. Quand un utilisateur windows effrayé par mes terminaux me dit qu'au moins sous windows c'est joli, je sors compiz-fusion et lui demande si windows sait gérer autant de choses :) c'est le seul intérêt pratique que j'aie trouvé à cet outil. Après, je leur explique pourquoi je n'utilise presque pas de trucs graphiques, et je fais une démo de la puissance écrasante du clavier contre la souris. Et je passe pour un barbu ^ (alors que bon, je suis loin de faire des trucs de fou, hein, mais il en faut peu pour impressionner les néophytes).
Désolé, mais… il faut que je te dise, tu devrais y penser un peu plus.
Je n'ai rien contre ce métier (au contraire même), ni aider les gens à devenir mes confrères, mais c'est un métier, et un milieu, assez particulier.
Commences par jouer avec ton PC. Par jouer, je n'entend pas lancer diablo, ou WoW ou peu importe… mais télécharger des interpréteurs ou compilateurs, lire des tutoriels pour apprendre les bases, etc. Ah, et prépares toi à devoir réparer ton système fréquemment au début, on pourrit assez vite un système quand on apprend à s'en servir pour de vrai.
Quand tu auras suivi quelques cours, par toi même, tu sauras si tu aimes ou pas. Enfin, tu sauras si tu aimes une partie du métier, parce que ça ne se limite malheureusement pas à créer des choses, on passe bien plus de temps à modifier ce que des gens ont fait dans le passé, et ce n'est pas toujours agréable.
Tu devras, si tu persévères dans cette voie, faire face à Monsieur A qui connait machin B qui connaît bidule C qui s'y connais et que du coup tu devrais écouter ce que Monsieur A à te dire parce qu'il va t'apprendre ton métier. Il y en à énormément en informatique… bien plus que dans les autres métiers j'ai l'impression. En tout cas, je n'ai jamais vu le cas avec des infirmiers, ascensoristes, électriciens… et bien sûr, tu devras réparer les conneries de Monsieur A.
Ah. Et toujours te remettre en question tu devras. Un jour, j'ai cru que j'étais bon. C'était il y à longtemps, depuis, j'ai appris que malgré le fait que je ne cesse d'apprendre depuis 10 ans de loisirs/travail (je pratique dans les deux) il y en à trop pour que je puisse me prétendre bon. De nouvelles techniques sortent fréquemment, dont il faut au moins acquérir des notions, et tu découvriras aussi régulièrement des techniques anciennes et éprouvées, qui te semblent dans un premier temps stupides mais sont en fait toujours aussi efficaces dans certaines situaions.
Bref, tu dois te préparer à devoir toujours apprendre, faire de la veille technologique tout au long de ta vie.
C'est simple, pour moi, la programmation c'est une affaire de passion. Du genre brûlante. Et comme on te l'as dit plus haut, fait attention à suivre les cours de tes profs, même si c'est lourd. Ne prend pas ta calculatrice pour te coder casse-brique, snake ou tetris pendant les cours de math/physique/français (vi, français: j'avais une trousse assez large et de bonne forme pour pouvoir coder en paix sans être grillé, surtout que je me suis toujours démerdé pour être au fond, proche d'un mur :) ).
Bon, maintenant que le disclaimer est fini, voici ce que tu demandes:
Et pas mal de sites à gauche et à droite, beaucoup sont spécialisés dans un langage donné, mais comme tu n'as pas encore choisi de langage… Ah, il y avait aussi un réseau nommé code-source je ne sais quoi, mais impossible de retrouver les URIs…
Sous linux, tous les bureaux font appel à la carte graphique pour afficher
À la carte graphique, oui, puisque c'est elle qui possède les ports pour brancher un écran. Au GPU, par contre, citation nécessaire… gnome, kde, enlightment et unity, ok. Mais pour XFCE et LXDE, je ne suis pas certain… (et je ne parlerai pas des "bureaux composés par leur utilisateur", on m'objecterai que ce ne sont pas de bureaux)
Quant aux effets ergonomiques… chacun ses goûts, perso je les trouve plutôt anti-ergonomiques, les trucs transparents, fondus, animations & co. Et ça rends mes machines poussives en plus: il n'y à pour moi pas plus ergonomique qu'une bécane réactive, à l'interface dénuée de fioritures (simplicity is beauty, qu'ils disent je crois?), qui permets un contrôle absolu au clavier :) les goûts et les couleurs…
Je pense essayer Mint et Debian en Live dans quelques temps ! :-) (comprendre au moins quelques semaines. :-( ).
Installer les programmes en manuel, c'est choisir ce que je veux installer, je trouve ça plutôt pas mal. ;-)
Il faut que tu comprennes que tu ne pourras pas installer de programmes en live: tu seras restreint aux logiciels par défaut. L'alternative, c'est d'installer une distro sur une clé USB, ça marche très bien (je l'ai fait avec une USB, ainsi qu'avec un HD externe, très pratique d'avoir ton système quand on te prête un PC et que tu t'es chopé une allergie à windows héhé).
Pour le point d'installer des programmes en manuel… je ne comprend pas ce que tu veux dire.
Si c'est aller sur un site, télécharger l'installateur, et double-cliquer pour installer, ça n'est juste pas la façon de faire des distributions linux, en général (bien que ce soit "possible", à condition d'installer certains logiciels). On préfère passer par un dépôt "centralisé" qui assure qualité, intégration (au système, pas nécessairement au bureau), diminution des risques de sécurité (moins de risques de virus, mais 0 absolu n'existe pas, et correction de failles de sécurité parfois refusées par l'upstream pour diverses raisons) et accessoirement, facilité (au bout de quelques mois, tu ne pourras plus revenir à la méthode archaïque de Windows).
Si c'est le faire en ayant un contrôle maximum, alors c'est soit apt, soit aptitude qu'il te faut, les outils graphiques que j'ai testés m'ont toujours offert moins de contrôle, mais ça fait longtemps que je n'en ai pas réessayé (à ma décharge, j'évite au maximum l'usage de la souris, et les applications graphiques ont tendance à ne pas être utilisable efficacement sans souris)…
Je ne parle pas de problèmes de compat au niveau software, mais au niveau pacquage. Sous Debian, depuis multiarch, il faut installer les lib à la fois en 32 et 64 bits, et ce n'est pas parfait, loin de là. J'ai constaté des conflits entre les lib, sans parler des paquets cassés parce que ce n'est pas strictement la même version.
Ça, c'est pour les problèmes de compatibilité.
D'ailleurs, ça ne tourne pas vraiment nativement, tu as une option du kernel (activée par la plupart des distros) ainsi que des paquets permettant l'usage du 64bits. Par contre, je suis d'accord: au niveau logiciel, ça marche très, très bien. C'est vraiment le problème de maintenance des paquets qui me fait conseiller le 32 bits à un débutant qui utilise d'anciennes applications Windows, qui sont très souvent sur du 32 bits et pas nécessairement recompilables.
Je peux aussi te parler d'impacts de performance. Tu n'es pas sans savoir qu'un programme 64 bit consomme plus de RAM que son équivalent 32 bit, je pense. Ce problème n'impacte pas juste la RAM qui est abondante, tout le monde le sait (même si j'ai tendance à préférer les outils qui ne la gâchent pas, mais ça ne m'empêche pas d'utiliser du 64bits) mais également… les caches processeur, L1, L2 et éventuellement L3, qui eux sont étroits (entre quelques kilos et mégas).
Ceci étant dit, j'ai entendu parler d'architecture kernel hybride, qui exploiterait les nouveaux registres et instructions du 64bit, mais qui continue d'utiliser un adressage plus léger, comme pour du 32 bits.
Mais ces arguments plus détaillés ne me semblaient pas pertinents compte tenu du niveau de technicité de l'interlocuteur original et de l'usage.
Donc, je pense que tu ranger ton poing :)
PS: je ne t'ai pas moinssé, parce que je comprend ce que tu veux dire. Et je doute que tu vas finir dans les négatifs, si tu tiens à ton karma: malgré le poing, qui me fait plutôt sourire, ton point de vue est pertinent. C'est juste que, pour moi, le multiarch n'est pas si beau que ça.
Vais foutre ma merde, mais pour l'utilisateur final, l'important, ce n'est pas la distribution, mais l'environnement de bureau.
Compte tenu du fait que tu apprécies l'IHM de windows 2000, je te conseillerais d'aller sois vers LXDE, soit vers XFCE. Probablement plus LXDE, en fait, mais bon, après, les goûts et les couleurs…
Côté distro, si tu utilises du vieux matos, ça devrait être supporté par à peu près tout le monde, mais certaines distros sont plus conservatrices que d'autres, côté pilotes.
Compte tenu du fait que tu te fiches d'avoir des softs récents et que tu veuilles un truc stable, j'ai l'impression que Debian serait adapté.
L'inconvénient de Debian, c'est qu'il faut activer manuellement les programmes qui n'ont pas une licence libre. Honnêtement, ça peut se faire très facilement, si tu installes en mode "expert". Je mets des guillemets parce qu'en fait, le mode expert si on garde les choix par défaut, c'est la même que le mode normal, excepté qu'il pose plus de questions, dont la fatidique: "Voulez installer des logiciels non libres" (ou un truc dans le genre, j'ai pas le texte exact sous la main…).
Mais bon, Ubuntu, Mint, et consort sont basés sur Debian, la seule chose que ça change, j'ai l'impression que c'est que les outils graphiques pour customiser le comportement du système sont installés par défaut. Il y à éventuellement des outils en plus, mais je doute qu'ils soient légion.
Personnellement, je trouve que les réglages par défaut sont plutôt efficaces, alors pas sûr que tu aies envie de t'amuser à modifier les choses… je n'ai pas l'impression que ce soit ton style, de bidouiller en permanence.
Pour ce qui est d'installer des programmes, ben, désolé mais la ligne de commande à de sacrés avantages:
c'est universel, d'une machine à l'autre, d'une config à l'autre, d'une distro à l'autre, on à peu voire pas de changements.
c'est simple à expliquer: pas besoin de captures d'écran pour faire comprendre à l'autre ce qu'il faut faire: il suffit d'écrire la ligne à utiliser.
Maintenant, comme dit par d'autres personnes, ce n'est pas obligatoire, il y à des choses du style synaptic, mais j'ai une nette préférence pour aptitude. L'inconvénient, c'est que c'est pas joli: c'est du ncurses comme on dit, ou semi-graphique. Tu connais peut-être dosshell? Bah dans le même style. Par contre, l'avantage, c'est qu'il te dit ce qu'il fait, et tu peux l'utiliser soit en ligne de commande, soit en mode semi-graphique. Bref, j'aime :)
Pour tes logiciels windows, vu que tu parles d'outils assez anciens, wine devrait être capable de les faire fonctionner sans windows. Pour en avoir le cœur net, c'est ici.
Compte tenu de ce fait, je te conseille d'installer une distribution 32 bits, tu auras moins d'emmerdes de compatibilité. Côté performance, il n'y à de toute façon aucune différence notable pour une utilisation bureautique.
Si tu utilises des outils DOS, il à dosbox qui envoie du pâté.
Et si il reste des trucs qui ne marchent pas, tu as virtualbox qui est simple à utiliser et relativement efficace. Contrairement à ce qui à été dit plus haut, tu n'as pas besoin d'avoir un processeur avec des fonctions avancées. En fait, ce sont des fonctions qui permettent principalement d'améliorer les performances des machines virtuelles, ainsi que d'utiliser des machines virtuelles 64 bits sur une machine physique 64 bits. Vu que je te conseille de toute façon de partir sur du 32 bits, l'émulation de machine virtuelle 64 bit ne serait pas possible si je ne me trompe pas. Conclusion: il n'y à simplement qu'un problème de performance, mais il me semble que tu parles d'applications anciennes, donc probablement peu gourmandes, du coup un matos plus récent (j'ai cru comprendre dans une réponse que tu changes le matos) compensera éventuellement le contrecoup.
PS: si tu pars pour une Debian, pars sur du Wheezy. La future stable est pour dans pas longtemps, mais il y à eu un changement très important pour le système, en lequel tout le monde n'à pas une grande confiance (et il y à eu énormément de discussions véhémentes à ce sujet).
PPS: désolé pour la réponse longue, j'ai essayé d'être exhaustif et objectif sans être trop technique… j'espère avoir réussi :)
Je pense que c'est une erreur de ne pas citer Debian dans ton listing (très intéressant ceci dit). Debian à la réputation d'être stable, et franchement, ce n'est pas usurpé. Je n'ai que peu de système sur une stable pure (seulement mes machines "sérieuses", donc les serveurs. Même le PC du boulot est mâtiné de testing/unstable, histoire d'avoir un peu de fun de temps en temps) mais je n'ai strictement jamais eu d'emmerdes sur ce type de système.
Même avec du testing/unstable, je n'ai jamais eu beaucoup de problèmes, excepté, il faut l'avouer, depuis quelques mois (ce qui m'a poussé à downgrader au maximum vers stable, ce qui se fait de manière tout de même stable), peu m'importe la cause, les effets sont là (entres autres, un délai de 30s d'udev au boot, une indispo de la TTY sur laquelle on à lancé startx. Non, je n'ai pas de source ni de bug, juste une expérience perso que je suis peut-être le seul à avoir).
Bon, après, ce n'est que mon expérience qui n'est même pas de 5 ans… surtout sur des stables pures. Et ce, sans DE, ce qui doit jouer énormément. Ah, je fais également attention à garder un système relativement clean (je ne suis pas parti de windows pour avoir un système plus crade, faut pas déconner), et je profite des MaJ pour nettoyer: un paquet que j'ai installé pour un test qui nécessite un MaJ saute directement (aptitude est quand même pratique pour ça, malgré ses problèmes de performance).
Tout ça pour dire qu'au final, je pense qu'en terme de facilité de MaJ sans prise de tête, Debian est quand même très sympa, et montre bien la force des distros "periodic-release". Après, à voir pour des machines de bureau "classiques" avec gnome ou KDE…
Par contre, on parle de Debian: les logiciels de la stable sont, en moyenne, vieux d'un an et demi (3-4 mois au début de la stable, âge de la période de freeze, et jusqu'à 2 ans et demi en fin de vie d'une stable, en sachant que les versions qui étaient dans testing au freeze ne sont pas forcément les toutes dernières versions elle-mêmes…).
C'est l'inconvénient de ce type de distro: on ne peut pas avoir du "ultra-stable" "ultra-récent"… tout comme on ne peut pas avoir le beurre, l'argent du beurre et le sourire de la crémière (quoique…)
Hum… vu que tu mentionnes une BSD ou il me semble qu'il faille compiler la plupart des paquets, je dirais, peut-être qu'il peut aller chercher du gentoo, ou d'autres distributions source style lunar linux, sorcerer ou source mage?
Je sais que du côté de gentoo, ce n'est pas spécialement trivial, mais peut-être que les autres sont plus simples (jamais testées)?
Vu que personne ne l'a encore faite, ben je m'en occupe.
En gros, Debian ne se limite pas à Debian stable, qui est plutôt à conseiller pour les serveurs. Officieusement, pour un desktop, je conseillerais plutôt une testing, bien que certains sur les ML conseilleraient plutôt unstable pour des raisons de sécurité (les versions et bugfix arrivent moins vite dans testing).
Et si tu tiens à conserver une base de Debian stable, ben, comme dis plus haut, debian stable + backports.
Autre solution: machines virtuelles. Tu démarres les machines virtuelles qui elles utilisent les dernières versions, puis tu utilises par exemple ssh -X me@myvm foo pour lancer l'application foo de la vm myvm (via l'utilisateur me) en déportant l'affichage sur ta machine stable.
Évidemment, les performances vont prendre un coup avec cette solution, et il faut savoir utiliser un minimum une solution de virtualisation, avec Xen la plus complexe à priori, mais qui permets aussi d'avoir le moins d'impact en terme de performances (jamais testé, ceci dit, c'est ceci dit un de mes items les plus hauts sur la todolist…).
Mais, si tu n'es pas du genre à laisser ta machine allumée 24h sur 24, ces tâches ne seront probablement pas exécutées, car la tâche cron s'éxécute à 3h01 temps local.
Et sinon, y'a anacron pour contrebalancer ce type de problème, justement (anachronique, facile à retenir :)).
D'un autre côté, ce sont les plans que la plupart des gens veulent, peut-être qu'il serait possible ensuite de forker pour réduire les coûts de production :)
Je plussoie pour le :set paste mais par contre, je suis très peu d'accord avec le fait de considérer que perdre l'indentation peut être un avantage. Surtout pour un langage style python, qui n'utilise que des blancs pour identifier les blocs de code. En fait, tu m'as donné un argument supplémentaire contre python: un programme dont le fond ne fonctionne plus parce que la forme à été altérée, je trouve ça dommage.
Devrait te satisfaire si le but n'est pas la sécurité (bon, j'ai pas fouillé les options de hexdump, il y à sûrement moyen de se débarrasser des head/cut).
En tout cas, ça ne force Mme Michu à se souvenir que de 4 caractères concaténés à son pseudo, pas la mer à boire.
J'imagine que c'est là la différence entre les maths et le dev. Moi, peut-être à cause de mon bagage matheux quasi inexistant, je perçois les opérateurs arithmétiques comme des fonctions. Du coup, je vois: floor_divide( float, int ). (Je mets floor par rapport au commentaire précédent, qui est plutôt pertinent du peu de connaissance que j'ai)
Que le dividende soit un nombre à virgule ou pas, n'empêche en rien que le résultat d'une telle fonction soit un entier, de 0 en l'occurrence. La question maintenant, c'est qu'est-ce que ferait a = 1.2f % 3.
Ici, on demande un reste, qui est censé ne pouvoir qu'être entier si j'ai bien compris, ce qui serait surprenant: on pourrait s'attendre, si on remplaçait par une fonction modulo, soit à avoir le résultat mathématique, soit le résultat logique qui serait lui, 1.2f (puisque l'on à pas pu diviser, donc rien enlever, on pourrait arguer qu'il devrait rester la totalité du dividende, qui est 1.2f, alors que ta définition indique que le résultat devrait être 1.).
Je peux me tromper, mais il me semble que ce n'est pas par rapport aux particuliers que ça à de l'importance, mais plutôt par rapport aux usines qui n'ont pas toujours tourné 24H/24 que ce système à été mis en place?
Accessoirement, avec l'énergie renouvelable, je me demande si c'est toujours aussi pertinent?
Ah oui, c'est pas mal en effet.
Si une variable était déclarée dans le bloc indenté, elle serait libérée à la fin du bloc ou pas? (dans le cas de C/C++ ce ne serait le cas que si le bloc est compris entre accolades, je précise, mais il m'est déjà arrivé d'utiliser cette méthode lors de refactoring, ce qui permets de repérer les diverses extrémités des spaghettis grâce au compilo qui engueule/insulte).
Bof, perso, que l'indentation change entre les dev, je m'en cogne mais alors, royal… parce qu'il existe un outil tout simple, tout con, pour éviter ce type d'emmerdes: astyle (d'ailleurs, GNU ferait bien de s'en servir quand ils font des release de la libcpp!).
Une fois combiné avec des hook dans le gestionnaire de version, ça ne pause plus vraiment de souci, et il n'y à pas que l'indentation que ça permets de corriger (malheureusement, je ne connait pas d'outil permettant d'altérer les noms d'un code-style à l'autre mais c'est la seule chose qui reste :) ).
Après tout, on impose bien des règles comme "pas d'exceptions, pas de RTTI, etc" dans certains projets, qui sont vérifiées par un outil (le compilo) alors on est plus à ça près.
Et ce n'est pas comme si cet outil était récent, je suis persuadé qu'il existe bien avant python. Au final, mieux vaut laisser les dev faire comme ils veulent, surtout quand on sait qu'il existe des outils permettant de rendre tout le monde heureux (perso, j'utilise -jyntA1 mais il reste quelques détails à corriger qui ne me satisfont pas encore).
Ce n'est quand même pas compliqué de mettre un hook dans git pour vérifier que le style est correct, rejeter sinon (voire éventuellement demander si on force le nettoyage du style, mais j'ai jamais testé cette solution) histoire que le contributeur mette un coup de astyle pour vérifier qu'il n'y à pas de bug introduit. Juste dommage que git prenne en compte les différences de style quand on diff/add. Me demande si y'a pas moyen de l'éviter. Ça ne me surprendrais pas.
Perso, je suis bien plus gêné non par les espaces, mais par le fait de ne pas avoir les accolades sur des lignes spécifiques, parce que mon œil trace instinctivement une ligne entre 2 accolades de même indentation (c'est aussi pour ça que je ne suis pas un super fan des langages qui utilisent begin/end, ou case/esac, mais bon… tant qu'ils sont sur leur ligne spécifique, j'ai rien à redire, ça reste une question de goût.). Donc, sur du code python je suis au final déstabilisé quand même.
De même, je sait directement qu'une ligne est la continuation de la précédente en fonction de l'alignement (indentation complétée à coups d'espaces => continuation de ligne), sans devoir aller lire la fin de la ligne précédente pour vérifier qu'elle à un '\'.
Oui, la phrase « lispisée » étant tellement plus lisible que la phrase indentée !
Je n'ai pas dit que la phrase avec lisp est plus belle, juste que celle avec indentation forcée est moche. D'ailleurs, est-il interdit d'indenter en lisp? Je pourrai code que des one-liner en C++ (à l'exception des directives) ce ne serait pas lisible, mais pour autant, il ne m'est pas interdit d'indenter… juste fortement recommandé.
Je suis largement en faveur de l'indentation, mais largement contre le fait de forcer un codestyle par le langage (par le projet, par contre, ça ne me choque absolument pas: il s'agit d'un choix non lié à la technologie)
Et penses-tu aussi pertinent que des débutants (le sujet ici) choisissent « l’indentation qu’ils préfèrent » ?
Non, mais je pense que ce n'est pas le rôle du langage.
Le prof peut imposer une indentation, un codestyle (ce qui est largement au-delà de la simple indentation: on fait les choses en entier ou on ne les fait pas), sans pour autant que le langage doive le faire. Et pour le valider c'est quand même simple:
#!/bin/sh
astyle < $1 | diff $1 - >/dev/null && echo ok || echo "Tu ne respectes pas le style imposé, corriges!"
Il suffit de remplacer "echo ok" par la commande pour compiler/exécuter/whatever du langage voulu, et si nécessaire d'ajouter des options à astyle, en fonction des goûts du prof.
À moins que le prof en question ne fournisse pas l'environnement de travail aux élève mais leur demande de l'installer, je ne pense pas que ça pose plus de problèmes que ça.
Le seul truc qu'il reste à ajouter à ça, ce sont les conventions de nommage et une vérification des éventuelles fautes de frappe, si le prof est un grammar-nazi (quoique, dans le cas d'un langage à typage faible, il me semble important d'utiliser un outil tel que aspell, voire même si c'est un projet sur lequel plusieurs personnes bossent, même en typage fort.).
[^] # Re: vieux PC : attention au bureau
Posté par freem . En réponse au message Quelle distribution pour remplacer Win2k ?. Évalué à 2.
Chacun ses goûts.
Perso, c'est i3, dmenu et lxterminal.
Pas "joli" à voir (quoiqu'avec quelques vim ça deviens vite coloré :)), mais difficile de faire plus fonctionnel. Et les fonctionnalité dont tu me parles me sont plus que communes (et je sais que je n'utilise même pas toute la puissance d'i3, par exemple je n'utilise pas les label/goto, et je ne me suis jamais amusé à jouer avec son IPC non plus).
Et pour la musique, ce bon vieux mpd, histoire de piloter via le wm volume et playlists :p
Sur un petit écran, l'absence de fioritures fait que ça reste agréable à utiliser (pas de place perdue), et sur des grands écrans, ma foi, les tuiles permettent de se balader d'un écran à l'autre instantanément.
Mais bon, chacun son truc. Ceci dit, je ressors de temps en temps compiz. Quand un utilisateur windows effrayé par mes terminaux me dit qu'au moins sous windows c'est joli, je sors compiz-fusion et lui demande si windows sait gérer autant de choses :) c'est le seul intérêt pratique que j'aie trouvé à cet outil. Après, je leur explique pourquoi je n'utilise presque pas de trucs graphiques, et je fais une démo de la puissance écrasante du clavier contre la souris. Et je passe pour un barbu ^ (alors que bon, je suis loin de faire des trucs de fou, hein, mais il en faut peu pour impressionner les néophytes).
# l'avenir sur une seconde...
Posté par freem . En réponse au message La programmation. Évalué à 9.
Désolé, mais… il faut que je te dise, tu devrais y penser un peu plus.
Je n'ai rien contre ce métier (au contraire même), ni aider les gens à devenir mes confrères, mais c'est un métier, et un milieu, assez particulier.
Commences par jouer avec ton PC. Par jouer, je n'entend pas lancer diablo, ou WoW ou peu importe… mais télécharger des interpréteurs ou compilateurs, lire des tutoriels pour apprendre les bases, etc. Ah, et prépares toi à devoir réparer ton système fréquemment au début, on pourrit assez vite un système quand on apprend à s'en servir pour de vrai.
Quand tu auras suivi quelques cours, par toi même, tu sauras si tu aimes ou pas. Enfin, tu sauras si tu aimes une partie du métier, parce que ça ne se limite malheureusement pas à créer des choses, on passe bien plus de temps à modifier ce que des gens ont fait dans le passé, et ce n'est pas toujours agréable.
Tu devras, si tu persévères dans cette voie, faire face à Monsieur A qui connait machin B qui connaît bidule C qui s'y connais et que du coup tu devrais écouter ce que Monsieur A à te dire parce qu'il va t'apprendre ton métier. Il y en à énormément en informatique… bien plus que dans les autres métiers j'ai l'impression. En tout cas, je n'ai jamais vu le cas avec des infirmiers, ascensoristes, électriciens… et bien sûr, tu devras réparer les conneries de Monsieur A.
Ah. Et toujours te remettre en question tu devras. Un jour, j'ai cru que j'étais bon. C'était il y à longtemps, depuis, j'ai appris que malgré le fait que je ne cesse d'apprendre depuis 10 ans de loisirs/travail (je pratique dans les deux) il y en à trop pour que je puisse me prétendre bon. De nouvelles techniques sortent fréquemment, dont il faut au moins acquérir des notions, et tu découvriras aussi régulièrement des techniques anciennes et éprouvées, qui te semblent dans un premier temps stupides mais sont en fait toujours aussi efficaces dans certaines situaions.
Bref, tu dois te préparer à devoir toujours apprendre, faire de la veille technologique tout au long de ta vie.
C'est simple, pour moi, la programmation c'est une affaire de passion. Du genre brûlante. Et comme on te l'as dit plus haut, fait attention à suivre les cours de tes profs, même si c'est lourd. Ne prend pas ta calculatrice pour te coder casse-brique, snake ou tetris pendant les cours de math/physique/français (vi, français: j'avais une trousse assez large et de bonne forme pour pouvoir coder en paix sans être grillé, surtout que je me suis toujours démerdé pour être au fond, proche d'un mur :) ).
Bon, maintenant que le disclaimer est fini, voici ce que tu demandes:
Et pas mal de sites à gauche et à droite, beaucoup sont spécialisés dans un langage donné, mais comme tu n'as pas encore choisi de langage… Ah, il y avait aussi un réseau nommé code-source je ne sais quoi, mais impossible de retrouver les URIs…
Bonne chance.
[^] # Re: Hissez haut moussaillon !
Posté par freem . En réponse au message La programmation. Évalué à 7.
Non, c'est le basic.
[^] # Re: vieux PC : attention au bureau
Posté par freem . En réponse au message Quelle distribution pour remplacer Win2k ?. Évalué à 1. Dernière modification le 06 novembre 2014 à 10:57.
À la carte graphique, oui, puisque c'est elle qui possède les ports pour brancher un écran. Au GPU, par contre, citation nécessaire… gnome, kde, enlightment et unity, ok. Mais pour XFCE et LXDE, je ne suis pas certain… (et je ne parlerai pas des "bureaux composés par leur utilisateur", on m'objecterai que ce ne sont pas de bureaux)
Quant aux effets ergonomiques… chacun ses goûts, perso je les trouve plutôt anti-ergonomiques, les trucs transparents, fondus, animations & co. Et ça rends mes machines poussives en plus: il n'y à pour moi pas plus ergonomique qu'une bécane réactive, à l'interface dénuée de fioritures (simplicity is beauty, qu'ils disent je crois?), qui permets un contrôle absolu au clavier :) les goûts et les couleurs…
[^] # Re: Le plus important, ce n'est pas la distro...
Posté par freem . En réponse au message Quelle distribution pour remplacer Win2k ?. Évalué à 2.
Il faut que tu comprennes que tu ne pourras pas installer de programmes en live: tu seras restreint aux logiciels par défaut. L'alternative, c'est d'installer une distro sur une clé USB, ça marche très bien (je l'ai fait avec une USB, ainsi qu'avec un HD externe, très pratique d'avoir ton système quand on te prête un PC et que tu t'es chopé une allergie à windows héhé).
Pour le point d'installer des programmes en manuel… je ne comprend pas ce que tu veux dire.
Si c'est aller sur un site, télécharger l'installateur, et double-cliquer pour installer, ça n'est juste pas la façon de faire des distributions linux, en général (bien que ce soit "possible", à condition d'installer certains logiciels). On préfère passer par un dépôt "centralisé" qui assure qualité, intégration (au système, pas nécessairement au bureau), diminution des risques de sécurité (moins de risques de virus, mais 0 absolu n'existe pas, et correction de failles de sécurité parfois refusées par l'upstream pour diverses raisons) et accessoirement, facilité (au bout de quelques mois, tu ne pourras plus revenir à la méthode archaïque de Windows).
Si c'est le faire en ayant un contrôle maximum, alors c'est soit apt, soit aptitude qu'il te faut, les outils graphiques que j'ai testés m'ont toujours offert moins de contrôle, mais ça fait longtemps que je n'en ai pas réessayé (à ma décharge, j'évite au maximum l'usage de la souris, et les applications graphiques ont tendance à ne pas être utilisable efficacement sans souris)…
[^] # Re: Le plus important, ce n'est pas la distro...
Posté par freem . En réponse au message Quelle distribution pour remplacer Win2k ?. Évalué à 1.
Tu veux plus de détails?
Je ne parle pas de problèmes de compat au niveau software, mais au niveau pacquage. Sous Debian, depuis multiarch, il faut installer les lib à la fois en 32 et 64 bits, et ce n'est pas parfait, loin de là. J'ai constaté des conflits entre les lib, sans parler des paquets cassés parce que ce n'est pas strictement la même version.
Ça, c'est pour les problèmes de compatibilité.
D'ailleurs, ça ne tourne pas vraiment nativement, tu as une option du kernel (activée par la plupart des distros) ainsi que des paquets permettant l'usage du 64bits. Par contre, je suis d'accord: au niveau logiciel, ça marche très, très bien. C'est vraiment le problème de maintenance des paquets qui me fait conseiller le 32 bits à un débutant qui utilise d'anciennes applications Windows, qui sont très souvent sur du 32 bits et pas nécessairement recompilables.
Je peux aussi te parler d'impacts de performance. Tu n'es pas sans savoir qu'un programme 64 bit consomme plus de RAM que son équivalent 32 bit, je pense. Ce problème n'impacte pas juste la RAM qui est abondante, tout le monde le sait (même si j'ai tendance à préférer les outils qui ne la gâchent pas, mais ça ne m'empêche pas d'utiliser du 64bits) mais également… les caches processeur, L1, L2 et éventuellement L3, qui eux sont étroits (entre quelques kilos et mégas).
Ceci étant dit, j'ai entendu parler d'architecture kernel hybride, qui exploiterait les nouveaux registres et instructions du 64bit, mais qui continue d'utiliser un adressage plus léger, comme pour du 32 bits.
Mais ces arguments plus détaillés ne me semblaient pas pertinents compte tenu du niveau de technicité de l'interlocuteur original et de l'usage.
Donc, je pense que tu ranger ton poing :)
PS: je ne t'ai pas moinssé, parce que je comprend ce que tu veux dire. Et je doute que tu vas finir dans les négatifs, si tu tiens à ton karma: malgré le poing, qui me fait plutôt sourire, ton point de vue est pertinent. C'est juste que, pour moi, le multiarch n'est pas si beau que ça.
# Le plus important, ce n'est pas la distro...
Posté par freem . En réponse au message Quelle distribution pour remplacer Win2k ?. Évalué à 0. Dernière modification le 05 novembre 2014 à 15:24.
Vais foutre ma merde, mais pour l'utilisateur final, l'important, ce n'est pas la distribution, mais l'environnement de bureau.
Compte tenu du fait que tu apprécies l'IHM de windows 2000, je te conseillerais d'aller sois vers LXDE, soit vers XFCE. Probablement plus LXDE, en fait, mais bon, après, les goûts et les couleurs…
Côté distro, si tu utilises du vieux matos, ça devrait être supporté par à peu près tout le monde, mais certaines distros sont plus conservatrices que d'autres, côté pilotes.
Compte tenu du fait que tu te fiches d'avoir des softs récents et que tu veuilles un truc stable, j'ai l'impression que Debian serait adapté.
L'inconvénient de Debian, c'est qu'il faut activer manuellement les programmes qui n'ont pas une licence libre. Honnêtement, ça peut se faire très facilement, si tu installes en mode "expert". Je mets des guillemets parce qu'en fait, le mode expert si on garde les choix par défaut, c'est la même que le mode normal, excepté qu'il pose plus de questions, dont la fatidique: "Voulez installer des logiciels non libres" (ou un truc dans le genre, j'ai pas le texte exact sous la main…).
Mais bon, Ubuntu, Mint, et consort sont basés sur Debian, la seule chose que ça change, j'ai l'impression que c'est que les outils graphiques pour customiser le comportement du système sont installés par défaut. Il y à éventuellement des outils en plus, mais je doute qu'ils soient légion.
Personnellement, je trouve que les réglages par défaut sont plutôt efficaces, alors pas sûr que tu aies envie de t'amuser à modifier les choses… je n'ai pas l'impression que ce soit ton style, de bidouiller en permanence.
Pour ce qui est d'installer des programmes, ben, désolé mais la ligne de commande à de sacrés avantages:
Maintenant, comme dit par d'autres personnes, ce n'est pas obligatoire, il y à des choses du style synaptic, mais j'ai une nette préférence pour aptitude. L'inconvénient, c'est que c'est pas joli: c'est du ncurses comme on dit, ou semi-graphique. Tu connais peut-être dosshell? Bah dans le même style. Par contre, l'avantage, c'est qu'il te dit ce qu'il fait, et tu peux l'utiliser soit en ligne de commande, soit en mode semi-graphique. Bref, j'aime :)
Pour tes logiciels windows, vu que tu parles d'outils assez anciens, wine devrait être capable de les faire fonctionner sans windows. Pour en avoir le cœur net, c'est ici.
Compte tenu de ce fait, je te conseille d'installer une distribution 32 bits, tu auras moins d'emmerdes de compatibilité. Côté performance, il n'y à de toute façon aucune différence notable pour une utilisation bureautique.
Si tu utilises des outils DOS, il à dosbox qui envoie du pâté.
Et si il reste des trucs qui ne marchent pas, tu as virtualbox qui est simple à utiliser et relativement efficace. Contrairement à ce qui à été dit plus haut, tu n'as pas besoin d'avoir un processeur avec des fonctions avancées. En fait, ce sont des fonctions qui permettent principalement d'améliorer les performances des machines virtuelles, ainsi que d'utiliser des machines virtuelles 64 bits sur une machine physique 64 bits. Vu que je te conseille de toute façon de partir sur du 32 bits, l'émulation de machine virtuelle 64 bit ne serait pas possible si je ne me trompe pas. Conclusion: il n'y à simplement qu'un problème de performance, mais il me semble que tu parles d'applications anciennes, donc probablement peu gourmandes, du coup un matos plus récent (j'ai cru comprendre dans une réponse que tu changes le matos) compensera éventuellement le contrecoup.
PS: si tu pars pour une Debian, pars sur du Wheezy. La future stable est pour dans pas longtemps, mais il y à eu un changement très important pour le système, en lequel tout le monde n'à pas une grande confiance (et il y à eu énormément de discussions véhémentes à ce sujet).
PPS: désolé pour la réponse longue, j'ai essayé d'être exhaustif et objectif sans être trop technique… j'espère avoir réussi :)
[^] # Re: Arch or not Arch
Posté par freem . En réponse au journal Une idée de distribution Linux. Évalué à 3.
Je pense que c'est une erreur de ne pas citer Debian dans ton listing (très intéressant ceci dit). Debian à la réputation d'être stable, et franchement, ce n'est pas usurpé. Je n'ai que peu de système sur une stable pure (seulement mes machines "sérieuses", donc les serveurs. Même le PC du boulot est mâtiné de testing/unstable, histoire d'avoir un peu de fun de temps en temps) mais je n'ai strictement jamais eu d'emmerdes sur ce type de système.
Même avec du testing/unstable, je n'ai jamais eu beaucoup de problèmes, excepté, il faut l'avouer, depuis quelques mois (ce qui m'a poussé à downgrader au maximum vers stable, ce qui se fait de manière tout de même stable), peu m'importe la cause, les effets sont là (entres autres, un délai de 30s d'udev au boot, une indispo de la TTY sur laquelle on à lancé startx. Non, je n'ai pas de source ni de bug, juste une expérience perso que je suis peut-être le seul à avoir).
Bon, après, ce n'est que mon expérience qui n'est même pas de 5 ans… surtout sur des stables pures. Et ce, sans DE, ce qui doit jouer énormément. Ah, je fais également attention à garder un système relativement clean (je ne suis pas parti de windows pour avoir un système plus crade, faut pas déconner), et je profite des MaJ pour nettoyer: un paquet que j'ai installé pour un test qui nécessite un MaJ saute directement (aptitude est quand même pratique pour ça, malgré ses problèmes de performance).
Tout ça pour dire qu'au final, je pense qu'en terme de facilité de MaJ sans prise de tête, Debian est quand même très sympa, et montre bien la force des distros "periodic-release". Après, à voir pour des machines de bureau "classiques" avec gnome ou KDE…
Par contre, on parle de Debian: les logiciels de la stable sont, en moyenne, vieux d'un an et demi (3-4 mois au début de la stable, âge de la période de freeze, et jusqu'à 2 ans et demi en fin de vie d'une stable, en sachant que les versions qui étaient dans testing au freeze ne sont pas forcément les toutes dernières versions elle-mêmes…).
C'est l'inconvénient de ce type de distro: on ne peut pas avoir du "ultra-stable" "ultra-récent"… tout comme on ne peut pas avoir le beurre, l'argent du beurre et le sourire de la crémière (quoique…)
[^] # Re: Oublie Linux pour ça ....
Posté par freem . En réponse au journal Une idée de distribution Linux. Évalué à 0.
Hum… vu que tu mentionnes une BSD ou il me semble qu'il faille compiler la plupart des paquets, je dirais, peut-être qu'il peut aller chercher du gentoo, ou d'autres distributions source style lunar linux, sorcerer ou source mage?
Je sais que du côté de gentoo, ce n'est pas spécialement trivial, mais peut-être que les autres sont plus simples (jamais testées)?
[^] # Re: cron ou pas cron...
Posté par freem . En réponse au journal Installe une libellule dans ton bureau. Évalué à 2.
Mea culpa pour la typo.
# Debian testing/unstable.
Posté par freem . En réponse au journal Une idée de distribution Linux. Évalué à 5. Dernière modification le 03 novembre 2014 à 12:38.
Vu que personne ne l'a encore faite, ben je m'en occupe.
En gros, Debian ne se limite pas à Debian stable, qui est plutôt à conseiller pour les serveurs. Officieusement, pour un desktop, je conseillerais plutôt une testing, bien que certains sur les ML conseilleraient plutôt unstable pour des raisons de sécurité (les versions et bugfix arrivent moins vite dans testing).
Et si tu tiens à conserver une base de Debian stable, ben, comme dis plus haut, debian stable + backports.
Autre solution: machines virtuelles. Tu démarres les machines virtuelles qui elles utilisent les dernières versions, puis tu utilises par exemple
ssh -X me@myvm foopour lancer l'application foo de la vm myvm (via l'utilisateur me) en déportant l'affichage sur ta machine stable.Évidemment, les performances vont prendre un coup avec cette solution, et il faut savoir utiliser un minimum une solution de virtualisation, avec Xen la plus complexe à priori, mais qui permets aussi d'avoir le moins d'impact en terme de performances (jamais testé, ceci dit, c'est ceci dit un de mes items les plus hauts sur la todolist…).
# cron ou pas cron...
Posté par freem . En réponse au journal Installe une libellule dans ton bureau. Évalué à 7.
Et sinon, y'a anacron pour contrebalancer ce type de problème, justement (anachronique, facile à retenir :)).
[^] # Re: Crowdfunding pour l'étoile noire
Posté par freem . En réponse au sondage Le sujet de l'Open World Forum 2014 qui m'intéresse le plus. Évalué à 2.
D'un autre côté, ce sont les plans que la plupart des gens veulent, peut-être qu'il serait possible ensuite de forker pour réduire les coûts de production :)
[^] # Re: Parenthèses vs indentation
Posté par freem . En réponse à la dépêche MicroAlg: langage et environnements pour l’algorithmique. Évalué à 4.
Je plussoie pour le
:set pastemais par contre, je suis très peu d'accord avec le fait de considérer que perdre l'indentation peut être un avantage. Surtout pour un langage style python, qui n'utilise que des blancs pour identifier les blocs de code. En fait, tu m'as donné un argument supplémentaire contre python: un programme dont le fond ne fonctionne plus parce que la forme à été altérée, je trouve ça dommage.[^] # Re: Testeur NEOX
Posté par freem . En réponse au message Ouverture de Club Pixel - hébergement Mumble. Évalué à 2.
J'imagine qu'un petit:
Devrait te satisfaire si le but n'est pas la sécurité (bon, j'ai pas fouillé les options de hexdump, il y à sûrement moyen de se débarrasser des head/cut).
En tout cas, ça ne force Mme Michu à se souvenir que de 4 caractères concaténés à son pseudo, pas la mer à boire.
[^] # Re: Versions des principaux logiciels ?
Posté par freem . En réponse au journal SUSE Linux Enterprise 12 disponible !. Évalué à 2.
J'ai envie de dire, 3.12 pour le kernel:
Vu en 1 min à peu près, par contre moins de 30 sec plus tard, rien au sujet de la libc. Bon, pas vraiment cherché on dira…
[^] # Re: Pascal ?
Posté par freem . En réponse à la dépêche MicroAlg: langage et environnements pour l’algorithmique. Évalué à 4.
Qu'un des paramètres de la division entière soit un flottant ou pas n'a pas à changer le fait que le retour de la division entière soit un entier…
[^] # Re: Pascal ?
Posté par freem . En réponse à la dépêche MicroAlg: langage et environnements pour l’algorithmique. Évalué à 1. Dernière modification le 27 octobre 2014 à 14:30.
J'imagine que c'est là la différence entre les maths et le dev. Moi, peut-être à cause de mon bagage matheux quasi inexistant, je perçois les opérateurs arithmétiques comme des fonctions. Du coup, je vois:
floor_divide( float, int ). (Je mets floor par rapport au commentaire précédent, qui est plutôt pertinent du peu de connaissance que j'ai)Que le dividende soit un nombre à virgule ou pas, n'empêche en rien que le résultat d'une telle fonction soit un entier, de 0 en l'occurrence. La question maintenant, c'est qu'est-ce que ferait
a = 1.2f % 3.Ici, on demande un reste, qui est censé ne pouvoir qu'être entier si j'ai bien compris, ce qui serait surprenant: on pourrait s'attendre, si on remplaçait par une fonction modulo, soit à avoir le résultat mathématique, soit le résultat logique qui serait lui, 1.2f (puisque l'on à pas pu diviser, donc rien enlever, on pourrait arguer qu'il devrait rester la totalité du dividende, qui est 1.2f, alors que ta définition indique que le résultat devrait être 1.).
[^] # Re: Une précision
Posté par freem . En réponse au journal Ubuntu is dying. Évalué à 1.
Je peux me tromper, mais il me semble que ce n'est pas par rapport aux particuliers que ça à de l'importance, mais plutôt par rapport aux usines qui n'ont pas toujours tourné 24H/24 que ce système à été mis en place?
Accessoirement, avec l'énergie renouvelable, je me demande si c'est toujours aussi pertinent?
[^] # Re: Et la fin de la beta c'est pour quand?
Posté par freem . En réponse au journal Ubuntu is dying. Évalué à 2.
Laisses, c'est un ArchUser il comprendra pas :)
[^] # Re: Parenthèses vs indentation
Posté par freem . En réponse à la dépêche MicroAlg: langage et environnements pour l’algorithmique. Évalué à 1.
Ah oui, c'est pas mal en effet.
Si une variable était déclarée dans le bloc indenté, elle serait libérée à la fin du bloc ou pas? (dans le cas de C/C++ ce ne serait le cas que si le bloc est compris entre accolades, je précise, mais il m'est déjà arrivé d'utiliser cette méthode lors de refactoring, ce qui permets de repérer les diverses extrémités des spaghettis grâce au compilo qui engueule/insulte).
[^] # Re: Parenthèses vs indentation
Posté par freem . En réponse à la dépêche MicroAlg: langage et environnements pour l’algorithmique. Évalué à 1.
Bof, perso, que l'indentation change entre les dev, je m'en cogne mais alors, royal… parce qu'il existe un outil tout simple, tout con, pour éviter ce type d'emmerdes: astyle (d'ailleurs, GNU ferait bien de s'en servir quand ils font des release de la libcpp!).
Une fois combiné avec des hook dans le gestionnaire de version, ça ne pause plus vraiment de souci, et il n'y à pas que l'indentation que ça permets de corriger (malheureusement, je ne connait pas d'outil permettant d'altérer les noms d'un code-style à l'autre mais c'est la seule chose qui reste :) ).
Après tout, on impose bien des règles comme "pas d'exceptions, pas de RTTI, etc" dans certains projets, qui sont vérifiées par un outil (le compilo) alors on est plus à ça près.
Et ce n'est pas comme si cet outil était récent, je suis persuadé qu'il existe bien avant python. Au final, mieux vaut laisser les dev faire comme ils veulent, surtout quand on sait qu'il existe des outils permettant de rendre tout le monde heureux (perso, j'utilise -jyntA1 mais il reste quelques détails à corriger qui ne me satisfont pas encore).
Ce n'est quand même pas compliqué de mettre un hook dans git pour vérifier que le style est correct, rejeter sinon (voire éventuellement demander si on force le nettoyage du style, mais j'ai jamais testé cette solution) histoire que le contributeur mette un coup de astyle pour vérifier qu'il n'y à pas de bug introduit. Juste dommage que git prenne en compte les différences de style quand on diff/add. Me demande si y'a pas moyen de l'éviter. Ça ne me surprendrais pas.
Perso, je suis bien plus gêné non par les espaces, mais par le fait de ne pas avoir les accolades sur des lignes spécifiques, parce que mon œil trace instinctivement une ligne entre 2 accolades de même indentation (c'est aussi pour ça que je ne suis pas un super fan des langages qui utilisent begin/end, ou case/esac, mais bon… tant qu'ils sont sur leur ligne spécifique, j'ai rien à redire, ça reste une question de goût.). Donc, sur du code python je suis au final déstabilisé quand même.
De même, je sait directement qu'une ligne est la continuation de la précédente en fonction de l'alignement (indentation complétée à coups d'espaces => continuation de ligne), sans devoir aller lire la fin de la ligne précédente pour vérifier qu'elle à un '\'.
[^] # Re: Parenthèses vs indentation
Posté par freem . En réponse à la dépêche MicroAlg: langage et environnements pour l’algorithmique. Évalué à 2.
Je n'ai pas dit que la phrase avec lisp est plus belle, juste que celle avec indentation forcée est moche. D'ailleurs, est-il interdit d'indenter en lisp? Je pourrai code que des one-liner en C++ (à l'exception des directives) ce ne serait pas lisible, mais pour autant, il ne m'est pas interdit d'indenter… juste fortement recommandé.
Je suis largement en faveur de l'indentation, mais largement contre le fait de forcer un codestyle par le langage (par le projet, par contre, ça ne me choque absolument pas: il s'agit d'un choix non lié à la technologie)
Non, mais je pense que ce n'est pas le rôle du langage.
Le prof peut imposer une indentation, un codestyle (ce qui est largement au-delà de la simple indentation: on fait les choses en entier ou on ne les fait pas), sans pour autant que le langage doive le faire. Et pour le valider c'est quand même simple:
Il suffit de remplacer "echo ok" par la commande pour compiler/exécuter/whatever du langage voulu, et si nécessaire d'ajouter des options à astyle, en fonction des goûts du prof.
À moins que le prof en question ne fournisse pas l'environnement de travail aux élève mais leur demande de l'installer, je ne pense pas que ça pose plus de problèmes que ça.
Le seul truc qu'il reste à ajouter à ça, ce sont les conventions de nommage et une vérification des éventuelles fautes de frappe, si le prof est un grammar-nazi (quoique, dans le cas d'un langage à typage faible, il me semble important d'utiliser un outil tel que aspell, voire même si c'est un projet sur lequel plusieurs personnes bossent, même en typage fort.).
[^] # Re: Pascal ?
Posté par freem . En réponse à la dépêche MicroAlg: langage et environnements pour l’algorithmique. Évalué à 3.
Pourquoi? Faire une division entière de 2 par 3, peu importe que 2 soit float ou pas?
[^] # Re: Pascal ?
Posté par freem . En réponse à la dépêche MicroAlg: langage et environnements pour l’algorithmique. Évalué à 1. Dernière modification le 27 octobre 2014 à 11:52.
Et m… double post!