lasher a écrit 2731 commentaires

« Mais avait-on besoin d'inventer un nouveau langage pour proposer une bibliothèque qui aide au développement? Je ne pense pas. »

Pas que. Je développe en C et Perl (C pour mes « vrais » programmes, Perl pour des scripts qui exploitent et post-traitent les sorties de mes progs C). Ne serait-ce qu'à cause de la façon dont le typage fonctionne dans chaque langage, en Perl je fais des choses qui fonctionnent aussi rapidement qu'en C (du moment que le goulot d'étranglement est le disque dur ou le réseau, honnêtement, Perl/Python/etc n'ont rien à envier à C/C++) mais ça me prend facilement cinq fois moins de temps.

Par exemple j'ai des fichiers dont le format se rapproche du CSV. Je dois manipuler les données dans tous les sens. En Perl [1] je n'ai eu qu'à me faire un petit module pour manipuler ce genre de fichiers (dont la fonction principale est quelque chose du genre csv_to_array() ), et surtout, une fois que j'ai récupéré mes données sous forme de tableau 2D, je peux les traiter en foutant le tout dans un tableau de hachage (qui est un type natif de Perl, pas besoin d'appeler une bibliothèque externe, et si je veux faire un hash de hash, tout est fait dynamiquement ... En C, et même en C++, ce serait quand même assez galère à obtenir comme comportement), un autre tableau, etc. En C, pour faire la même chose (ie faire mon petit module d'extraction « brute » de données, et le post-traitement à proprement parler), j'aurais eu non-seulement plus de lignes de code (ça à la limite, on s'en fiche, si c'est bien écrit et encapsulé), mais aussi bien plus de manipulations de fonctions pour extraire les infos en fonction de la nature de mes données. Je ne peux pas trop expliciter plus, mais tout mon discours ici est de dire que, même si j'adore vraiment le C, quand il s'agit de développer vite une application qui n'est pas trop intensive niveau I/O, utilisation CPU, etc., alors Python/Perl/Ruby & co sont clairement de meilleurs choix selon moi. Je ne parle même pas du côté merveilleux de Python à pouvoir accepter des fonctions C « directement » quand on a besoin de perfs supplémentaires (en Perl on peut aussi faire, mais c'est beaucoup, beaucoup plus lourd).


[1] Je ne connais pas assez bien Python, donc je ne peux pas trop en parler, et de façon générale il faudrait que je m'y prenne différemment car il est fortement typé, donc les opérations sur des floats ou des strings devraient être « explicites », mais ce serait évidemment faisable aussi.

Je pense que les « quelques trucs » c'est ce qui fait qu'on peut dire que ce n'est pas compatible. Je ne sais pas à quel point les modifications à faire sont importantes - et surtout à quel point elles peuvent se révéler sensibles - mais ce n'est pas trivial, surtout si tu dois requalifier ton code ensuite ...

Je savais que quelqu'un allait tiquer. :-) En pratique, je ne connais personne, ni aucun projet d'envergure utilisant php sans le web. Ça en fait un « langage du Web » selon moi.

Bon, autant je suis un grand grand fan du langage C, mais dire que « tout ce que Python fait, je sais le faire "mieux" et plus maintenable pour le futur en C/C++ » me semble très présomptueux.

Même en utilisant les bibliothèques C qui vont bien, il faut bien avouer que les langage dits de 4è génération (Python, Ruby, Perl, et dans une moindre mesure - car orienté web uniquement - PHP) permettent de développer bien plus rapidement quelque chose de fonctionnel qu'en C. De plus très souvent, si on veut tout refaire « depuis zéro » (parce qu'on aime réinventer la roue, parce qu'on a le syndrôme du « Not Invented Here », ou tout bêtement parce qu'une vraie bonne raison le requiert), ces langages proposent nativement tout un tas de trucs (tables de hachage, augmentation dynamique et implicite de la taille des tableaux, etc). En C, je n'en parle même pas. En C++, certes, il y a la STL, mais il y a tout de même de gros écueils à éviter, et des subtilités parfois très euh ... subtiles. Un exemple tout bête :


for (i = <un_certain_type_d_iterateur;<condition>; i++) {
// quelque chose à faire
}


Bon, ben si l'opérateur '++' a été surchargé, on se retrouve avec deux évaluations de l'objet i, ce qui d'un point de vue perfs est pas génial. On me dira que oui mais bon, quand on surcharge un opérateur, il faut faire gaffe, mais c'est un exemple relativement simple de pourquoi C++ est loin d'être le meilleur langage « universel ». Je préfère 100 fois un programme Perl ou Python. S'il y a besoin d'aller vite, évidemment, alors il faut commencer à fureter du côté de C ou C++. Et même là, parfois on a des surprises.

Sinon, le fait est que malgré l'ascension de Python et Ruby (et avant eux de PHP), Perl reste encore très utilisé (peut-être plus par les admins que par des dévs purs et durs, je te l'accorde). Perl date de 1987 d'après wikipedia. Il a été utilisé (et l'est encore) depuis vingt ans, je trouve que c'est déjà pas mal du tout. Certes, C est plus vieux, mais il lui manque une bibliothèque standard aussi fournie que celle de Java ou au moins C++ (oui, il y a la glibc, mais tout le monde ne veut/peut pas l'utiliser -- vu que c'est pas standard, justement).

Enfin, si on parle de C++, le principal problème à mon avis est le fait que malgré l'existence d'une norme, l'implémentation de celle-ci est partielle au mieux [1] (je pense à C++98 notamment). Je ne parle même pas de la compatibilité entre compilateurs, ou des classes qui existent désormais dans la STL, mais qui sont redondantes avec celles mises au point par de gros frameworks (genre Qt) à l'époque où aucun standard n'existait, mais évidemment avec des différences de comportement, d'API, etc.

Tout ça pour dire quoi ? Affirmer qu'on fait mieux et plus maintenable que Python (ou un langage du genre) peut être vrai, mais je doute très fortement que ce soit réalisé dans les mêmes délais (après, faire du code crade, quel que soit le langage, c'est possible, bien sûr).

[1] Et même en C, C99 n'est pas implémenté intégralement, même par GCC, à cause de fonctionnalités « avancées » voulues par le comité de normalisation mais qui sont fichtrement difficiles à mettre en oeuvre.

Tu as essayé le « litterate programming » de Knuth ? :)

Il faut aussi avouer que Python n'a pas eu le même soutien que Java, ni la même publicité au départ ...

Un compilateur n'a pas pour but de vérifier ton code, il a pour but de transformer ton code en exécutable.

Je ... hein ? Un compilateur fait bien plus que ce que tu sembles croire.

La vérification des types, et la garantie de leur sûreté fait partie du rôle du compilateur... Quand la norme/le standard/la spécification du langage le permet. Par exemple en C, faire une vérification de type fiable est difficile, car le langage est faiblement typé. En Java, du moment qu'on exclut les types primitifs (donc pour tout le reste qui nous intéresse déjà beaucoup plus, à savoir les objets), il y a du lambda calcul un peu partout, avec une garantie de « type safety ».

Un compilateur sert aussi de « prouveur » -- même si le plus souvent les preuves ne sont que « partielles ». Je veux dire par là que le compilateur, en démontrant que des bouts de ton programme satisfont certaines propriétés -- par exemple, si tu fais une boucle dont l'en-tête est

M = 1000;
... // pas de réécriture de M
N = M
for (i = 0; i < N; ++i)

le compilateur devrait être capable d'inférer la borne de la boucle for, et du coup de déterminer certaines propriétés liées à ladite boucle. Bref, le compilateur est aussi là pour garantir certaines propriétés au programmeur concernant son programme. Après, la somme des propriétés dépend des objectifs du langage.


Justement, utiliser un compilateur pour contrôler la qualité est vachement inquiétant parce que ça n'a pas été conçu pour ça et, surtout, cela n'a aucune valeur ! N'importe qui peut te pondre du code qui compile mais qui ne tourne pas.

Ben non. Plus tu peux déterminer de « fautes » en amont (je mets entre guillemets, parce que parfois soit on fait un truc « crade » mais qui va vite, soit on perd 10 à 20% de perfs, ou plus), et moins ton code risquera d'avoir de bugs. Plus exactement, en C, il est facile de compiler un code, « sans erreur », et que celui-ci plante, ou pire, donne un résultat inexact. En Java, ou encore « pire », en OCaml, certains types d'erreur (comme celles dues au transtypage, ou aux types en règle générale) sont totalement évitées car détectées à la compilation. Je ne vois pas ce que tu peux reprocher à ce comportement. Et oui, c'est clairement le rôle du compilateur de faire tout ça, car de son point de vue (et des specs du langage), il s'agit bien d'une erreur du programmeur.

Concernant l'inutilité de l'étape de compilation, je serais d'accord avec toi si les compilateurs étaient de bêtes traducteurs « code source » => « code machine », mais c'est très loin d'être le cas. Il y a bien sûr la partie front-end qui fait les analyses lexicales et grammaticales (et si je ne me trompe pas, une partie des analyses sur les types se fait à ce moment), mais juste après il y aussi le middle-end qui se charge de transformer le code pour l'optimiser, puis le back-end qui génère le code. Sans parler du fait que middle-end et back-end ont besoin de communiquer pour générer efficacement du code, etc.

Au final, un bytecode (bien) compilé, avec en plus du JIT pour les parties « chaudes » du programme peut permettre de gros gains de perfs au lancement de l'application.

L'asm est incontournable dans le cadre d'écriture de bibliothèques de fonctions, oui, car il s'agit d'avoir le code le plus « compact » et performant possible. Maintenant, je suis quand même assez assez sceptique sur son utilisation à outrance. Par exemple, l'utilisation des intrinsics est strictement équivalente à celle des instructions SSE sur x86 (tout au plus, si on utilise icc, ce dernier risque de dérouler plus d'instructions que ce qu'on a déjà fait à la main), et ça permet de garder du « C » partout dans le code, plutôt que d'avoir à insérer de l'asm, ou de devoir appeler une fonction rédigée uniquement en asm dans un fichier à part.

Pour les OS, évidemment, l'asm est nécessaire, mais si on peut l'éviter, il faut (ça semble « évident » dit comme ça, mais j'ai l'impression que beaucoup de gens préfèrent l'aspect bidouille à l'aspect « quand je reviens dessus plus tard, je sais ce que ça fait »).

De nos jours, les compilateurs font à la fois beaucoup et très peu. Beaucoup, parce qu'ils font pas mal de transformations sur le programme; très peu, parce que ce qui sort au niveau de la recherche est implémenté au moins 10 ans plus tard dans les compilateurs. Et puis surtout, même s'ils tiennent un peu compte des threads, les compilateurs sont quand même extrêmement axés mono-processeur. Ils optimisent à fond dans une optique séquentielle, alors que désormais il faudrait plutôt penser parallèle -- surtout quand la cible est un processeur multicoeur. :)

De plus, sauf si tu prends icc (ou peut-être le compilateur de MS, je ne sais pas), gcc vectorise encore très mal (voire pas), avec un choix d'instructions SSE pas forcément judicieux. Les applications « vraiment optimisées pour un cpu donné » y'en a pas tant que ça -- il y en a, bien sûr, et heureusement ! Mais l'optimisation pour un processeur donné empêche la portabilité dans beaucoup de cas, et demande une maintenance par plate-forme, ce qui est quand même assez contraignant.

Oui enfin, le C n'est pas portable hein. Tu as du C portable façon POSIX, du C portable façon ISO seulement, et surtout, surtout, quand il s'agit de coder un OS, même si tu essaies très fort, tu auras forcément des bouts de code totalement non-portables. Par exemple, les types en C ISO ne sont que des relations d'ordre, du type sizeof(char) <= sizeof(short) <= sizeof(int) <= sizeof(long), etc. D'où le besoin d'une norme POSIX qui propose des types fixes (uint32_t, etc) [1].

Dès qu'on parle de programmation bas-niveau (telle que celle d'un OS), il ne faut pas voir le C comme autre chose qu'un « assembleur de haut niveau ».

Concernant les bouts de code à « spécialiser » en fonction des architectures, je suis assez d'accord. Cela dit, ça fait quand même un grand nombre d'optimisations spécifiques. Alors si par exemple sur x86, on peut utiliser les intrinsics, le problème est que sur une autre plate-forme, le nom et la sémantique des instructions diffèrent, ce qui force à tout réécrire, et qui est tout de même assez pénible.

Par exemple, sur PowerPC 32 bits, il existe 32 registres adressables, alors que sur archi amd64/intel64, on n'a que 16 registres (sans parler des x86 32 bits et de leurs 8 registres). Bref, dans le cas du ppc, on a plein de registres à disposition (RISC oblige), avec des instructions qui peuvent en tirer parti -- par exemple, il existe une instruction qui affecte les valeurs situées à partir d'une certaine adresse dans tous les registres, e.g. :
r1 <- @tab[0]
r2 <- @tab[1]
...
r32 <- @tab[30]

... alors que sur x86, à cause de l'héritage CISC, on doit faire un peu différemment (en « vrai », il y a évidemment plein de registres sur un processeur x86, mais ils sont cachés, et on est obligé de faire confiance au matériel pour renommer les registres en interne de façon intelligente).

Ce genre d'instruction n'existe pas pour le SSE d'Intel/AMD. En revanche, on y trouve des pxor (parallel XOR, qui permet d'effectuer des XOR sur 128 bits d'un coup), et autres choses plutôt sympa pour la crypto, par exemple.

Sauf que voilà, du coup, l'algo sous-jacent à une certaine fonction (filtre pour traiter des images, ...) risque de différer pas mal d'une archi à l'autre. On se retrouve donc finalement avec une fonction qui a la même interface, indépendante de l'architecture (MIPS, PowerPC, x86, x86_64, ia64, etc), mais un fonctionnement interne très différent, avec des perfs elles aussi très différentes. Et surtout, il faut trouver des gens pour maintenir ce genre de code (un par archi, voire un par génération d'une même archi ...).

Maintenir (et mettre à jour !) correctement ce genre de code est très délicat, car le moindre bug risque non-seulement de faire planter l'appli (cas « idéal »), mais surtout de donner un résultat erroné (et là, c'est déjà plus coton).

Enfin, même si j'aime bien l'assembleur, je suis pour son éradication sauf cas exceptionnel. On a vraiment très rarement besoin d'accéder aux instructions assembleur. Déjà, en insérant de l'assembleur en-ligne dans un code C, on coupe toute velléité d'optimisation au compilateur (qui se « houla, il tripatouille autre chose que du c/c++/java/pascal/whatever, qu'il se débrouille puisqu'il est si malin »). Donc déjà, ça signifie faire une fonction à part, compilée dans un fichier objet. Ensuite, il faudrait déjà qu'il n'existe pas déjà une interface « C » (intrinsics pour SSE, instructions vectorielles pour profiter d'AltiVec sur ppc, etc) pour utiliser ces instructions SIMD. Généralement de toute manière, le nom des instructions est très proche de l'instruction assembleur correspondante. Par contre, au programmeur de vérifier l'alignement des données [2], sinon ça va planter grave, à lui de vérifier que l'opération qu'il veut effectuer est légale dans le cadre d'instructions vectorielles, etc.

Il existe cependant quelques rares cas où il n'existe pas d'équivalent « C » à ce qu'on peut faire en assembleur. Par exemple, un de mes collègues, expert en cryptographie, râlait il n'y a pas si longtemps sur le fait qu'on ne pouvait pas récupérer des infos concernant les retenues ou les overflows (qu'on a dans le registre d'état, mais qui est totalement masqué dans les langages de 3è génération et plus).

[1] Enfin si je ne me trompe pas, avec C99, ce genre de type rentre dans la norme du langage.
[2] Tiens, encore un truc qui fait que le C n'est pas trop portable dans ce cas.

Apprends la ponctuation s'il te plaît. Il manque un point à ta phrase.

oups oui pardon, ça sonne mieux. :)

On ne sait pas bien stocker l'énergie en surplus. (J'ai ouï dire qu'on remontait l'eau en amont des barrages !)

Oui, mes vieux souvenirs de 1ère scientifique me disent que dans les centrales, la nuit on effectue ... l'hydrolise de l'eau.

Il ne faut pas tout confondre.

Typage dynamique :

var = 1
var = "toto"


On se fiche de savoir si la variable a été déclarée avant (par exemple on peut forcer la déclaration des variables en Perl, pourtant le langage est dynamique et faiblement typé...).

Dans ce cas, à la même variable var, j'ai affecté 2 valeurs qui avaient des types différents.

Pour ce qui est du typage faible/fort :

Le langage C est faiblement typé. Ça veut dire qu'il est possible de faire ce genre de choses :

int i = 3;
i = i + 'a';


Si tu essaies avec Python de faire le même genre de choses (mélanger des int et des chaînes de caractères, des flottants et des int, ou même des objets de type différents avec d'autres objets de types différents), tu vas juste réussir à obtenir une erreur.

Donc pour résumer :

Typage dynamique : une variable peut prendre différentes valeurs, de type différent.
Typage fort : on ne peut pas additionner des choux et des carottes.
Typage faible : on peut additionner des choux et des carottes, et parfois - parfois seulement - ça a du sens ...

On t'a déjà dit que la greffe d'ovaires ne fonctionnerait pas sur toi.

Oui enfin, si je me souviens bien, Gates a soutenu républicains et démocrates lors des avant-dernières élections (oui, les deux partis), et c'est sans doute pareil cette année.

D’ailleurs, si, pour toi, la technique de la lecture correspond à une simple reconnaissance de phonèmes, ce n’est pas étonnant que tu ne lises pas vite.

Je ne sais pas si je lis vite ou lentement. Je sais juste que (de par mon activité professionnelle et mes goûts personnels) je lis beaucoup.

Je n'ai jamais dit que la lecture n'était qu'une reconnaissance de phonème -- en fait, j'ai même carrément dit le contraire. J'ai volontairement exagéré le trait, je l'admets. Et oui, le terme de « phonème » était soigneusement choisi pour justement exagérer le trait encore plus. J'aurais pu lancer un troll en douce en parlant de lecture globale ou autres, mais ça se serait vu je pense.

Concernant la lecture à voix haute, je suis bien d'accord (cela dit, un poème est souvent fait pour être entendu plutôt que lu -- mais dans ce cas, on ne cherche pas à lire vite).

Oui enfin quand même, lire 200 pages en 120 minutes, c'est pas donné à tout le monde. Je lis beaucoup pour tout un tas de raisons : pour le boulot j'ai des articles scientifiques à lire, pour chez moi j'ai tout un tas de bouquins qui varient entre l'essai et le roman. Si j'arrive à faire 1 min / page, c'est déjà pas mal. Si en plus le texte est en anglais, on peut rajouter entre 30 et 60 secondes... Bref, je pense que tout le monde n'a pas ta capacité de lecture.

Pour les romans, tu dis que ça va vite, mais je te trouve un peu « rapide » justement pour dire ça. Lire « Le ravissement de Lol V. Stein » (oui, je sais, « LOL »...), malgré ses 150 ou 200 pages, ce n'est quand même pas la même chose que lire un Dan Brown -- à vue de nez, je dirais qu'on met autant de temps à lire l'un ou l'autre, en supposant qu'on soit bien d'accord sur la notion de lecture, qui pour moi consiste aussi à comprendre et analyser un minimum ce qui est lu. Si pour du Brown, je te l'accorde, l'analyse va vite (en même temps, il s'agit juste d'un gros roman de gare), pour un Duras, outre le style volontairement elliptique (phrases non ponctuées, voire non terminées, afin de reproduire un certain « flot de pensée », etc.), il faut aller un peu plus loin que la simple reconnaissance de phonèmes. :)

J'avais lu quelque part (je ne sais plus où, sans doute à l'occasion du salon du livre ou autre machin) qu'en France on était « grand lecteur » à partir de 10 livres lus par an. Je trouve ça assez aberrant, car effectivement, un livre de 40 pages de Bourdieu ne se lit quand même pas de la même manière qu'un « six compagnons » de 150. En supposant qu'ils visent des livres « d'adulte » avec un nombre de pages moyen, je peux très bien être un grand lecteur comme un énôôôôôrme lecteur.

Ça par contre c'est assez dommage, étant donné que pas mal de trucs « multimédia » peuvent clairement profiter des 8 registres de plus du mode 64 bits.

Sachant qu'il y a 3 generations de fortran derriere cela laisse reveur avec des changement fondamentaux surtout par rapport au 77 qui est vraiment mais vraiment obsolete.

Euh. Obsolète ? J'irai le dire à certains gros industriels qui produisent encore aujourd'hui du code F77 pour de très grosses applis (genre simulation de procédés de fonderie).

Cela dit, oui, implémenter FORTRAN 77 est bien plus simple que ses successeurs.

Oui je sais, c'est un jeu libre, tout ça. Mais puisque vous proposez un binaire Windows, il serait bien que ça tourne correctement. En voyant cette news, j'avais envoyé (insouciant et naïf que j'étais) l'URL à une amie qui joue à ce jeu sur le site original, mais qui ne passera pas à un système libre de sitôt. Mais bon, mieux vaut un système proprio avec du libre dedans que rien du tout, me dis-je.

... Bon ben, c'est pas ça. Elle a un écran bleu au bout de 5 min, et du coup refuse de sortir avec moi, et hésite à m'adresser de nouveau la parole. Tout confus, je redémarre l'ordinateur familial (le dual boot a été validé par le pater familias), installe le jeu, et .... Pas d'écran bleu, mais le jeu se fige au début (dès que j'appuie sur la barre espace en fait). Du coup, je fais quoi pour tirer un coup, moi ?

c'est un choix qui a été fait et qui te plait pas, comment dire...

=> LinuxFR, tu l'aimes ou tu le quittes ?

--> [ ]

Concernant Henri IV, Louis Legrand & co :

- si tu es sectorisé, ils n'ont pas le droit de t'empêcher d'aller dans le lycée de ton choix;
- sinon, effectivement, ils ont le droit de sélectionner les élèves situés hors-secteur.

Bien entendu, avec la suppression de la carte scolaire, la donne est un peu changée (mais pas vraiment en ce qui concerne les élèves faisant une demande dans leur secteur). Ce qui change beaucoup de choses par contre, c'est le fait que Henri IV / Louis Legrand se trouvent en plein quartier latin à Paris, et que de fait, la population y est plus aisée et donc peut plus facilement pourvoir à l'éducation de ses enfants. Il y a donc une « pré-sélection » de fait (un prof de prépa de mon lycée appelait cette population « ceux de la rive gauche »).

Comme il a été dit, le passage du public au privé implique nécessairement une évaluation des connaissances de l'élève. De plus, tu donnes le cas d'un lycée militaire, ce qui d'emblée te place dans une position à part. Les « grands » lycées parisiens (et leur équivalent ailleurs) pratiquent (pratiquaient ? après tout maintenant c'est « légal ») une sélection officieuse. Les profs savent parfaitement lorsqu'un élève habite le secteur pour de faux. S'il est assez bon cependant, ils vont bien se garder de l'empêcher de rester. Par contre, si son niveau ne convient pas, alors ils vont tout faire pour lui pourrir la vie (une fois un élève accepté, il est difficile de le virer sans bonne raison).

Merci d'arrêter de sous-entendre que la méthode globale est encore utilisée à fond les ballons partout. Ce qui est préconisé de nos jours est une méthode que je qualifierais de « semi-globale ». En pratique, il s'agit de faire un numéro d'équilibriste entre méthode syllabique et méthode globale. Mes neveux (des jumeaux) en ont fait l'expérience, et savent lire correctement pour des enfants de 7 ans.

Maintenant, de même qu'il existe encore des instituteurs - pardon, des professeurs des écoles - qui utilisent la méthode syllabique, il y en a qui continuent avec la méthode globale (et là, c'est la catastrophe).

« e ne sais pas si les principes légaux sont les mêmes, mais quand tu loues un appartement et que le propriétaire entre sans ton autorisation, quelle qu'en soit la raison, c'est illégal. Il n'a même pas le droit de garder un double des clefs normalement. »

Sauf si c'est un meublé. Dans ce cas, il a le droit de garder un jeu de clefs pour lui.