Hive Arc a écrit 68 commentaires

"Ceci dit, si .NET tient ses promesses, ça va faire mal... " Quelles promesses ? Faire le menage, la cuisine, raser gratis ou faire des logiciels en un click ? MS.net est un solution produit plus du tout une "plateforme" ! Ainsi le comparer à Java est ridicule, si on veut trouver un concurent à mettre en face dans le monde Java on peut voir IBM Websphere ou Sun One ! Mais MS.net comme plateforme à part entiere est relativement virtuel. Ceci est confirmer par l'arret de l'utilisation des suffixes ".net" dans tous les produits cuvées 2003 et les opérations comerciales (TV, radio, ...). MS c'est rendu compte que ce qui compté c'etat le produit et pas le "virtuel". Au lieu de réver au "golem.net", on ferait peut-etre mieux de booster le projet classpath pour offrir une implementation d'une VM opensource, seul piece non-opensource a lors actuelle pour offrir une veritable alternative modulaire, performante et perenne au rouleau compresseur alimenté par la pompe à fric MS ! Agissez sur maintenant sur : http://www.gnu.org/software/classpath/ http://www.gnu.org/software/classpathx/

C'est de la pure propagande pro MS ! Non, mono n'est pas l'implementation libre de MS.net, tout simplement car il n'existe pas de spec complete de MS.net !!!! Ce qui a été (habilement) standardisé à l'ECMA (et en cours à l'ISO) c'est une SOUS PARTIE seulement de l'ensemble. Tout ceci reste du pipotage, et le seul but avoué de l'ensemble est de conforter Windows comme plateforme de référence du poste de developpement et d'eloigner toute alternative. Non mono n'est pas une implementation de .net et non, mono n'est pas une alternative à d'autres solutions libres (PHP/JBoss ...) ! Si le FUD comercial de MS arrive meme ici ou va-t-on ? dotNet ne sera JAMAIS disponible sur une plateforme non krosoft, dixit balmer qui a été clair sur le sujet ! Quand au portage eventuel, c'est niet etant donné qu'il n'y a aucune ouverture du code envisagé ! Enfin, une réecriture avec compatibilité (telle qu'envisagée par mono) est illusoire, sans code de reference et sans spec détaillée de l'ensemble des élements ! Une seule question reste : Qui peut encore croire à de tels "pipotages.net" ?

Et on fait comment pour soummetre un site à dir.com ?!?

http://compsoc.dur.ac.uk/whitespace/tutorial.php(...)

Whitespace rulezzzzz !
Il parait que MS à lancé un nouveau concept révolutionaire nommé tabular* (prononcer tabular star), il s'agit d'un clone de whitespace mais avec des tabulations, malgrés les dénégation de MS qui prétendent qu'il dérive des celebres "keyword" et logo !

Il semble même que le tabular* dispose d'un GCTK (Garbage collecto with troll killer), qui evite toute prise de tête inutile dans les forums ...

A suivre donc ;-)

en premier l'aspect penible : http://minilien.com/?er1EyEGraO(...)

Ensuite, le "temps monstre", c'est la raison pour laquelle Java utilise des type simple qui ne sont pas des objets !

Et savoir quoi utiliser peut être considéré comme une optimisation possible du code ... d'ou un OptimizeIt ... ou ton JProbe :P

.. la pratique.

Et ne pas generaliser c'est toujours mieux ...

J'aime les interface et j'aime l'heritage ;-)

Et c'est plutot ridicule, d'ailleur le choix du +=, on aurrait pu imaginer le << qui aurait été peut être plus "logique".... enfin, qu'importe car il y a pire comme syntaxe...

Au hazard, les attributs personalisés et leur passage de parametre ... ;-)

http://minilien.com/?E7gK3IALnu(...) (Un doc PDF sur la différence)

En gros pour faire simple (que les experts de la STL me pardonnent), on pourrait effectuer le travail necessaire au templating C++ simplement par le preprocesseur, il ne subsiste aucune trace au runtime et ne peut être présent que de façon spécialisée.

Dans le cas de la genericité, l'tuilisation du préprocesseur seul ne pourrait pas suffir car on peut voir le type parametré comme une "pré-condition" optionelle à une classe. Qui subsiste à l'execution, et qui peut étre à tout moment re-généralisé.

Si tu veux plus de detail, je te conseille la lecture de la JSR-014.


Et il n'y a aucun PB à ne pas connaitre qqch de nouveau ;-)

Chacun ayant une limite a ses conaissances, il vaut mieux toujours rester humble face la connaissance, et ta position t'honnores.

Un langage alternatif intérésant... mais il manque les Categories ;-)

http://minilien.com/?B2FTxO7FG1(...)

Ca c'est du concept genial que j'ai retrouvé nelle part.

L'idée d'une categorie est de rajouter des fonctionalités supplémentaires à une classe sans qu'elle entrent en compétition avec une classe (donc pas d'heritage necessaire, pais pas de surcharge authorisé pour la categorie)

Cela permet par exemple d'ajouter un comportement de persistence ou d'affichage, totalement indépendant du code métier.

En some un précurseur de la prog orienté aspect ;-)

D'apres ce que j'ai comprit, ton compilo est en Java mais l'assembleur généré n'est pas 100% bytecode, pourquoi ne pas utiliser la VM à 100% pour le runtime ?

Car l'avantage que tu met en avant pour le compilo : la portabilité, se retrouverais aussi pour l'execution ;-)

Excuses moi par avance si j'ai mal comprit le principe de nosica.

... et la 1.4.2 a comme code "mantis" ;P

Chacun est libre de son choix ;-) En premier, avec des "si" on fait toujours bcp de choses. Ainsi, le format des DOC n'est : ni ouvert, ni standardisé, ni propre, ni même stable ... alors si openoffice voulais l'utiliser par défaut il faudrait plutot dire, de quel format DOC tu parles, celui de OfficeXP, 97, 95 ou le format MS-XMLizé ;-) Pour moi, je préfere clairement utilisé une spec dont tout est clairement définit et qui fonctionne partout : PDF ... faute de pouvoir utiliser FO ;-) On ne peut pas vraiment comparé un tel b*rdel MSien, avec une techno dont l'ensemble des specs, des documentation et des codes sources sont disponibles pour le public. Je comprend ta frustation par rapport à certains choix de java, mais là encore, Java n'es pas un langage d'expert mais bien généraliste. Oui, tel ou tel langage, fait mieux, plus concit, plus efficace pour tel ou tel point. Mais il n'en reste pas moins, qu'il reste relativement efficace pour pour une grande majorité de besoins. Et par experience, les cas ou il se revele moins adequat sont compensé par les gains (souplesse, simplicité) réalisés sur le reste du developpement. Enfin, si tu as suivit l'histoire de Java tu as put te rendre compte, que les utilisateurs Java son des gens plutot ouvert au débat et sensible à la découvertes d'autres techno (OS, langages, concepts ...). Java dans sa forme actuelle n'est pas une finalité, mais une étape pour plus d'ouverture. Si tu aimes les defits linguistiques regarde Kiev et OpenJava, 2 langages trés interessants par leur concepts : http://minilien.com/?Leh6p2bYVK

Que si la chaine est définie implicitement, style "test" dans : String a ="test"; String b ="test"; if(a==b){ // oui :o) } Alors cette chaine sera membre du pool de constante, et l'on pourra tester avec joie un == entre les deux, car il n'existe qu'une seule occurence d'une instance de String ayant la même valeur dans le pool. Ainsi , a et b pointant sur le même objet, le test sur les références sera vrai ;-) Pour ajouter une chaine explicite au pool de constante on peut utiliser la methode .intern(), qui retourne une référence sur une chaine identique mais présente dans le pool. Pratique pour optimiser certains algo ;-) Genre, "au hazard", le calcul de clé de hachage ou le tri de chaines dans un tableau à clé ... A noter que tout celà fonctionne car la classe String est dit non modifiable (unmutable string).

Bien sur, en Java ceci est comme indiqué une exception. Mais je te ferais remarquer au passage, que la façon de compiler en assembleur le resultat n'est pas vraiment définit avec précision dans les 1eres specs. Ainsi, bcp l'on deja noté, entre javac (v6) et jikes (par exemple), il y a un légere différence. Pour en avoir le coeur net, decompile ton bytecode (en ayant prit soit de ne pas l'avoir obscurcit). Lorsque je parlais de semantique cachée, je voulais dire que voir : client << product + qte; n'est pas forcement trés clair, et que lorsque tu as à voir bcp de code en revue (qui n'est generalement pas ton code), si tu dois avant de tenter de comporendre et maitriser la semantique des opérateurs sela ne simplifie ni ne rend rapide la compréhensio du code. client.order(product,qte); Dans le premier cas, non seulement se pose le PB de la semantique de '<<' et '+' mais également la question d'objet traditionel, à qui celà s'applique ! Pour quelqu'un qui s'est mit à l'objet sur le tard, cela semble bizzare, car il a vecu avec la notion de précédence omniprésente pour lire des choses du style : (int *) f[] (CHAR *href ...) Mais, est-ce que de telles choses sont vraiment si indispensable que cela ? Si tu fais des claculs sientifiques toutes la journée, alors oui peut-être ... mais pour la majorité d'entre nous qui fait plutot de l'algorithmique, je n'en suis pas vraiment sur. Enfin, je te rassures si tu veux faire de de la surcharge d'opérator va sur http://minilien.com/?jF4qfYTgy8 et fait ton choix ;-) Je te propose de joindre le debat sur la JCP, et de proposer tes idées. On sais jamais peut-etre feras-tu.penser la balance ...

Car on trouve par exemple pour Tiger (le code de la 1.5),
une proposition d'introduction du autoboxing

http://minilien.com/?uyQm2hDFMK(...)

Par contre pour ce qui est de la genericité, et du reste, alors que chez MS cela reste au niveau du lab, on en est plutot au niveau de la derniere ligne droite du coté Java ...

Car la genericité, cela n'est pas une "lubie", mais bien une decision longtement débatue et réfléchie. Et sera présente dans la 1.5 avant la fin de l'année !

Sur ce point, il va etre interessant de noter les retards prit par les editeurs d'IDE Java, et il se peut bien que les outils opensource soit les premiers à proposer la compatibilité langage 1.5 ;-)

(cf. la completion, le debug, etc ...)

Pour finir, la JSR-045 semble être quelque chose d'interressant http://minilien.com/?53EJIPmK9p(...)

Car elle permetrait ainsi de faciliter l'intégration de la foultitude de langages developpés pour la plateforme Java
http://minilien.com/?jF4qfYTgy8(...)

Tiens, c'est marrant mais cela me rappelle qqch, une plateforme avec plusieurs langages qui compile pour un meme bytecode ;-)

pour les opérateurs !

Je comprend l'interet de définir une synthaxe plus courte. Et j'en ait moi même fait l'utilisation pendant longtemps en C++.

Mais à quoi cela sert-il si on en comprend pas la semantique sous-jacente ? ou si cette semantique n'est pas constante ?

Quelle semantique assiger à << ou [] ? sur une liste, cela est facile, mais sur des objets plus métiers, cela reste plus "obscur" :(

C'est un peu la même règle qui à mené Borland et Sun à définit la spec JavaBean et qui vise à ne pas cacher une semantique sous des attraits "sexy".

Bien sur, on aime avoir des expression simple, mais à l'heure ou l'on a des outils qui font de la complétion une règle, pourquoi souhaiter abbréger à tout prix.

Il faut penser qu'en java la notion d'opérateur existe, puisque par exemple on peut faire la chose suivante :

String a = "test";
String str = "un "+a;

Mais ceci reste l'exception qui confirme la règle ;-)

Une pré-version de la genericité en Java
http://minilien.com/?bqvde3x13R(...)

Des implications de la genericité, un "for" amélioré dans le 1.5:
http://minilien.com/?qQ1hWSQfaM(...)

J'attend avec impatience la 1.5, car vraiment la genericité telle qu'elle a été implementé est un régal qui va faire oublier les cauchemards des template C++. Ceux qui ont déja joué avec le debogage de templace C++ me comprennent je pense ;)

La "normalisation" de C# n'as pas vraiment d'impact notable sur l'avenir de MS.net comme veritable plateforme concurente de Java.

Car, malgrés l'excelente communication de MS sur le sujet (les FUD diront certains), le processus de standardisation n'a d'importance que lorsqu'il sert au plus grand nombre et lorsqu'il est significatif. Ce qui aurrait pu être le cas si MS avait standardisé intégralement l'ensemble de la plateforme. Or il n'en est rien. Ainsi seul les éléments fondateurs l'ont été (comme C# par ex), mais rien sur les elements un peu plus consitutifs qui font sa specificité.

Force est de constater que MS est de plus en plus seul sur sa plateforme et que l'on constate même certains "bastions" VBistes sont tentés par les sirennes de Java.

Du coté de Sun, si le spectre de voir MS récupérer Java semble s'eloigner, je doute qu'il soit encore suffisament loint pour qu'ils envisagent un opensource intégral. En effet MS serait "trop content" de pouvoir faire une annonce du style "MS.net compatible Java !", histoire de recuperer tout le parc existant des applicatifs Java et des developpeurs ... pour bien sur passer à Studio :)

Enfin, il ne faut pas oublier que Sun, n'est plus le verritable maitre de Java, ainsi comme indiqué plus tot dans le fil, l'adoption de la genericité (solution comparable au template C++ ) pour le 1.5, s'est faite contre leur avis (poussé principalement par gosling, pour qui cela n'etait "pas necessaire"). Or le processus JCP est maintenant définit de façon à ce que tout soit public et les votes fait de façon ouvertes.

Ce qui ne manque d'ailleur pas de démontrer les tentatives de certains de tirrer la couverture de telle ou telle spec au plus prés des specification de leur produit (cf. la derniere spec J2EE et la tentative d'IBM de passer en force ...).

En fait, pour que Java soit de plus en plus un element moteur de la percée de linux, il ne manque plus guere que la volonté de certains guru de tux de ne plus voir Java comme un ennemi, mais comme une opportunité de vrai liberté de choix de plateforme.

Ainsi, il n'y a plus guerre de raison à ce que le projet GNU-ClassPath, n'accouche pas bientot si tout le monde est de bonne volonté et arrete de transformer Linux en cloche-merle.

A chacun de voir ce qui est vraiment important ...

http://minilien.com/?Yg7iSOgAsL(...) (Le PLAF GTK+)

Je l'avais raté celle là ... Merci !

Il semble par contre que ce PLAF (pluggable look and feel) ne sera considéré que natif dans le futur 1.5.
Sur ce point, on peut esperer que si la communauté, marque son interret, il soit basculé bien avant pour la finale du 1.4.2 <:o)