Je ne pense pas.
Je ne cherche pas les problèmes. Ceux là existent déjà. Ce que je propose est une autre solution. Au lieu de s'acharner à réinventer la poudre à chaque nouvelle techno pour solutionner ces problèmes, penchons nous pour voir si en créant un OS vraiment objet, on ne redéfini pas différemment le problème de telle façon que les solutions apparaissent plus simples, que l'on ouvre la voie à de nouveaux chemins qui permettrait de pouvoir accomplir de choses encore plus complexes et de manière plus simple.
1) ne pas confondre l'approche objet et les langages objets
Tout à fait d'accord
2) a quoi ca sert concretement, et à quel prix ?
Unix en son temps avec ses préceptes (tout est fichier, des outils qui font qu'une et une seule chose et le font bien, etc.) a simplifié bcp de choses.
Hurd tente de pousser plus loin cette approche.
Un OS tout objet simplifierait encore plus de choses. Il permettrait de ne plus se préoccuper de la persistance, de la distribution, si ce n'est en terme d'administration, etc. En fait, il faut s'imaginer Squeak par exemple en OS avec les préceptes de Smalltalk (en tant qu'environnement objet) en plus loin.
3) c'est bien beaux de vouloir faire table rase de l'existant mais il ne faut pas sous evaluer les problèmes suceptibles d'être ainsi créés.
Pourquoi pas ? Il y aura toujours l'existant ... et autre chose qui peu à peu prendra forme. Dans le LL, on peut se le permettre, donc d'innover plus facilement.
4) interet d'une VM dans ton modèle ?
En fait c'est juste une idée. La VM serait le programme sur lequel la machine booterait. Il serait l'interface entre la machine et l'OS et proposerait tout ce qui est nécessaire pour construire un véritable environnement objet. Pour des raisons de perfs, certaines parties de la VM devront peut-être être codées en langage C ou assembleur.
En fait, pour se donner une idée, il faut s'imaginer une VM Smalltalk sur laquelle tu booterais !
5)...
Il n'y aurait, par exemple, qu'un programme principal : le noyau ou la VM.
Tout le reste ne serait qu'objets. Même les drivers. Tout. La VM ou le noyau serait l'environnement virtuel dans lequel les objets vivent. Ils communiquent au travers de lui au même titre qu'avec lui.
Par exemple, pour un lecteur vidéo : tu ne lances pas l'application. Tu le prends des catalogues objets (il est déjà instancié). Tu peux le cloner si tu veux. et tu lui envois des messages : ouvrir un fichier vidéo (un objet aussi), lire ledit fichier vidéo. Tu peux même l'incorporer dans ton programme.
Pour se donner un aperçu de cela, il suffit juste d'essayer par exemple Squeak. http://www.squeak.org(...)
il semble qu'il reste un boulot important de définitions rigoureuses à faire), quand est ce que tu codes cet OS :p ?
Je suis tout à fait d'accord.
Quand vais je coder cet OS ? hum ... qd j'aurais plus de temps pour moi, que je me serais former dans la conception d'un noyau ou d'une VM et que j'aurais avec moi un certain nombres de volontaires enthousiastes :)
Oui on peut faire du bas niveau en objet. Aucun problème à ça.
...
Fais un codec en C++ object (avec fonctions virtuels etc). Ça va ramer.
Comme je l'ai dis dans un commentaire, le résultat obtenu dans la conception d'un système objet dépend des outils que l'on dispose pour le faire.
Le problème est que bcp n'ont de perception de l'objet qu'au travers de leur langage ou environnement objet et le plus souvent celà même qui sont assez limités.
Tu parles de lecteur vidéo uniquement en Java ou en Smalltalk ? Je te prends au mot, télécharge Squeak par exemple http://www.squeak.org(...)
(il incorpore un catalogue d'objets dont parmi eux un lecteur vidéo)
et on en reparle. Je pense (et je l'espère) que ça va te faire reflechir.
On est a une époque où le niveau de performance est important
En es tu vraiment si sûr ? Ne vois tu pas qu'autour de nous de plus en plus d'applis "lourdent" qui sortent (OpenOffice.org, Mozilla par exemples) sous pretexte que les machines sont devenues suffisamment puissantes et le deviennent plus au fur et mesure. L'époque où seule les perfs étaient importantes disparait peu à peu ... pour tomber dans un autre excès :(
Bien sûr, ce n'est pas vrai pour tout : des parties de codes sont opimisées (codecs, certaines parties des VM, etc.) mais ce n'est plus une grande partie voire la totalité des applications comme ce l'était encore il y a quelques années.
Désolé mais c'est une excuse à deux balles.
En es tu vraiment sûr. Ce que je dis pour ces développeurs l'est aussi pour chacun d'entre nous. Cela ne signifie pas pour autant que leur boulot n'est pas bien. Au contraire !
Un jour, comme ceux de leur collègues qui se sont mis par exemple à Eiffel, ils passeront peut-être à écrire des systèmes objets comme il se sont mis à appliquer les principes de l'approche objet. N'oublions pas qu'à une certaine époque on disait qu'il était inconcevable d'appliquer le paradigme objet dans les couches basses.
Nier les expériences passées est aussi un grave défaut.
...
Quand je dis que l'habitude est notre plus grand ennemie ne signifie en aucune manière qu'il faut nier les expériences passées. On peut voir l'habitude comme régir en règles des choses passées qui pouvaient être vraies en leur temps.
Je pense que je me suis très mal exprimé : je ne voulais pas dire que les concepteurs de noyaux étaient des vieux qui ne voulaient pas changer leurs habitudes.
De toute façon, chacun d'entre nous à nos habitudes que l'on ne veut pas remettre en question.
Les concepteurs de noyaux évoluent : ils se sont bien mis à appliquer les concepts du paradigme objet, ils ne sont peut-être pas encore prêt (parce qu'ils ne disposent pas encore des outils nécessaires ou qu'ils ne connaissent pas ceux là) à passer à l'étape suivante. Le domaine des noyaux d'OS est riche : la recherche dans les microkernels, celle dans les exokernels.
Je ne demande qu'un pas de plus ... aller plus loin que nos conceptions classiques : un OS vraiment objet. Sans pour autant dire que ce qui est classique est ringard !
Le monde n'est pas divisé en deux :
- les vieux cons qui font du procédurale
- les jeunes dans le vent qui font de l'objet
Je n'ai jamais qualifié ni sous entendue que les concepteurs de noyaux d'OS actuels étaient des vieux. Ni non plus diviser le monde en deux : celui des
vieux cons et celui des jeunes. Je te fairai remarquer que c'est ton appréciation de mes propos et en aucune manière mes propos. Que finalement cette perception vient de toi.
Le monde est diversifié et changeant. J'aime GNU/Linux, FreeBSD, et j'aime leur travail. C'est très bien, mais allons encore plus loin comme Unix en son temps a posé une pierre dans la mare : un OS tout objet. Pourquoi pas ? Dans les débuts, on va sûrement avoir des difficultés, c'est propre à l'ampleur de la tâche. Mais posons le défis aux vues de ce que cela pourrait apporter.
Ce n'est pas parce que le noyau est écrit en C++ que l'OS est pour autant objet.
Ce n'est pas parce que tu écris un programme en C++ (ou autre langage objet) que tu fais de l'objet et que ton programme soit objet.
A part ceci, si mes souvenirs sont bon, le kernel de BeOS était codé en C++ et pour autant n'était pas plus lent.
Il y a autant de façon de faire de l'objet qu'il existe d'outils pour le faire :)
En parlant de bas niveau, Eiffel semble être apprécié de l'autre côté de l'atlantique dans certain cercle de l'embarqué.
Sais tu que dans tes décodeurs C+ il y a une JVM et des services Java qui tournent ? une JVM adaptée bien sûr.
Pourquoi veux tu absolument que "L'objet n'est pas adapté au bas niveau !"
Pourquoi veux tu rendre statique une idée dans un univers changeant et mouvant. Ce qui était vrai autrefois ne l'est pas nécessairement aujourd'hui et encore moins demain.
Avant, oui, maintenant, avec les compétences et l'expérience actuelle, voyons ... modifions ... changeons
De grands progès ont été réalisés dans les VM pour langages objets.
De grands progrès ont été réalisés dans l'implémentation des concepts objets dans les langages pour les rendre plus performant.
De grandes avancées ont été réalisées dans les conceptions d'OS.
Même maintenant, les bases de données vraiment objet tirent leur épingle du jeu !
Tu parles faire de l'objet de "bas niveau". Tiens donc, mais pourquoi : parce que l'approche objet évolue et par ses qualités les développeurs l'adoptent peu à peu. Pourquoi "bas niveau" : parce que ce ne sont pas des développeurs objets et qu'ils sont habitués à coder d'une certaine façon avec des outils donnés : l'habitude est notre plus grand ennemi (je ne sais plus qui a dis ça), mais elle est là. Bien sûr, dans le très bas niveau (en embarqué pure par exemple), l'objet "vrai" (s'il y a de l'objet "vrai") est probablement pas encore du tout adapté.
Ce n'est pas un système d'exploitation mais un environnement objet.
Il illustre juste dans mon commentaire que l'objet n'est pas toujours synonyme de "lourd, lent et pas souple". Tout dépend des outils que l'on dispose. Fais par exemple la même chose que squeak mais en Java et effectivement, tu pourras par contre dire, AMHA, "lourd, lent et pas souple".
Malheureusement, trop de personnes qualifient l'objet qu'au travers des outils limités qu'ils disposent.
Par contre, je pense que Squeak donne un apperçu de ce que pourrait-être un OS objet pour l'utilisateur. Il suffit juste d'imaginer que c'est un OS complet (oublier son interface graphique si on n'aime pas) : tu ne joues plus avec des applications, mais avec des objets, uniquement avec des objets. Tu imagines alors ce que pourrait être un tel OS si les documents étaient aussi que des objets !
Le noyau de MacOS X est Darwin. Darwin s'appuit sur le microkernel March 3 retouché par les ingénieurs d'Apple. Darwin, contrairement à Hurd, n'est qu'une couche monolitique (uni-serveur) au-dessus de March. Au-dessus de March est implémenté toutes les composants Unix provenant du monde BSD : NetBSD, FreeBSD, OpenBSD. Il y a peut-être aussi des composants provenant des système V.
Je crois que tu délires un peu.
Quelques explications :
- qd on parle de "procédurale", on pense à classique, pas nécessairement à vieux. Ce qui est vieux n'est pas nécessairement "has been". Seulement aujourd'hui, l'aspect procédurale ou fonctionnelle est quelque chose de classique, de commun. Même les langages objets comme C++, Java ou Eiffel utilisent les aspects "procédurales" pour implémenter des concepts objets ; CLOS ceux "fonctionnelles".
- qd on parle d'objet, on pense à moderne parce que c'est encore nouveau et que bon nombres de technos ne sont pas encore complétement objet ou qu'en surface (ce qui ne veut pas dire que tout doit être en objet). Parce que c'est nouveau, oui, les premiers jets étaient lourds et manquaient de souplesse : il y eu donc des ratés comme dans les bases de données avec O2. Pourtant, l'approche objet évolue, les techniques d'implémentation de ces concepts aussi. Ce qui fait que, si hier ce n'était pas encore possible d'écrire une techno en objet sans contre-partie handicapant, aujourd'hui ça l'est bcp moins ... Et ceci grâce aussi en partie au fait que l'on s'est fait aussi la main hier sur les technos objets.
Quant à trop lourd, trop lent et pas souple, essaie aujourd'hui un environnement Smalltalk de ce jour (squeak par exemple). Je pense que tu redéfiniras autrement ta perception de l'objet.
Maintenant, à part les couches utilisateur, je n'ai pas connu de tentatives (à part, dans une certaine mesure, Smalltalk à ces débuts) à faire un bon OS uniquement en objet.
Ha, oui, en fait text.rb doit se trouver parmi les libraries de Ruby (/usr/lib/ruby/1.8 pour Debian). Il faudra que je change ça.
Pour les options dans newalb.rb, je prends note et je vais le faire.
Quant au lien, je ne comprends pas rès bien. Sur l'interface web, les liens pour remonter de niveau sont par défaut en haut, sous le titre :
Nos albums photos
^
Toto chez les papoos
"Nos albums photos" et "Toto chez les papoos" sont deux liens : le premier vers la racine des albums web et "Toto ..." vers l'album "Toto ...", album père de celui courant.
Est-ce ça dont tu parles ou d'une autre fonctionnalité ?
Je connais Hurd. C'est un OS qui AMHA, encore aujourd'hui, est moderne et qui s'appuit sur les concepts auquels j'aspire.
Toutefois, il s'arrête en route et ne va pas au-delà des schémas existants : les codeurs sont des développeurs d'OS habitués aux systèmes classiques. Je ne pense pas qu'ils aient vraiment une culture objet.
Avec l'OS suscité au dessus, je vais encore plus loin puisque tout est objet. Cela veut dire quoi : que l'OS est un gros conteneur d'objets instanciés (les classes elles-mêmes sont des objets) qui gère leur cycle de vie et qui soit fortement multi-threadé (des pools de threads pour les opérations des objets ou un pool de threads pour chaque objet, différentes implémentations sont possibles), etc.
En fait, je me suis apperçu, et ceci particulièrement au travers de Smalltalk, que finalement un environnement vraiment objet pourrait simplifier nombre de choses et peut apporter une grande souplesse et flexibilité sans rajouts d'artifices ou sans bricolages.
Mais bon, faut pas rêver ... Ou alors je dois me mettre la main à la tâche ... pas facile qd on n'a pas les compétences adéquates, ni le temps.
Comme tous les serveurs d'appli, si ce n'est que ZOPE va plus loin.
Comme je l'ai écrit en commentaire, on glisse peu à peu vers un modèle de type serveur d'applis. Mais les serveurs d'applis restent des applis qui tournent sur des systèmes dites classiques. Par ce fait, du fait qu'ils doivent s'adapter au système sous-jacent, entre autre, ils restent lourds en consommation ressource. De plus, tu ne peux pas construire avec tout un environnement ... du moins pas encore.
Non. Atheos comme BeOS sont des systèmes classiques au-dessus lequel l'API et l'environnement graphique est objet. Ce sont donc des systèmes orientés applis, que celles-ci soient ou non écrites en objet
Cela serait un peu le principe d'un os basé sur un exonoyau
Non, ce dont il parle c'est un microkernel.
Le principe de l'exokernel est d'avoir une architecture modulaire comme le kernel et d'éviter les pb de perfs éventuels du type d'archi microkernel ou même monokernel.
IBM fait de la recherche dans les exokernels. Dans une architectrure hexokernel, tu n'as plus de couche (HAL) entre le matériel et l'environnement utilisateur. Le principe de l'exokernel est de répartir dans des librairies le code du kernel/microkernel et chaque application est liée à ces librairies : au lieu de passer par le HAL avec des appels systèmes, chaque appli interroge directement le matériel au travel de la librairie, donc d'appels de fonctions.
Le pb de performances des microkernels est un faux pb. En fait, à l'époque, tout le monde se focalisait sur March qui est une usine à gaz. L4ka est un autre microkernel et est très performant ; c'est pourquoi l'équipe de Hurd regarde aussi du côté de ce microkernel pour, peut-être, à terme remplacer GNU March.
Sérieusement, quels avantages ça présenterait ? Pour quels inconvénients ?
Pourquoi un OS objet ? on a des serveurs d'applications objets qui font la même chose (ou presque) après tout. Oui, mais ça reste un serveur d'application au-dessus d'un OS classique sur lequel tourne des applications et non des objets. Que crois tu pourquoi, peu à peu, on se dirige vers des architectures de type serveur d'application ? Parce qu'il y a un véritable avantage et besoin : les composants sont faciles à coder, faciles à déployer, à maintenir, à intéragir ensemble, etc.
Mais voilà, ça reste une serveur d'application ... une simple application elle-même ... avec tous les inconvénients que cela draine : difficulté dans son administration, grosse consommation des ressources, architecture qui doit s'adapter aux particularités de chaque système sur lequel il doit s'installer, etc.
Quelle différence avec un cluster "normal" ?
C'est inhérent à l'OS et à sa conception objet. Imagine que dans un environnement vraiment objet, tu ne fais pas d'appels indirect à une opération via une référence, mais tu envoie bien un message à un objet via sa référence. Donc, il est assez simple d'étendre de façon transparante ce mécanisme de messagerie pour qu'il soit distribué. La distribution étant gérée de façon transparante par l'OS.
Quelle différence avec des modules noyau ?
Ce sont en quelque sorte des modules noyaux ... excepté que ce sont tout simplement de simples objets ...
L'orienté objet c'est bien, mais ce n'est pas forcément la panacée, en particulier pour les couches basses (il y a quand même un certain overhead entre autres).
Ha les idée préconçues ! Elles ont la vie dure !
Ce n'est pas parce qu'il y a des outils, pour faire de l'objet, mal foutus ou pas dédiés pour les couches basses, que des développeurs soit disant objet codent avec leur pied, que l'objet est pour autant pas adapté ou si limité que l'on se complait à dire (jusqu'à s'en convaincre).
Connais tu le langage objet Eiffel ? Sais tu que de l'autre côté de l'altlantique ils l'apprécient dans certains cercles de l'embarqué !
Après tout, on n'a pas besoin de l'objet pour faire des systèmes lourds : Windows par exemple :) Ou Solaris :)
Je vois que tu ne vois pas l'avantage d'un système objet. Par ces concepts même et par une implémentation bien faite il simplifierait bcp de choses. Cela avait commencé avec Unix : tout est fichier ... cela pourrait continuer avec un tel système : tout est objet, les objets peuvent-être implicitement distribués, ils peuvent s'interchangés, etendus, la communication/interaction inter-application s'en trouverait simplifiée puisque ce serait tout simplement de la communication inter-objet (tel objet envoie tel message à tel objet ou j'appelle telle méthode de tel objet). Même les documents seraient des objets !
Je pense que pour ce donner un apperçu d'un tel OS, il faudrait essayer squeak et l'imaginer en mieux et ce que cela pourrait donner en OS (ne pas se focaliser sur son interface graphique, mais plutôt sur les concepts qui s'y dessinent).
Déjà, choisir une net install est une mauvaise erreur par rapport à un jeu de CD si en plus tu es limité dans le temps. Le téléchargement des paquets + leur installation peut prendre environ 2 heures si tu installes une version 'desktop' (environnement de bureau dans l'installateur).
Ensuite, comme l'a si bien dit précédemment Aurélien, tes propos n'étaient pas en accord avec peut-être l'attente de ton public.
AMHA, il aurait mieux valu d'abord les titiller en leur présentant GNU/Linux : qu'est ce que c'est, les applis que l'on trouve, les choix, l'installation / suppréssion d'un programme, etc. Bref, l'usage au quotidien d'un linuxien lambda (simple utilisateur). Pour ceux qui veulent faire du dev, une présentation des outils disponibles peut-être faite.
C'est ensuite, dans une autre séance, après avoir sensibilité précédemment le public à GNU/Linux, que tu peux leur proposer une démonstration d'install, voir une install-party.
le café ? Si Java :)
(Java signifie café en argo anglais.)
Sinon, par rapport au nullable type, une solution de conception du langage, plus élegant à mon avis, peut être celle d'Eiffel : un objet prédéfini Void qui est de type NONE, lui même descendant de toutes les classes de ton appli. Bref, autrement dit pas une bidouille que doit se tapper le développeur.
Je suis pour faciliter la vie des développeurs (donc au détriment du ou des concepteurs de langages). Malheureusement, c'est souvent l'inverse que l'on observe : le concepteur qui facilite sa vie au détriment du développeur qui doit utiliser son langage.
Par rapport à C# et .NET, je trouve que ce sont des outils interessant.
Le seul truc qui me fait tiquer, c'est qu'ils viennent de Microsoft et je me méfie de ses produits. Souvent c'est : au début ça parait super, à l'utilisation c'est finalement plus limité que prévu, et à la fin, au fur et à mesure des évolutions, c'est le cauchemar ... mais c'est trop tard (faut comprendre : l'existant, les licences, les développeurs qui ne connaissent que ça et tout ça).
Il est vrai que la perception d'un langage "utilisable" dépend de chacun. Ma perception est : "s'exprimer simplement, de façon élegante, sans à faire du contorsionnisme ou du bidouillage pour arriver à mes fins et avec une syntaxe simple."
Ainsi, pour l'avoir utiliser, dans les langages à typage statique, la covariance et la généricité contrainte apportent une souplesse très importante.
Le fait aussi de pouvoir affiner la visibilité au niveau classe pour telles ou telles méthodes (par exemple, telle méthode n'est accessible que pour les objets de telle classe) permet d'implémenter de façon élegante un certain nombre de patterns (visual proxy, factory, etc.) sans se compliquer les méninges.
Je suis d'accord que Java et C# sont des langages de masse, et comme bcp de chose destinée à la masse, le résultat est obtenu par "un équilibre par le bas".
Quant à Smalltalk, AMHA je ne pense pas que c'est de la "masturbation intellectuelle" :) Je pense plutôt que c'est une façon de pensée différente de ce que l'on a l'habitude (un peu comme GNU/Linux pour les windowsiens). J'ai l'impression que toute notre vie, et particulièrement professionnelle, on nous "lobotomise", on nous "écrase" par nous imposer des limites dans notre champs de perception. Or, pour avoir codé avec, Smalltalk nous offre un moyen d'exprimer pleinement nos capacités, limitées ou non. Elle offre à notre perception ce qu'est en fait l'univers : infinie où toutes choses se mouvoient et changent ; chose que l'on a perdu, peut etre depuis l'enfance, à percevoir.
Une fois que tu connais la syntaxe de Smalltalk (qui n'est pas difficile en soit), et que tu as passé le plus difficile (un champs de perception non limitée), alors tu peux exprimer de façon très simple et élegante des solutions complexes.
Pour moi, la "masturbation intellectuelle" dans le développement est de trouver des solutions de coutournement des limitations d'un outil pour arriver à exprimer quelque chose qui se doit d'être évident. D'autant plus si les mécanismes de représenter simplement notre expression existe et avec une syntaxe simple.
Heu, non Eiffel est un langage des années 80 qui s'est affirmé dans les années 90 !
Déjà en avance pour son époque :)
AMHA, son auteur, Bertrand Meyer, en dehors de l'homme lui-même, a des idées et des conceptions que bon nombre d'entre nous, et particulièrement les concepteurs de langages objet, devrait s'inspirer.
Sinon, non, ce n'est pas qu'un langage d'université. Il est vrai qu'en France il est surtoût connu dans ce milieu. Mais aux Etats-Unis il est utilisé dans l'industrie et semble être apprécié dans certains cercles du milieu embarqué là bas.
Tu parles d'événements et de meta-donnés. Si tu veux vraiment faire de la méta programmation, je te recommande fortemement Smalltalk-80 ou Squeak (une version Smalltalk-80 orientée multimédia).
Quant à C#, je le vois avant tout comme une action marketing de Microsoft à l'encontre de Sun. C# 1.x est un java like de Microsoft, C# 2 est une avancée pour incorporer des mécanismes minimum que font de lui un langage objet à typage statique suffisamment utilisable (que Java n'était pas AMHA et qu'il va l'être avec Java 1.5), ceci afin de répondre à la réponse de Sun avec Java 1.5.
Si dans tout ça, nous développeurs, on trouve notre bonheur tant mieux.
Par rapport à la généricité contrainte, elle doit faire partie de C# 2 qui n'apparaitra qu'avec Visual .NET 2005 qui doit être encore en version beta sauf si je me trompe. Je parlais de la version 1.1. Autrement dit celle utilisée actuellement et pour lequel plein de petits développeurs Microsoftiens s'extasient (ce n'est pas péjoratif, attention !).
Par rapport à l'ajout de méthodes, ton lien ne me donne pas l'information escomptée.
Par rapport à la covariance (et à la contravariance), elle est plutôt restreinte. Applicable seulement aux méthodes de délégation (un mécanisme semblable aux agents d'Eiffel par exemple).
Par rapport aux autres goodies ... hum. Le nullable type n'apporte pas grand chose excepté si le langage a un pb de ... conception. Quant au mot clé 'yield' il est interéssant même si de grandes discussions ont encore lieux par rapport au bien fondé d'un pareil mécanisme.
A t'on vraiment vraiment la même définition de covariance ?
Je me pose la question par rapport au mot-clé 'out' que tu apportes comme solution.
La covariance est la faculté de raffiner le type des paramètres d'une méthode en sous-types.
Par exemple, covariance des paramètres et du résultat de retour :
class Number
add (other: Number): Number
end
class Integer <: Number
add (other: Integer): Integer
end
Bien sûr, avec la généricité, si elle le permet, on peut se permettre une écriture à la F-Bound:
class Number [ T <: Number [T] ]
add(other: T): T
end
class Integer [ T <: Integer [T] ] <: Number [ T <: Number [T] ]
end
Sinon, il apparaitrait que C# 2.0 intégrera la généricité contrainte (si j'ai bien compris). Il apparaitra, si j'ai toujours bien compris avec Visual .NET 2005.
A part ça, je comprends que les développeurs Microsoft s'exaltent face à C#. Jusqu'à présent, ils fallaient qu'ils se tappent Visual C++ ou Visual Basic. Deux langages qui n'ont d'objet que leur prétention (bon, d'accord, j'exagère), un peu comme bcp de développeurs d'ailleurs (ho la la, que je suis méchant, vraiment :) ).
Et tout d'un coup, on leur propose un langage des années 90, né au 21e siècle, C#. Pour eux, qui ne connaissent que le monde Microsoft ou qui sont condamnés à développer pour ses plate-formes, c'est une découverte ! Expérience vécue dans ma boite.
[^] # Re: Mark Twain
Posté par Miguel Moquillon (site web personnel) . En réponse au journal j'ai un rêve .... Évalué à 1.
Je ne cherche pas les problèmes. Ceux là existent déjà. Ce que je propose est une autre solution. Au lieu de s'acharner à réinventer la poudre à chaque nouvelle techno pour solutionner ces problèmes, penchons nous pour voir si en créant un OS vraiment objet, on ne redéfini pas différemment le problème de telle façon que les solutions apparaissent plus simples, que l'on ouvre la voie à de nouveaux chemins qui permettrait de pouvoir accomplir de choses encore plus complexes et de manière plus simple.
Ce n'est peut-être qu'un rêve ...
[^] # Re: Hmhm
Posté par Miguel Moquillon (site web personnel) . En réponse au journal j'ai un rêve .... Évalué à 4.
Tout à fait d'accord
Unix en son temps avec ses préceptes (tout est fichier, des outils qui font qu'une et une seule chose et le font bien, etc.) a simplifié bcp de choses.
Hurd tente de pousser plus loin cette approche.
Un OS tout objet simplifierait encore plus de choses. Il permettrait de ne plus se préoccuper de la persistance, de la distribution, si ce n'est en terme d'administration, etc. En fait, il faut s'imaginer Squeak par exemple en OS avec les préceptes de Smalltalk (en tant qu'environnement objet) en plus loin.
Pourquoi pas ? Il y aura toujours l'existant ... et autre chose qui peu à peu prendra forme. Dans le LL, on peut se le permettre, donc d'innover plus facilement.
En fait c'est juste une idée. La VM serait le programme sur lequel la machine booterait. Il serait l'interface entre la machine et l'OS et proposerait tout ce qui est nécessaire pour construire un véritable environnement objet. Pour des raisons de perfs, certaines parties de la VM devront peut-être être codées en langage C ou assembleur.
En fait, pour se donner une idée, il faut s'imaginer une VM Smalltalk sur laquelle tu booterais !
Il n'y aurait, par exemple, qu'un programme principal : le noyau ou la VM.
Tout le reste ne serait qu'objets. Même les drivers. Tout. La VM ou le noyau serait l'environnement virtuel dans lequel les objets vivent. Ils communiquent au travers de lui au même titre qu'avec lui.
Par exemple, pour un lecteur vidéo : tu ne lances pas l'application. Tu le prends des catalogues objets (il est déjà instancié). Tu peux le cloner si tu veux. et tu lui envois des messages : ouvrir un fichier vidéo (un objet aussi), lire ledit fichier vidéo. Tu peux même l'incorporer dans ton programme.
Pour se donner un aperçu de cela, il suffit juste d'essayer par exemple Squeak.
http://www.squeak.org(...)
Je suis tout à fait d'accord.
Quand vais je coder cet OS ? hum ... qd j'aurais plus de temps pour moi, que je me serais former dans la conception d'un noyau ou d'une VM et que j'aurais avec moi un certain nombres de volontaires enthousiastes :)
[^] # Re: J'en ai rèvé^Umarre
Posté par Miguel Moquillon (site web personnel) . En réponse au journal j'ai un rêve .... Évalué à 3.
Comme je l'ai dis dans un commentaire, le résultat obtenu dans la conception d'un système objet dépend des outils que l'on dispose pour le faire.
Le problème est que bcp n'ont de perception de l'objet qu'au travers de leur langage ou environnement objet et le plus souvent celà même qui sont assez limités.
Tu parles de lecteur vidéo uniquement en Java ou en Smalltalk ? Je te prends au mot, télécharge Squeak par exemple
http://www.squeak.org(...)
(il incorpore un catalogue d'objets dont parmi eux un lecteur vidéo)
et on en reparle. Je pense (et je l'espère) que ça va te faire reflechir.
En es tu vraiment si sûr ? Ne vois tu pas qu'autour de nous de plus en plus d'applis "lourdent" qui sortent (OpenOffice.org, Mozilla par exemples) sous pretexte que les machines sont devenues suffisamment puissantes et le deviennent plus au fur et mesure. L'époque où seule les perfs étaient importantes disparait peu à peu ... pour tomber dans un autre excès :(
Bien sûr, ce n'est pas vrai pour tout : des parties de codes sont opimisées (codecs, certaines parties des VM, etc.) mais ce n'est plus une grande partie voire la totalité des applications comme ce l'était encore il y a quelques années.
En es tu vraiment sûr. Ce que je dis pour ces développeurs l'est aussi pour chacun d'entre nous. Cela ne signifie pas pour autant que leur boulot n'est pas bien. Au contraire !
Un jour, comme ceux de leur collègues qui se sont mis par exemple à Eiffel, ils passeront peut-être à écrire des systèmes objets comme il se sont mis à appliquer les principes de l'approche objet. N'oublions pas qu'à une certaine époque on disait qu'il était inconcevable d'appliquer le paradigme objet dans les couches basses.
Quand je dis que l'habitude est notre plus grand ennemie ne signifie en aucune manière qu'il faut nier les expériences passées. On peut voir l'habitude comme régir en règles des choses passées qui pouvaient être vraies en leur temps.
Je pense que je me suis très mal exprimé : je ne voulais pas dire que les concepteurs de noyaux étaient des vieux qui ne voulaient pas changer leurs habitudes.
De toute façon, chacun d'entre nous à nos habitudes que l'on ne veut pas remettre en question.
Les concepteurs de noyaux évoluent : ils se sont bien mis à appliquer les concepts du paradigme objet, ils ne sont peut-être pas encore prêt (parce qu'ils ne disposent pas encore des outils nécessaires ou qu'ils ne connaissent pas ceux là) à passer à l'étape suivante. Le domaine des noyaux d'OS est riche : la recherche dans les microkernels, celle dans les exokernels.
Je ne demande qu'un pas de plus ... aller plus loin que nos conceptions classiques : un OS vraiment objet. Sans pour autant dire que ce qui est classique est ringard !
Je n'ai jamais qualifié ni sous entendue que les concepteurs de noyaux d'OS actuels étaient des vieux. Ni non plus diviser le monde en deux : celui des
vieux cons et celui des jeunes. Je te fairai remarquer que c'est ton appréciation de mes propos et en aucune manière mes propos. Que finalement cette perception vient de toi.
Le monde est diversifié et changeant. J'aime GNU/Linux, FreeBSD, et j'aime leur travail. C'est très bien, mais allons encore plus loin comme Unix en son temps a posé une pierre dans la mare : un OS tout objet. Pourquoi pas ? Dans les débuts, on va sûrement avoir des difficultés, c'est propre à l'ampleur de la tâche. Mais posons le défis aux vues de ce que cela pourrait apporter.
[^] # Re: J'en ai rèvé^Umarre
Posté par Miguel Moquillon (site web personnel) . En réponse au journal j'ai un rêve .... Évalué à 2.
http://www.squeak.org/(...)
Mon apprentissage Smalltalk je l'ai fait à l'université.
Auparavant, j'avais un background C++ et une pauvre culture en objet :)
[^] # Re: J'en ai rèvé^Umarre
Posté par Miguel Moquillon (site web personnel) . En réponse au journal j'ai un rêve .... Évalué à 2.
Ce n'est pas parce que tu écris un programme en C++ (ou autre langage objet) que tu fais de l'objet et que ton programme soit objet.
A part ceci, si mes souvenirs sont bon, le kernel de BeOS était codé en C++ et pour autant n'était pas plus lent.
[^] # Re: J'en ai rèvé^Umarre
Posté par Miguel Moquillon (site web personnel) . En réponse au journal j'ai un rêve .... Évalué à 1.
En parlant de bas niveau, Eiffel semble être apprécié de l'autre côté de l'atlantique dans certain cercle de l'embarqué.
Sais tu que dans tes décodeurs C+ il y a une JVM et des services Java qui tournent ? une JVM adaptée bien sûr.
Pourquoi veux tu absolument que "L'objet n'est pas adapté au bas niveau !"
Pourquoi veux tu rendre statique une idée dans un univers changeant et mouvant. Ce qui était vrai autrefois ne l'est pas nécessairement aujourd'hui et encore moins demain.
Avant, oui, maintenant, avec les compétences et l'expérience actuelle, voyons ... modifions ... changeons
De grands progès ont été réalisés dans les VM pour langages objets.
De grands progrès ont été réalisés dans l'implémentation des concepts objets dans les langages pour les rendre plus performant.
De grandes avancées ont été réalisées dans les conceptions d'OS.
Même maintenant, les bases de données vraiment objet tirent leur épingle du jeu !
Tu parles faire de l'objet de "bas niveau". Tiens donc, mais pourquoi : parce que l'approche objet évolue et par ses qualités les développeurs l'adoptent peu à peu. Pourquoi "bas niveau" : parce que ce ne sont pas des développeurs objets et qu'ils sont habitués à coder d'une certaine façon avec des outils donnés : l'habitude est notre plus grand ennemi (je ne sais plus qui a dis ça), mais elle est là. Bien sûr, dans le très bas niveau (en embarqué pure par exemple), l'objet "vrai" (s'il y a de l'objet "vrai") est probablement pas encore du tout adapté.
[^] # Re: J'en ai rèvé^Umarre
Posté par Miguel Moquillon (site web personnel) . En réponse au journal j'ai un rêve .... Évalué à 2.
Il illustre juste dans mon commentaire que l'objet n'est pas toujours synonyme de "lourd, lent et pas souple". Tout dépend des outils que l'on dispose. Fais par exemple la même chose que squeak mais en Java et effectivement, tu pourras par contre dire, AMHA, "lourd, lent et pas souple".
Malheureusement, trop de personnes qualifient l'objet qu'au travers des outils limités qu'ils disposent.
Par contre, je pense que Squeak donne un apperçu de ce que pourrait-être un OS objet pour l'utilisateur. Il suffit juste d'imaginer que c'est un OS complet (oublier son interface graphique si on n'aime pas) : tu ne joues plus avec des applications, mais avec des objets, uniquement avec des objets. Tu imagines alors ce que pourrait être un tel OS si les documents étaient aussi que des objets !
[^] # Re: de mémoire
Posté par Miguel Moquillon (site web personnel) . En réponse au journal j'ai un rêve .... Évalué à 3.
[^] # Re: J'en ai rèvé^Umarre
Posté par Miguel Moquillon (site web personnel) . En réponse au journal j'ai un rêve .... Évalué à 4.
Quelques explications :
- qd on parle de "procédurale", on pense à classique, pas nécessairement à vieux. Ce qui est vieux n'est pas nécessairement "has been". Seulement aujourd'hui, l'aspect procédurale ou fonctionnelle est quelque chose de classique, de commun. Même les langages objets comme C++, Java ou Eiffel utilisent les aspects "procédurales" pour implémenter des concepts objets ; CLOS ceux "fonctionnelles".
- qd on parle d'objet, on pense à moderne parce que c'est encore nouveau et que bon nombres de technos ne sont pas encore complétement objet ou qu'en surface (ce qui ne veut pas dire que tout doit être en objet). Parce que c'est nouveau, oui, les premiers jets étaient lourds et manquaient de souplesse : il y eu donc des ratés comme dans les bases de données avec O2. Pourtant, l'approche objet évolue, les techniques d'implémentation de ces concepts aussi. Ce qui fait que, si hier ce n'était pas encore possible d'écrire une techno en objet sans contre-partie handicapant, aujourd'hui ça l'est bcp moins ... Et ceci grâce aussi en partie au fait que l'on s'est fait aussi la main hier sur les technos objets.
Quant à trop lourd, trop lent et pas souple, essaie aujourd'hui un environnement Smalltalk de ce jour (squeak par exemple). Je pense que tu redéfiniras autrement ta perception de l'objet.
Maintenant, à part les couches utilisateur, je n'ai pas connu de tentatives (à part, dans une certaine mesure, Smalltalk à ces débuts) à faire un bon OS uniquement en objet.
[^] # Re: génération des thumbs
Posté par Miguel Moquillon (site web personnel) . En réponse au journal WAGEN. Évalué à 2.
Pour les options dans newalb.rb, je prends note et je vais le faire.
Quant au lien, je ne comprends pas rès bien. Sur l'interface web, les liens pour remonter de niveau sont par défaut en haut, sous le titre :
Nos albums photos
^
Toto chez les papoos
"Nos albums photos" et "Toto chez les papoos" sont deux liens : le premier vers la racine des albums web et "Toto ..." vers l'album "Toto ...", album père de celui courant.
Est-ce ça dont tu parles ou d'une autre fonctionnalité ?
[^] # Re: Hurd : orienté objet
Posté par Miguel Moquillon (site web personnel) . En réponse au journal j'ai un rêve .... Évalué à 3.
Toutefois, il s'arrête en route et ne va pas au-delà des schémas existants : les codeurs sont des développeurs d'OS habitués aux systèmes classiques. Je ne pense pas qu'ils aient vraiment une culture objet.
Avec l'OS suscité au dessus, je vais encore plus loin puisque tout est objet. Cela veut dire quoi : que l'OS est un gros conteneur d'objets instanciés (les classes elles-mêmes sont des objets) qui gère leur cycle de vie et qui soit fortement multi-threadé (des pools de threads pour les opérations des objets ou un pool de threads pour chaque objet, différentes implémentations sont possibles), etc.
En fait, je me suis apperçu, et ceci particulièrement au travers de Smalltalk, que finalement un environnement vraiment objet pourrait simplifier nombre de choses et peut apporter une grande souplesse et flexibilité sans rajouts d'artifices ou sans bricolages.
Mais bon, faut pas rêver ... Ou alors je dois me mettre la main à la tâche ... pas facile qd on n'a pas les compétences adéquates, ni le temps.
[^] # Re: Zope!
Posté par Miguel Moquillon (site web personnel) . En réponse au journal j'ai un rêve .... Évalué à 5.
Comme je l'ai écrit en commentaire, on glisse peu à peu vers un modèle de type serveur d'applis. Mais les serveurs d'applis restent des applis qui tournent sur des systèmes dites classiques. Par ce fait, du fait qu'ils doivent s'adapter au système sous-jacent, entre autre, ils restent lourds en consommation ressource. De plus, tu ne peux pas construire avec tout un environnement ... du moins pas encore.
[^] # Re: AtheOS ?
Posté par Miguel Moquillon (site web personnel) . En réponse au journal j'ai un rêve .... Évalué à 2.
[^] # Re: de mémoire
Posté par Miguel Moquillon (site web personnel) . En réponse au journal j'ai un rêve .... Évalué à 5.
Non, ce dont il parle c'est un microkernel.
Le principe de l'exokernel est d'avoir une architecture modulaire comme le kernel et d'éviter les pb de perfs éventuels du type d'archi microkernel ou même monokernel.
IBM fait de la recherche dans les exokernels. Dans une architectrure hexokernel, tu n'as plus de couche (HAL) entre le matériel et l'environnement utilisateur. Le principe de l'exokernel est de répartir dans des librairies le code du kernel/microkernel et chaque application est liée à ces librairies : au lieu de passer par le HAL avec des appels systèmes, chaque appli interroge directement le matériel au travel de la librairie, donc d'appels de fonctions.
Le pb de performances des microkernels est un faux pb. En fait, à l'époque, tout le monde se focalisait sur March qui est une usine à gaz. L4ka est un autre microkernel et est très performant ; c'est pourquoi l'équipe de Hurd regarde aussi du côté de ce microkernel pour, peut-être, à terme remplacer GNU March.
voir http://l4ka.org/(...)
[^] # Re: ...
Posté par Miguel Moquillon (site web personnel) . En réponse au journal j'ai un rêve .... Évalué à 6.
Hum ... trop de développement objet peut-ête ? :)
Pourquoi un OS objet ? on a des serveurs d'applications objets qui font la même chose (ou presque) après tout. Oui, mais ça reste un serveur d'application au-dessus d'un OS classique sur lequel tourne des applications et non des objets. Que crois tu pourquoi, peu à peu, on se dirige vers des architectures de type serveur d'application ? Parce qu'il y a un véritable avantage et besoin : les composants sont faciles à coder, faciles à déployer, à maintenir, à intéragir ensemble, etc.
Mais voilà, ça reste une serveur d'application ... une simple application elle-même ... avec tous les inconvénients que cela draine : difficulté dans son administration, grosse consommation des ressources, architecture qui doit s'adapter aux particularités de chaque système sur lequel il doit s'installer, etc.
C'est inhérent à l'OS et à sa conception objet. Imagine que dans un environnement vraiment objet, tu ne fais pas d'appels indirect à une opération via une référence, mais tu envoie bien un message à un objet via sa référence. Donc, il est assez simple d'étendre de façon transparante ce mécanisme de messagerie pour qu'il soit distribué. La distribution étant gérée de façon transparante par l'OS.
Ce sont en quelque sorte des modules noyaux ... excepté que ce sont tout simplement de simples objets ...
Ha les idée préconçues ! Elles ont la vie dure !
Ce n'est pas parce qu'il y a des outils, pour faire de l'objet, mal foutus ou pas dédiés pour les couches basses, que des développeurs soit disant objet codent avec leur pied, que l'objet est pour autant pas adapté ou si limité que l'on se complait à dire (jusqu'à s'en convaincre).
Connais tu le langage objet Eiffel ? Sais tu que de l'autre côté de l'altlantique ils l'apprécient dans certains cercles de l'embarqué !
Après tout, on n'a pas besoin de l'objet pour faire des systèmes lourds : Windows par exemple :) Ou Solaris :)
Je vois que tu ne vois pas l'avantage d'un système objet. Par ces concepts même et par une implémentation bien faite il simplifierait bcp de choses. Cela avait commencé avec Unix : tout est fichier ... cela pourrait continuer avec un tel système : tout est objet, les objets peuvent-être implicitement distribués, ils peuvent s'interchangés, etendus, la communication/interaction inter-application s'en trouverait simplifiée puisque ce serait tout simplement de la communication inter-objet (tel objet envoie tel message à tel objet ou j'appelle telle méthode de tel objet). Même les documents seraient des objets !
Je pense que pour ce donner un apperçu d'un tel OS, il faudrait essayer squeak et l'imaginer en mieux et ce que cela pourrait donner en OS (ne pas se focaliser sur son interface graphique, mais plutôt sur les concepts qui s'y dessinent).
[^] # Re: Itanium c'est bien.
Posté par Miguel Moquillon (site web personnel) . En réponse au journal La renaissance de l'Itanium?. Évalué à 2.
Miguel
[^] # Re: Demo site ?
Posté par Miguel Moquillon (site web personnel) . En réponse au journal WAGEN. Évalué à 3.
Oui, c'est une bonne idée. Dès que j'aurais le temps, je le proposerai sur mon site avec des photos non personnelles.
[^] # Re: génial
Posté par Miguel Moquillon (site web personnel) . En réponse au journal WAGEN. Évalué à 2.
Tiens, j'ignorais. Je ne connais pas l'allemand. C'est marrant ça. On peut interpréter ça comme uen voiture qui parcours le chemin des photos :)
[^] # Re: génération des thumbs
Posté par Miguel Moquillon (site web personnel) . En réponse au journal WAGEN. Évalué à 2.
As tu eu des difficultés avec ?
# Pb de pédagogie
Posté par Miguel Moquillon (site web personnel) . En réponse au journal Pédagogie et installation debian. Évalué à 8.
Ensuite, comme l'a si bien dit précédemment Aurélien, tes propos n'étaient pas en accord avec peut-être l'attente de ton public.
AMHA, il aurait mieux valu d'abord les titiller en leur présentant GNU/Linux : qu'est ce que c'est, les applis que l'on trouve, les choix, l'installation / suppréssion d'un programme, etc. Bref, l'usage au quotidien d'un linuxien lambda (simple utilisateur). Pour ceux qui veulent faire du dev, une présentation des outils disponibles peut-être faite.
C'est ensuite, dans une autre séance, après avoir sensibilité précédemment le public à GNU/Linux, que tu peux leur proposer une démonstration d'install, voir une install-party.
[^] # Re: révolutionnaire !
Posté par Miguel Moquillon (site web personnel) . En réponse à la dépêche Java 2 Standard Edition version 5.0. Évalué à 3.
(Java signifie café en argo anglais.)
Sinon, par rapport au nullable type, une solution de conception du langage, plus élegant à mon avis, peut être celle d'Eiffel : un objet prédéfini Void qui est de type NONE, lui même descendant de toutes les classes de ton appli. Bref, autrement dit pas une bidouille que doit se tapper le développeur.
Je suis pour faciliter la vie des développeurs (donc au détriment du ou des concepteurs de langages). Malheureusement, c'est souvent l'inverse que l'on observe : le concepteur qui facilite sa vie au détriment du développeur qui doit utiliser son langage.
Par rapport à C# et .NET, je trouve que ce sont des outils interessant.
Le seul truc qui me fait tiquer, c'est qu'ils viennent de Microsoft et je me méfie de ses produits. Souvent c'est : au début ça parait super, à l'utilisation c'est finalement plus limité que prévu, et à la fin, au fur et à mesure des évolutions, c'est le cauchemar ... mais c'est trop tard (faut comprendre : l'existant, les licences, les développeurs qui ne connaissent que ça et tout ça).
[^] # Re: révolutionnaire !
Posté par Miguel Moquillon (site web personnel) . En réponse à la dépêche Java 2 Standard Edition version 5.0. Évalué à 3.
Il est vrai que la perception d'un langage "utilisable" dépend de chacun. Ma perception est : "s'exprimer simplement, de façon élegante, sans à faire du contorsionnisme ou du bidouillage pour arriver à mes fins et avec une syntaxe simple."
Ainsi, pour l'avoir utiliser, dans les langages à typage statique, la covariance et la généricité contrainte apportent une souplesse très importante.
Le fait aussi de pouvoir affiner la visibilité au niveau classe pour telles ou telles méthodes (par exemple, telle méthode n'est accessible que pour les objets de telle classe) permet d'implémenter de façon élegante un certain nombre de patterns (visual proxy, factory, etc.) sans se compliquer les méninges.
Je suis d'accord que Java et C# sont des langages de masse, et comme bcp de chose destinée à la masse, le résultat est obtenu par "un équilibre par le bas".
Quant à Smalltalk, AMHA je ne pense pas que c'est de la "masturbation intellectuelle" :) Je pense plutôt que c'est une façon de pensée différente de ce que l'on a l'habitude (un peu comme GNU/Linux pour les windowsiens). J'ai l'impression que toute notre vie, et particulièrement professionnelle, on nous "lobotomise", on nous "écrase" par nous imposer des limites dans notre champs de perception. Or, pour avoir codé avec, Smalltalk nous offre un moyen d'exprimer pleinement nos capacités, limitées ou non. Elle offre à notre perception ce qu'est en fait l'univers : infinie où toutes choses se mouvoient et changent ; chose que l'on a perdu, peut etre depuis l'enfance, à percevoir.
Une fois que tu connais la syntaxe de Smalltalk (qui n'est pas difficile en soit), et que tu as passé le plus difficile (un champs de perception non limitée), alors tu peux exprimer de façon très simple et élegante des solutions complexes.
Pour moi, la "masturbation intellectuelle" dans le développement est de trouver des solutions de coutournement des limitations d'un outil pour arriver à exprimer quelque chose qui se doit d'être évident. D'autant plus si les mécanismes de représenter simplement notre expression existe et avec une syntaxe simple.
[^] # Re: révolutionnaire !
Posté par Miguel Moquillon (site web personnel) . En réponse à la dépêche Java 2 Standard Edition version 5.0. Évalué à 2.
Déjà en avance pour son époque :)
AMHA, son auteur, Bertrand Meyer, en dehors de l'homme lui-même, a des idées et des conceptions que bon nombre d'entre nous, et particulièrement les concepteurs de langages objet, devrait s'inspirer.
Sinon, non, ce n'est pas qu'un langage d'université. Il est vrai qu'en France il est surtoût connu dans ce milieu. Mais aux Etats-Unis il est utilisé dans l'industrie et semble être apprécié dans certains cercles du milieu embarqué là bas.
Tu parles d'événements et de meta-donnés. Si tu veux vraiment faire de la méta programmation, je te recommande fortemement Smalltalk-80 ou Squeak (une version Smalltalk-80 orientée multimédia).
Quant à C#, je le vois avant tout comme une action marketing de Microsoft à l'encontre de Sun. C# 1.x est un java like de Microsoft, C# 2 est une avancée pour incorporer des mécanismes minimum que font de lui un langage objet à typage statique suffisamment utilisable (que Java n'était pas AMHA et qu'il va l'être avec Java 1.5), ceci afin de répondre à la réponse de Sun avec Java 1.5.
Si dans tout ça, nous développeurs, on trouve notre bonheur tant mieux.
[^] # Re: révolutionnaire !
Posté par Miguel Moquillon (site web personnel) . En réponse à la dépêche Java 2 Standard Edition version 5.0. Évalué à 1.
Par rapport à l'ajout de méthodes, ton lien ne me donne pas l'information escomptée.
Par rapport à la covariance (et à la contravariance), elle est plutôt restreinte. Applicable seulement aux méthodes de délégation (un mécanisme semblable aux agents d'Eiffel par exemple).
Par rapport aux autres goodies ... hum. Le nullable type n'apporte pas grand chose excepté si le langage a un pb de ... conception. Quant au mot clé 'yield' il est interéssant même si de grandes discussions ont encore lieux par rapport au bien fondé d'un pareil mécanisme.
[^] # Re: révolutionnaire !
Posté par Miguel Moquillon (site web personnel) . En réponse à la dépêche Java 2 Standard Edition version 5.0. Évalué à 1.
Je me pose la question par rapport au mot-clé 'out' que tu apportes comme solution.
La covariance est la faculté de raffiner le type des paramètres d'une méthode en sous-types.
Par exemple, covariance des paramètres et du résultat de retour :
Sinon, il apparaitrait que C# 2.0 intégrera la généricité contrainte (si j'ai bien compris). Il apparaitra, si j'ai toujours bien compris avec Visual .NET 2005.
A part ça, je comprends que les développeurs Microsoft s'exaltent face à C#. Jusqu'à présent, ils fallaient qu'ils se tappent Visual C++ ou Visual Basic. Deux langages qui n'ont d'objet que leur prétention (bon, d'accord, j'exagère), un peu comme bcp de développeurs d'ailleurs (ho la la, que je suis méchant, vraiment :) ).
Et tout d'un coup, on leur propose un langage des années 90, né au 21e siècle, C#. Pour eux, qui ne connaissent que le monde Microsoft ou qui sont condamnés à développer pour ses plate-formes, c'est une découverte ! Expérience vécue dans ma boite.