Discussion :

[FremyCompany]

Java posséde lui aussi les generics

Ceci est alors assez récent. Désolé, je ne savais pas.

XML Literal : C'est à dire ?

http://blogs.msdn.com/xmlteam/archiv...ruary-ctp.aspx

Ca dépend ... en fait, tout ça n'est qu'une version bridée et moche des closures, que ce soit en Java ou en C#.

Pas uniquement. Tu as aussi AddressOf en VB.Net qui te donne une référence à une fonction qui existe déjà.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Hum ... plusieurs dizaines de langages tournent sur la JVM.

Ce n'est pas la politique de Sun des les supporter. Ils existent mais sont quasi-nuls dans la pratique, contrairement à DotNet où on trouve tout du moins C# et VB.NET.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Graphiques tu veux dire ?

Oui, désolé de l'imprécision dont j'ai fait preuve.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Java2D et Draw2D font pareil.

Pas sûr. Tu sais dessiner sur une TextBox avec Draw2D ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Gné ? Peut être que c'est parceque le .net est plus un monde à un seul IDE ?

Non. C'est juste prévu dans le langage. SharpDevelop supporte cela de la même manière que VS.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Java possède un truc qui s'appèle annotations qui fait exactement ça.

Ce n'est pas tout à fait pareil. Les annoations ca sert juste à générer de la doc, non ?

[millie]

Ceci est alors assez récent. Désolé, je ne savais pas.

Ca date de 2004...

[sinok]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Java possède un truc qui s'appèle annotations qui fait exactement ça.

Ce n'est pas tout à fait pareil. Les annoations ca sert juste à générer de la doc, non ?

Non ce sont "les mêmes" qu'en .net et çà date de java 5, donc 2004 pour la release, la mise en place ayant été décidé bien avant comme pour les générics, les process de validation étant bien plus long pour java que pour .NET, c'est d'ailleurs un avantages de .NET, Microsoft étant seul décisionnaire dans ce cas, alors que Sun doit faire avec un gros panel d'entreprises intervenant au niveau des décisions, genre IBM &cie, quand on voit toute la controverse amené par la mise en place des closures à l'heure actuelle pour java7

[lacombefr]

est ce Java connait les mots clés ref et out que j'utilise en .NET ?

Ils permettent de passer en paramètre de méthodes des variables non initialisées par exemple.

Ca permet d'avoir des méthodes qui "retournent" plusieurs valeurs plutôt qu'une seule..

exemple :

public bool maMethode(int parametre1, out int valeurDeRetour1, out int valeurDeRetour2, ref string valeurDeRetour3)
-> ici la méthode "retourne" un bool mais aussi 2 int et un string (en fait "out" signifie que la valeur est null et que la méthode devra obligatoirement l'initialiser, tandis que ref est déjà initialisé on la passe juste en référence)

[djo.mos]

Pas uniquement. Tu as aussi AddressOf en VB.Net qui te donne une référence à une fonction qui existe déjà.

Non, ça n'a rien à voir avec les closures.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Hum ... plusieurs dizaines de langages tournent sur la JVM.

Ce n'est pas la politique de Sun des les supporter. Ils existent mais sont quasi-nuls dans la pratique, contrairement à DotNet où on trouve tout du moins C# et VB.NET.

Non. Sun supporte JRuby, et récemment Python aussi. Elle planifie aussi de supporter PHP.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Java2D et Draw2D font pareil.

Pas sûr. Tu sais dessiner sur une TextBox avec Draw2D ?

On parle de dessin là ou de contrôles graphiques ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Java possède un truc qui s'appèle annotations qui fait exactement ça.

Ce n'est pas tout à fait pareil. Les annoations ca sert juste à générer de la doc, non ?

[/quote]
Non, ça, c'est la javadoc != annotations.

[djo.mos]

est ce Java connait les mots clés ref et out que j'utilise en .NET ?

Non.

[Keihilin]

les process de validation étant bien plus long pour java que pour .NET, c'est d'ailleurs un avantages de .NET, Microsoft étant seul décisionnaire dans ce cas, alors que Sun doit faire avec un gros panel d'entreprises intervenant au niveau des décisions

Problème dont on a déjà parlé je crois.
Java = évolution concertée, donc lente.
.Net = concertation beaucoup beaucoup beaucoup plus limitée, donc évolution plus rapide.

Cela a comme effet de faire prendre de l'avance aux principaux langages de la plateforme .Net au niveau des fonctionnalités offertes et je pense que cela crée une saine concurrence. .Net a beaucoup appris et profité des "erreurs" de Java avant de sortir, et maintenant que le petit frère prend de l'avance, nuls doutes que Java peut/doit profiter des retours d'expériences de la communauté .Net.

Je pense que globalement les deux mondes suivent la même route et que même si les priorités respectives créent des décalages, la direction est la même. On peut à mon avis prédire que d'ici 5 ou peut être 10 ans, .Net et Java ça sera blanc bonnet et bonnet blanc.

N'en déplaise aux petits imbéciles intégristes des 2 bords, les leaders technologiques d'aujourd'hui sont des gens issus de .Net ou de Java et qui ont fait l'effort d'aller vers le concurrent pour, au final, être aussi à l'aise dans un environnement que dans l'autre en sachant tirer le meilleur de chaque monde et en critiquant de manière objective et constructive.

[gorgonite]

"Si on se basait sur l'orthographe de la personne...."

il est clair que je demanderais plus à Voltaire qu'à Linus de coder un OS

[EDIT]Je ferais aussi remarquer que mon frère de 12 ans joue à Bitefight aussi, ce qui prouve naturellement le degré d'évolution psychologique de gorgonite...

ou la matûrité exceptionnelle de ton frère

-------------------------------


Revenons à nos moutons...

Comme on dit "La vertu n'attends pas le nombre des années". Ce genre de commentaire n'aide pas à faire avancer le débat.

mais certaines choses ne s'apprennent que par l'expérience...

tu as clairement de fort a priori et un manque de "connaissance générale" des langages de programmation... ce qui rend parfois tes arguments quelque peu "calqués sur les trolls et/ou les aspects marketing"

Microsoft ne va pas séduire autant de monde avec DotNet (C# = 3e langage en entreprise, sans compter que VB.NET est aussi assez utilisé) si c'est un remake de Java. Si il a du succès, c'est qu'il fait mieux. Ou qu'il est mieux vendu, mais ca ne me semble pas trop être le cas, Sun ayant une politique de marketing assez conséquente, comme MS.

si la qualité d'un langage était un facteur déterminant pour son adoptation dans le monde professionnel... php ou vb6 n'auraient jamais été considérés comme des alternatives sérieuses

- Génériques (pas loin des Template C++, même si c'est différent car on ne peut pas utiliser d'expression, juste des types)

generics et template sont deux choses totalement différentes, les generics n'apportant que le polymorphisme paramétrique aux langages objets...

- Gestion du COM + acceptation de plusieurs langages et interactivité totale ou partielle (selon les specs des langages non-MS) de ces langages entre eux (C#, VB.NET, J#, F#, Ruby, COBOL.NET, PHP, ...)

il faut quand même avouer que le support de nombreux langages non supportés par Microsoft est parfois assez limité... voire ne consiste qu'en une encapsulation des librairies pour pouvoir les utiliser sous .Net (un peu comme si on prétendait que la JNI le fait)

- GDI+ est très facile à utiliser et très performant

beaucoup s'accordent pourtant à penser que c'est le point faible de windows... kernel32 avait été plutot bien fait, et GDI est venu (tout) gaché

- Possibilité d'avoir des attributs sur des classes, des propriétés, des méthodes, des champs, ...

je ne repasserais pas sur les attributs... mais il est clair que les propriétés sont un plus agréables

[EDIT]
LISP n'a pas le même objectif que Java.
Tout comme F# n'a pas le même que C#.
Comparons ce qui est comparable.

dans ce cas, Java est-il vraiment comparable à C# ?

il ne faut pas oublier que la JVM a été pensée pour être un émulateur de cpu... et on continue de le ressentir

par exemple, Sun se force envers et contre tout à garder une forme de compatibilité ascendante, et on a parfois droit à un jeu subtil de réécriture de bytecode à l'exécution pour revenir à des performances de VM moderne

Ca dépend ... en fait, tout ça n'est qu'une version bridée et moche des closures, que ce soit en Java ou en C#.

d'où l'intérêt de l'interopérabilité totale entre F# et C#... un point pour .Net

Hum ... plusieurs dizaines de langages tournent sur la JVM.

mais tout comme pour .Net rares sont ceux qui tourne efficacement dessus

- Type inférence

sous F#, il y a une vraie inférence de type... et donc une sûreté logicielle dès la compilation. mais ce n'est pas le cas des autres langages .Net

- Types et méthodes anonymes
- Expressions Lambda

encore une fois, sous F# ok, mais sous C# c'est trop limité

[djo.mos]

Envoyé par FremyCompany Voir le message
Hum ... plusieurs dizaines de langages tournent sur la JVM.
mais tout comme pour .Net rares sont ceux qui tourne efficacement dessus

C'est moi qui a dit ça

Au fait, en parlant du F#, je vais sortir mon atout (piques): Scala.
Donc, inférence de types, closures, pattern matching, xml directement dans le code, acteurs, fonctionnel à gogo, etc. le tout compilé vers du bytecode et s'exsécute aussi efficacement que Java

[gorgonite]

Au fait, en parlant du F#, je vais sortir mon atout (piques): Scala.
Donc, inférence de types, closures, pattern matching, xml directement dans le code, acteurs, fonctionnel à gogo, etc. le tout compilé vers du bytecode et s'exsécute aussi efficacement que Java

pour avoir été dans le labo de l'EPFL qui produit Scala durant mon stage de master, je peux te dire que ce n'est pas encore au niveau de F#

[djo.mos]

pour avoir été dans le labo de l'EPFL qui produit Scala

Arf ... mon atout s'est fait volatilisé ... je passes

[FremyCompany]

Non, ça n'a rien à voir avec les closures.

Oui, c'est ce que je dis, ce n'est pas des closures dans ce cas. On disait que le Délégués et les Evènement en .NET ce n'était qu'un utilisation des closures, je dis que ce n'est pas tout à fait exact.

Non. Sun supporte JRuby, et récemment Python aussi. Elle planifie aussi de supporter PHP.

PHP avec les libraires Java ? Ou PHP dans son éditeur de site web ? Il y a de la marge entre les deux....

On parle de dessin là ou de contrôles graphiques ?

En DotNet, cela n'a aucune importance. Tu peux dessiner sur des contrôles graphiques (comme la boite de texte, ....) en t'abonnant à l'event Paint, si cela te chante. Ou utiliser des contrôles graphiques dans un "dessin" (un panel avec une méthode abonée à Paint, en fait)

Non, ça, c'est la javadoc != annotations.

Ok, je n'ai rien dit dans ce cas. Il semble que mes connaissances de Java date de Java4. Il me manque pas mal de truc sur Java5. Je vais une fois me renseigner là dessus...

mais certaines choses ne s'apprennent que par l'expérience...

tu as clairement de fort a priori et un manque de "connaissance générale" des langages de programmation... ce qui rend parfois tes arguments quelque peu "calqués sur les trolls et/ou les aspects marketing"

Je ne te contredirai pas sur ce point. Je n'ai jamais affirmé avoir la connaissance absolue. Tu as absolument raison.

Si la qualité d'un langage était un facteur déterminant pour son adoptation dans le monde professionnel... php ou vb6 n'auraient jamais été considérés comme des alternatives sérieuses

Pour VB6, c'est tant la facilité de la syntaxe que le très bon éditeur GUI (très avancé pour l'époque et toujours pas mauvais pour aujourd'hui) qui a été déterminante. VB6 était un langage assez mauvais quand on parlait objet et tuti quanti. PHP est un langage tellement simple qu'il a été adopté par pas mal de gens. Mais c'est aujourd'hui sa faiblesse aussi (il gère l'objet mais les gens n'y sont pas habitués).

Generics et template sont deux choses totalement différentes, les generics n'apportant que le polymorphisme paramétrique aux langages objets...

Ils sont assez comparables selon moi dans "l'esprit". Mais c'est clair que la forme diffère du tout au tout et les manières de faire aussi.

il faut quand même avouer que le support de nombreux langages non supportés par Microsoft est parfois assez limité... voire ne consiste qu'en une encapsulation des librairies pour pouvoir les utiliser sous .Net (un peu comme si on prétendait que la JNI le fait)

Je ne suis pas d'accord avec toi sur ce point. Phalenger est un projet très abouti et facilement intégrable dans une appli C#.

D'ailleurs j'ai oublié le Ruby et le JScript.NET dans ma liste.

Beaucoup s'accordent pourtant à penser que c'est le point faible de windows... kernel32 avait été plutot bien fait, et GDI est venu (tout) gaché

Chacun son avis sur la question. Attention que GDI+ != GDI.

je ne repasserais pas sur les attributs...

Désolé, encore une méconnaissance de Java5

mais il est clair que les propriétés sont un plus agréables

Oh que oui !

Dans ce cas, Java est-il vraiment comparable à C# ?

Je le pense. Regarde tous les points communs que je leur ai trouvé. Et je n'ai pas poussé le vice jusqu'à comparer les FrameWorks.

sous F#, il y a une vraie inférence de type... et donc une sûreté logicielle dès la compilation. mais ce n'est pas le cas des autres langages .Net

Si si, maintenant ça l'est. C'était même indispensable pour LINQ.

encore une fois, sous F# ok, mais sous C# c'est trop limité

Pourquoi ? Ce sont les mêmes fonctions...

[gorgonite]

Pour VB6, c'est tant la facilité de la syntaxe que le très bon éditeur GUI (très avancé pour l'époque et toujours pas mauvais pour aujourd'hui) qui a été déterminante. VB6 était un langage assez mauvais quand on parlait objet et tuti quanti.

il est clair que pour les interfaces graphiques, c'était vraiment bien... perso à une époque je vais des GUI en VB6, et j'importais des dll C++ pour tout ce qui nécessitait un peu de prog propre

Je ne suis pas d'accord avec toi sur ce point. Phalenger est un projet très abouti et facilement intégrable dans une appli C#.

connais pas Phalanger, je pensais à Perl.Net et IronPython...

Chacun son avis sur la question. Attention que GDI+ != GDI.

arf, faudra que je pense à ouvrir mes yeux

Si si, maintenant ça l'est. C'était même indispensable pour LINQ.

Pourquoi ? Ce sont les mêmes fonctions...

ce n'est pas indispensable en fait...
disons que F# apporte une compilo qui fait pas mal de boulot, puis qui converti tout cela en bytecode, si je me souviens bien)
il devient alors facile d'utiliser ces classes dans un autre langage .Net ; mais rien n'oblige à disposer d'un procédé de compilation aussi efficace, seule une vérification des interfaces déclarées dans le bytecode est nécessaire

en gros, au moment où l'on fait l'export vers du code bytecode ou natif, on perd une partie de l'information et on se limite à ce qui est nécessaire à l'exécution et l'interopérabilité

c'est un peu la raison pour laquelle un dessambleur avec interprétation abstraite n'arrive pas à reproduire le code C d'origine, mais seulement un code dans un sous-ensemble de C
c'est d'ailleurs la raison pour laquelle je pense aussi que la JVM est trop fortement Java car le bytecode produit est facilement retransposable en Java

[LLB]

Encore quelques avantages (récents) de DotNet :
- Type inférence
- Types et méthodes anonymes
- Expressions Lambda

Il n'y a pas eu de modification dans .Net pour tout ça. C'est lié uniquement aux langages.

Hum ... plusieurs dizaines de langages tournent sur la JVM.

La JVM a été créée pour Java (astuce : regarde le nom). .Net a été créé pour être indépendant du langage : les spécifications ont été écrites dans le but d'être large et ne parlent pas d'un langage en particulier. Tout n'est pas parfait, mais c'est plutôt bien fait. Microsoft Research a d'ailleurs développé ILX (pour compiler vers le CLR des spécificités de ML) et la DLR (pour les langages dynamiques).

Côté langages dynamiques, la JVM a du retard, même c'est prévu (il me semble) dans la prochaine version. Côté langages fonctionnels, y en a-t-il un qui soit développé par Sun ? MS Research a fait beaucoup de recherche dans ce domaine là.

La JVM ne gère pas les generics. Le langage Java permet des generics, mais seulement grâce à un hack. Cela a quelques problèmes : les performances sont moindres et des informations sont perdues après compilation. Quelques recherches sur Internet montrent les problèmes liés aux generics dans Java. Pour comprendre l'implémentation des generics dans .Net, ce papier de D. Syme et A. Kennedy est intéressant : http://research.microsoft.com/~dsyme...s/generics.pdf

La JVM ne gère pas les appels de fonction terminaux. Toute fonction récursive en Java utilise donc la pile... ce qui me semble être une limitation énorme. Heureusement, certains langages (au moins Scala, il me semble) réussit à contourner cette limitation avec un goto. Mais cette astuce ne marche que pour le cas de la récursion simple.

(inférence de type dans Linq)
ce n'est pas indispensable en fait...

Certes, mais je crois que ça aurait été très désagréable sans inférence de type.

(fonctions anonymes)
Pourquoi ? Ce sont les mêmes fonctions...

En pratique, ce n'est pas tout à fait compilé de la même façon, même si c'est un détail.

Ce qui diffère surtout, c'est que les fonctions anonymes sont énormément utilisées en F# (notamment pour les fonctions d'ordre supérieur), alors qu'elles sont très rarement en C#. C'est une différence culturelle entre les deux langages (F# est clairement orienté fonctionnel) et cela se voit quand on compare les bibliothèques. Et F# bénéficie d'une vraie inférence de type.

connais pas Phalanger

C'est un projet très sympa, qui marche bien (on peut faire tourner PhpBB et plein d'autres logiciels - on peut même utiliser PHP pour faire des interfaces graphiques ou jouer avec Silverlight) et qui est efficace (il est bien plus rapide que l'interpréteur PHP officiel).

[Médinoc]

À ma connaissance, Java ne permet pas de créer ses propres types valeur, uniquement des types référence nécessitant une allocation (les seuls types valeur que connait Java sont les types primitifs).
Si une application doit faire beaucoup de calculs sur des Color ou des DateTime, les performances s'en ressentent...

J'allais aussi parler des limites de la JVM quant aux generics, mais cela a déjà été fait.

[el_slapper]

et puis Cobol ou Fortran sont des langages de niche, là ou C(et variantes), Java ou dotnet sont des langages généralistes. Cobol reste très efficace en traitements de gestion purs. Fortran aussi, dans son domaine. Evidemment, dès qu'on s'éloigne un poil du domaine de prédilection, ces langages sont à foutre à la poubelle.

DotNet et Java, donc, 2 plateformes à vocations généralistes, avec lesquelles on peut tout faire(sauf peut-être du FPS), mais avec des philosophies radicalement différentes. Du peu que j'en ai vu, je préfère dotnet, mais c'est tout sauf un avis informé(1 semaine de Java et 2 de dotnet.....).

[eclesia]

En DotNet, cela n'a aucune importance. Tu peux dessiner sur des contrôles graphiques (comme la boite de texte, ....) en t'abonnant à l'event Paint, si cela te chante. Ou utiliser des contrôles graphiques dans un "dessin" (un panel avec une méthode abonée à Paint, en fait)

Il n'y a pas de limite a ce dont est capable Java2D.
J'ai meme tendance a croire que swing est plus permisif que dotnet sur ce sujet la car Swing n'est pas du tout basé sur des composants natif. Tout est dessiné.

un petit exemple de ce qu'on peut faire avec Java2D avec une demi-jounée devant soi.
http://img155.imageshack.us/img155/1103/capture1bk0.png

et DotNet n'est pas l'avenir de Java comme tu semble le penser ... qu'est ce qu'il faut pas entendre ...
Que se soit un concurrent c'est normal, mais dire que c'est carrement l'avenir ... tu es loin de la realité.

[Tommy31]

Juste pour dire que Java évolue, et que la prochaine mouture prévoit les améliorations suivantes:

- XML litérals
- Closure
- Quelques idiomes supplémentaires le rendant moins verbeux

[FremyCompany]

Il n'y a pas eu de modification dans .Net pour tout ça. C'est lié uniquement aux langages.

Je réagirais juste là-dessus en disant que les méthodes lambda ont demandé pas mal de code en plus, notamment au niveau des conversions entre delégués de types différents.

Plus les délégués "génériques" de type Func(Of .....)

[LLB]

Je réagirais juste là-dessus en disant que les méthodes lambda ont demandé pas mal de code en plus, notamment au niveau des conversions entre delégués de types différents.

Plus les délégués "génériques" de type Func(Of .....)

Oui, mais seulement dans le compilateur C#, à ma connaissance. F# gère les fonctions anonymes depuis le début (2002).