"La surveillance effectuée par la CLR concerne les erreurs de programmation classiques qui causent la majorité des défaillances logicielles depuis de longues années : accès à des éléments dun tableau en dehors des limites, accès à des zones de mémoire non allouées, écrasement mémoire dûs à des dépassement de tailles allouées."
Je ne vois pas *pourquoi* la CLR le ferait alors que la sémantique du langage (ou le compilo pour les langages de bas niveau) peut s'en occuper.
"Au final, que représentent 10% de pénalité sur les performances si ceci permet dobtenir une fiabilité et une disponibilité aujourdhui non atteignables."
Les 10% sortent d'un chapeau que je ne veux même pas voir (c'est super variable en fait voir : http://www.bagley.org/~doug/shootout/(...) ). D'autre part, parseonne n'a attendu .NET pour développer des applications fiables de transactions financières en Smalltalk.
C'est justement les applications utilisateur qui peuvent gagner (avoir un Word, un Autocad ou un Rose qui ne plante pas, le rêve).
L'intérêt que je trouve à la démarche est de répondre à la question : peut-on limiter la coloration d'une VM vers le langage qu'elle implante pour ensuite n'avoir qu'une seule instance des infrastructures dans le système ?
Cette démarche comporte un risque (dont Microsoft se fout) c'est de coincer les développeurs dans un langage particulier, en diminuant ainsi leur potentiel d'apprentissage.
Je suis en désaccord, le système utilisé pour la VM n'apporte rien par rapport à un Makefile sélectif.
Je disait que VisualWorks 2.5 est plus rapide que la dernière version de Squeak que j'ai testé (téléchargée il y a 2mois). Je reprécise car je ne suis pas sûr que nous nous soyons compris
Une fois le problème de la VM réglé, il faudra quand même mettre un vrai GC.
Je me suis enregistré (mais j'ai pas grand-chose à dire vu que je suis étudiant et que l'application qu j'en ai eu est commerciale).
le vrai système de gestion de mémoire, c'est un système de GC évolué, beaucoup plus souple que le système de ma grand-mère malloc/free
diminuer la bricole en C/C++ : je vois pas le rapport avec Windows, les noyaux sont coincés entre ADA et C.
Je vois pas le rapport entre machine virtuelle géante et ordinateur universel, relis la phrase, le but serait d'avoir dans le système une seule instance de chaque infrastructure nécessaire pour faire tourner un langage de haut niveau. Et l'intégration de ces p*tains de tags-bit dans les procs x86(désolé, cette absence m'énerve !).
Unix n'a rien qui se rapproche de près ou de loin avec le CLR(ou alors je l'ai pas vu) et ça ne fait en rien de Windows un meilleur OS (pour quelle application d'abord ?)
Microsoft a préféré privilégier les échanges DDE et OLE entres applications plutôt que le pipe. J'ai pas d'avis sur la question.
Le fait que tu croies que cette idée vienne de Microsoft : 1) cette idée (le CLR et une bibliothèque de classes commune) vient de Smalltalk entre 1972 et 1980.
2) n'est pas suffisant pour en faire une mauvaise idée.
Tendre vers de vrais logiciels : c'est pas clair comme phrase, c'est plutôt tendre vers une meilleure qualité, je ne développe pas pour 2 raisons : tu n'as pas l'air d'avoir une culture énorme du sujet (sinon, tu aurais compris l'allusion) et je suis en désacord total avec une mode en vogue sur comp.objects (remplacer le typage par des tests) mais plutôt en phase avec comp.lang.functional.
Il va peut-être falloir lui filer des cours de rattrapage parce qu'il ne pas grand chose aux technologies des machines virtuelle. Comme la plupart des développeurs C/C++ d'ailleur ('toute façon le GC c'est pour les mecs qui savent pas programmer :-)
.NET n'est pas que ce petit Hailstorm.
Personellement, l'intérêt que je trouve à .NET est surtout d'avoir une machine virtuelle géante (avec un vrai système de gestion de la mémoire) et une biblothèque de classes communes, ça va peut-être diminuer la bricole en C/C++ et tendre vers de vrais logiciel.
Je pense (et je suis pas le seul) que développer la VM dans un sous-dilecte de Smalltalk n'était pas très pertinent dès la départ, la maintenance n'a pas gagné.
D'autre part, je suis étonné de la tornade que c'est prise Squeak par rapport à VisualWorks (j'ai travillé 3 mois avec la version 2.5 et ça met une taule sévère à Squeak). La base de développement est la même pourtant.
Pourquoi le GC n'a pas de scavenger (éboueur) entre la première et la deuxième génération ? Toutes les études sur la durée de vie des objets montrent que c'est efficace.
C'est pourquoi j'utilise VisualWorks NC qui est très loin d'être libre.
C'est con d'avoir un nom qui ressemble à Framatome dont le Systus est excellent (mais loin d'être libre) mais qui est surtout le leader mondial du combustible nucléaire !
Une partie du développement va passer en OCaml (enfin un vrai langage, rapide : http://www.bagley.org/~doug/shootout/(...) et SÛR).
Je pense que avant de toucher aux fondation, il vaut mieux réfléchier.
Ca pourraît être un certain progrès vu sous cet angle.
Bon c'est sûr que ça rendra pas leur code maintenable mais bon, 'toute façon le C c'est bien et les autre langages ils sont lents et on développent tous des drivers en temps réel (hard évidemment !) pour le noyau haute disponibilité (faudra qd même que quelqu'un m'explique la fiabilité en C un jour).
J'ai un léger doute sur la techno PHP là.
y'a pas une techno compilée (genre java) qui ne pas démarrerai l'exécutable à chaque nouvelle requête ?
Vous avez quoi comme base derrière ?
D'après le code que j'ai vu (www.radio-u.org) ça ressemblait à du MySQL, faudrait peut-être passer à PostgreSQL avec des 'stored procedure' et des 'stored requests' nan ?
Il tient mieux la charge (j'ai un doute là, j'ai retrouvé le bench mais il date de 2000, ils ont peut-être fait une vraie base maintenant chez MySQL).
MatLab c'est pas libre et y'a pas de 'h' dedans.
Scilab (inria) c'est mieux (polynômes [X], fractions rationelles ...), c'est libre et mon pote il bosse dessus (projet SIMPA)
C'est peut-être pas la peine de répondre, quand tu vois le niveau.
Du style : "Le C, ça fait 30 ans que ça existe, c'est une valeur sûre"
le LISP a été inventé en 1958, Smalltalk en 1972, scheme pareil, ça fait 44 ans que ça existe mais ça doit être à un mec de 15 à qui tu répond.
Mais tout ça c'est de la merde parce que c'est pas C !
D'autre part, ici personne ne développe d'application 'généraliste", on n'a que des développeurs de drivers, de temps-réel (mal informés) et de noyaux.
C'est un site de temps-réel ou d'embarqué ici ?
C'est un site de développeur du noyau ?
La plupart du temps c'est la flemme d'apprendre un langage qui conduit à utiliser le C.
Quand tu vois le ramassi de conneries au dessus (ça prends plus de mémoire, c'est plus lent, on utilise le C pour écrire les compilos [et alors ?], la meilleure : je développe des drivers ou le noyau [à temps plein ?]).
Surtout que la plupart des langages permettent une interconnexion avec le C pour les fonctions critiques.
C'est dommage de discréditer ainsi un site pas mal par ailleur.
et _c'est_ rapide, sauf si c'est un programmeur C qui écrit.
Il faudrait peut-être s'attaquer à la complexité avant de dire que c'est lent.
Il faudrait aussi éliminer les préjugés (cf. le modèle de mémoire minable de OpenCascade).
Je crois que l'image du hacker inculte, chevelu et borné n'est pas prête de disparaître.
Tous les benchs sérieux que j'ai vu plaident pour des langages de haut niveau (même ceux de gens qui avaient des intérêts économiques contraires).
[^] # Re: dontnet-fr.org
Posté par Dugland Bob . En réponse à la dépêche .NET rétrécirait-il comme peau de chagrin ?. Évalué à 2.
Je ne vois pas *pourquoi* la CLR le ferait alors que la sémantique du langage (ou le compilo pour les langages de bas niveau) peut s'en occuper.
"Au final, que représentent 10% de pénalité sur les performances si ceci permet dobtenir une fiabilité et une disponibilité aujourdhui non atteignables."
Les 10% sortent d'un chapeau que je ne veux même pas voir (c'est super variable en fait voir : http://www.bagley.org/~doug/shootout/(...) ). D'autre part, parseonne n'a attendu .NET pour développer des applications fiables de transactions financières en Smalltalk.
C'est justement les applications utilisateur qui peuvent gagner (avoir un Word, un Autocad ou un Rose qui ne plante pas, le rêve).
L'intérêt que je trouve à la démarche est de répondre à la question : peut-on limiter la coloration d'une VM vers le langage qu'elle implante pour ensuite n'avoir qu'une seule instance des infrastructures dans le système ?
Cette démarche comporte un risque (dont Microsoft se fout) c'est de coincer les développeurs dans un langage particulier, en diminuant ainsi leur potentiel d'apprentissage.
[^] # Re: Encore un sarcasme ...
Posté par Dugland Bob . En réponse à la dépêche Création d'une liste de diffusion des utilisateurs de Squeak. Évalué à 1.
Je disait que VisualWorks 2.5 est plus rapide que la dernière version de Squeak que j'ai testé (téléchargée il y a 2mois). Je reprécise car je ne suis pas sûr que nous nous soyons compris
Une fois le problème de la VM réglé, il faudra quand même mettre un vrai GC.
Je me suis enregistré (mais j'ai pas grand-chose à dire vu que je suis étudiant et que l'application qu j'en ai eu est commerciale).
[^] # Re: Y'en a qui sont à la rue
Posté par Dugland Bob . En réponse à la dépêche .NET rétrécirait-il comme peau de chagrin ?. Évalué à 4.
le vrai système de gestion de mémoire, c'est un système de GC évolué, beaucoup plus souple que le système de ma grand-mère malloc/free
diminuer la bricole en C/C++ : je vois pas le rapport avec Windows, les noyaux sont coincés entre ADA et C.
Je vois pas le rapport entre machine virtuelle géante et ordinateur universel, relis la phrase, le but serait d'avoir dans le système une seule instance de chaque infrastructure nécessaire pour faire tourner un langage de haut niveau. Et l'intégration de ces p*tains de tags-bit dans les procs x86(désolé, cette absence m'énerve !).
Unix n'a rien qui se rapproche de près ou de loin avec le CLR(ou alors je l'ai pas vu) et ça ne fait en rien de Windows un meilleur OS (pour quelle application d'abord ?)
Microsoft a préféré privilégier les échanges DDE et OLE entres applications plutôt que le pipe. J'ai pas d'avis sur la question.
Le fait que tu croies que cette idée vienne de Microsoft : 1) cette idée (le CLR et une bibliothèque de classes commune) vient de Smalltalk entre 1972 et 1980.
2) n'est pas suffisant pour en faire une mauvaise idée.
Tendre vers de vrais logiciels : c'est pas clair comme phrase, c'est plutôt tendre vers une meilleure qualité, je ne développe pas pour 2 raisons : tu n'as pas l'air d'avoir une culture énorme du sujet (sinon, tu aurais compris l'allusion) et je suis en désacord total avec une mode en vogue sur comp.objects (remplacer le typage par des tests) mais plutôt en phase avec comp.lang.functional.
[^] # Re: dontnet-fr.org
Posté par Dugland Bob . En réponse à la dépêche .NET rétrécirait-il comme peau de chagrin ?. Évalué à -1.
La grande blague :
http://www.dotnet-fr.org/intro_dotnet_tmr.php3(...)
C'est con pour un mec qui veut vendre des technos Microsoft !
Il a pas compris en quoi c'était génial (sur certains points) mais pas super nouveau.
[^] # Re: YAL
Posté par Dugland Bob . En réponse à la dépêche Création d'une liste de diffusion des utilisateurs de Squeak. Évalué à 1.
j'en ai pas encore trouvé et pourtant j'ai testé !
Le seul truc qui change, c'est la bibliothèque de classes et la lenteur.
Ceci dit, la différence de bibliothèque de classe fait peut-être dire à certains que c'est différent à cause de la réflexivité.
# Y'en a qui sont à la rue
Posté par Dugland Bob . En réponse à la dépêche .NET rétrécirait-il comme peau de chagrin ?. Évalué à -9.
Personellement, l'intérêt que je trouve à .NET est surtout d'avoir une machine virtuelle géante (avec un vrai système de gestion de la mémoire) et une biblothèque de classes communes, ça va peut-être diminuer la bricole en C/C++ et tendre vers de vrais logiciel.
[^] # Re: Encore un sarcasme ...
Posté par Dugland Bob . En réponse à la dépêche Création d'une liste de diffusion des utilisateurs de Squeak. Évalué à 1.
D'autre part, je suis étonné de la tornade que c'est prise Squeak par rapport à VisualWorks (j'ai travillé 3 mois avec la version 2.5 et ça met une taule sévère à Squeak). La base de développement est la même pourtant.
Pourquoi le GC n'a pas de scavenger (éboueur) entre la première et la deuxième génération ? Toutes les études sur la durée de vie des objets montrent que c'est efficace.
C'est pourquoi j'utilise VisualWorks NC qui est très loin d'être libre.
# Encore un sarcasme ...
Posté par Dugland Bob . En réponse à la dépêche Création d'une liste de diffusion des utilisateurs de Squeak. Évalué à 0.
Ne nous emballons pas, vu la vitesse du truc (entre autres le GC est pourri, et pas de JIT), ça pète pas des briques.
L'intérêt réel de la chose est le portage de Morphic depuis Self.
Pour les curieux, un langage _vraiment_ différent : http://research.sun.com/self/language.html(...)
il est prototype-based (fondé sur des prototypes) au lieu du traditionnel class-based (fondé sur des classes).
# C'est la veille du marathon de Paris qui vous fait dire ça ?
Posté par Dugland Bob . En réponse à la dépêche Marathon 2 est toujours vivant (enfin presque). Évalué à -8.
# domage que le nom soit aussi équivoque
Posté par Dugland Bob . En réponse à la dépêche Framasoft devient de plus en plus libre. Évalué à 0.
[^] # Re: Oui mais....
Posté par Dugland Bob . En réponse à la dépêche GSL : bibliothèque scientifique de GNU. Évalué à -1.
[^] # Re: Oui mais....
Posté par Dugland Bob . En réponse à la dépêche GSL : bibliothèque scientifique de GNU. Évalué à 3.
Je pense que avant de toucher aux fondation, il vaut mieux réfléchier.
# Les hackers adolescents boutoneux vont-ils lacher le C ?
Posté par Dugland Bob . En réponse à la dépêche Le GOTO++, nouveau langage de programmation révolutionnaire. Évalué à 4.
Bon c'est sûr que ça rendra pas leur code maintenable mais bon, 'toute façon le C c'est bien et les autre langages ils sont lents et on développent tous des drivers en temps réel (hard évidemment !) pour le noyau haute disponibilité (faudra qd même que quelqu'un m'explique la fiabilité en C un jour).
-1 sarcasme
[^] # Re: sarcasme
Posté par Dugland Bob . En réponse à la dépêche Conception et développement orientés objets au CNAM. Évalué à -7.
# sarcasme
Posté par Dugland Bob . En réponse à la dépêche Conception et développement orientés objets au CNAM. Évalué à -4.
CF : la news sur les outils de débuggage mémoire.
[^] # Re: Non mais ça va pas !
Posté par Dugland Bob . En réponse à la dépêche Et si le réseau sans fil était un service public?. Évalué à 3.
[^] # Re: oui, mais comment les connaitre avant.
Posté par Dugland Bob . En réponse à la dépêche 20% de dépenses inutiles en infrastructures. Évalué à 1.
En plus c'est plus gros (par contre faut pas leur dire qu'il est vide dedans)
-1 je me moque
[^] # Re: soit j'ai lupé un truc, soit...
Posté par Dugland Bob . En réponse à la dépêche Mise à jour LinuxFr. Évalué à 2.
y'a pas une techno compilée (genre java) qui ne pas démarrerai l'exécutable à chaque nouvelle requête ?
Vous avez quoi comme base derrière ?
D'après le code que j'ai vu (www.radio-u.org) ça ressemblait à du MySQL, faudrait peut-être passer à PostgreSQL avec des 'stored procedure' et des 'stored requests' nan ?
Il tient mieux la charge (j'ai un doute là, j'ai retrouvé le bench mais il date de 2000, ils ont peut-être fait une vraie base maintenant chez MySQL).
[^] # Re: MatLab
Posté par Dugland Bob . En réponse à la dépêche La chaîne cyberthèse va passer au libre. Évalué à -1.
-1 décideur pressé qui va monter en charge.
# MatLab
Posté par Dugland Bob . En réponse à la dépêche La chaîne cyberthèse va passer au libre. Évalué à -3.
Scilab (inria) c'est mieux (polynômes [X], fractions rationelles ...), c'est libre et mon pote il bosse dessus (projet SIMPA)
-1 ça trolle
# Est-ce que ça parle de microkernel ?
Posté par Dugland Bob . En réponse à la dépêche La famille Tenenbaum. Évalué à -1.
[^] # Re: Tests persos
Posté par Dugland Bob . En réponse à la dépêche Recherche des bogues et fuites de mémoire. Évalué à 2.
[^] # Re: au XXI ème siècle ?
Posté par Dugland Bob . En réponse à la dépêche Recherche des bogues et fuites de mémoire. Évalué à 1.
Du style : "Le C, ça fait 30 ans que ça existe, c'est une valeur sûre"
le LISP a été inventé en 1958, Smalltalk en 1972, scheme pareil, ça fait 44 ans que ça existe mais ça doit être à un mec de 15 à qui tu répond.
d'autre part, y'a un bon bench :
http://www.bagley.org/~doug/shootout/(...)
(faites gaffe, les listes n'en sont pas, sinon les fonctionnels exploseraient les autres)
Mais tout ça c'est de la merde parce que c'est pas C !
D'autre part, ici personne ne développe d'application 'généraliste", on n'a que des développeurs de drivers, de temps-réel (mal informés) et de noyaux.
[^] # Re: au XXI ème siècle ?
Posté par Dugland Bob . En réponse à la dépêche Recherche des bogues et fuites de mémoire. Évalué à -2.
C'est un site de développeur du noyau ?
La plupart du temps c'est la flemme d'apprendre un langage qui conduit à utiliser le C.
Quand tu vois le ramassi de conneries au dessus (ça prends plus de mémoire, c'est plus lent, on utilise le C pour écrire les compilos [et alors ?], la meilleure : je développe des drivers ou le noyau [à temps plein ?]).
Surtout que la plupart des langages permettent une interconnexion avec le C pour les fonctions critiques.
C'est dommage de discréditer ainsi un site pas mal par ailleur.
[^] # Re: au XXI ème siècle ?
Posté par Dugland Bob . En réponse à la dépêche Recherche des bogues et fuites de mémoire. Évalué à 0.
et _c'est_ rapide, sauf si c'est un programmeur C qui écrit.
Il faudrait peut-être s'attaquer à la complexité avant de dire que c'est lent.
Il faudrait aussi éliminer les préjugés (cf. le modèle de mémoire minable de OpenCascade).
Je crois que l'image du hacker inculte, chevelu et borné n'est pas prête de disparaître.
Tous les benchs sérieux que j'ai vu plaident pour des langages de haut niveau (même ceux de gens qui avaient des intérêts économiques contraires).