ɹǝıʌıʃO a écrit 373 commentaires

Moi je veux la version internationale, avec la ville de Krung Thep Mahanakhon Amon Rattanakosin Mahinthara Ayutthaya Mahadilok Phop Noppharat Ratchathani Burirom Udomratchaniwet Mahasathan Amon Piman Awatan Sathit Sakkathattiya Witsanukam Prasit (Thaïlande), le village de Llanfairpwllgwyngyllgogerychwyrndrobwllllantysiliogogogoch (Pays de Galles), le lac Chargoggagogg­manchauggagogg­chaubunagungamaugg (États-Unis), la colline de Taumatawhakatangihangakoauauotamateaturipukakapikimaungahoronukupokaiwhenuakitanatahu (Nouvelle-Zélande) et la gare de Gorsafawddacha'idraigodanheddogleddollônpenrhynareurdraethceredigion (Pays de Galles, décidément ils sont forts). Du moins, s'ils arrivent à imprimer les noms sur les cases.

Normalement, les étudiants handicapés ont droit à des aménagements : secrétaire pour ceux qui ne peuvent pas écrire, interprète pour les sourds, supports de cours en braille pour les aveugles, etc. En pratique, c'est plus ou moins effectif selon les établissements, le type de handicap, le budget de l'année et l'âge du capitaine. Pour les examens, ils ont un tiers temps de plus et un secrétaire si besoin.

Quant à la programmation pour un aveugle, je suppose que ce doit être possible avec une tablette braille et beaucoup de mémoire (mais pour ça, ils ont l'habitude).

Par contre les projets et autres "devoirs" à rendre là évidement ils peuvent pas savoir

Comme à la fac, mais c'est normal. Les devoirs non surveillés servent surtout à mettre les étudiants en situation. C'est essentiellement une évaluation formative, par opposition à l'évaluation certificative qu'est l'examen surveillé.

C'est l'ENAC. Il est vrai que l'ENIAC, ce serait vraiment très spécial comme matériel :-D

Pour être fixé, c'est simple : va dans un collège, dis que tu envisages de devenir prof et demande à assister à des cours. Puisque tu as une licence, tu peux même chercher à en donner comme vacataire. Ainsi tu t'orienteras en connaissance de cause. Après cette année, tu pourras aussi chercher des vacations dans le supérieur. Certains établissements prennent des étudiants avec un M1, d'autres demandent un M2. Là, pour obtenir un poste de permanent, il faut passer par la thèse, ou parfois par l'agrégation.

D'autre part, tu emploies quatre mots liés aux notions de déprime et de dépression. Une déprime passagère n'est pas inquiétante, mais si tu penses que ton état est plutôt une dépression, il faut en parler à ton médecin traitant. C'est vraiment important.

les machines mises à disposition des étudiants de licence sont en double botte, celles du master recherche sont sous Linux, je ne sais pas pour les autres. Je me souviens d'ailleurs que quand j'étais en M2R on m'avait donné un projet en architecture qui consistait à modifier le code source d'un émulateur d'Alpha pour essayer un nouveau prédicteur de branchements, j'avais trouvé ça intéressant.

"il a eu été" est tout à fait correct. C'est du passé surcomposé, un temps inusité (mais "autorisé") en France mais plus fréquent au Québec, par exemple.

"c'est" est invariable lorsqu'il est employé comme un présentatif, donc "c'est les erreurs...", "c'est des jeunes" peuvent très bien être correct.

Quel est le problème dans "des gens qui croient que" ?

"sachent que" : verbe savoir, présent du subjonctif, troisième personne du pluriel. Où est la faute ?

"La France, c'est le pays où on parle le français" : l'article défini devant un nom de langue est facultatif et assez peu courant mais pas interdit, me semble-t-il.

Les universités françaises sont souvent montrées du doigt pour leur manque d'intégration de leurs cursus de formation aux problématiques de l'entreprise, préférant la théorie à la pratique.

Tiens, c'est bizarre. Lors de mon dernier contact avec l'univers impitoyable des SSII (en plus c'en était une bonne : Microsoft Gold Partner, c'est tout dire), ce qu'on m'a dit est que les élèves ingénieurs arrivent avec tout juste assez de théorie et que l'idée de rendre la formation plus appliquée serait donc très mauvaise. En tant qu'universitaire, théoricien, [ajoutez ici quelques clichés dans le même genre], ça me convient...

Je te recommande la yaourtière. Très simple d'utilisation, économique, prend peu de place, donne des yaourts de très bonne qualité, évite de jeter des emballages non recyclables (les bouteilles ou briques de lait le sont).

presque

let ls = Sys.readdir (Sys.getcwd ()) in
Array.sort String.compare ls;
Array.iter print_endline ls

mais là, on a plutôt une illustration du côté "obscur" ;) de Caml, ce qui n'était pas mon but...

En effet, par extraordinaire, je donne une réponse différente à une question différente. Je présente mes plus plates excuses à ceux que ce concept peut choquer. Ici, la question concerne ceux qui trouvent que les langages fonctionnels ne sont pas adaptés pour écrire des programmes qui servent en pratique et l'exemple ne sert qu'à montrer qu'il n'y a pas de difficulté particulière. En pratique, si je veux afficher le contenu d'un répertoire, je fais comme tout le monde et j'utilise la commande ls de la coquille de service.

J'oubliais... La NASA utilise des logiciels en Java pour piloter ses engins martiens à distance, mais ils fonctionnent au sol. Les robots eux-mêmes n'utilisent pas Java. Une source claire à ce sujet : http://www.sun.com/aboutsun/media/features/mars.html

Je programme rarement un noyau de système, en revanche j'ai souvent besoin d'un petit programme très spécialisé qui doit être prêt rapidement, facile à lire et à modifier, et correct. Pour illustrer l'intérêt d'un langage comme Caml dans ce contexte, voyons ce que donne un micro-ls : afficher le contenu du répertoire courant dans l'ordre alphabétique.

open Unix

(* renvoie la liste des fichiers du répertoire donné *)
let rec lire_dir dir =
  try
    let d = readdir dir in
    d::lire_dir dir
  with End_of_file -> []

(* affiche une liste de chaînes de caractères *)
let rec afficher_dir = function
    h::t -> print_endline h; afficher_dir t
  | [] -> ()

(* programme principal *)
let _ =
  let dir = opendir (getcwd ()) in
  let l = lire_dir dir in
  afficher_dir (List.sort String.compare l);
  closedir dir

Par rapport à C, on s'épargne la déclaration de nombreuses variables, on peut directement utiliser une liste que l'on trie d'un simple appel de fonction... Le résultat est un programme beaucoup plus court et qui contient moins de possibilités de bugs (que celui qui ne s'est jamais planté en bricolant à la main une liste en C me jette le premier transistor). Quand aux performances, il est fort possible que le passage à C permette de gagner quelques microsecondes, mais dans ce genre de cas ça ne change pas grand-chose.

Je confirme, c'était effectivement l'année dernière.

On peut faire la même chose avec tous ces langages, au moins en théorie, si l'on en croit Church et Turing. C'est une excellente raison pour choisir celui qui convient le mieux à la tâche à réaliser : C pour écrire un pilote de carte graphique, Fortran pour exploiter au mieux une grosse machine parallèle à mémoire partagée (le langage est horrible mais comme il est très utilisé par cette communauté, c'est pour lui qu'on a des compilateurs qui profitent pleinement du matériel), Prolog lorsque le problème s'exprime facilement sous forme déclarative, Lustre pour contrôler le système de sécurité d'un réacteur nucléaire, Caml pour le traitement de données structurées (langages, graphes, etc.). D'où l'intérêt d'enseigner plusieurs approches de la programmation. On n'est pas obligé d'aimer Caml, pas plus que Prolog ou Lustre, mais il faut au moins les connaître, sans quoi on manque quelque chose.

Au-delà du langage, c'est l'approche qui compte vraiment. Un exemple en est gcc : comme il doit être capable de s'auto-compiler, il doit impérativement :) être écrit en C. Pourtant, la principale nouveauté de la version 4 est le passage à un nouveau modèle de représentation du code intermédiaire appelé tree-ssa. Ce modèle est directement issu de l'approche fonctionnelle de la programmation, où on s'intéresse à différentes transformations sur les données structurées. Pour gcc, les transformations utilisées servent à optimiser le code. C'est ce genre d'exemples qui mène à des boutades du style "C (ou C++, ou autre chose) est le langage fonctionnel du futur".

C, un langage porté à bout de bras par le succès d'Unix, est un cas à part. Il bénéficie d'une gigantesque inertie : comme "tout" est écrit en C et que "tous les systèmes" ont un compilateur C, "tout le monde" apprend C et donc programme en C. Je ne sais plus qui remarquait que C n'est pas vraiment portable mais plutôt porté : on s'arrange pour que ça marche, puisqu'il le faut. À l'origine il était proche du matériel : on envoie au processeur une séquence d'instructions à exécuter, une par une, les données étant supposées disponibles. Très bien... pour une machine des années 1980. Maintenant nous sommes en 2006 et les machines ne fonctionnent plus du tout de cette manière, mais la base installée est tellement énorme et les progrès en traitement des langages tels que l'on adapte les compilateurs et on utilise des bibliothèques ou des services fournis par système (création et contrôle de processus) plutôt que réécrire les programmes. Personne ne sait si cette tendance va durer ou si d'autres langages vont s'imposer. Ce qui est sûr, c'est que chacun va pouvoir continuer de faire ce qui lui plaît. Pour ma part j'utilise généralement Caml quand j'ai quelque chose à écrire, mais ça ne m'empêche pas de garder de l'intérêt pour l'assembleur x86.

n'est pas plus difficile qu'apprendre la programmation impérative. Là où l'enseignement commence par l'approche fonctionnelle, les étudiants s'y habituent et trouvent bizarre les boucles et autres impérativeries lorsqu'elles sont introduites par la suite. L'université de Paris Sud a fait le choix inverse, ce qui va me conduire dès la semaine prochaine à expliquer que non, on n'a pas besoin d'une boucle while pour calculer ce que demande l'énoncé... Les autres approches (déclarative, réactive, etc.) ont du reste les mêmes problèmes d'image : elles ne sont pas plus difficiles, simplement moins répandues.

C'est une démonstration de Peter Van Roy qui a attiré mon attention dessus. À voir, donc : http://www.mozart-oz.org/

Je note le conseil de lecture. Je note aussi que les critiques disponibles sur Internet sont très contrastées, il est notamment copieusement accusé d'écrire à charge uniquement. Pour ma part, puisque je ne l'ai pas encore lu, je ne peux pas en dire grand-chose, mais tout de même plusieurs choses m'intriguent :
- l'auteur aurait-il confondu commerce équitable et Max Havelaar ? Si c'est le cas, c'est une lourde erreur. Personnellement, j'achète des produits issus du commerce équitable non Max Havelaar sur la base de la confiance que j'accorde aux personnes qui me disent qu'elles-mêmes ou leurs collègues vont sur place et constatent que ces pratiques améliorent effectivement les conditions de vie des travailleurs, par exemple des produits de la marque Rapunzel ou des vêtements.
- l'auteur distingue-t-il entre les différentes marques qui apposent le label Max Havelaar sur leurs produits ? Il y a de grandes différences entre celles qui se limitent au minimum nécessaire (marques de distributeurs...) et celles qui vont plus loin et s'en expliquent (Solidar'Monde, etc).
- l'auteur prend-il en compte la parole des marques elles-mêmes ? Sur la question du transport, par exemple : ils sont tout à fait conscients du problème et n'y peuvent pas grand-chose pour le moment. Ce n'est pas pour autant qu'il faut jeter le café avec l'eau du bateau.

De même, la question de la vente dans les supermarchés ou les boutiques grand public (La Redoute, etc) n'est pas si simple. Certes c'est très bien de faire des boutiques où les altermondialistes du quartier viennent tous les trois se tenir compagnie, et du reste j'en fréquente, mais vu le volume de production concerné, si on veut écouler les produits, il va bien falloir s'adresser à un grand nombre de clients d'une façon ou d'une autre - c'est une des premières revendications des producteurs concernés eux-mêmes. Les boutiques en ligne sont une piste, mais elles ne suffisent pas.

ce coefficient, multiplié par la fréquence du FSB (le bus qui relie le processeur au chipset), donne la fréquence totale du processeur. Le diminuer implique donc que le processeur effectue moins de millions de cycles par secondes et donc consomme moins de courant, mais aussi permet de diminuer la tension d'alimentation du processeur, ce qui améliore encore l'économie. Voilà pourquoi on ne peut faire varier la fréquence que par un certain pas : un nombre entier de fois la fréquence du FSB.

Quant aux derniers chiffres, je vote pour la deuxième solution.

Et dans le cas de ceux que je possède, soit ceux de Manset, c'est ridicule. Il intéresse essentiellement des gens qui veulent le vrai support original, qui paient presque le triple du prix auquel on trouve la galette pour avoir aussi le livret accompagnant dix mille exemplaires d'Obok, etc. En tous cas ça ne m'a pas empêché de l'acheter, il y a suffisamment peu de chanson francophone valant vraiment le coup pour s'épargner ce genre de caprices. Notons que le CD Caravane de Raphaël, sur lequel un certain... Gérard Manset signe les paroles de Peut-être a-t-il rêvé, est diffusé par Capitol Records, un label d'EMI, sans système de protection contre la copie.

le -print est attaché à la deuxième partie du -or, comme on peut le voir en essayant ceci : find . -name '*.cpp' -print -or -name '*.h' -print

Plus simplement, on peut utiliser des parenthèses : find . \( -name '*.cpp' -or -name '*.h' \) -print

Il y a quelques problèmes de chronologie là-dedans.

- XFree existait avant Linux. Il me semble d'ailleurs avoir lu il y a fort longtemps que la possibilité de le lancer fut l'un des premiers objectifs importants (quelqu'un a des références là-dessus ?).
- Les distributions sont apparues assez tôt, quand il y a eu quelque chose d'un peu fonctionnel à distribuer. Par exemple, la Slackware 1.01, sortie le 4 août 1993, comprenait XFree 1.3 et le noyau 0.99pl12A.
- L'arrivée de Gnome et KDE, précédés bien sûr de GTK+ et Qt, est bien plus tardive. Je me souviens non sans émotion de l'époque où les fenêtres de Mosaic, utilisant Motif, étaient arrangées par fvwm (qui se souvient de TheNextLevel ?) ou AfterStep. Le genre de souvenir qui permet de dire "Nous, les vieux, on y était" et de lâcher "Ah, ces jeunes !" avec un gros soupir entendu. Ce à quoi "Et alors ?" est une réponse relativement valable, il faut bien l'admettre.

Je me demande si quelqu'un tient une chronologie de tout le bazar*. L'arrivée des modules dans le noyau, le support du format ELF, des futexes, la possibilité de dépasser les (combien déjà ?) Go à l'installation de Lilo, les principaux progrès des distributions, par exemple la détection automatique du matériel à l'installation, mais aussi des choses comme les premières utilisations de Linux dans l'industrie, à l'université, etc. Il y a bien des pages sur l'histoire de Linux, mais celles que j'ai trouvées sont maigres.

* oui, c'est exprès.

Plus précisément, il faut des diphones. En (très) gros, pour deux sons élémentaires A et B donnés d'une langue, un diphone va représenter le son résultant de l'enchaînement AB. La façon normale de constituer une base de diphones pour alimenter un logiciel de synthèse vocale est d'extraire des diphones d'une base de mots enregistrés en studio. La licence choisie permet de créer des sons dérivés de ceux fournis et de les redistribuer avec la même licence, ce qui a l'air suffisant, à moins que les auteurs du logiciel n'aient d'autres exigences.

C'est sympa de faire un journal là-dessus, j'avais déjà vu passer le nom mais sans m'y attarder. C'est un projet colossal et très intéressant. Par exemple, les quelques petites phrases qu'il donne sur la parallélisation de l'exécution des programmes écrits en Lisaac se jettent dans de vastes domaines de recherche grand ouverts. Le mien, entre autres.

En ce qui me concerne, Lisaac prend tout son sens en tant que langage évolué pour la programmation système. Actuellement, je n'en connais pas. C'est un domaine qui nécessite de pouvoir mettre le clavier dans le cambouis plus que ne le permet normalement un langage de haut niveau : par exemple, alors qu'un ramasse-miettes est très pratique en temps normal, il est catastrophique pour écrire un pilote de périphérique. Il reste à voir comment ça se passe dans la pratique, ce qui signifie lire la doc, le code, etc. Du temps à passer dessus en perspective...

Puisque je passe par là, j'en profite pour quelques mises au point. J'ai failli prendre un troll sur la tête en arrivant : vous pourriez ranger vos affaires, quand même...

Sur l'INRIA : c'est un très grand institut, assez disparate. J'ai eu l'occasion de voir que les chercheurs étrangers ont parfois du mal à en comprendre l'organisation, ce qui leur donne un point commun avec les Français. Notamment, elle contient de grands théoriciens et... de grands praticiens. En gros, dans mon projet, lorsque les gens ne codent pas en C, c'est qu'ils codent en Fortran. Ou qu'ils ne codent pas.

Sur la valorisation de la recherche, comme dit plus haut, les développeurs d'Objective Caml, par exemple, s'en occupent en compagnie de quelques très grosses entreprises. Cela ne doit pas faire oublier que c'est avant tout un langage expérimental, donc qui change souvent et profondément. Les chercheurs ont besoin de tels langages. Pour expérimenter, pas pour vendre.

Sur les nouveaux langages et nouveaux paradigmes, je me demande bien ce qui peut pousser à croire qu'il n'y en a pas, aux États-Unis ou ailleurs. Pict, fondé sur le pi-calcul, est l'exemple qui me vient là tout de suite, mais c'en est juste un. Il en apparaît tout le temps de nouveaux, ce qui est une excellente chose pour l'informatique en général.

Sur les anciens, il faut comprendre qu'un langage donné, plus largement un paradigme donné a son champ d'application. Par exemple, la programmation fonctionnelle s'applique très bien au traitement de données structurées, en particulier les langages de programmation. Ce n'est pas pour rien que les développeurs de gcc se sont donné tant de mal pour implanter tree-ssa dans la version 4 : cette traduction du code impératif et spaghetteux en une forme fonctionnelle favorise l'analyse et la transformation du code, et particulièrement son optimisation. Il est tentant de croire qu'un langage donné va sauver le monde, mais c'est illusoire. Écrire un serveur http en Caml, par exemple, serait possible mais difficile, du moins avec de bonnes performances.

Ah tiens, les performances. En voilà un domaine où les idées reçues ont la vie dure, sans doute en grande partie en raison d'une méconnaissance des architectures actuelles. En écrivant des boucles et des affectations plutôt que des fonctions récursives et des liaisons, on a l'impression d'être plus proche de la machine : on envoie une instruction, on enregistre le résultat, on passe à la suivante. Sans le dire comme ça, les gens ont en tête une machine de von Neumann. C'était vrai, en gros, jusqu'à l'arrivée du Pentium. Maintenant, on est passé à l'autre modèle : celui du flot de données. Les instructions sont exécutées dans le désordre, en parallèle tant que c'est possible, et le facteur limitant est généralement la latence de la mémoire : dès qu'une donnée arrive, elle réveille les instructions qui l'attendaient. Ainsi, le modèle le mieux adapté est la description du calcul en fonction de la disponibilité des données, en séparant autant que possible le code en morceaux indépendants. C'est ce qu'on fait, entre autres, en programmation fonctionnelle, où une évaluation est possible quand on a les résultats d'autres évaluations dont elle dépend, et pas en programmation impérative où on impose un ordre sur l'exécution des lignes du code (généralement du haut vers le bas, mais on trouve de tout dans le folklore).

C'est pour ce genre de raisons que, paradoxalement, on arrive très bien à convaincre des matheux du bien-fondé de la programmation fonctionnelle, mais on a plus de mal avec des informaticiens (ou plutôt des "informatheux", comme dirait une de mes connaissances) - sauf, comme c'est le cas dans certains établissements, quand on commence par là avec des étudiants ne sachant pas programmer (entendu dans un amphi brestois, deuxième semestre de MIAS : "les boucles c'est nul, la récursivité c'est vachement plus facile"). Les étudiants arrivent avec des idées qui reposent sur leur expérience et leurs connaissances, et un nouveau paradigme les bouscule plutôt violemment. Or, on ne peut guère parler d'analyse de langages de programmation à des gens qui n'ont pas encore les bases de la compilation, ou d'architectures parallèles alors qu'ils ne sont même pas initiés aux architectures séquentielles. En gros, les principaux avantages du paradigme fonctionnel ne leur sont pas encore accessibles, et il faut bien reconnaître que la fonction factorielle, fût-elle récursive terminale, montre assez vite ses limites. Alors on trouve toutes sortes de réactions, d'opinions qui peuvent durer ou changer. En tous cas rien de bien inquiétant.

Bon je vous laisse, j'ai comme l'impression que ma propension à écrire des pavés a encore frappé. Je vais donc aller exécuter un script : logout ; shutdown ; sleep.