MiniMoi a écrit 107 commentaires

...est à mon sens la programmation concurrente, ou multithreading en anglais.
Un bon langage adapté au futur sera un langage qui permette d'écrire "naturellement" des applications multithread, mais je n'en connais pas à l'heure actuelle... (cependant il est vrai que mes connaissances en terme de langages sont limitées)


Je suis vraiment convaincu par les mérites des langages fonctionnels, mais par exemple OCaml ne permet pas grand-chose dans le domaine du multithreading, hélas. Je ne sais plus très bien où (sur la ML de OCaml il me semble) j'avais vu que les concepteurs du langage sont opposés à ça, tant qu'il n'y a pas de paradigme efficace de programmation concurrente.

Qu'en est-il ?

N'y-a-t-il pas au contraire un espoir suscité par les langages fonctionnels ?
Il me semble en effet qu'un programme écrit d'une certaine façon en fonctionnel peut être parallélisé très facilement, par exemple un truc du genre :

let rec f l =
match l with
|[] -> []
|x::r -> (quelque_chose x)::(map f r) ;;

En gros faire du MapReduce...

Il ne faut pas non plus comparer des choses difficilement comparables.
En premier lieu, un navigateur web est un composant "visible", pas un logiciel de retouche photo, dans le sens où tout le monde utilise un navigateur web.
De plus dans le passé il y a eu d'autres navigateurs webs, Netscape par exemple. Donc les gens, mêmes ceux qui sont peu informés, connaissent des alternatives, si ils utilisent internet depuis longtemps.

Ensuite, IE est un mauvais produit. Pas Photoshop, qui reste très supérieur à Gimp par de nombreux aspects. De plus c'est un outil qui nécessite un long apprentissage, et changer n'est pas si simple.
Enfin, Firefox s'installe sans mal sous Windows, Gimp il faut (fallait ?) installer séparément Gtk+, ce qui suffit à dissuader pas mal de monde.

Je pense que ce qu'il veut dire, et que tout les programmeurs OCaml ont expérimenté, c'est que le typage strict d'OCaml, associé aux avertissements en cas de filtrage non exhaustifs (ou le programmeur n'a pas envisagé tous les cas) permet au compilateur de lever des erreurs su beaucoup plus de cas.

Donc en fait si ton code compiles, il a beaucoup moins d'erreurs possibles que ton code C qui compile...


Par ailleurs la programmtion en Caml est souvent plus "sûre" car elle permet de coller de près aux concepts mathématiques. En effet de très nombreux algorithmes sont définis par des récursions, ou par "induction", ce qui se traduit littéralement en Caml...

Oui en fait je voulais dire, avec l'algorithme tel qu'il est.
Je viens de parcourir en diagonale les slides, et il semble que la forme de surcharge prévue soit un peu moins puissante que celle prévue par le C++ par exemple.

De plus je me demande si les concepteurs de OCaml iront faire ceci, car la preuve du noyau de OCaml serait sans doute à refaire, ce qui doit prendre un certain temps. Après je n'ai pas vu en détails, il suffirait peut-être d'adapter.

En tout cas ça va rendre l'UE "fondements de la programmation" plus difficile ;-)

Et oui en effet il n'y aura JAMAIS de surcharge des opérateurs (oui, je sais, il ne faut jamais dire jamais) parce que sinon on ne permet pas l'inférence de type, et le polymorphisme paramétrique. J'ai étudié dans un cours l'algorithme de typage, et il apparaît clairement que la surcharge ne permettrait plus de résoudre le système des contraintes, et de typer une expression.

Alors, pourquoi ne pas oublier le typage automatique ?
Parce que c'est la force principale de OCaml. Il est connu et reconnu que le typage fort, strict et automatique prévient de beaucoup d'erreurs. En fait je dirais presque que si un code Caml compile, alors il marche. C'est un peu faux évidemment, mais pas si loin que ça de la vérité. De plus le typage paramétrique est vraiment extrèmement plaisant à manipuler, par exemple pour faire des conteneurs standards, c'est 100x mieux qu'en C++.

Sinon pour utiliser "*" sur des matrices tu ne peux pas mais tu peux avoir une syntaxe plus sympa par exemple avoir *_ en faisant :

let prefix*_ a b = matrix_mul a b;;
let c = a *_ b;;



Sinon pour la question sur le compilateur je dirais que c'est lié au fait que OCaml soit à la base un projet de recherche, très ancien, non placé sous licence GPL.
Donc initialement lorsque le projet a démarré, gcc n'existait pas et était encore moins multilangages.
De plus il me semble que certaines spécificités des langages fonctionnels permettent des optimisations pas forcément très claires sur la représentation interne de gcc.
Enfin, il ne faut pas oublier que OCaml doit tourner à la fois sur une machine virtuelle et sur un compilateur, et ce genre de chose doit êter pus difficile à obtenir avec le même comportement en écrivant d'une part un front-end gcc et de l'autre une machine virtuelle.

Que ce langage soit si peu utilisé !
J'ai appris le Caml Light en prépa, les 3 premières heures j'ai détesté, impossible de comprendre la syntaxe, la façon d'exprimer les choses (quand le cours commence par "pas de boucles" * , ça fait étrange).

Puis on découvre une autre façon de concevoir les choses, et finalement le retour à un autre langage est bien douloureux. En tout cas je pense que c'est une excellent idée de l'enseigner, ça permet de programmer de façon intelligente, mais pour le reste, c'est vrai qu'à chaque fois que j'ai voulu faire des "vraies" choses avec, j'étais mal à l'aise. En revanche pour prototyper un algorithme complexe, c'est idéal...

Pourquoi ce ne sont pas les meilleurs langages qui sont utilisés ?
:-(


* Oui je sais les boucles existent, mais ce n'est pas l'esprit du langage

>> Par ailleurs, avec l'extension PAE des processeurs x86, on n'a plus vraiment la limite des 4Go de RAM qui devenait bloquante en 32 bits

Il me semble que cette extension est assez lente, et qu'il reste un limite de mémoire par processus, mais peut-être que je suis dans le faux.
A mon sens la principale raison de Microsoft pour faire ceci est de passer outre cette fâcheuse limite, qui est aussi un fardeau dans la gestion des fichiers de grande taille (dans Linux il me semble que c'est assez acrobatique pour les fichiers de plus de 4Go, ça marche, mais de façon complexe sur x86).


>>Sinon, il faut être objectif, MS sais faire un OS multi-plateforme, il suffit de voir sa version embarqué de Windows

Si tu veux parler de Windows CE, ce n'est pas du tout le même noyau que NT. Les structures internes sont différentes, avec quelques surprises (impossibilité d'allouer plus de 64 Mo à un processus et nombre limité de processus).
De plus pour Windows CE il me semble que la plate-forme MIPS ayant été abandonnée, il ne reste plus qu'ARM...
Donc on a vu mieux comme OS multiplateforme...

C'est trouvé !
Merci au mécène anonyme (christophe !)

Bonjour,

Comme certain je viens de découvrir FON par Linux Magazine, et je me demande si quelqu'un n'a pas une invitation FON pour moi...

Mon adresse mail : 02pt3dvelu87n59 AROBASE jetable POINT org

C'est un alias pour éviter le spam (malin les bots maintenant), mais bien entendu je donnerais volontier la vraie à mon éventuel bienfaiteur.
Et vive les Linus !

Tous des drogués alcooliques de toute façon ces Centraliens...

Quel étage ?

Je n'incriminais pas directement g++, contrairement à ce que le titre du post pourrait le faire croire...
Je n'ai qu'une connaissance très partielle du C++ et du C, j'étais juste intrigué par le fait que le bug ne se produise qu'avec certaines options de compilation et certaines versions de g++...

D'ailleurs depuis j'ai trouvé le bug, une écriture au-delà des limites d'un tableau...
Ca vous donne pas envie de persévérer dans le C++ ce genre de choses. Dans ma jeunesse (classes prépa) OCaml signalait immédiatement ce genre de choses, je ne savais pas que g++ ne savait pas reconnaitre un probleme comme le précédent :


for ( int i=3 ; i< 7 ; i++ )
{
temp_vect[i] = 14+i;
}


avec bien sur temp_vect[] qui n'est pas assez grand, et déclaré en variable globale...


C'est bon à savoir, je ferais attention maintenant.
Mais bon, les projets d'études quand on a a pas de cours de programmation, faits à plusieurs avec personne qui ne connait vraiment bien la programmation, ça donne forcément ce genre de problèmes...

Personnellement j'étais un peu dans le même cas que toi avant la version Dapper d'ubuntu. Elle n'est pas parfaite, mais en utilisant le wiki d'ubuntu-fr ou encore le forum j'ai pu résoudre tous mes problèmes de matériel, et finalement on obtient quelque chose de simple, qui marche, avec une forte communauté (même francophone).

http://www.ubuntu-fr.org/

Merci pour toutes ces réponses.
Jer suis en train de voir ce que ça donne avec valgrind. Pour l'instant sur le code compilé avec -03 valgrind segfault (après le programme tout de même), je suis en train de voir ce que ça donne sur la version compilée en -g.

Merci pour le truc des variables temporaires, je penchais aussi pour un problème de mémoire qui est accédée différemment selon les flags d'optimisation... Reste à trouver ça, parce que je e peux pas compiler le programme en -g (le prog tourne presque 3x plus vite avec -O3 !).

Et sinon, aucun warning avec -Wall...

Pour avoir eu un cours de typage détaillant l'algo d'inférence de types de Caml, je doute que ça soit possible de mettre à la fois la surcharge des opérateurs et la sureté du typage ensemble...

En effet une des grandes force de Caml est que l'algorithme de typage est prouvé, et une fois qu'on voit comment il fonctionne en détail, on comprend le pourquoi du comment...

En plus il faut mettre un bémol à cette non surcharge des opéraeurs : beaucoup de fonctions en Caml sont polymorphes, justement grâce à l'algo d'inférence des types, qui donne des types polymorphes dès qu'il peut (par ex si je parle de la fonction foobar : 'a -> 'b -> 'a je sais qu'elle prend n'importe quel type en premier argument, n'importe quel type en euxième argument et renvoie n'importe quel type, mais le premier, pas le deuxième ;)

Je ne sais pas si ce genre de projet va passionner les foules...
J'ai l'impression que les utilisateurs d'OCaml aiment la "belle" informatique, c'est-à-dire l'algorithmique sophistquée...
Il est vrai que le langage rend des choses compliquées tellement plpus simples (dès qu'il s'agit de récursivité en particulier) et propres que ceci est logique. Mais d'un autre côté je ne suis pas fan de la syntaxe dès qu'il s'agit de faire des applications "réelles", et je crois que la plupart des programmeurs OCaml n'aimeront pas trop passer des mois sur des projets de bindings...

Au temps pour moi, je pensais que le retrait de la société qui supportait initialement le projet allait mener celui-ci à une mort certaine.

Mais je maintiens qu'avant que nous puissons voir un CPU libre, il s'écoulera de l'eau sous les ponts.

En plus il apparaît de plus en plus le problème des brevets : j'ai de forts doutes sur la possibilité de réaliser un processeur sans enfreindre un brevet, ne serait-ce que les brevets évidents qui ont hélas été accordés.

Peut-être parce que personne n'a l'argent nécessaire pour fondre ces processeurs ? Déjà les process 90nm c'est pas donné à tout le moinde (une poignée de fondeurs), mais surtout créer les masques coûte très cher, sans oublier que le HDL ne donne pas directement le processeur, il y a beaucoup de travail à faire après.

Enfin je ne suis pas sur que ce soit la solution : si une vidéo est cryptée avec du AES, c'est pas le fait que tu aies un processeur libre qui te permettra de décrypter le contenu...

De toute façon je crois que le hardware libre sera la dernière étape, et peut-être qu'elle n'arrivera jamais : il n'y a qu'à voir l'échec du projet OpenGraphics...

D'accord, merci pour ces précisions, le problème de Java serait donc lié à l'interface graphique... C'est dommage, mais effectivement les bindings de Qt devraient pas mal aider...

Pour la mémoire je savais déjà, c'est lié au Garbage Collector et à des optimisations de la JVM.

Je vais essayer de me faire mon avis, mais peut-être que je vais abandonner le C++ maintenant...

Sur une machine assez similaire (PM 2GHz, 1Go), mais même là je le trouve trop lent.
Enfin je ne sais pas, il manque une certaine impression de fluidité, après je ne sais pas à quoi c'est du. Et puis je ne suis pas le seul à trouver Eclipse trop lent...

Mais la question c'est plutôt : pourquoi il n'y a pas de programmes rapides en Java ? (à ma connaissance)

Pourquoi ne pas préférer Beryl à Compiz ?
J'avais Compiz sur Dapper, et maintenant Beryl sur Edgy, parce qu'il paraît que Beryl c'est ultra plus super mieux, et mieux maintenu...
Des choses ont changé dans le dev de Compiz ?

Je profite d'une dépêche qui parle de LaTeX pour parler de LyX.
C'est vraiment un excellent logiciel qui permet de produire des documents ms en page par LaTeX sans se fatiguer, avec toujours la possibilité d'insérer du code LaTeX si besoin est, et de retoucher le document en faisant un export LaTeX en cas de problème.

Il y a même un support DocBook dedans mais j'avoue ne pas avoir testé.

Seul défaut : la gestion de l'UTF8 qui donne quelque chose d'assez ignoble pour l'interface sur Edgy...

Les 70Mo c'est en regardant dans le gestionnaire de tâches sous Windows XP, avec je ne sais plus quelle version de Matlab (R14 je crois).

Les boucles sont particulièrement lentes sous Matlab, et par rapport à Python c'est très sensible...
De plus tout écrire sous forme de matrice je ne suis pas convaincu par cette approche bien que c'est toujours celle qu'on finit par prendre car plus rapide.

Exemple : la transformée de Fourier, qui est en O(n.log(n)) si on se débrouille bien, si on le fait trivialement avec des matrices ça devient du 0(n²).
L'exemple est mal choisit parce que des fonctions internes de Matlab le font déjà, mais par exemple pour un algo où tu n'as besoin que d'un élément de la matrice, tout calculer est très lourd... Sans compter que par exemple pour un algo je me suis retrouvé avec une matrice 1000*1000 alors qu'une double boucle simple règle le problème.

Ce n'est pas handicapant pour des petites matrices, mais dès que la taille du problème grandit...

Sinon je ne nie pas que Matlab a de très bonnes toolboxes, mais je n'ai pas eut l'occasion de m'en servir.

Je confirme, Matlab est vraiment très lent...
J'ai testé sous Windows l'an dernier pour des cours, et rien que l'éditeur de texte lague sur mon portable @800MHz (en mode économie d'énergie sur batterie).

En plus je trouve ça inadmissible qu'un logiciel si cher prenne 70Mo de mémoire au démarrage, et plus de 100 après 2-3 petites multiplications de matrices 512x512...
Sans oublier la politique de licences éducations pourrie...

Heureusement dans mon école c'est Scilab only maintenant.

Enfin je n'ai pas encore testé Scilab.
Quelqu'un sait si les boucles sont aussi lentes que sous Matlab ? Parce que le langage est interprété très très lentement avec Matlab...


Pour en revenir à Python je pense que ça peut vraiment être plus performant que Matlab, su fait que le langage est beaucoup plus rapide, et du fait de la richesse des bibliothèques autour. Pour en avoir parlé avec un thésard, le gros plus est de pouvoir écrire tout ce qui est périphérique de façon très simple, et de prototyper très vite.

Espérons que ça ne signifie pas que la projet mozilla va dériver vers d'autres horizons... Si tous les développeurs les plus actifs de mozilla travaillent pour une société, il peut très bien y avoir une dérive dans les objectifs de Mozilla. Je ne connais pas la licence de Mozilla, mais si ce n'est pas la GPL il est à craindre une cission entre une version libre bridée et une version non libre.
Et quid du support de projets annexes comme SeaMonkey ?

En même temps, seul l'avenir nous le dira, ne pas crier au loup trop vite.

LMDMF vaincra!! Même si la bande FM a perdu sa plus fantastique émission culturelle, elle est encore présente dans nos coeur, Niluje président!!