Y'a aussi un domaine encore pas trop explorer : la compilation pour plusieurs processeurs. D'ici 5 ans, le moindre pc de bureau sera multi coeur, multi thread.
Or programmer en paralléle est un art difficile. Ocaml propose du calcul automatiquement reparti mais uniquement pour un cluster. Les contraintes ne sont pas équivalentes (notamment sur la hierarchie mémoire et la gestion contradictoire du cache).
J'aimerais voir d'autres moyen de faire du parallèlisme plus simple que les threads. Par exemple, comme l'utilisation de fonction asynchrones avec un état d'attente quand on essait d'accéder aux résultats de la fonction.
Enfin, bref, un nouveau langage peut exploser le C sans soucis, si il fait attention au hardware sous lequel il tourne et pas sur un modèle qui date des années 80.
Faite attention à la programmation par contrat qui dégage en mode release par rapport au mode debug.
Un mode debug c'est bien pour le debug mais pas pour la validation.
Par exemple, dans l'industrie, tu lances toujours tes long scripts de validation sur la version du binaire final, surtout si tu es dans une application dite temps réel. Si le but de lisaac est d'être bas niveau, il y a un gros marché à ce niveau là.
Or, il ne signifie rien de faire une validation lourde dans une appli temps réel en mode debug.
Le cout d'une validation est telle, que souvent, on préfaire faire modifier le hardware que le soft !
Tout ça pour dire que cela serait bien de faire une vérification statique avec "back propagation" pour vérifier le contrat, plutôt que de le faire au run time.
Il ne le font que sur des cas triviaux, notamment parce qu'en C le compilo ne maitrise pas le layout mémoire et parce que la sémantique des boucles s'y prètent mal.
C'est utile aussi pour la mémoire. Sur un code d'exemple, entre la version simple en C et la version C tuné à mort, j'ai une moyenne de x10... Y'a du progres possible pour les compilos.
J'imagine bien un placeur de bloc mémoire qui tient compte de la vrai hierarchie mémoire (hierarchie de cache, taille de page, taille de prefetch, taille de ligne de cache, alignement mémoire,...) et qui ne croit pas que tout est linéaire.
mouais les perfs se veulent proche du C. M'enfin le C est très loin d'étre compilo friendly et je ne comprends pas qu'un langage n'explose toujours pas le C ! Y'a tellement d'optimisation impossible à faire proprement en C !
Mélange pas les api kernel qui sont déclaré comme "flottante" et si le gusse veut ne pas se faire chier il n'a cas diffuser son drivers en GPL.
Concernant les applis, cela peut marcher ou pas. Mais la compatibilité binaire n'est pas un but (cf les versions incompatibles des objets gcc notamment provenant de c++). Il suffit de voir la compatibilité de bug que doit garder windows pour éviter que certaines applis se mettent à déconner après correction.
Je pourrais aussi parler du cauchemard des versions multiples de la même lib sous windows.
JE suis globalement d'accord avec ce que tu dis sauf :
"Que se passe-t-il si un assassin « salit » sa victime avec l'empreinte génétique de quelqu'un d'autre, de préférence quelqu'un avec un parfait profil de suspect ?"
Je dirais la même chose quand un crime essait d'être maquillé.
Il y a tout de même un petit soucis. L'objet a été vendu pour sa réutilisabilité. Avec le recule, on se rend compte que c'est en fait rare (20% dans les faits ?). donc, chaque objet est spécifique.
Donc, avec ton exemple, pour que grep marche il faut une méthode read_char. Si tu veux un cut ? il faut un select_fields(), etc ... en gros une méthode par programme à piper ?
Certe, c'est "plus puissant" mais pas assez générique, sauf si les interfaces sont standardisé mais cela risque de beaucoup ressemblé à un passage de xml (avec la pénalité de parse en moins).
Si tu passes un objet, imagine faire un grep, si tu n'a acces qu'à des méthodes, c'est comme si grep était inclus dans l'objet d'entrée ! Donc il n'y plus d'interet à piper.
Si tu as du xml, au lieu d'avoir un programme pour choper chaque champs, tu peux en avoir un genre find _lenom_du_champ et cela marche partout.
je sais. Donc celui qui reçoit l'objet doit connaitre son interface. Donc, tu limite vachement les possibilités de pipe. Avec XML, il y a juste à connaitre le xml.
Dans le cas du truc MS, au contraire du pipe, cela ne peut marcher si l'objet qui reçoit est prévus pour. Donc en gros, tu perds l'interet de connecté de faire des petits bouts qui cause le même langage (l'ASCII). Le xml permet de mieux structurer.
[^] # Re: Benchmarks
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Lisaac 0.84 est sorti. Évalué à 2.
Or programmer en paralléle est un art difficile. Ocaml propose du calcul automatiquement reparti mais uniquement pour un cluster. Les contraintes ne sont pas équivalentes (notamment sur la hierarchie mémoire et la gestion contradictoire du cache).
J'aimerais voir d'autres moyen de faire du parallèlisme plus simple que les threads. Par exemple, comme l'utilisation de fonction asynchrones avec un état d'attente quand on essait d'accéder aux résultats de la fonction.
Enfin, bref, un nouveau langage peut exploser le C sans soucis, si il fait attention au hardware sous lequel il tourne et pas sur un modèle qui date des années 80.
"La première sécurité est la liberté"
[^] # Re: le... "versionning" ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Lisaac 0.84 est sorti. Évalué à 1.
Un mode debug c'est bien pour le debug mais pas pour la validation.
Par exemple, dans l'industrie, tu lances toujours tes long scripts de validation sur la version du binaire final, surtout si tu es dans une application dite temps réel. Si le but de lisaac est d'être bas niveau, il y a un gros marché à ce niveau là.
Or, il ne signifie rien de faire une validation lourde dans une appli temps réel en mode debug.
Le cout d'une validation est telle, que souvent, on préfaire faire modifier le hardware que le soft !
Tout ça pour dire que cela serait bien de faire une vérification statique avec "back propagation" pour vérifier le contrat, plutôt que de le faire au run time.
"La première sécurité est la liberté"
[^] # Re: Benchmarks
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Lisaac 0.84 est sorti. Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: Benchmarks
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Lisaac 0.84 est sorti. Évalué à 2.
J'imagine bien un placeur de bloc mémoire qui tient compte de la vrai hierarchie mémoire (hierarchie de cache, taille de page, taille de prefetch, taille de ligne de cache, alignement mémoire,...) et qui ne croit pas que tout est linéaire.
"La première sécurité est la liberté"
# gandhi...
Posté par Nicolas Boulay (site web personnel) . En réponse au journal La FSF acuse micrososft de l'avoir censurée. Évalué à 4.
J'attends avec un impatience la phase suivante :)
"La première sécurité est la liberté"
[^] # Re: Benchmarks
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Lisaac 0.84 est sorti. Évalué à 4.
"La première sécurité est la liberté"
[^] # Re: Benchmarks
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Lisaac 0.84 est sorti. Évalué à 2.
"La première sécurité est la liberté"
# sync ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal XFS: demain j'arrête.... Évalué à 3.
"La première sécurité est la liberté"
[^] # Re: Benchmarks
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Lisaac 0.84 est sorti. Évalué à 6.
"La première sécurité est la liberté"
[^] # Re: ...
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche TomTom, fabricant de GPS, contribue au libre. Évalué à 6.
Concernant les applis, cela peut marcher ou pas. Mais la compatibilité binaire n'est pas un but (cf les versions incompatibles des objets gcc notamment provenant de c++). Il suffit de voir la compatibilité de bug que doit garder windows pour éviter que certaines applis se mettent à déconner après correction.
Je pourrais aussi parler du cauchemard des versions multiples de la même lib sous windows.
"La première sécurité est la liberté"
# un installeur text sai null
Posté par Nicolas Boulay (site web personnel) . En réponse au journal installateurs en mode graphique vs texte. Évalué à -7.
"La première sécurité est la liberté"
[^] # Re: ...
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche TomTom, fabricant de GPS, contribue au libre. Évalué à 4.
"La première sécurité est la liberté"
[^] # Re: [X] Plus d'une fois par semaine
Posté par Nicolas Boulay (site web personnel) . En réponse au sondage Mon OS plante. Évalué à 3.
je suis toujours en mdk 10.1, j'en conclue que le support ne s'est toujours améliorer ?
"La première sécurité est la liberté"
[^] # Re: ...
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche TomTom, fabricant de GPS, contribue au libre. Évalué à 4.
"La première sécurité est la liberté"
[^] # Re: Oui mais...
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Migrations vers l'open source: pourquoi se taire ?. Évalué à 10.
"La première sécurité est la liberté"
[^] # Re: Never underestimate the bandwidth of a station wagon full of tapes..
Posté par Nicolas Boulay (site web personnel) . En réponse au journal La liberté de vous l'enlever. Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: man
Posté par Nicolas Boulay (site web personnel) . En réponse au message fwrite vs write. Évalué à 2.
"La première sécurité est la liberté"
# ma pub :)
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Liberticide et compagnie. Évalué à 4.
http://olivier.rioland.free.fr/linux.php3?sujet=alien
"La première sécurité est la liberté"
[^] # Re: meuh
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Liberticide et compagnie. Évalué à 2.
"Que se passe-t-il si un assassin « salit » sa victime avec l'empreinte génétique de quelqu'un d'autre, de préférence quelqu'un avec un parfait profil de suspect ?"
Je dirais la même chose quand un crime essait d'être maquillé.
"La première sécurité est la liberté"
[^] # Re: Reflexion...
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Les systèmes bases de données orientées objets. Évalué à 5.
"La première sécurité est la liberté"
[^] # Re: ...
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Langages pour desktop. Évalué à 3.
Et j'ai vu leur demo à Solution linux, et cela m'avait l'air pas très "générique".
"La première sécurité est la liberté"
[^] # Re: ...
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Langages pour desktop. Évalué à 1.
Donc, avec ton exemple, pour que grep marche il faut une méthode read_char. Si tu veux un cut ? il faut un select_fields(), etc ... en gros une méthode par programme à piper ?
Certe, c'est "plus puissant" mais pas assez générique, sauf si les interfaces sont standardisé mais cela risque de beaucoup ressemblé à un passage de xml (avec la pénalité de parse en moins).
"La première sécurité est la liberté"
[^] # Re: ...
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Langages pour desktop. Évalué à 2.
Si tu as du xml, au lieu d'avoir un programme pour choper chaque champs, tu peux en avoir un genre find _lenom_du_champ et cela marche partout.
"La première sécurité est la liberté"
[^] # Re: Texas ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal proposition de job. Évalué à 6.
"La première sécurité est la liberté"
[^] # Re: ...
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Langages pour desktop. Évalué à 2.
Dans le cas du truc MS, au contraire du pipe, cela ne peut marcher si l'objet qui reçoit est prévus pour. Donc en gros, tu perds l'interet de connecté de faire des petits bouts qui cause le même langage (l'ASCII). Le xml permet de mieux structurer.
"La première sécurité est la liberté"