Discussion :

[JeitEmgie]

Méthodologie de comparaison de quoi ?
- de la syntaxe du langage ?
- du nombre de classe/methode de la libraires ?
- du nombre de lignes de code pour faire un solitaire ?
- du temps passé a comprendre la philosophie du langage ?

Est-ce que tu penses vraiment qu'on peut faire une grille de criteres exaustive qui caracterise un langage/framework ?

il ne s'agit pas d'exhausitivité…
mais de regarder des cas précis de résolution de patterns de problèmes récurrents qui surgissent habituellement dans des situations types…
… problèmes qui classiquement ne sont pas abordés dans les tutoriaux de la plupart des environnements parce qu'ils ont une facheuse tendance à mettre en évidence leurs sales côtés…

la syntaxe des langages est une problématique relativement secondaire, sauf à attirer l'attention sur d'éventuelles constructions sources fréquentes d'erreur qui peuvent asser outre la vérification syntaxique du compilateur (genre le = et le == du C… du temps où il n'y avait pas le warning adhoc…)

le nombre de classes/méthodes d'une librairie n'a d'intérêt à être relevé que si cela traduit une erreur dans l'abstraction du problème censé être représenté par la classe ou un manque par rapport aux fonctionnalités encapsulées (par exemple une classe SSL qui ne donnerait pas accès à toutes les fonctionnalités sous-jacentes de SSL…)

le nombre de lignes de code pour des exemples triviaux n'a pas beaucoup d'intérêt, mais passer de 130.000 lignes à 48.000 tout en ayant plus de fonctionnalités couvertes, est une situation digne de commentaires…
(non, je rassure tout le monde, si l'exemple est réel, il ne concerne ni Java ni .Net…)

et comparer le temps qu'a mis X à comprendre Chose et Y à comprendre Machin ? … sans commentaire…

Moi je ne le pense pas. Je fais peux faire une grille de criteres exaustive qui caracterise ma problematique. Et ensuite regarder si tel ou tel langage/framework est plus ou moins bien adapté a mon probleme.

il n'y a pas que le problème du choix, qui sera souvent guidé par des critères externes (expertise acquise, environnement du client, …) , il y a aussi l'évaluation des coûts, du temps nécessaire, et des "risques" : les points - parfois annexes, donc souvent sous-estimés - qui font perdre du temps…

Il n'y a pas de formule magique qui te donne le meilleur langage/framework avec des criteres vagues comme (je te cite) la "classique" situation de devoir présenter à l'utilisateur une liste d'objets dont il pourra "éditer" ou "supprimer" des objets existant, et en "créer" de nouveaux…"

de nouveau cette manie de répondre avant de lire et de comprendre :
d'abord je ne cherche pas de formule magique, ensuite "la classique situation de la liste d'objets" n'est qu'un contexte pour aborder des petits problèmes qui peuvent vite se transformer en casse-tête avec certains frameworks :

que l'utilisateur puisse ordonner les colonnes à sa guise, décider celles qu'il voit et que cette customisation soit sauvegardée automatiquement d'une cession à l'autre ...

imaginons que N colonnes représentant des états booléens, mais que pour chaque ligne ce groupe de N colonnes doit se comporter comme un groupe de bouton radio, donc quand l'utilisateur met à ON l'une des colonnes qui était à OFF, celle qui était ON doit passer à OFF…

l'application a besoin de lignes dont la hauteur est dynamique et différente
de ligne en ligne

l'application a besoin d'entête de colonnes dont le contenu est une image…

d'entêtes de colonnes sur plusieurs lignes…

etc.


et bien sûr je ne prends ce contexte de GUI et de liste d'objets qu'à titre d'exemples car tout le monde peut visualiser mentalement de quoi l'on parle…
mais on pourrait s'amuser de même dans d'autres domaines comme par exemple l'incorporation d'un outil de bug reporting automatique dans une application en beta test…

(on remarquera que jusqu'ici personne n'a encore posté pour aucun des petits exemples : "cela je vois comment le réaliser : il faut faire 1, 2, 3, …")

et certes je ne m'attends pas à voir surgir des réponses en noir et blanc à ce genre de comparaison, les situations justifiant un no go pour l'une ou l'autre technologie devant être l'exception (enfin… c'est à souhaiter pour les "combattants" …)
mais on pourrait espérer voir un peu plus clair dans les points forts et faibles, surtout ceux que le hype marketing de l'un et l'autre essaie de cacher…

On pourrait aussi aborder les questions relatives à la qualité de la documentation :
lorsqu'on pousse un environnement à ses limites, on est toujours confronté au besoin de sous-classer, or pour bien sous-classer, on est parfois amené à comprendre quelles méthodes originales sont appelées, dans quel ordre et par qui.
Quid de la doc à ce sujet ? Et si ce n'est pas documenté, quels sont les moyens pour le découvrir ?

[heid]

Quid de la doc à ce sujet ? Et si ce n'est pas documenté, quels sont les moyens pour le découvrir ?

dvp.com quelle question !

[JeitEmgie]

dvp.com quelle question !

la question signifie en clair :

a. est-ce les éventuels système d'obfuscation de code mis en place par le fournisseur de la technologie pour la "protéger" vous empêche oui ou non d'utiliser les techniques simples et habituelles (points d'arrêts et backtrace…) pour réaliser ce que vous voulez…

b. est-ce que la technologie est suffisament stable d'une version mineure à l'autre pour ce que vous auriez découvert soit toujours d'application à la prochaine mise à jour ou est-ce que ces éventuels changements sont documentés…

etc.

[super_navide]

y a t'il un équivalent de l'exelent java monkey engine en C#
y a t'il un équivalent de groovy en c#

de plus moi je pense que JAVA et la depuis longtemps j'ai mis pas mal de temps à matriser la syntaxe et toutes les APIS et framework de java , Swing Instrumentation Proxy WeakReference ClassLoader , les génériques les anotations les classe internes , mécanisme de synchronisation , groovy , Servlet , Applet ,Java Hot Spot ,java debug interface etc...

Je ne vait pas tous reprendre de zéro avec un nouveau langage , et je pense que pour une société c'est pareil former des gens pour être capable de faire la même chose sous C# à un coup énorme.


de plus les docs sur java il y en bcp plus que sur C# donc le choix est vite fait Java

[berceker united]

y a t'il un équivalent de l'exelent java monkey engine en C#
y a t'il un équivalent de groovy en c#

de plus moi je pense que JAVA et la depuis longtemps j'ai mis pas mal de temps à matriser la syntaxe et toutes les APIS et framework de java , Swing Instrumentation Proxy WeakReference ClassLoader , les génériques les anotations les classe internes , mécanisme de synchronisation , groovy , Servlet , Applet ,Java Hot Spot ,java debug interface etc...

Je ne vait pas tous reprendre de zéro avec un nouveau langage , et je pense que pour une société c'est pareil former des gens pour être capable de faire la même chose sous C# à un coup énorme.


de plus les docs sur java il y en bcp plus que sur C# donc le choix est vite fait Java

T'inquiète pas, une entreprise étant sur java ne va pas refaire ou évoluer son produit sur C#. ça serait un choix catastrophique.
Tu as peur de changer et pourquoi ? Entre java et c# l'orthographe n'est pas très différente. N'oublions pas que microsoft à "pompé" sur sun de ce point de vue. En a profité pour faire des améliorations. Si tu as réussi a trouvé ton nid dans Java tu trouveras les même reflexe pour c#. Je pense que tu as acquis un méthodologie avec java donc elle sera aussi valable pour l'autre. Maintenant, si tu n'as pas besoin de c# te prend pas la tête mais c'est dommage de ne pas s'y intéressé.

[Damien69]

Bonjour, j'ai pas lu tout les post, mais le peut que j'ai lu parle surtout des GUI et de l'intégration dans les OS. Quand j'ai commencé la programmation j’ai hésité entre java et .net finalement j’ai opter pour java et mon choix c’est basé plutôt sur le choix des application pour faire tourner mon développement WEB , le fait que tournant sur windows et linux je puisse utiliser mes application dans les deux OS. Chaque langage a ces inconvenant et avantages. Quand je vois des postes ou on parle de transparence dans les fenêtres etc. possible avec .net et pas java c’est quand même limite. Je pense que le plus important c’est de savoir si un langage convient au projet, savoir si on veut être bloquer avec Microsoft ou pas. Savoir si les API et framework sont disponible dans tel ou tel langage pour pas à avoir a réinvente la roue et la robustesse des applications. Le sujet est trop vaste pour faire un débat. Je travail pour une entreprise qui a fait le choix de J2EE afin de pas de pouvoir utiliser des serveur linux aussi car le langage et les API sont éprouvé, en entreprise je pense pas que l’on choisisse un langage car en .net un bouton peut faire un feu d’artifice en une ligne de code alors qu’il en faut 10 en java. De toute façon il y a aura toujours de fan de .net et de java. Pour ma part je développe en java mais si j’ai besoin je passerais sous .net, il faut pas oublié qu’un langage n’est qu’un outil pour créer et pas une fin en soit. Pour conclure pour moi un langage se choisie plutôt en fonction du projet, la volonté ou non de pouvoir l’utiliser sur plusieurs plate-forme, le choix du serveur pour le déploiement, sont efficacité pour faire tel ou tel chose. Par exemple AGF développe encore en cobol car le langage est adapté pour leur besoin.

[pseudocode]

@JeitEmgie:

Je comprend bien ce que tu veux faire: savoir quel est le langage/framework permettant de realiser le plus "facilement" les "problemes" que TU estimes "récurents".

Comme tu le dis toi meme, le choix d'un langage/framework ne se limite pas a la "facilité du developpement". C'est meme generalement ce qui compte le moins, car les contraintes "externes" sont souvent beaucoup plus prioritaires (cout, delai, license, formation, environnement, ...)

Ton exemple "récurents" d'IHM est sympa, et va surement attirer des commentaires interessants du genre "je peux le faire facile en Java", "je peux le faire encore plus simple en C#", "ca prend 20 lignes de SWT", "Battu. 18 lignes de xaml", etc...

Quand aux outils de documentation, ca fait partie de ce que j'ai appelé les caracteristiques de la problematique, au meme titre que ton "bug reporting", ou ton "ergonomie de selection de colonnes".

C'est une liste de criteres qui te permettront de choisir (ou ne pas choisir) ton langage/framework. Mais je ne vois pas pourquoi on limiterai ce choix a Java ou C# ? Une appli Access 2007 ne serait elle pas plus simple dans ce cas ? Et pourquoi pas C++ & QT ? ou un client riche Flash ?

Je pense franchement que poser un exemple récurrent et comparer les "implementations" en Java/C# n'apportera aucun element permettant de départager les 2 plateformes... Tout simplement parceque, comme l'a dit adiGuba, la difference est au niveau de la philosophie (= les objectifs) des deux plateformes, et pas au niveau du code généré.

[berceker united]

Bonjour, j'ai pas lu tout les post, mais le peut que j'ai lu parle surtout des GUI et de l'intégration dans les OS. Quand j'ai commencé la programmation j’ai hésité entre java et .net finalement j’ai opter pour java et mon choix c’est basé plutôt sur le choix des application pour faire tourner mon développement WEB , le fait que tournant sur windows et linux je puisse utiliser mes application dans les deux OS. Chaque langage a ces inconvenant et avantages. Quand je vois des postes ou on parle de transparence dans les fenêtres etc. possible avec .net et pas java c’est quand même limite. Je pense que le plus important c’est de savoir si un langage convient au projet, savoir si on veut être bloquer avec Microsoft ou pas. Savoir si les API et framework sont disponible dans tel ou tel langage pour pas à avoir a réinvente la roue et la robustesse des applications. Le sujet est trop vaste pour faire un débat. Je travail pour une entreprise qui a fait le choix de J2EE afin de pas de pouvoir utiliser des serveur linux aussi car le langage et les API sont éprouvé, en entreprise je pense pas que l’on choisisse un langage car en .net un bouton peut faire un feu d’artifice en une ligne de code alors qu’il en faut 10 en java. De toute façon il y a aura toujours de fan de .net et de java. Pour ma part je développe en java mais si j’ai besoin je passerais sous .net, il faut pas oublié qu’un langage n’est qu’un outil pour créer et pas une fin en soit. Pour conclure pour moi un langage se choisie plutôt en fonction du projet, la volonté ou non de pouvoir l’utiliser sur plusieurs plate-forme, le choix du serveur pour le déploiement, sont efficacité pour faire tel ou tel chose. Par exemple AGF développe encore en cobol car le langage est adapté pour leur besoin.

Amen
Il faut choisir un language parce qu'il peut faire ceci cela, encore moin si c'est pas utile pour le projet.
J'ai remarqué que beaucoup de développeur prenait une orientation plus pour s'amuser avec que pour le bien du projet. Et là, il y a deux logiques qui s'affronte. La logique entreprise qui elle pense au rapport temps/coût. Le développeur qui lui pense "Je voudrais bien m'amuser avec". Au final, beaucoup d'entreprise s'oriente vers du php . La, le développeur java, .net ou autre commence à rochonner en disant "ouais mais c'est de la merde il est pas puissant, il peut pas faire ceci et cela", le gars lui répond - Mais attend c'est juste pour faire un intranet.
Tout cela pour dire qu'il y a des languages adapatés au besoin. C'est pas le language qui décide de l'orientation du projet.

[pseudocode]

Pour conclure pour moi un langage se choisie plutôt en fonction du projet, la volonté ou non de pouvoir l’utiliser sur plusieurs plate-forme, le choix du serveur pour le déploiement, sont efficacité pour faire tel ou tel chose.

[JeitEmgie]

@JeitEmgie:

Je comprend bien ce que tu veux faire: savoir quel est le langage/framework permettant de realiser le plus "facilement" les "problemes" que TU estimes "récurents".

… encore une fois, ce ne sont que des exemples…
… on peut en faire des pages et d'un autre genre, et cela sans même parler de GUI…
et ce n'est pas que JE les estime récurrents, ce sont des questions du type FAQ extraites de forums de développement de différents frameworks…

Ton exemple "récurents" d'IHM est sympa, et va surement attirer des commentaires interessants du genre "je peux le faire facile en Java", "je peux le faire encore plus simple en C#", "ca prend 20 lignes de SWT", "Battu. 18 lignes de xaml", etc...

mais ce n'est pas cela (le nombre de lignes) qui est intéressant…
c'est que la manière (sous-classe, filtrage pre- post- opération, délégation, … : quels paradigmes doivent-ils être mis en œuvre pour arriver à la solution ?)
de résoudre ces snippets va révéler beaucoup sur la nature même d'un framework… le degré de liberté laissé au développeur, l'originalité de ce qu'il pourra produire et à quel "coût" : par exemple, si parmi les critères du cahier des charges il y a quelque chose du genre :
l'application visant une clientèle d'utilisateurs particuliers, l'éditeur du logiciel ayant une forte image, il ne veut pas que son produit puisse être étiquetté au premier coup d'œil : "développé en machin-chose" …
quel surcoût cela implique-t-il ?

Quand aux outils de documentation, ca fait partie de ce que j'ai appelé les caracteristiques de la problematique, au meme titre que ton "bug reporting", ou ton "ergonomie de selection de colonnes".

… ce ne sont que des exemples…

[QUOTE=pseudocode]
C'est une liste de criteres qui te permettront de choisir (ou ne pas choisir) ton langage/framework.
[quote]
au-delà du choix : l'évaluation des délais pour réaliser quelque chose de précis…

Mais je ne vois pas pourquoi on limiterai ce choix a Java ou C# ? Une appli Access 2007 ne serait elle pas plus simple dans ce cas ? Et pourquoi pas C++ & QT ? ou un client riche Flash ?

et bien d'autres encore…
…bien volontiers…

Je pense franchement que poser un exemple récurrent et comparer les "implementations" en Java/C# n'apportera aucun element permettant de départager les 2 plateformes...

je ne pose pas un problème récurrent, j'utilise un exemple simple à comprendre, pour demander que l'on parle méthodologie de comparaison…

et je me fous de départager les 2 plate-formes…

Tout simplement parceque, comme l'a dit adiGuba, la difference est au niveau de la philosophie (= les objectifs) des deux plateformes, et pas au niveau du code généré.

et alors ?
qu'il y ait une différence de philosophie ne signifient pas que les terrains d'application soient totalement disjoints…

et si un environnement est choisi pour des raisons externes ou au contraire parce qu'il a un point fort particulier, les problèmes de surcoût, de dépassement de délai… auront évidemment lieu la plupart du temps dans les parties d'un projet où l'on est confronté aux points faibles de la technologie choisie, même si c'est pour des "petites" parties du projet…

[pseudocode]

@JeitEmgie:

J'ai l'impression que tu amalgames les problematiques de conception et les problematiques d'implementation.

Ce que tu enumeres dans "sous-classe, filtrage pre- post- opération, délégation, paradigmes, questions du type FAQ extraites de forums de développement, ... " ce sont des problemes de conception.

La réponse a ces problemes n'est pas du type ".net" ou "J2SE", mais plutot du type "Styles d'architecture X" ou "Design-Pattern Y".

Ce que tu enumeres dans "snippets, degré de liberté laissé au développeur, l'originalité de ce qu'il pourra produire" ce sont des problemes d'implémentation.

La réponse a ces problemes n'est pas non plus du type ".net" ou "J2SE", mais plutot du type "Bonne pratiques", "tutorial" ou "exemple".

Quand a une "methodologie de comparaison" basée sur des "snippets" de code qui "révélent la nature d'un framework"... bof... j'y crois pas trop.

[JeitEmgie]

@JeitEmgie:

J'ai l'impression que tu amalgames les problematiques de conception et les problematiques d'implementation.

Ce que tu enumeres dans "sous-classe, filtrage pre- post- opération, délégation, paradigmes, questions du type FAQ extraites de forums de développement, ... " ce sont des problemes de conception.

l'interrogation est : jusqu'à quel point les choix conceptuels qui prévalent dans telle architecture influence-t-ils la solution finale et ce y compris dans les formes d'implémentation qui en seraient favorisées, voire imposées ou au contraire défavorisées voire proscrites…

et ce n'est pas un amalgame, mais bien le cœur du travail : le dialogue permanent entre conception et implémentation… c'est lui qui entraîne l'évolution des produits…

La réponse a ces problemes n'est pas du type ".net" ou "J2SE", mais plutot du type "Styles d'architecture X" ou "Design-Pattern Y".

mais les architectures .Net et Java+X sont basées sur des design patterns, (enfin c'est à espérer…) donc, question pour quelqu'un de "l'extérieur" : à quel point ces architectures et les choix qu'elles sous-entendent, influencent-ils mes propres choix de design pattern…

Ce que tu enumeres dans "snippets, degré de liberté laissé au développeur, l'originalité de ce qu'il pourra produire" ce sont des problemes d'implémentation.

mais si ce sont des spécifications d'un cahier des charges, ce sont aussi des problèmes "contractuels"…
et nettoyer un cahier des charges en faisant des allées et venues entre l'aspect conception et des problèmes d'implémentation nécessite des réponses autres que des truismes…

La réponse a ces problemes n'est pas non plus du type ".net" ou "J2SE", mais plutot du type "Bonne pratiques", "tutorial" ou "exemple".

mais je me moque du problème ".net" ou "J2SE"…
il est souvent résolu par des choix "supérieurs"…
une fois le choix imposé, tout ce qui est "naturel" pour l'outil choisi ne posera pas de problèmes particuliers ou posera les problèmes "habituels", mais comment l'environnement réagit-il à des sollicitations inhabituelles ?
Les 80% du code écrit en 20% du temps sont peu intéressants,
les 20% du code qui nécessitent 80% du temps sont toujours beaucoup plus "amusants"…

Quand a une "methodologie de comparaison" basée sur des "snippets" de code qui "révélent la nature d'un framework"... bof... j'y crois pas trop.

ce n'est pas une question de religion…
si un vendeur vous dit que son produit peut "le" faire, ce n'est pas sur des généralités ou des démos prémachées que vous saurez si sa définition de "faire" correspond à la vôtre…

mais il faudrait que quelqu'un me montre au moins une solution - sans entrer dans les détails d'implémentation, les "steps" à réaliser suffisent - d'un des problèmes posés…

… et le fait que rien ne vienne est déjà une réponse en soi…

[pseudocode]

Qu'entends tu par "les architectures .Net et Java+X" ?

- L'architecture de la Machine virtuelle et des librairies ?
- Ou, plus certainement, l'architecture des applications developpées ?

Dans ce dernier cas, les 2 frameworks ne t'imposent aucun motif de conception. Tu peux faire du Call-n-Return, de l'Aspect, du procedural, du blackboard, du massivement parallele, ...

C'est a toi de choisir ta conception puis d'evaluer quel framework correspond le mieux. Si tu veux faire du MVC en java pour une appli Desktop, prends Swing. Si tu veux faire du MVC en C# sur une appli web, prends Asp.net. etc...

l'interrogation est : jusqu'à quel point les choix conceptuels qui prévalent dans telle architecture influence-t-ils la solution finale et ce y compris dans les formes d'implémentation qui en seraient favorisées, voire imposées ou au contraire défavorisées voire proscrites…

L'influence ne vient pas tant des "choix conceptuels", mais plutot des contraintes exterieures.

Si on t'imposes des délais cours, tu choisieras un langage/framework qui t'apporte le maximum de fonctions "out of the box". Genre Ruby-on-rail si tu veux faire une appli web de datamanagement assez basique.

Si on t'impose le langage/framework, tu devras adapter les fonctionalités de ton appli a ce que permet ton langage/framework.

mais si ce sont des spécifications d'un cahier des charges, ce sont aussi des problèmes "contractuels"… et nettoyer un cahier des charges en faisant des allées et venues entre l'aspect conception et des problèmes d'implémentation nécessite des réponses autres que des truismes…

L'exemple cité ci-avant de "fenetre plein-ecran transparante" est le cas ou on doit dire "non, on ne peut/doit pas faire ca en Swing". C'est pas qu'on ne PEUT pas le faire a coup de JNI ou autre. C'est que ca sort du cadre de ce que Swing sait faire naturellement ("out of the box"). Si Java/JSE est une contrainte du projet, alors il faut adapter les fonctionalités de l'appli en consequence. Si la "fenetre plein-ecran transparante" est indispensable, alors il faut revoir la contrainte de langage.

Tout se negocie. Sinon c'est la porte ouverte aux code "usine a gaz" avec des "hack" de partout.

une fois le choix imposé, tout ce qui est "naturel" pour l'outil choisi ne posera pas de problèmes particuliers ou posera les problèmes "habituels", mais comment l'environnement réagit-il à des sollicitations inhabituelles ?

Il n'a pas a réagir a des sollicitations inhabituelles. Ce n'est pas au langage/framework de s'adapter a ton probleme. C'est a toi de choisir, pour chaque problematique, la solution la plus adaptée. Meme si ca necessite d'employer 5 langages et 3 frameworks differents !

Les 80% du code écrit en 20% du temps sont peu intéressants,
les 20% du code qui nécessitent 80% du temps sont toujours beaucoup plus "amusants"…

Oui, j'ai remarqué ca aussi... Mais bizarement les bugs sont toujours dans les 80% de code "peu intéressants". Sans doute car, comme ca n'interesse personne, c'est souvent baclé

si un vendeur vous dit que son produit peut "le" faire, ce n'est pas sur des généralités ou des démos prémachées que vous saurez si sa définition de "faire" correspond à la vôtre…

mais il faudrait que quelqu'un me montre au moins une solution - sans entrer dans les détails d'implémentation, les "steps" à réaliser suffisent - d'un des problèmes posés…

… et le fait que rien ne vienne est déjà une réponse en soi…

100% d'accord. Je fais rarement confiance aux plaquettes commericales genre "votre appli J2EE en 1 heure avec notre logiciel !"

Mais il faut quand meme se ranger aux avis de la communauté sur certains points:

There were five primary goals in the creation of the Java language:
- object-oriented programming methodology.
- allow the same program to be executed on multiple operating systems.
- contain built-in support for using computer networks.
- designed to execute code from remote sources securely.
- easy to use by selecting what was considered the good parts of other object-oriented languages.

The .NET Framework was designed with several intentions:
- Interoperability
- Common Runtime Engine
- Language Independence
- Base Class Library
- Simplified Deployment
- Security

[FremyCompany]

Là tu mets le point sur un des désavantages de Java : l'intégration au système !
Mais même temps cela peut être un avantage selon les besoins...

Essayes de déployer ton application sur des systèmes MacOS, Unix ou Linux...

Euh tu parles de MONO ? Mais je ne sais pas si il gère entièrement le .NET 2 pour les Winforms donc...

Mon application n'a aucun intérêt à tourner sous autre chose que windows, de toute facon, vu qu'elle sert à patcher EXPLORER.EXE

[JeitEmgie]

Qu'entends tu par "les architectures .Net et Java+X" ?

remplacez architecture par environnement …

Dans ce dernier cas, les 2 frameworks ne t'imposent aucun motif de conception. Tu peux faire du Call-n-Return, de l'Aspect, du procedural, du blackboard, du massivement parallele, ...

…nous voilà bien avancés…

Si tu veux faire du MVC en java pour une appli Desktop, prends Swing. Si tu veux faire du MVC en C# sur une appli web, prends Asp.net. etc...

… très léger le MVC de Swing… V et C ne sont pas vraiment séparé…
et celui de asp.net n'incite pas beaucoup à la séparation non plus… à voir le nombre de tutoriels sur le Net qui ont pour sujet "Comment mettre en place le MVC en ASP.Net"…
si l'on doit vous expliquer comment mettre en place le MVC en asp.net …
c'est qu'il ne saute pas aux yeux !
on est très loin de, par exemple, RoR (un MVC fortement contraignant) ou OPENStep/Cocoa (un MVC faiblement contraignant)…

… mais on avance enfin un petit peu dans la bonne direction : on commence à définir certains "contours" : pas vraiment de vrais MVC ou pas complets mais bon, assez pour faire "comme si"…

Si on t'imposes des délais cours, tu choisieras un langage/framework qui t'apporte le maximum de fonctions "out of the box".

Si on t'impose le langage/framework, tu devras adapter les fonctionalités de ton appli a ce que permet ton langage/framework.

très puéril tout cela… ce qui rend d'ailleurs ce docte ton d'autant plus déplacé…

L'exemple cité ci-avant de "fenetre plein-ecran transparante" est le cas ou on doit dire "non, on ne peut/doit pas faire ca en Swing". C'est pas qu'on ne PEUT pas le faire a coup de JNI ou autre. C'est que ca sort du cadre de ce que Swing sait faire naturellement ("out of the box"). Si Java/JSE est une contrainte du projet, alors il faut adapter les fonctionalités de l'appli en consequence. Si la "fenetre plein-ecran transparante" est indispensable, alors il faut revoir la contrainte de langage.

c'est typiquement le genre de demande qui si elle émanait d'un client, nécessiterait un petit travail d'interprétation, …
Après tout, ce que demande réellement le client c'est peut-être tout simplement un écran de démarrage original qui le démarque de ses concurrents… ?
et exprimé comme cela, Swing, Machin ou Chose, … on devrait être capable de lui trouver une solution sympa… (quitte à, comme je l'ai dit précédement, lui jouer un movie au démarrage de son appli…)

Evidemment, s'il nous fait un caprice d'enfant gâté, il faudra bien improviser…

Il n'a pas a réagir a des sollicitations inhabituelles. Ce n'est pas au langage/framework de s'adapter a ton probleme.

que voulez vous dire : que ce sont les besoins de l'utilisateur qui doivent s'adapter peut-être ?
ce ne serait pas plutôt ce qui est entre vos deux oreilles qui est censé combler le fossé entre les 2 ?

C'est a toi de choisir, pour chaque problematique, la solution la plus adaptée. Meme si ca necessite d'employer 5 langages et 3 frameworks differents !

oui certes … si l'on fait abstraction de ce nouveau truisme, cela se conçoit à une certaine échelle…
et encore : on multiplie beaucoup plus facilement les langages que les frameworks dans le cadre d'une application…

mais il arrivera toujours un moment où dans le cadre d'un code donné vous êtes dans un environnement précis et vous devez faire avec ce que vous avez… vous ne pouvez pas toujours changer d'environnement en plein milieu d'une application :

"cher utilisateur, ne pouvant réaliser facilement cette fonction avec Chose, je lance maintenant un outil développé avec Machin pour pouvoir répondre à votre légitime demande… veuillez patienter quelques instants…"

Il y a une condition implicite à tout patchwork de technologies qui ne devrait échapper à personne, mais comme vous semblez aimer les truismes, je le dis quand même :

que tout cela soit totalement transparent pour l'utilisateur…

Oui, j'ai remarqué ca aussi... Mais bizarement les bugs sont toujours dans les 80% de code "peu intéressants". Sans doute car, comme ca n'interesse personne, c'est souvent baclé

il y a une certaine corrélation entre le nombre de lignes de code et la quantité de bugs…
le mot baclé ne fait pas partie de mon vocabulaire…

Mais il faut quand meme se ranger aux avis de la communauté sur certains points:

vous continuez à tourner en rond…

en prenant des exemples type GUI j'ai probablement induit dans votre esprit une image erronée des intentions du propos initial…

prenons un autre exemple :
tous les environnements offrent une solution pour la gestion des threads…
mais quels sont les modes de communication OO inter-threads proposés ?
fonctionnent-ils aussi entre process sur le même hôte ?
fonctionnent-ils entre process distants ?

[pseudocode]

très puéril tout cela… ce qui rend d'ailleurs ce docte ton d'autant plus déplacé…

Oui, tu as parfaitement raison et je m'excuse d'avoir emis une idée non conforme a ta vision des choses. Devant tant d'intelligence et de mots inusités (parfois a plus de 3 syllabes), je ne peux que me prosterner.

Si personne sur cette planette n'a, jusque ici, réussi a créer une "methodologie de comparaison"(tm) pour comparer des frameworks, ce n'est pas lié a la difficulté ou l'inutilité de la tâche. Certe non. C'etait simplement que tout le monde (y compris moi) n'avait pas eu la maturité d'esprit nécessaire pour envisager l'interet de la chose.

Nous, le troupeau des chefs de projet, architectes, concepteurs et developpeurs, prenions le probleme par le mauvais bout. Nous pensions betement qu'il fallait d'abord analyser un probleme pour trouver une solution.

Alors que c'etait si simple. Il suffit d'evaluer une fois pour toute chaque solution puis, lorsqu'un probleme se présente, prendre la meilleure solution ! Oh, combien de temps perdu en Analyse et Conception a faire de la séparation de responsabilité ou a dissocier les tiers...

Loué soit JeitEmgie. Que son nom brille a tout jamais au firmament des methodologistes de comparaison.

Mea culpa... Mea maxima culpa...


NB: Pueril moi ? ca m'etonnerai. Je sais meme pas ce que ca veut dire

[FremyCompany]

Oui, tu as parfaitement raison et je m'excuse d'avoir emis une idée non conforme a ta vision des choses. Devant tant d'intelligence et de mots inusités (parfois a plus de 3 syllabes), je ne peux que me prosterner.

Si personne sur cette planette n'a, jusque ici, réussi a créer une "methodologie de comparaison"(tm) pour comparer des frameworks, ce n'est pas lié a la difficulté ou l'inutilité de la tâche. Certe non. C'etait simplement que tout le monde (y compris moi) n'avait pas eu la maturité d'esprit nécessaire pour envisager l'interet de la chose.

Nous, le troupeau des chefs de projet, architectes, concepteurs et developpeurs, prenions le probleme par le mauvais bout. Nous pensions betement qu'il fallait d'abord analyser un probleme pour trouver une solution.

Alors que c'etait si simple. Il suffit d'evaluer une fois pour toute chaque solution puis, lorsqu'un probleme se présente, prendre la meilleure solution ! Oh, combien de temps perdu en Analyse et Conception a faire de la séparation de responsabilité ou a dissocier les tiers...

Loué soit JeitEmgie. Que son nom brille a tout jamais au firmament des methodologistes de comparaison.

Mea culpa... Mea maxima culpa...


NB: Pueril moi ? ca m'etonnerai. Je sais meme pas ce que ca veut dire

Excellent ! Mais bon, ca ne fait pas avancer le débat...

[pseudocode]

Excellent ! Mais bon, ca ne fait pas avancer le débat...

Bah y a pas de debat:

• .Net impose l'OS et te laisse libre d'utiliser le langage que tu veux.
• JSE impose le langage et te laisse libre d'utiliser l'OS que tu veux.

Apres on peut comparer ".Net avec J#" et "JSE sur windows", parceque c'est le point d'intersection des deux solutions. Mais bof...

[JeitEmgie]

Oui, tu as parfaitement raison et je m'excuse d'avoir emis une idée non conforme a ta vision des choses. Devant tant d'intelligence et de mots inusités (parfois a plus de 3 syllabes), je ne peux que me prosterner.

vous faites bien mon brave…

Si personne sur cette planette n'a, jusque ici, réussi a créer une "methodologie de comparaison"(tm) pour comparer des frameworks, ce n'est pas lié a la difficulté ou l'inutilité de la tâche. Certe non. C'etait simplement que tout le monde (y compris moi) n'avait pas eu la maturité d'esprit nécessaire pour envisager l'interet de la chose.

là, vous vous montez le bourrichon tout seul…

Nous, le troupeau des chefs de projet, architectes, concepteurs et developpeurs, prenions le probleme par le mauvais bout. Nous pensions betement qu'il fallait d'abord analyser un probleme pour trouver une solution.

j'ai posé quelques problèmes sous forme de snippets : où sont les analyses et les solutions ?

Alors que c'etait si simple. Il suffit d'evaluer une fois pour toute chaque solution puis, lorsqu'un probleme se présente, prendre la meilleure solution ! Oh, combien de temps perdu en Analyse et Conception a faire de la séparation de responsabilité ou a dissocier les tiers...

vous ne lisez pas ce que l'on écrit… il ne s'agit pas d'aboutir à des jugements absolus et définifs… juste aborder la comparaison par quelques exemples pratiques… et de préférence pas ceux des promoteurs des technologies comparées…

et maintenant vous vous lancez dans des digressions qui n'ont rien à voir avec le sujet…

Mea culpa... Mea maxima culpa...

vous me relirez tout Knuth, tout Kay, et je vous absous…

[yann2]

Salut

Je ne veux pas nourrir ce si beau troll, mais je pense effectivement qu'on peut dresser des grilles de comparaisons pour des frameworks . Par contre ce n'est pas du tout ce que j'attend dans les débats de DVP. Je préfère largement la castagne (c'est bien plus constructif...).

Pour les grilles il faut effectivement ce limiter à un problème donné (qu'attendons nous d'un framework pour résoudre notre problème). Donc je trouve le débat filausaufik plus intéressant ici !

Bon sinon J2SE, J2EE et .Net je trouve ça bien (faites l'amour, pas la guerre) !

La concurrence tire la qualité des deux frameworks vers le haut. Que demander de plus ?

Ps : je ne connais pas le framework .Net, je me suis intéressé au langage C#, ça ressemble beaucoup à Java. C'est, pour moi, un gros avantage (pas besoin d'apprendre une nouvelle syntaxe pour utiliser le framework .Net).

Sinon, de ce que j'ai pu voir, .Net et J2SE/J2EE c'est kif kif. Après, il faut regarder du côté de l'outillage disponible.

tchuss