Axioplase ıɥs∀ a écrit 3050 commentaires

Le matériel était effectivement adapté au langage utilisé pour logiciels qui tournaient dessus. C'était bien codé dans des LISPs à typage dynamique et avec GC.

Alors non, ce n'était pas dépourvu de bugs (car les dialectes de LISP étaient nombreux, et pas forcément aussi agréables que l'actuel Common Lisp), tout comme le rappelle Joe Marshall dans son très bon blog où il raconte des histoires de debuggage qu'il a vécues dans les années 80 [1].

Mais bon, les GC d'alors, c'était pas la panacée, hein. Ni les interprètes et compilateurs…

Sinon, tu dis : « De plus faut-il rappeler que les LISP sont généralement dynamiquement typés ? », mais je ne vois pas le rapport avec le GC. Enfin, avec le typage dynamique, tu as un tag sur tes données, donc le GC sais différencier un entier d'une adresse, une chaîne de caractères d'un symbole… Ça se nettoie très bien tout ça.
Puis le typage dynamique n'impose pas qu'on ne type rien ! T'as pleins d'optimisations de typage local, d'évaluation partielles qu'on peut faire quand même…

[1] : http://funcall.blogspot.com/2009/03/talk-to-greenblatt.html cette série d'articles s'étale sur plusieurs mois.

>> S'il faut un langage compilé pour obtenir de meilleures performances, pourquoi en faire un langage à gestion automatique de mémoire ?

Quel rapport entre la vitesse et la gestion de la mémoire ?

>> En plus avec un garbage collector, le côté "temps réel" est beaucoup plus délicat à assurer (typiquement on a beaucoup de mal à régler le moment où il doit se déclencher et les mauvais cas sont fréquents).

Ben, tu prends un GC temps-réel, et hop.
Ou alors un GC-hybride…
Choisir son GC fait aussi partie du développement d'une appli ou du choix d'un langage pour un problème donné…

>> Mais alors les langages de scripts les plus utilisés sont vraiment si lents que ça par rapport à du code compilé en natif mais avec peu d'optimisation ?

Ça dépend du langage. Perl, Python et Ruby sont des gros bousins que personne de sensé ne veut compiler, car la sémantique de ces langages est une horreur pour tout écrivain de compilateurs (attention, je ne dis pas que les langages sont des horreurs, juste leur sémantique). Inversement, Scheme se compile très bien…

Après, je te rappelle que les langages de scripts peuvent aussi se compiler, non seulement vers du code machine, mais aussi pour une VM…

>> Le touch pad qui ne marche plus, puis remarche, puis ne marche plus, puis remarche,

C'est comme les clignotants de ma voiture !
Une fois ils marchent, une fois ils marchent plus, une fois ils marchent, une fois ils marchent plus…

C'était combien de temps ?
Car 75 pages de présentation, avec beaucoupbeaucoup de redondance (car je fais pas la différence entre deux pages dont seul le checksum du commit change), c'est pas mal indigeste !
Je rententerai de lire tout ça plus tard, car là, ça m'a vite achevé…

Quel a été, objectivement, l'accueil du public ?

Ben, perso, moi qui ne suis pas *du tout* orienté matos, j'ai découvert ça avec le TP en question à l'époque. J'ai des préoccupations différentes quand je fais un programme, et du moment que mon algo est de même complexité que la solution optimale théorique, je suis content. La tenue des données en cache, c'est tellement rarement l'un de mes soucis que j'ai vite fait de n'en avoir plus rien à faire.

Évidemment, ça dépend de l'industrie dans laquelle tu travailles (et pour avoir lu ton parcours, je me doute bien qu'à toi, ça te parait évident), mais c'est à mon avis une évidence et un critère de développement pour moins de la moité des programmeurs.

D'autant plus que ce sont des optimisations qui ne sont pas forcément algorithmiques et qui ne sont valides que dans certains langages bas-niveau…

>> Le débat porte donc sur le fait que code plus court = code tenant mieux dans le cache code du processeur, donc meilleur exécution...

Des générations entières de programmeurs Fortran à la belle époque te remercie d'avoir rappelé le lien fort entre optimisations et matériel, notamment taille des caches du processeur.


-- 
Axioplase, qui avait eu un TP sur l'optimisation de code fortran dans un cours orienté compilation et matériel ^^

Le satellite s'appelle Simon Bolivar ?
C'est marrant !

Enfin, on a bien un porte avion Charles de Gaulle…

Que penses-tu de l'extension « scrapbook » pour firefox ?
Elle te permet même de ne sauver que les parties qui t'intéressent dans une page web…

La page : http://amb.vis.ne.jp/mozilla/scrapbook/index.php?lang=en
Une bonne grosse doc : http://amb.vis.ne.jp/mozilla/scrapbook/files/ScrapbookTutori(...)

>> Vivement un IDE

/me -> [  ]

>> - Pas de variable (trop variable :F)

main = let x = "etmonculcestdupoulet?" in putStrLn x

>> - Pas de notion d'objet (trop restrictif)

Objets et fermetures sont (grossièrement) isomorphes

>> - Essaie de réduire au maximum les effets de bord

Sur le papier.
En pratique, c'est pareil que partout ; simplement les utilisateurs vont préférer tout passer en paramètre plutôt que de stocker dans une variable (et en pratique, une monade State, c'est des effets de bords, sinon c'est pas super efficace)

>> - Permet de créer facilement des modules génériques et réutilisables

Comme partout. Quand t'es prêt à passer trois fois plus de temps à généraliser ton code que t'en as passé à le créer pour résoudre ton problème.


Bref, haskell (que j'adore), c'est pas la panacée, loin de là…
En revanche, c'est hype, ça donne le poil luisant et ça attire les financements anglo-saxons.

Encore une fois, le langage est un outil, et le langage X peut être super pour planter des clous, mais une bouse impossible pour tourner des vis.
Quand j'ai besoin de Haskell, je sors mon ghc, mais quand j'ai besoin de perl ou de postscript, je vais pas me faire chier avec haskell.

c'est qu'on aura des sites réservés aux gens qui ont une bonne orthographe, comme sur le futur http://hétérogénéité.accents.aig.us

Chez moi (ffmpeg 0.5@freebsd), ça marche très bien sur une entrée en avi, mais ça ne coupe pas une entrée en mkv.

Ouais, enfin, t'as des sites légitimes qui vont s'écrire avec « é » ( U+00C9) et d'autres avec « é » (U+0065 suivi de U+0308).

Et là, bonjour la sécurité (car bien sûr, tu crois que ta banque va te filer une clef publique la prochaine fois que tu iras au guichet et que les sites vont avoir une sécurité fiable ?)

Tu me files une pétition contre cette extension des noms, je signe de suite.

Il reste à traduire ".php" en arabe et en maya !

Le japonais autorise les écritures horizontales et verticales.
Et on trouvait même en son temps (jusque mi-XXème siècle) de l'horizontale de droite à gauche (le migiyokogaki, ça se fait encore pas pour les devantures de restaurants chics).

C'est bien connu, l'élève dépasse le maître.

Ça me fait cauchemarrer moi aussi (c'est le « LOL » d'halloween).

>> La liberté, c'est aussi la liberté de se branler. C'est bien, le libre: on peut faire n'importe quoi avec.

Donc la branlette est sous licence BSD ?
Car une branlette GPL, tu peux pas en faire profiter une prostituée (une méchante propriétaire qui ne partage pas ses techniques et qui cherche à niquer la concurrence pour amasser tous les sous).

>> phraset non plus

Mais je devine qu'il est en bépo ^^

Ouais mais bon, on parle plus d'apprendre à programmer là.
Moi aussi, j'ai ri/pleuré avec mes premiers cours de Scheme à la fac, alors que j'avais une formation autodidacte en ASM 80x86.
Puis un jour, j'ai eu des vrais trucs à coder, et j'ai appris la puissance de Scheme (et de CL) en pratique.

Pour les maths, t'as http://dynamo.iro.umontreal.ca/~gambit/wiki/index.php/Dumpin(...) qui te liste
1. Ising: Computer simulations of the Ising model of spins using the Metropolis algorithm or the Wolff algorithm.
2. BLAS: Thin wrapper for level 1, 2 and 3 BLAS linear algebra routines for the Gambit Scheme system.
3. LAPACK: Thin wrapper for higher-level linear algebra routines for the Gambit Scheme system.
4. FFTW3: A wrapper for some FFTW3 functions for the Gambit Scheme system. (real, complex, multi-dimensional FFT functions)

Aussi, vctlib is released into public domain (BSD license). It is not as optimized as BLAS and LAPACK are, but vctlib still delivers C-like performance for most operations.
http://carretechnologies.com/scheme/vctlib/

Bon, ben si je dois *intégrer* de l'algèbre linéaire dans une appli, je pense que je vais faire le choix Scheme (ou ML, ou autre. Mon langage de choix dépend souvent de l'approche que je vais suivre pour la résolution du problème, en fonction de la facilité avec laquelle je peux représenter mes données et contraintes).

Quand à Scheme/Lisp pour l'IA, c'était vrai pendant le boom de l'"Inintelligence Artificielle".
Maintenant, que la mode est passée, et qu'on s'est aperçu qu'un bot n'allait pas tromper un humain juste en embarquant un interprète Prolog, les gens utilisent beaucoup plus R (pour le calcul) ou Python (pour une raison qui m'échappe, mais je connais pas le langage).

>> Comme d'habitude avec vous que des affirmations mais pas de lien

A moins que tu ne méprises profondément ceux qui font de l'informatique (dans le sens scientifique du terme), http://www.plt-scheme.org/ est un bon exemple de recherche académique avec Scheme.

>> je n'ai jamais entendu parler d'un gros code en scheme.
>> ps: pas la peine de me filer des liens sur le scheme j'arrache les touches parentheses de me clavier des que je vois un truc s'en approchant...

Ha oui, en effet.
Pas étonnant que tu n'aies jamais vu de gros code en Scheme…

Tiens, un jeu très marrant : http://www.quantzgame.com/quantz-le-jeu.html

Dans le monde de la recherche, il existe la recherche sur les langages de prog : et alors des projets de recherche en Scheme, y en a pas mal (qui vont reposer sur MIT Scheme, Gambit-C, Larceny, etc)… T'as aussi HOP à l'INRIA.
Je connais aussi des matheux qui font du calcul symbolique en Scheme (et d'autres en CL)

Du Scheme, t'en as aussi dans la finance, dans la gestion d'universités…

En revanche, là où je suis d'accord, c'est
1/ que c'est pas "mainstream"
2/ que c'est rarement mis en avant par les boites


Je ne te dis pas non plus que c'est "classique", je te dis que tu peux considérer le langage si t'es pas borné.

Un langage à la sémantique simple, qui se compile efficacement, qui s'étend les doigts dans le nez pour en faire un DSL, qui permet la prog orientée objet, qui peut avoir des exceptions, un gestion complexe du flux d'exécution (via call/cc), des threads, de la prog distribuée, des bindings pour le web, le graphisme, l'IA, l'audio… des debuggers, des IDEs, etc…
J'estime qu'il faut être ignorant pour se dire que C est forcément mieux adapté pour développer un logiciel.
Et je ne dis pas non plus que Scheme est mieux que tout, je dis juste encore une fois que C n'est pas *du tout* la panacée, et qu'il serait mieux pour les programmeurs (et transitivement pour les utilisateurs) d'utiliser des langages un peu plus pratiques.

Si t'as pas envie de faire de calcul numérique en Scheme, je te rassure, moi non plus.
Et j'ai pas envie d'écrire un jeu vidéo en C non plus. Mais si certains sont prêts à se faire chier avec C pour coder un jeu, on peut consciemment se faire plaisir à faire du calcul en Scheme. Le temps que tu perds à l'exécution, tu le gagneras sans doute dans le temps de développement. Et encore une fois, tu peux embarquer du C dans la plupart des Schemes, pour tes endroits critiques.


Bref, si je n'arrive pas à te convaincre (de toute façon, j'ai autre chose à faire), je souhaite juste que tu comprennes que Scheme n'est pas un gadget, aussi mauvaise et limitée qu'ait pu être ton expérience avec.

Je parle pas de bugs en général, mais de bugs "car écrit en C".

Les bugs en question (segfaults, corruption de mémoire, bugs de format string), tu les retrouverais pas si tu codais dans un langage à peine plus haut niveau, sans pour autant perdre des poils de bite en rapidité/efficacité.

Les bugs "logiciels" (genre t'écrase ton fichier au lieu de faire un append), c'est une chose que je laisse faire comme un grand.
Tu fais l'algorithme, c'est déjà pas mal.

Encore une fois, je ne dis pas que C pue parcequ'il est bas niveau, je dis que bien des codeurs puent, car ils codent en C du code qui pue alors qu'ils pourraient faire aussi bien et avec moins de bugs (segfaults, corruption de mémoire, etc) s'ils prenaient un langage plus adapté à la programmation "générale" (en opposition à "système/bas-niveau").

Je pense qu'Ada est un "C-like" déjà super bien par exemple (avec en natif concurrence et POO pour ceux qui veulent). Je cherche pas à faire passer tout le monde à OCaml, je cherche juste à avoir des logiciels de qualités écrits dans un langage qui fait abstraction de l'endianness de la belle sœur du programmeur.

Wikipedia dit "Originally named the GNU C Compiler, because it only handled the C programming language, GCC 1.0 was released in 1987"

C'est chiant IPoT, t'en a toujours un pour te faire chier.
Bon, j'y vais, y a le Flic de Beverly Hills 2 qui vient de sortir au cinoche…

T'as souffert à l'UPMC ou bien ?
En tout cas, si tu compares Scheme à ce que tu as vu en 1ère année dans ton cours "programmation récursive", alors c'est comme si après avoir essayé ton tricycle offert pour tes 3 ans, tu revenais plus tard, blasé, en disant "la moto, c'est nul. En plus, personne ne peut monter à deux dessus. Je le sais, je l'ai *pas* vu."

Tu ne connais personne qui utilise Scheme, moi j'en connais plein !
D'ailleurs,
- du Scheme, j'en ai fait en entreprise (c'était pas scientifique, je vais pas te mentir).
- du Common Lisp, j'en ai fait en entreprise (c'était scientifique. Du logiciel d'analyse financière jusqu'à l'étude de déformations de matériaux, en passant par le data-mining)

Scheme scientifique, t'en trouve pas mal chez les utilisateurs de Gambit-C. Même du jeu vidéo en Scheme d'ailleurs. C'est juste pas forcément du LL, et pas forcément des produits répandu.

Perl et Python, là, je me permet à mon tour d'être dubitatif…
(J'ai bien vu des API d'IA en python dans une de mes facs, mais les gars se plaignaient de la rapidité)

Allez, pour le fun, encore du Scheme : http://philosecurity.org/2009/01/12/interview-with-an-adware(...)