ce journal me rappel le projet Haskore ayant pour but de créer(?) de la musique en se basant sur un langage de programmation.
Dans le cas de Haskore(1), il s'agit d'un langage de programmation purement fonctionnel (Haskell) qui permet de décrire la musique qui sera créer/jouer.
Je laisse au créateur Haskore le soin de le décrire :
"Haskore is a collection of Haskell modules designed for expressing musical structures in the high-level, declarative style of functional programming. In Haskore, musical objects consist of primitive notions such as notes and rests, operations to transform musical objects such as transpose and tempo-scaling, and operations to combine musical objects to form more complex ones, such as concurrent and sequential composition. From these simple roots, much richer musical ideas can easily be developed."
Un aspect intéressant de Haskore est aussi qu'il repose sur l'approche DSEL (2) qui permet d'exploiter directement la puissance du langage sur lequel on repose (declaratif, typage fort, dynamiquemant typé, d'ordre supperieur, intérpreté ou compilé, ...) pour exprimer des chose dans un style proche du domaine qu'on a ciblé.
Il n'y a donc
- ni parsing d'un fichier à partir d'un programme écrit dans un langage plus généraliste
(le contenu du fichier parsé est alors souvent simpliste et limité en terme d'expressivité)
- ni de création d'un nouveau langage (très difficile et pas toujours très concluant par rapport à ).
- ni même de codage direct dans un langage généraliste (même si l'approche DSEL pourrait le faire croire, ce n,'est pas le cas)
Un autre exemple de cet approche est Fran(3). C'est un peu vieux mais c'est très intéressant de voir comment décrire des animations peut devenir simple et relativement naturel avec un langage à la base généraliste, mais qu'on a 'spécialisé' à la définition de ces animations. Regardez le tutorial (4), je le trouve super.
PS : cette approche (DSEL) n'est pas restreinte à Haskell, et peut être implémenter dans de nombreux autres langages généraliste.
Le langage Haskell présente cependant certaines qualités qui le rende particulièrement adapté à cet usage (par exemple pouvoir definir de nouveaux opérateur est bien venu dans cet optique).
si on prend cet exemple "écrire une classe en Perl, l'hériter en Python et l'instancier en Tcl" ce n'est peu être pas ce qu'il y a de plus conseillé (et encore, je ne peux même pas affirmer que ce genre de chose est mauvaise).
Mais l'idée de pouvoir 'simplement' réutiliser dans un langage (e.g. perl) des composants écrits dans un autre langage (e.g. python), je trouve ca vraiment très intéressant.
"En fait la distribution est personalisée (c'est un système expérimental anti-pirates en vue d'une commercialisation éventuelle). C'est la raison pour laquelle l'inscription est nécessaire. Ce serait dommage de vous priver d'Anubis pour si peu de chose. Il est quand même gratuit."
... ouais ouais gratuit ... c'est cela ...
Je ne pense pas que ce soit une bonne chose de chercher à "commercialiser" des langage aussi experimentaux.
Il me semble au contraire plus intéressant de liberer completement
ces langages de manière permettre à une communauté de se créer dessus et à le faire réellement exister et se repandre.
Il me semble d'ailleur que nombres de langages se sont saborder en devenant "commerciaux" .
---------
Oui mais justement, en maths "f(x) = x + x" c'est pas une déclaration de fonction, c'est pas grand chose. Pour déclarer une fonction on fait ça proprement (Soit f : x -> x + x) ou avec une équation (Soit f telle que pour tout x, f(x) = x + x), mais on balance jamais "f(x) = x + x", c'est pas rigoureux.
---------
Oui effectivement le terme definir n'etait peut etre pas le plus adapté (j'ai penser à denoter ce qui me paraissait meilleur mais 1) n'etant pas plsu sur 2 ) toruvant cela un peu pompeux , je gardais definir).
Cependant, j'ai ecris
f x = x + x
car, je reprenais l'exemple de ce qui se fait en haskell.
pour parler de ce que je connais en haskell, et cela semble propre selon ce que tu dis, on aurait pu ecrire :
f :: a -> a
f x = x + x (pareil que f (x) = x + x)
(c'est presque ce que j'ecrivais a l'ecole me semble t'il)
ou meme
f :: forall a. a -> a
f x = x + x
mais dans les faits je trouve bien aussi qu'un langage INFORAMTIQUE me trouve tout seul le type de la fonction que j'ai ecrit ou me dise si le type de la fonction n'est pas bien typé, ambigue, ou qu'il a besion d'information complementaire.
Apres tout meme si ce n'ai pas tres rigoureux, je n'imagine pas qu'un mathematicien ne se permette pas de temps a autre et lorsqu'aucun doute n'est permis, d'ecrire ce genre de chose ;-)
f (x) = a x² + b x + c
delta = b² - 4ac
mais je me trompe peut etre.
toujours est il que dans le cadre d'un langage inforamtique je trouve tres agreable la maniere dont on peut 'poser' ces fonctions, et encore plus magique le fait que celles ci soient referentiellement transparente , c'est a dire exemptes de tout effet de bord.
Je ne suis pas mathematicien et j'ai (et continue) de coder en C++ mais haskell m'a veritablement apaisé dans ma maniere de coder et considerer les problemes informatiques (que ceux ci soient bas niveau ou haut niveau, l'important reste de toujours penser dans les termes de ce problemes (et d'ailleur le c/c++ est difficile pour ca mais java / etc ne s'en sortent pas toujours tellement mieux ) ).
pour les tuples en retour je suis d'accord avec toi , ca reste une valeur de retour unique (ou je n'ai pas bien saisie alors)
C'est rigolo, mais je te trouve plutot radicale et vehement dans tes avis.
Ne le prend pas mal hein, c'est juste la maniere dont tu defend certains avis :
------------
Ca doit donc servir aux tests et à rien d'autres.
Le reste c'est de la bidouille.
------------
Je déteste le concept du = et ==
------------
Or je parlais du fait que justement
------------
Je trouve aussi personnellement que que Lissac a une syntaxe particulierment rebutante.
------------
mais que j'etais ouvert aux argument de personne qui la trouve bien, et c'est d'ailleur pourquoi je te demandais ton avis (je me permet de te tutoyer aussi)
C'est pour quoi je te trouve dur et radical envers des gens qui partent justement du fait qu'il 'deteste' la syntaxe de Lissac.
Mais bon, ceci n'est que digression et j'entend bien tes arguments :-)
Cependant, quelque petites choses :
----------
J'ai été très marqué par Pascal, qui m'a beaucoup marqué, c'est pour cela que j'aime le ':='
----------
vi, tout a fait d'accord, c'est important dans un langages imperatif d'avoir fait cette distinction avec le '=' de la logique ou des maths (je me demande en fait si il s'agit bien du meme ? je n'arrive pas encore a me decider)
-----------
Je déteste le concept du = et ==
Un égale '=' mathématiquement, c'est une reflexion binaire réflexive, symétrique, transitive, antisymétrique. Point barre.
Un égale est donc une opération
'a * 'a -> bool
Ca doit donc servir aux tests et à rien d'autres.
-------
justement c'est la que je decroche, si justement on considere que '=' c'est mathematique (c'est une reflexion binaire réflexive, symétrique, transitive, antisymétrique. ) e.g. f (x) = x * x, je ne vois pas necessairement pourquoi ca ne servirait qu'au test et rien d'autre ???
prend le cas du lambda calcul. si tu dit que
f (x) = x + x (x etant un reel par exemple)
ce n'ai pas pour faire quelque test que ce soit, mais juste pour definir la fonction f (de type R -> R ).
mais c'est la meme chose si tu dis
ma_variable = 42
si on considere que ma_variable est un variable mathematique , non ?
ainsi
f(ma_varaible)
sera juste reduite en
ma_variable * ma_variable
il n'y a donc ni affectation (pour laquel l'operateur ':=' qui a ete crée pour ca est bien plus parlant ), ni test.
et d'aileur en fonctionnel on peut aussi avoir besion du ==
is_zero n = n == 0
ensuite le (truc avec trois barre qu'on utilise en marth et que je ne sais pas ecrire ici :-) ) serait peut etre plus judicieux mais pas utilisable en ascii donc je le trouve tres bien ce == pour un test d'egalité.
d'ou ma reponse : je n'ai rien contre = et == bien au contraire.
----------------------
Pour les majuscules, je m'y suis fait, c'est une décision ferme de Benoit, qui y est très attaché, et l'impression que le langage nous gueule dessus choque des gens habitué à communiquer en chat, ce qui n'est pas du tout dans sa culture, d'où le fait que ça ne lui ait jamais effleuré l'esprit.
---------------------
Je pense aussi pour ma part qu'il est important qu'un langage contraigne le codeur, et meme si peut penser que cela le limite, c'est plus souvent pour son bien (et surtout le bien de l'ensemble de gens qui code dans ce langage et qui donc ont un besoin imperieux de partager certaines convention critique de lecture/ecriture du code)
--------------------
la possibilité qu'une fonction rende plusieurs valeurs, comme dans les langages fonctionnels.
-------------------
Heu, je serais plutot en desaccord, ou je ne connais pas de langage retournant plusieur valeur. Peux tu m'eclairer la dessus car en reflechissant a quoi cela pourrait ressembler, je ne m'en fait pas du tout une idée possitive.
Je trouve aussi personnellement que que Lissac a une syntaxe particulierment rebutante. Mais, comme le souligne Moonz qui dit que "j'aime bien le concept, mais la syntaxe me fait fuir", il est important de ne pas s'arreter a la seule syntaxe mais de bien comprendre ce que le langage peut amener de nouveau ou d'interessant.
En fait cela m'a rappelé une reflexion qu'a eu Wadler lorsqu'il a travaillé à poser les bases de haskell.
------------------
My experience on the Haskell committee caused me to formulate 'Wadler's Law': time spent in debating a feature doubles as one moves down the following list:
Je trouve cette reflexion particulierement interessante. Je trouve d'ailleur qu'il est plus souvent question dans ce fil de discussion de syntaxe que reflexion sur la difference semantique des langages et le rapport de cette semantique avec le besion de faire des boucles.
Ensuite, c'est ma vie ;-), mais j'aime bien la syntaxe d'haskell ;-) , même si c'est ce qu'il y a derriere que je trouve d'encore plus interessant (transparence referencielle, concept des monads, evaluation paresseuse, etc...).
Je voulais enfin demander à Ontologia ce qu'il pense de la syntaxe de Lissac en dehors de toute autre consideration sur le langage. Je suis curieux et ouvert à son avis car je me demande ce qui peut plaire aux personnes dans cette syntaxe.
PS : Pour en revenir sur le sujet de ce journal, il est interessant de voir que haskell ne presente tout simplement pas de probleme de boucle tels que presentés dans ce journal (je precise que j'entend ici boucle de controle au sens imperatif) car le langage n'en permet pas
(meme si il est possible de construire certaine fonction qui denote le fonctionnement de telle boucle, via les monades, mais bon).
> Le pire de tout c'est le 1:N , dans ce cas là grosso-modo c'est quasiment
> comme si les threads n'existait pas. Tout se dérouel en userland et totu est
> rattaché au même processus (donc au même thread kernel, donc au même CPU)
tout depend du point de vu et surtout de l'usage que l'on fait des threads.
Ainsi que je le disait precedement, les threads permettent d'offrir aux programmeurs un acces au paradigme de la programmation concurente qui peut s'averer plus adapté pour ecrire certains types de programmes.
Dans ce cas la, la gestion des threads en 1:N est bien souvent celle qui permet la gestion la plus fine pour le scheduler. Ainsi si tu considere la simulation d'un tres grand nombre d'entités et que tu a un imperatif de reactivité, ce mode est le plus adapté.
Je me pose d'ailleur une question : est il si simple de savoir si l'on gere plusieurs threads legers (géré par le langage ou user-land si on veut) en mode 1:N.
Apres tout lorsqu'on programme, le runtime du langage sur lequel on repose
peut tout a fait switcher plusieurs threads legers (si le langage integre bien sur les threads leger en interne, ce qui est loin d'être le cas de tout les langages) sur plusieurs threads kernell (process) si cela lui lui semble plus adapté à l'archi sur laquelle il repose, par exemple si le code s'execute sur du multi-core.
Il n'est en effet pas a la charge du programmeur d'un langage haut niveau de s'adresser directement à l'un ou l'autre des coeurs.
Donc au final pour arriver à la fin de cette digression alambiquée (c'est confu dans ma tete aussi) la gestion des threads par le kernel en 1:1 ne pose aucun probleme particulier, et n'empeche pas necessairement les langages qui permettent de faire de manière interne du 1:N d'un coté et de faire usage des threads kernel de l'autre, d'optenir du M:N.
Un langage generaliste moderne doit donc pouvoir offrir les moyens de programmer aisement de manière concurrente et ceci en permettant de gerer des threads user-land ET kernel-land.
Je pense au langage Haskell et plus particulierement à l'implementation GHC de celui-ci, pour laquelle une active discussion est mené pour gérer la concurrence.
Bon sur les produit microsoft et la suite office en particulier, je comprend tout a fait ce que tu veux dire, mais pour ma part je ne me permettrait pas de dire que ce sont des produit *pourri*.
Imaginons un exemple utopique qui ferait que la suite office est gratuite. Pourquoi cette exemple, parceque le prix ou il la commercialise est a mon sens la seule chose veritablement pourri dans cette histoire. Et bien si office etait gratuit, pourrais tu encore te permettre de dire qu'elle est pourri ? Si oui la suite OpenOffice l'est encore plus. Paradoxalement toutes les suites de ce genre seraient aussi pourries les unes que les autres mais n'ayant pas mieux tout le monde s'en servirait !
Donc pour ma part je trouve qu'en dehors du prix, la suite office est quand meme un produit de qualité. (de toute facon je doit reconnaitre que je fait du latex + beamer + gnumeric donc je ne suis peut etre pas tres connaiseeur des faiblesse reel des produit microsoft).
Sur C#, oui il se sont largement inspiré de Java. En même temps Java ne s'etait pas beaucouop genné pour repomper dans d'autre langage. Pour être honnete Sun avec toute sa force commerciale n'a pas fait plus avec Java que reusir à introduire dans le monde de l'industrie des idées et des outils deja connus et utilisés, mais a trop petite echelle.
Depuis l'arrivé de C#, Sun a d'ailleur enfin fait evolué Java, en tout cas un peu plus qu'a l'allure de pacha qu'avant C#. Le coup du boxing unboxing manuel des types primitifs dans des objets etait tout simplement scandaleux. Maintenant on a une belle concurence Java/C# qui amenne à de nombreuses avancés, ce dont je me rejouit pleinement. Mais je continue aussi de penser que C# evolue pieux et plus vite que Java.
juste pour la reference a l'asm dans les jeux,
epic game (moteur d'Unreal) n'en utilise pas du tout !
Je pensais avant que cela s'averai indispensable aussi, mais
connaissant maintenant les faits, je veux bien comprendre aussi
pourquoi il est délirant de vouloir se servir d'asm dans le cas
de projet aussi ambitieux et accesoirement multiplateforme.
A lire ! tres interessantes remarque sur les contraintes des jeux video et comment epic games y refechit.
> Et jusqu'à preuve du contraire, citer un future
> échec^W^W^Wproduit Microsoft comme référence
> sur linuxfr est du plus profond mauvais goût...
Ce genre de remarque me fais souvent plus pitié que sourir...
Confondre la politique general de microsoft, certain produit (et encore dans l'ensemble il est completement idiot de dire que leurs produits sont pourris, tout au plus certain de leur aspect ne te plaise pas comme le prix mais de la a denigrer systematiquement sans avoir aucun argument) avec ce sur quoi il sont en train de travailler je trouve ca domage.
Peux tu vraiment affirmer que C#/.Net soit un echec.
A mon gout c'est l'un des effort les plus intéressants issue de chez microsoft. Je trouve C# et tout particulierement le futur de celui-ci avec LINQ tout a fait enthousiasmant.
Il est capital que l'industrie informatique aille dans ce sens plutot que dans le tiens et tant pis (ou tant mieux) si ca fait de microsoft.
Maintenant regarde un peu singularity (et SING# comme langage formel de plus bas niveau) et tu pourra être etonné.
pour commencer, je peux me tromper dans ce que je dis, et je suis heureux de pouvoir discuter de ceci.
Je parlais bien cependant de la NPTL quand je disais que chaque thread etaient en fait encapsulé dans un process.
La NPTL semble surtout ensuite apporter certaine primitive de synchronisation entre les threads(process) crées.
j'ai tenu a verifier et dans WikiPedia http://en.wikipedia.org/wiki/NPTL
(qui bien sur n'est pas parole d'evengile, mais bon) je lis :
NPTL uses a similar approach to LinuxThreads, in that the primary abstraction known by the kernel is still a process, and new threads are created with the clone() system call (called from the NPTL library). However, NPTL requires specialized kernel support to implement (for example) the contended case of synchronisation primitives which might require threads to sleep and be re-awoken. The primitive used for this is known as a futex.
NPTL is a so-called 1×1 threads library, in that threads created by the user (via the pthread_create() library function) are in 1-1 correspondence with schedulable entities in the kernel (processes, in the Linux case). This is the simplest possible threading implementation.
Maintenant je peux me meprendre sur certain point et je suis ouvert a toutes discussions.
Pour ce qui est des jeux et en imaginant que la boite qui produit le moteur de unreal (epic games) puisse etre considerée comme digne d'interet, alors je dirais que le futur des jeux video ne passera pas par le C/C++ mais effectivement pas des langages plus proche de Caml/Haskell/etc ...
Pour ce qui est des kernels, et en considerant que les temps actuels sont au retour des micro-kernel (bon quelque année encore mais les derniers propos de Tannenbaum et les recent travaux de microsoft sur singularity semble aller dans ce sens) alors je dirais que oui oui il se pourrait que hors le micro-kernel proprement dit (qui sera surement en C puisque pour une fois que le C est le langage le plus adapté pour quelque chose, à savoir attaquer le hardware au plus bas niveau) la majorité du noyau (j'englobe tout cette fois ci, systeme de fichier, etc ... ) soit surement dans des langage de plus haut niveau (C#/...)
> ben l'api des thread posiw est pas vraiment complexe .... bon c'est
> sur tu geres tous les access toi même mais je dirai chiant ou long
> mais pas compliqué .
La gestion des threads en C/C++ est compliqué par le fait que ces deux langages ne possede aucune primitives de concurence et de gestion des threads en interne.
Si effectivement au premier abord tu peux avoir l'impression que ce n'est pas si compliqué de faire du multithread en C/C++, le fait est que dans le cas d'applications réelles (autre que toy-app) le programmeur se trouve confronté à de nombreux bugs, non reproductibles, très difficille à trouver et encore plus à éliminer.
> "Ou alors, les threads sont indépendants, et alors, pourquoi en
> utiliser en premier lieu ?" ben pour parallèliser le traitement
> ( archi multi-proc tous ca ... )
Les threads peuvent en effet etre utilisé pour accelerer certain traitement. Mais ceci n'est qu'un cas particulier de leur utilisation.
De mon point de vu, les threads permettent surtout d'offrir aux programmeurs un acces au paradigme de la programmation concurente.
L'intérêt n'est pas d'aller plus vite, c'est surtout de coder plus simplement certain type de probleme très complexe qui se pretent mieux à mode de pensée.
> et pourquoi pas des fork a la place? ben histoire de changement
> de contexte plus court ...
Sache que sous Linux processus et thread sont pour ainsi dire la meme chose (Ce n'est pas le cas sur tout les OS, et Solaris possede une gestion des threads réellement intéressante).
Ce sont dans les fait des processus kernel-land avec comme seul difference que pour les threads ces processus partage le même espace mémoire. le scheduling se fait ensuite par le kernel comme n'importe quel process et "quasiment" à la même vitesse.
Voir ainsi l'appel system clone
$ man clone =>
NAME
clone - create a child process
DESCRIPTION
clone creates a new process, just like fork(2).
...
The main use of clone is to implement threads: multiple threads
of control in a program that run concurrently in a shared
memory space.
Il me semble que fork (...) fait appel à clone dans les fait
De l'époque de ses debuts, ou on se moquait de ces perfs tres tres mauvaises
à aujourd'hui ou elles sont parfaitement correctes pour un framework de cette
taille et avec toutes les fonctionnalités qu'il porte.
A chaque version SUN nous ressortait le coup de vous voyez bien ça va
2 fois plus vite aujourd'hui que hier et maintenant on va vous montrer des
benchs qui demontre que Java ça va plus vite que tout les autres.
Au final, Java aura honnetement mis 10 à arriver à des perfs plus plus honorable,
et je vois mal ce que tu pourrais alors reprocher à mono.
Parceque le C est l'un des langages les plus proche de la machine après l'assembleur (je pense que le fortran est à placer entre les deux ) et qu'a ce titre il est l'un des plus apte à en tirer le meilleur parti celui de la machine.
Le revers de la médaille c'est que tu programme à très bas niveau et qu'a ce titre
tu a à te preoccuper de détail dont dans une très grande majorité des cas tu aimerai
ne pas avoir à gerer. Ainsi il ne faut pas s'etonner du nombre de buffer overflow
issue de certain programme en C (ou autre) par rapport à d'autre ecrit en Java.
Donc dire que OCaml est derrière le C en terme de vitesse n'est pas clair. Qu'est ce qui est plus rapide en C qu'en OCaml ? De mon avis, on est par exemple beaucoup plus rapide à ecrire un programme en OCaml qu'en C.
Et puis il suffit de gouter au systeme de typage à la ML pour comprendre le plaisir
que l'on peut avoir à coder en OCaml.
Si Ocaml est encore derriere le C en terme de performence dans le cas d'application
tres pointues, cest parceque par ailleur il offre un confort d'utilisation sans commune mesure vis a vis de celui ci, et que ce confort passe a travers l'utilisation d'un machine virtuelle qui naturellement prend des resources.
Si OCaml et Haskell possedent tous les deux un moteur de type à la ML
leurs differences sont profondes.
- OCaml est un langage fonctionnel à évaluation stricte et possède par la même occasion des traits impératifs. Le fait que celui-ci melange les deux approche, le rend particulierement agreable à utiliser, on a les avantages des fonctions d'ordre superieurs et du moteur d'inference de type avec la simplicité de la programmation impérative (que certains trouverons plus naturel et plus simple).
- Haskell est un langage fonctionnel à évaluation paresseuse qui lui ne possede "aucun" aspect impératif. En theorie il ne possede donc aucune des caractéristiques presente sur une machine VonNeuman (pas d'allocation, pas de structure de controle de l'execution...). En cela on dit souvent que c'est un langage fonctionnel "pur". Ces aspects le rende assez difficile au premier abord, voir rebuterons même les plus motivés. C'est essenciellement un langage de recherche, même si il commence à être utilisable dans le cas d'application plus courante.
# "computer music" Avec Haskore
Posté par brouillon . En réponse au journal Petit soft utile pour les musiciens. Évalué à 3.
Dans le cas de Haskore(1), il s'agit d'un langage de programmation purement fonctionnel (Haskell) qui permet de décrire la musique qui sera créer/jouer.
Je laisse au créateur Haskore le soin de le décrire :
"Haskore is a collection of Haskell modules designed for expressing musical structures in the high-level, declarative style of functional programming. In Haskore, musical objects consist of primitive notions such as notes and rests, operations to transform musical objects such as transpose and tempo-scaling, and operations to combine musical objects to form more complex ones, such as concurrent and sequential composition. From these simple roots, much richer musical ideas can easily be developed."
Un aspect intéressant de Haskore est aussi qu'il repose sur l'approche DSEL (2) qui permet d'exploiter directement la puissance du langage sur lequel on repose (declaratif, typage fort, dynamiquemant typé, d'ordre supperieur, intérpreté ou compilé, ...) pour exprimer des chose dans un style proche du domaine qu'on a ciblé.
Il n'y a donc
- ni parsing d'un fichier à partir d'un programme écrit dans un langage plus généraliste
(le contenu du fichier parsé est alors souvent simpliste et limité en terme d'expressivité)
- ni de création d'un nouveau langage (très difficile et pas toujours très concluant par rapport à ).
- ni même de codage direct dans un langage généraliste (même si l'approche DSEL pourrait le faire croire, ce n,'est pas le cas)
Un autre exemple de cet approche est Fran(3). C'est un peu vieux mais c'est très intéressant de voir comment décrire des animations peut devenir simple et relativement naturel avec un langage à la base généraliste, mais qu'on a 'spécialisé' à la définition de ces animations. Regardez le tutorial (4), je le trouve super.
PS : cette approche (DSEL) n'est pas restreinte à Haskell, et peut être implémenter dans de nombreux autres langages généraliste.
Le langage Haskell présente cependant certaines qualités qui le rende particulièrement adapté à cet usage (par exemple pouvoir definir de nouveaux opérateur est bien venu dans cet optique).
1 : http://www.haskell.org/haskore/onlinetutorial/index.html
2 : http://www.iue.tuwien.ac.at/phd/heinzl/node33.html
3 : http://conal.net/fran/
4 : http://conal.net/fran/tutorial.htm
[^] # Re: confus
Posté par brouillon . En réponse au journal Publication de Parrot 1.0. Évalué à 4.
Mais l'idée de pouvoir 'simplement' réutiliser dans un langage (e.g. perl) des composants écrits dans un autre langage (e.g. python), je trouve ca vraiment très intéressant.
[^] # Re: Anubis et les "catégories bicartésiennes fermées"
Posté par brouillon . En réponse à la dépêche Sortie de la version 2.5 du langage Tom. Évalué à 1.
pas trop ouvert comme attitude :
"En fait la distribution est personalisée (c'est un système expérimental anti-pirates en vue d'une commercialisation éventuelle). C'est la raison pour laquelle l'inscription est nécessaire. Ce serait dommage de vous priver d'Anubis pour si peu de chose. Il est quand même gratuit."
... ouais ouais gratuit ... c'est cela ...
Je ne pense pas que ce soit une bonne chose de chercher à "commercialiser" des langage aussi experimentaux.
Il me semble au contraire plus intéressant de liberer completement
ces langages de manière permettre à une communauté de se créer dessus et à le faire réellement exister et se repandre.
Il me semble d'ailleur que nombres de langages se sont saborder en devenant "commerciaux" .
[^] # Re: Ruby
Posté par brouillon . En réponse au journal A mort les boucles. Évalué à 1.
Oui mais justement, en maths "f(x) = x + x" c'est pas une déclaration de fonction, c'est pas grand chose. Pour déclarer une fonction on fait ça proprement (Soit f : x -> x + x) ou avec une équation (Soit f telle que pour tout x, f(x) = x + x), mais on balance jamais "f(x) = x + x", c'est pas rigoureux.
---------
Oui effectivement le terme definir n'etait peut etre pas le plus adapté (j'ai penser à denoter ce qui me paraissait meilleur mais 1) n'etant pas plsu sur 2 ) toruvant cela un peu pompeux , je gardais definir).
Cependant, j'ai ecris
f x = x + x
car, je reprenais l'exemple de ce qui se fait en haskell.
pour parler de ce que je connais en haskell, et cela semble propre selon ce que tu dis, on aurait pu ecrire :
f :: a -> a
f x = x + x (pareil que f (x) = x + x)
(c'est presque ce que j'ecrivais a l'ecole me semble t'il)
ou meme
f :: forall a. a -> a
f x = x + x
mais dans les faits je trouve bien aussi qu'un langage INFORAMTIQUE me trouve tout seul le type de la fonction que j'ai ecrit ou me dise si le type de la fonction n'est pas bien typé, ambigue, ou qu'il a besion d'information complementaire.
Apres tout meme si ce n'ai pas tres rigoureux, je n'imagine pas qu'un mathematicien ne se permette pas de temps a autre et lorsqu'aucun doute n'est permis, d'ecrire ce genre de chose ;-)
f (x) = a x² + b x + c
delta = b² - 4ac
mais je me trompe peut etre.
toujours est il que dans le cadre d'un langage inforamtique je trouve tres agreable la maniere dont on peut 'poser' ces fonctions, et encore plus magique le fait que celles ci soient referentiellement transparente , c'est a dire exemptes de tout effet de bord.
Je ne suis pas mathematicien et j'ai (et continue) de coder en C++ mais haskell m'a veritablement apaisé dans ma maniere de coder et considerer les problemes informatiques (que ceux ci soient bas niveau ou haut niveau, l'important reste de toujours penser dans les termes de ce problemes (et d'ailleur le c/c++ est difficile pour ca mais java / etc ne s'en sortent pas toujours tellement mieux ) ).
pour les tuples en retour je suis d'accord avec toi , ca reste une valeur de retour unique (ou je n'ai pas bien saisie alors)
[^] # Re: Ruby
Posté par brouillon . En réponse au journal A mort les boucles. Évalué à 1.
Ne le prend pas mal hein, c'est juste la maniere dont tu defend certains avis :
------------
Ca doit donc servir aux tests et à rien d'autres.
Le reste c'est de la bidouille.
------------
Je déteste le concept du = et ==
------------
Or je parlais du fait que justement
------------
Je trouve aussi personnellement que que Lissac a une syntaxe particulierment rebutante.
------------
mais que j'etais ouvert aux argument de personne qui la trouve bien, et c'est d'ailleur pourquoi je te demandais ton avis (je me permet de te tutoyer aussi)
C'est pour quoi je te trouve dur et radical envers des gens qui partent justement du fait qu'il 'deteste' la syntaxe de Lissac.
Mais bon, ceci n'est que digression et j'entend bien tes arguments :-)
Cependant, quelque petites choses :
----------
J'ai été très marqué par Pascal, qui m'a beaucoup marqué, c'est pour cela que j'aime le ':='
----------
vi, tout a fait d'accord, c'est important dans un langages imperatif d'avoir fait cette distinction avec le '=' de la logique ou des maths (je me demande en fait si il s'agit bien du meme ? je n'arrive pas encore a me decider)
-----------
Je déteste le concept du = et ==
Un égale '=' mathématiquement, c'est une reflexion binaire réflexive, symétrique, transitive, antisymétrique. Point barre.
Un égale est donc une opération
'a * 'a -> bool
Ca doit donc servir aux tests et à rien d'autres.
-------
justement c'est la que je decroche, si justement on considere que '=' c'est mathematique (c'est une reflexion binaire réflexive, symétrique, transitive, antisymétrique. ) e.g. f (x) = x * x, je ne vois pas necessairement pourquoi ca ne servirait qu'au test et rien d'autre ???
prend le cas du lambda calcul. si tu dit que
f (x) = x + x (x etant un reel par exemple)
ce n'ai pas pour faire quelque test que ce soit, mais juste pour definir la fonction f (de type R -> R ).
mais c'est la meme chose si tu dis
ma_variable = 42
si on considere que ma_variable est un variable mathematique , non ?
ainsi
f(ma_varaible)
sera juste reduite en
ma_variable * ma_variable
il n'y a donc ni affectation (pour laquel l'operateur ':=' qui a ete crée pour ca est bien plus parlant ), ni test.
et d'aileur en fonctionnel on peut aussi avoir besion du ==
is_zero n = n == 0
ensuite le (truc avec trois barre qu'on utilise en marth et que je ne sais pas ecrire ici :-) ) serait peut etre plus judicieux mais pas utilisable en ascii donc je le trouve tres bien ce == pour un test d'egalité.
d'ou ma reponse : je n'ai rien contre = et == bien au contraire.
----------------------
Pour les majuscules, je m'y suis fait, c'est une décision ferme de Benoit, qui y est très attaché, et l'impression que le langage nous gueule dessus choque des gens habitué à communiquer en chat, ce qui n'est pas du tout dans sa culture, d'où le fait que ça ne lui ait jamais effleuré l'esprit.
---------------------
Je pense aussi pour ma part qu'il est important qu'un langage contraigne le codeur, et meme si peut penser que cela le limite, c'est plus souvent pour son bien (et surtout le bien de l'ensemble de gens qui code dans ce langage et qui donc ont un besoin imperieux de partager certaines convention critique de lecture/ecriture du code)
--------------------
la possibilité qu'une fonction rende plusieurs valeurs, comme dans les langages fonctionnels.
-------------------
Heu, je serais plutot en desaccord, ou je ne connais pas de langage retournant plusieur valeur. Peux tu m'eclairer la dessus car en reflechissant a quoi cela pourrait ressembler, je ne m'en fait pas du tout une idée possitive.
voila, au plaisir
[^] # Re: Ruby
Posté par brouillon . En réponse au journal A mort les boucles. Évalué à 2.
En fait cela m'a rappelé une reflexion qu'a eu Wadler lorsqu'il a travaillé à poser les bases de haskell.
------------------
My experience on the Haskell committee caused me to formulate 'Wadler's Law': time spent in debating a feature doubles as one moves down the following list:
* Semantics
* Syntax
* Lexical syntax
* Lexical syntax of comments
------------------
Je trouve cette reflexion particulierement interessante. Je trouve d'ailleur qu'il est plus souvent question dans ce fil de discussion de syntaxe que reflexion sur la difference semantique des langages et le rapport de cette semantique avec le besion de faire des boucles.
Ensuite, c'est ma vie ;-), mais j'aime bien la syntaxe d'haskell ;-) , même si c'est ce qu'il y a derriere que je trouve d'encore plus interessant (transparence referencielle, concept des monads, evaluation paresseuse, etc...).
Je voulais enfin demander à Ontologia ce qu'il pense de la syntaxe de Lissac en dehors de toute autre consideration sur le langage. Je suis curieux et ouvert à son avis car je me demande ce qui peut plaire aux personnes dans cette syntaxe.
PS : Pour en revenir sur le sujet de ce journal, il est interessant de voir que haskell ne presente tout simplement pas de probleme de boucle tels que presentés dans ce journal (je precise que j'entend ici boucle de controle au sens imperatif) car le langage n'en permet pas
(meme si il est possible de construire certaine fonction qui denote le fonctionnement de telle boucle, via les monades, mais bon).
[^] # Re: Y'a pire :)
Posté par brouillon . En réponse au journal Perl/Linux nightmare.. Évalué à 2.
[^] # Re: ...
Posté par brouillon . En réponse à la dépêche Erlang/OTP R11B supporte les architectures multiprocesseur. Évalué à 4.
> comme si les threads n'existait pas. Tout se dérouel en userland et totu est
> rattaché au même processus (donc au même thread kernel, donc au même CPU)
tout depend du point de vu et surtout de l'usage que l'on fait des threads.
Ainsi que je le disait precedement, les threads permettent d'offrir aux programmeurs un acces au paradigme de la programmation concurente qui peut s'averer plus adapté pour ecrire certains types de programmes.
Dans ce cas la, la gestion des threads en 1:N est bien souvent celle qui permet la gestion la plus fine pour le scheduler. Ainsi si tu considere la simulation d'un tres grand nombre d'entités et que tu a un imperatif de reactivité, ce mode est le plus adapté.
Je me pose d'ailleur une question : est il si simple de savoir si l'on gere plusieurs threads legers (géré par le langage ou user-land si on veut) en mode 1:N.
Apres tout lorsqu'on programme, le runtime du langage sur lequel on repose
peut tout a fait switcher plusieurs threads legers (si le langage integre bien sur les threads leger en interne, ce qui est loin d'être le cas de tout les langages) sur plusieurs threads kernell (process) si cela lui lui semble plus adapté à l'archi sur laquelle il repose, par exemple si le code s'execute sur du multi-core.
Il n'est en effet pas a la charge du programmeur d'un langage haut niveau de s'adresser directement à l'un ou l'autre des coeurs.
Donc au final pour arriver à la fin de cette digression alambiquée (c'est confu dans ma tete aussi) la gestion des threads par le kernel en 1:1 ne pose aucun probleme particulier, et n'empeche pas necessairement les langages qui permettent de faire de manière interne du 1:N d'un coté et de faire usage des threads kernel de l'autre, d'optenir du M:N.
Un langage generaliste moderne doit donc pouvoir offrir les moyens de programmer aisement de manière concurrente et ceci en permettant de gerer des threads user-land ET kernel-land.
Je pense au langage Haskell et plus particulierement à l'implementation GHC de celui-ci, pour laquelle une active discussion est mené pour gérer la concurrence.
[^] # Re: Eheh
Posté par brouillon . En réponse à la dépêche Erlang/OTP R11B supporte les architectures multiprocesseur. Évalué à 4.
Imaginons un exemple utopique qui ferait que la suite office est gratuite. Pourquoi cette exemple, parceque le prix ou il la commercialise est a mon sens la seule chose veritablement pourri dans cette histoire. Et bien si office etait gratuit, pourrais tu encore te permettre de dire qu'elle est pourri ? Si oui la suite OpenOffice l'est encore plus. Paradoxalement toutes les suites de ce genre seraient aussi pourries les unes que les autres mais n'ayant pas mieux tout le monde s'en servirait !
Donc pour ma part je trouve qu'en dehors du prix, la suite office est quand meme un produit de qualité. (de toute facon je doit reconnaitre que je fait du latex + beamer + gnumeric donc je ne suis peut etre pas tres connaiseeur des faiblesse reel des produit microsoft).
Sur C#, oui il se sont largement inspiré de Java. En même temps Java ne s'etait pas beaucouop genné pour repomper dans d'autre langage. Pour être honnete Sun avec toute sa force commerciale n'a pas fait plus avec Java que reusir à introduire dans le monde de l'industrie des idées et des outils deja connus et utilisés, mais a trop petite echelle.
Depuis l'arrivé de C#, Sun a d'ailleur enfin fait evolué Java, en tout cas un peu plus qu'a l'allure de pacha qu'avant C#. Le coup du boxing unboxing manuel des types primitifs dans des objets etait tout simplement scandaleux. Maintenant on a une belle concurence Java/C# qui amenne à de nombreuses avancés, ce dont je me rejouit pleinement. Mais je continue aussi de penser que C# evolue pieux et plus vite que Java.
[^] # Re: Eheh
Posté par brouillon . En réponse à la dépêche Erlang/OTP R11B supporte les architectures multiprocesseur. Évalué à 2.
epic game (moteur d'Unreal) n'en utilise pas du tout !
Je pensais avant que cela s'averai indispensable aussi, mais
connaissant maintenant les faits, je veux bien comprendre aussi
pourquoi il est délirant de vouloir se servir d'asm dans le cas
de projet aussi ambitieux et accesoirement multiplateforme.
[^] # Re: Eheh
Posté par brouillon . En réponse à la dépêche Erlang/OTP R11B supporte les architectures multiprocesseur. Évalué à 3.
Et alors, en quoi ce que j'ai dit te géne ? je me cite
"je dirais que le FUTUR des jeux video ne passera pas par le C/C++"
^^^^
C'est sur je ne dis pas quand, et je ne m'avancerai pas la dessus ;-)
Maintenant je reconnais que j'avais oublié la ref :
http://www.st.cs.uni-sb.de/edu/seminare/2005/advanced-fp/doc(...)
A lire ! tres interessantes remarque sur les contraintes des jeux video et comment epic games y refechit.
> Et jusqu'à preuve du contraire, citer un future
> échec^W^W^Wproduit Microsoft comme référence
> sur linuxfr est du plus profond mauvais goût...
Ce genre de remarque me fais souvent plus pitié que sourir...
Confondre la politique general de microsoft, certain produit (et encore dans l'ensemble il est completement idiot de dire que leurs produits sont pourris, tout au plus certain de leur aspect ne te plaise pas comme le prix mais de la a denigrer systematiquement sans avoir aucun argument) avec ce sur quoi il sont en train de travailler je trouve ca domage.
Peux tu vraiment affirmer que C#/.Net soit un echec.
A mon gout c'est l'un des effort les plus intéressants issue de chez microsoft. Je trouve C# et tout particulierement le futur de celui-ci avec LINQ tout a fait enthousiasmant.
Il est capital que l'industrie informatique aille dans ce sens plutot que dans le tiens et tant pis (ou tant mieux) si ca fait de microsoft.
Maintenant regarde un peu singularity (et SING# comme langage formel de plus bas niveau) et tu pourra être etonné.
[^] # Re: ...
Posté par brouillon . En réponse à la dépêche Erlang/OTP R11B supporte les architectures multiprocesseur. Évalué à 6.
Je parlais bien cependant de la NPTL quand je disais que chaque thread etaient en fait encapsulé dans un process.
La NPTL semble surtout ensuite apporter certaine primitive de synchronisation entre les threads(process) crées.
j'ai tenu a verifier et dans WikiPedia
http://en.wikipedia.org/wiki/NPTL
(qui bien sur n'est pas parole d'evengile, mais bon) je lis :
NPTL uses a similar approach to LinuxThreads, in that the primary abstraction known by the kernel is still a process, and new threads are created with the clone() system call (called from the NPTL library). However, NPTL requires specialized kernel support to implement (for example) the contended case of synchronisation primitives which might require threads to sleep and be re-awoken. The primitive used for this is known as a futex.
NPTL is a so-called 1×1 threads library, in that threads created by the user (via the pthread_create() library function) are in 1-1 correspondence with schedulable entities in the kernel (processes, in the Linux case). This is the simplest possible threading implementation.
Maintenant je peux me meprendre sur certain point et je suis ouvert a toutes discussions.
[^] # Re: Eheh
Posté par brouillon . En réponse à la dépêche Erlang/OTP R11B supporte les architectures multiprocesseur. Évalué à 3.
Pour ce qui est des kernels, et en considerant que les temps actuels sont au retour des micro-kernel (bon quelque année encore mais les derniers propos de Tannenbaum et les recent travaux de microsoft sur singularity semble aller dans ce sens) alors je dirais que oui oui il se pourrait que hors le micro-kernel proprement dit (qui sera surement en C puisque pour une fois que le C est le langage le plus adapté pour quelque chose, à savoir attaquer le hardware au plus bas niveau) la majorité du noyau (j'englobe tout cette fois ci, systeme de fichier, etc ... ) soit surement dans des langage de plus haut niveau (C#/...)
[^] # Re: ...
Posté par brouillon . En réponse à la dépêche Erlang/OTP R11B supporte les architectures multiprocesseur. Évalué à 8.
> sur tu geres tous les access toi même mais je dirai chiant ou long
> mais pas compliqué .
La gestion des threads en C/C++ est compliqué par le fait que ces deux langages ne possede aucune primitives de concurence et de gestion des threads en interne.
Si effectivement au premier abord tu peux avoir l'impression que ce n'est pas si compliqué de faire du multithread en C/C++, le fait est que dans le cas d'applications réelles (autre que toy-app) le programmeur se trouve confronté à de nombreux bugs, non reproductibles, très difficille à trouver et encore plus à éliminer.
Le gestion des threads à travers une bibliotheque est d'ailleur très critiquée. voir :
"Threads Cannot be Implemented as a Library"
http://www.hpl.hp.com/techreports/2004/HPL-2004-209.html
qui en detaille les raisons
> "Ou alors, les threads sont indépendants, et alors, pourquoi en
> utiliser en premier lieu ?" ben pour parallèliser le traitement
> ( archi multi-proc tous ca ... )
Les threads peuvent en effet etre utilisé pour accelerer certain traitement. Mais ceci n'est qu'un cas particulier de leur utilisation.
De mon point de vu, les threads permettent surtout d'offrir aux programmeurs un acces au paradigme de la programmation concurente.
L'intérêt n'est pas d'aller plus vite, c'est surtout de coder plus simplement certain type de probleme très complexe qui se pretent mieux à mode de pensée.
> et pourquoi pas des fork a la place? ben histoire de changement
> de contexte plus court ...
Sache que sous Linux processus et thread sont pour ainsi dire la meme chose (Ce n'est pas le cas sur tout les OS, et Solaris possede une gestion des threads réellement intéressante).
Ce sont dans les fait des processus kernel-land avec comme seul difference que pour les threads ces processus partage le même espace mémoire. le scheduling se fait ensuite par le kernel comme n'importe quel process et "quasiment" à la même vitesse.
Voir ainsi l'appel system clone
$ man clone =>
NAME
clone - create a child process
DESCRIPTION
clone creates a new process, just like fork(2).
...
The main use of clone is to implement threads: multiple threads
of control in a program that run concurrently in a shared
memory space.
Il me semble que fork (...) fait appel à clone dans les fait
[^] # Re: Amélioration des performances
Posté par brouillon . En réponse à la dépêche Interview De Icaza et actualité Mono. Évalué à 6.
De l'époque de ses debuts, ou on se moquait de ces perfs tres tres mauvaises
à aujourd'hui ou elles sont parfaitement correctes pour un framework de cette
taille et avec toutes les fonctionnalités qu'il porte.
A chaque version SUN nous ressortait le coup de vous voyez bien ça va
2 fois plus vite aujourd'hui que hier et maintenant on va vous montrer des
benchs qui demontre que Java ça va plus vite que tout les autres.
Au final, Java aura honnetement mis 10 à arriver à des perfs plus plus honorable,
et je vois mal ce que tu pourrais alors reprocher à mono.
[^] # Re: meuh
Posté par brouillon . En réponse au message Ecrire dans un fichier qui est dans $HOME. Évalué à 2.
permettent la concataination
exemple :
int i = 42;
string brol("toto");
ostringstream strbuf;
strbuf << i << " du texte " << brol << " et plein d'autres choses..." ;
// pour recuperer la string c++
string truc = strbuf.str();
// pour recuperer la chaine de caracteres C
const char* bidule = strbuf.c_str();
avec ceci tu peux donc tres simplement construire ton path
PS : l'utilisation de string avec buffer est en fait le comportement caché
utilisé lors de la concatenation de chaine de caracteres en Java.
[^] # Re: Cette librairie est géniale
Posté par brouillon . En réponse à la dépêche wxWidgets 2.6 est sorti. Évalué à 1.
Tu peux preciser stp.
[^] # Re: Lent ?
Posté par brouillon . En réponse à la dépêche Présentation d'OCaml à Rennes le jeudi 7 avril, 20h, MCE, 48 bd Magenta. Évalué à 2.
Le revers de la médaille c'est que tu programme à très bas niveau et qu'a ce titre
tu a à te preoccuper de détail dont dans une très grande majorité des cas tu aimerai
ne pas avoir à gerer. Ainsi il ne faut pas s'etonner du nombre de buffer overflow
issue de certain programme en C (ou autre) par rapport à d'autre ecrit en Java.
Donc dire que OCaml est derrière le C en terme de vitesse n'est pas clair. Qu'est ce qui est plus rapide en C qu'en OCaml ? De mon avis, on est par exemple beaucoup plus rapide à ecrire un programme en OCaml qu'en C.
Et puis il suffit de gouter au systeme de typage à la ML pour comprendre le plaisir
que l'on peut avoir à coder en OCaml.
Si Ocaml est encore derriere le C en terme de performence dans le cas d'application
tres pointues, cest parceque par ailleur il offre un confort d'utilisation sans commune mesure vis a vis de celui ci, et que ce confort passe a travers l'utilisation d'un machine virtuelle qui naturellement prend des resources.
[^] # Haskell VS OCaml
Posté par brouillon . En réponse à la dépêche Présentation d'OCaml à Rennes le jeudi 7 avril, 20h, MCE, 48 bd Magenta. Évalué à 2.
leurs differences sont profondes.
- OCaml est un langage fonctionnel à évaluation stricte et possède par la même occasion des traits impératifs. Le fait que celui-ci melange les deux approche, le rend particulierement agreable à utiliser, on a les avantages des fonctions d'ordre superieurs et du moteur d'inference de type avec la simplicité de la programmation impérative (que certains trouverons plus naturel et plus simple).
- Haskell est un langage fonctionnel à évaluation paresseuse qui lui ne possede "aucun" aspect impératif. En theorie il ne possede donc aucune des caractéristiques presente sur une machine VonNeuman (pas d'allocation, pas de structure de controle de l'execution...). En cela on dit souvent que c'est un langage fonctionnel "pur". Ces aspects le rende assez difficile au premier abord, voir rebuterons même les plus motivés. C'est essenciellement un langage de recherche, même si il commence à être utilisable dans le cas d'application plus courante.