Comme tu dis, ces logiciels permettent, mais n'imposent pas. Certes IE 7 corrige quand même (partiellement) le tir, mais il n'empêche qu'au moment où IE s'est mis à faire dans l'activeX (c'est à dire euh ... dès que MS a sorti activeX ? :)), MS a poussé à mort pour que tout le monde intègre cette techno dans ses sites. Idem pour "sa" version de JS. Alors oui, c'est vrai, JS à la base, c'était quand même pas bien brillant, mais c'était « pour tout le monde chez les développeurs ».
Pour la pile TCP/IP bien sûr que si. Ne serait-ce que parce que le matériel en face ne parle que comme ça (routeurs, etc).
Pour le shell, si, aussi. Il s'agit d'une interface entre l'utilisateur et son disque dur par exemple. Sans shell, l'utilisateur (pas le programmeur hein !) n'a aucun moyen d'accéder à son périphérique-disque dur.
Euh, d'habitude j'ai tendance à mettre tes posts en "pertinent" (même si je ne suis pas toujours d'accord avec), mais là tu dis une grosse connerie.
La pile TCP/IP, le "shell" (même graphique) qui permet d'accéder aux fichiers, la pile USB, etc., tout ça est nécessaire pour remplir le contrat d'un OS : assurer l'interface entre les périphériques et l'utilisateur.
L'utilisation d'un navigateur web n'est en rien une nécessité pour discuter avec les périphériques.
« [À propos de l'exécution d'un prog dans n'importe quel cas] En Java non plus, cf le maintenant célèbre NullPointerException. »
Pas tout à fait d'accord. Ce qui fait de Java un langage « presque » type-safe (« presque » à cause des types primitifs qui ne sont pas des objets), c'est la garantie que ton programme ne sera pas dans un état « bloqué » / « coincé » (stuck). Quand tu as un null pointer exception, ton programme se termine bien « correctement » (même si la sortie est une erreur). À titre de comparaison en C, comme il n'y a pas de sûreté des types, tu peux te retrouver avec des résultats totalement erronés sans pour autant avoir le moyen de vérifier « facilement » que c'est bien le cas.
« le débat sur les multicores me fait rigoler vu que la majorité des programmes C, C++ ou Java n'exploitent pas non plus le multicore. »
Tout dépend le type de code. En Java, pour du code qui utilise du calcul intensif par exemple, avec beaucoup d'irrégularité mémoire (pointer chasing), on a des programmes aussi rapides qu'en C++ (à condition de faire du « vrai » C++, et pas du « C avec namespaces et templates » -- dans ce dernier cas, C gagne, mais pas forcément de beaucoup).
En Python, puisqu'on peut embarquer relativement simplement des fonctions C externes, il est dommage de ne pas avoir de « vrai » modèle de threads.
Dernière chose : l'argument du « de toute manière les codes actuels n'exploitent pas le multicore », bien qu'énonçant un fait véridique, n'est pas solide : jusqu'à il y a peu, l'intérêt d'utiliser du multiprocesseur en dehors de programmes serveur ou de certains programmes types (comme Photoshop/Gimp par ex) n'avait pas vraiment de sens. Maintenant qu'on est coincé à la même fréquence mais avec plus d'unités de calcul, il va falloir réapprendre à programmer pour inclure l'option parallèle. Parce que plusieurs coeurs c'est bien, mais s'ils doivent se partager non seulement la mémoire cache (4 Mo pour 2 coeurs c'est très bien, 4 Mo pour 4 ça devient pas très grand), mais aussi - et surtout - le bus mémoire, tes processus parallèles, pour peu qu'ils soient limités par l'accès à la bande passante mémoire, risquent de faire la gueule. Je ne parle même pas de la concurrence pour accéder à une carte réseau, ou un disque dur, etc. Le problème existait déjà avant, mais avec la présence de plusieurs coeurs, il s'amplifie.
En fait le multicore amène dans le grand public (et donc plus précisément aux programmeurs qui programment « pour » ledit grand public) des problématiques qui auparavant étaient réservées au domaine du calcul scientifique. Dans l'absolu, je préférerais de loin que tout soit programmé séquentiellement, car on s'enlève tout un tas de bugs potentiels, mais le fait est que je vois difficilement comment on peut se passer de paralléliser certains bouts de codes. Par exemple, un certain nombre de programmes qui permettent de faire du calcul scientifique sont faits en Python, avec derrière des bibliothèques mathématiques programmées en C. Bon, très bien. C'est juste dommage de ne pas pouvoir paralléliser les calculs quand ont sait qu'on a un système multicore. Idem pour tout ce qui est encodage, filtre pour images, etc.
PHP est déjà d'envergure internationale. C'est un langage très utilisé. N'empêche, quand on parle de scripter des petits trucs hors le Web, j'entends 10 fois plus parler de Python, Perl, ou Ruby que de PHP.
Maintenant, oui, on peut se servir de PHP comme d'un langage de script « générique ». Il n'a juste pas été fait pour ça à la base.
« 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.
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.
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 ...
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.
[^] # Re: continuons
Posté par lasher . En réponse au journal La CEE rouvre le procès MS dans la guerre des navigateurs.. Évalué à 3.
[^] # Re: Merci Opera
Posté par lasher . En réponse au journal La CEE rouvre le procès MS dans la guerre des navigateurs.. Évalué à 3.
Pour le shell, si, aussi. Il s'agit d'une interface entre l'utilisateur et son disque dur par exemple. Sans shell, l'utilisateur (pas le programmeur hein !) n'a aucun moyen d'accéder à son périphérique-disque dur.
[^] # Re: Merci Opera
Posté par lasher . En réponse au journal La CEE rouvre le procès MS dans la guerre des navigateurs.. Évalué à 1.
[^] # Re: Merci Opera
Posté par lasher . En réponse au journal La CEE rouvre le procès MS dans la guerre des navigateurs.. Évalué à 4.
La pile TCP/IP, le "shell" (même graphique) qui permet d'accéder aux fichiers, la pile USB, etc., tout ça est nécessaire pour remplir le contrat d'un OS : assurer l'interface entre les périphériques et l'utilisateur.
L'utilisation d'un navigateur web n'est en rien une nécessité pour discuter avec les périphériques.
[^] # Re: Grandiose
Posté par lasher . En réponse au journal Linuxfr en J2EE. Évalué à 3.
Pas tout à fait d'accord. Ce qui fait de Java un langage « presque » type-safe (« presque » à cause des types primitifs qui ne sont pas des objets), c'est la garantie que ton programme ne sera pas dans un état « bloqué » / « coincé » (stuck). Quand tu as un null pointer exception, ton programme se termine bien « correctement » (même si la sortie est une erreur). À titre de comparaison en C, comme il n'y a pas de sûreté des types, tu peux te retrouver avec des résultats totalement erronés sans pour autant avoir le moyen de vérifier « facilement » que c'est bien le cas.
[^] # Re: Grandiose
Posté par lasher . En réponse au journal Linuxfr en J2EE. Évalué à 7.
Tout dépend le type de code. En Java, pour du code qui utilise du calcul intensif par exemple, avec beaucoup d'irrégularité mémoire (pointer chasing), on a des programmes aussi rapides qu'en C++ (à condition de faire du « vrai » C++, et pas du « C avec namespaces et templates » -- dans ce dernier cas, C gagne, mais pas forcément de beaucoup).
En Python, puisqu'on peut embarquer relativement simplement des fonctions C externes, il est dommage de ne pas avoir de « vrai » modèle de threads.
Dernière chose : l'argument du « de toute manière les codes actuels n'exploitent pas le multicore », bien qu'énonçant un fait véridique, n'est pas solide : jusqu'à il y a peu, l'intérêt d'utiliser du multiprocesseur en dehors de programmes serveur ou de certains programmes types (comme Photoshop/Gimp par ex) n'avait pas vraiment de sens. Maintenant qu'on est coincé à la même fréquence mais avec plus d'unités de calcul, il va falloir réapprendre à programmer pour inclure l'option parallèle. Parce que plusieurs coeurs c'est bien, mais s'ils doivent se partager non seulement la mémoire cache (4 Mo pour 2 coeurs c'est très bien, 4 Mo pour 4 ça devient pas très grand), mais aussi - et surtout - le bus mémoire, tes processus parallèles, pour peu qu'ils soient limités par l'accès à la bande passante mémoire, risquent de faire la gueule. Je ne parle même pas de la concurrence pour accéder à une carte réseau, ou un disque dur, etc. Le problème existait déjà avant, mais avec la présence de plusieurs coeurs, il s'amplifie.
En fait le multicore amène dans le grand public (et donc plus précisément aux programmeurs qui programment « pour » ledit grand public) des problématiques qui auparavant étaient réservées au domaine du calcul scientifique. Dans l'absolu, je préférerais de loin que tout soit programmé séquentiellement, car on s'enlève tout un tas de bugs potentiels, mais le fait est que je vois difficilement comment on peut se passer de paralléliser certains bouts de codes. Par exemple, un certain nombre de programmes qui permettent de faire du calcul scientifique sont faits en Python, avec derrière des bibliothèques mathématiques programmées en C. Bon, très bien. C'est juste dommage de ne pas pouvoir paralléliser les calculs quand ont sait qu'on a un système multicore. Idem pour tout ce qui est encodage, filtre pour images, etc.
[^] # Re: Grandiose
Posté par lasher . En réponse au journal Linuxfr en J2EE. Évalué à 2.
Maintenant, oui, on peut se servir de PHP comme d'un langage de script « générique ». Il n'a juste pas été fait pour ça à la base.
[^] # Re: Grandiose
Posté par lasher . En réponse au journal Linuxfr en J2EE. Évalué à 4.
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.
[^] # Re: Grandiose
Posté par lasher . En réponse au journal Linuxfr en J2EE. Évalué à 2.
[^] # Re: Grandiose
Posté par lasher . En réponse au journal Linuxfr en J2EE. Évalué à 2.
[^] # Re: Grandiose
Posté par lasher . En réponse au journal Linuxfr en J2EE. Évalué à 4.
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.
[^] # Re: Grandiose
Posté par lasher . En réponse au journal Linuxfr en J2EE. Évalué à 4.
[^] # Re: Grandiose
Posté par lasher . En réponse au journal Linuxfr en J2EE. Évalué à 6.
[^] # Re: Grandiose
Posté par lasher . En réponse au journal Linuxfr en J2EE. Évalué à 5.
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.
[^] # Re: Bof
Posté par lasher . En réponse au journal Microsoft réécrit Hurd ?. Évalué à 4.
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 »).
[^] # Re: Prix public?
Posté par lasher . En réponse à la dépêche Emtec lance le programme One Laptop Per Hacker. Évalué à 2.
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.
[^] # Re: Bof
Posté par lasher . En réponse au journal Microsoft réécrit Hurd ?. Évalué à 8.
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.
[^] # Re: RIP Mandrake
Posté par lasher . En réponse à la dépêche Il faut sauver le soldat Williamson !. Évalué à 1.
[^] # Re: A qui sert l'économie d'énergie ?
Posté par lasher . En réponse au journal Interdiction des ampoules à incandescence. Évalué à 1.
[^] # Re: A qui sert l'économie d'énergie ?
Posté par lasher . En réponse au journal Interdiction des ampoules à incandescence. Évalué à 1.
Oui, mes vieux souvenirs de 1ère scientifique me disent que dans les centrales, la nuit on effectue ... l'hydrolise de l'eau.
[^] # Re: Et vous qu'en pensez vous de ce journal ?
Posté par lasher . En réponse au journal Google App Engine ma tuer. Évalué à 7.
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 ...
[^] # Re: Et c'est pas un spam débile ce truc ?
Posté par lasher . En réponse au journal Arrêt sur Images et Facebook. Évalué à 4.
[^] # Re: Bonne chance...
Posté par lasher . En réponse à la dépêche Barack Obama et l'Open Source. Évalué à 7.
[^] # Re: Livres = intelligence ?
Posté par lasher . En réponse au journal Is Google making us stupid?. Évalué à 1.
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).
[^] # Re: Livres = intelligence ?
Posté par lasher . En réponse au journal Is Google making us stupid?. Évalué à 3.
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.