Discussion :

[adiGuba]

Allez voir quand meme la video "Windows Presentation Foundation Mashup" sur YouTube...

Mais je ne pense pas que Java soit vraiment à la traine de ce coté là ! Il suffit de jeter un coup d'oeil sur le projet Looking Glass...

Maintenant dans les deux cas je pense que cela demande du travail et des compétences qui ne sont pas forcément accessible pour tout le monde (je parle pour moi en premier lieu )

a++

[Syrion]

Maintenant dans les deux cas je pense que cela demande du travail et des compétences qui ne sont pas forcément accessible pour tout le monde (je parle pour moi en premier lieu )

En fait le seul WTF c que la programation objet passe mal sur les GPU donc l'API JOGL est une translation de la lib C OpenGL... gl.h -> Gl.java glu.h -> Glu.java.
Et autant Java3D est orienté scène 3D, hyper structuré, autant JOGL respecte le côté geek des APIs 3D à l'ancienne avec 2000 méthodes dont il faut connaître l'enchînement, exit les objets "naturels" dont la manipulation est compréhensible en 2tutos...

[joho]

En fait le seul WTF c que la programation objet passe mal sur les GPU donc l'API JOGL est une translation de la lib C OpenGL... gl.h -> Gl.java glu.h -> Glu.java.
Et autant Java3D est orienté scène 3D, hyper structuré, autant JOGL respecte le côté geek des APIs 3D à l'ancienne avec 2000 méthodes dont il faut connaître l'enchînement, exit les objets "naturels" dont la manipulation est compréhensible en 2tutos...

WOW je viens de ne rien comprendre c'est assez impressionant (en meme temp je ne suis qu'un enfant dans la programmation et un embryon de la programmation 3D mais bon

Sinon, pour la base de registre et la portabilité, il me semble que les classes java.util.prefs.Preferences écrivent permettent sous windows d'écrire dans la base de registre (et sous d'autres système de faire autre chose ce qui permet de la portabilité)

Autre choses, est ce que certains ont des benchs comparant DotNET et java sur la vitesse d'execution d'une appli Web,son temp de réponse a une requete x ou y, sa capacité a tenir la charge ou la vitesse d'execution d'une appli desktop.

Dernière chose, il y a quelque chose qu'on a je penses oublié de prendre en compte. La vitesse a laquelle on fait une appli en java comparée a la vitesse d'une meme appli en DotNET. Le fait qu'un IDE écrivent énormement de code a la place du developpeur ce qui accélère le developpement et facilite la maintenance est un facteur déterminant pour un projet.

Si deux sociétés viennent avec 2 technos différentes et que l'une des boites proposent de faire le projet en un temp plus court je penches que cela risque de faire pencher la balance a son égard. Microsoft à la réputation d'avoir l'avantage (des vieux chiffres expliquait qu'un developpeur DotNET écrivait 30% de code en moins qu'un developpeur java) mais quand est-il maintenant ?

[anthyme]

Moi je suis pas spécialement pro dotnet ou pro java, je prefere les langage un peu plus agile mais bon je vais quand même donner mon avi...

Mais je vais parler encore de la portabilité, mais cette fois ci, celle des IDE (je pense qu'on a assez remarqué l'avantage de java sur les applis en elle même)
J'ai fait le tour des ide et y en a 2 qui ressortent : Visual Studio evidement et monodevelop qui est pas mal sauf que maintenant voila je suis sous mac OS X (faut pas croire, regarder les demonstration de developpeurs en video, c'est de plus en plus fréquent d'en voir sous mac) et la c'est le vide intersideral ... eclipse avec le plug in C# ? franchement il apporte rien de plus qu'un bloc note et un script qui lance le compilateur mono... en java pas de problemes, les éditeurs sont souvent ecrit en java eux même et donc multi-plateforme...
Sinon pour parler un peu de mono ... j'ai tester des applis d'amis bossant beaucoup sur dotnet et bin aucunes ne sont passé sauf une petites calculette a cause de bibliothèques absentes... donc bon...

Voila je finirais cet avi sur l'élément capital de ce débat :
<spam>Vive Python</spam>

[JeitEmgie]

Au lieu d'accumuler les avis du genre "moi, je… " pourquoi ne pas comparer les outils et les frameworks de développement en partant d'exemples concrets que tous nous rencontrons quand il s'agit de développer une application…

comment s'implémente telle fonctionnalité dans tel environnement ?
que fait-il faire : sous-classer, fournir une callback, recourrir à un hack, … ?
combien de lignes de codes la solution "recommandée" exige-t-elle ?
quelles en sont les implications en terme de maintenance ?
quelles sont les facilités de mise au point possibles ?
etc.

une comparaison un peu plus systématique des outils/frameworks aurait, à mon avis, un intérêt qu'une suite d'opinions exprimant les préférences subjectives de chacun n'offre que très peu …
d'autant plus que ces suites d'opinion finissent par se remplir de trolls, de truismes ou de digressions sans grand intérêt…

[pseudocode]

Au lieu d'accumuler les avis du genre "moi, je… " pourquoi ne pas comparer les outils et les frameworks de développement en partant d'exemples concrets que tous nous rencontrons quand il s'agit de développer une application…

Tu pars du principe que ces 2 technologies sont comparables.

Ok, elles se ressemblent dans leur fonctionnement (langage objet+code intermediaire+virual machine). Pour autant, je ne les considere pas comme comparable dans leur utilisation. Je place dotNet coté client (ihm) et Java coté serveur (business). Suivant le type de programme que tu veux faire (jeu, widget, web-service, SOA, ...) tu auras des conclusions differentes, et c'est normal.

[JeitEmgie]

Tu pars du principe que ces 2 technologies sont comparables.

Ok, elles se ressemblent dans leur fonctionnement (langage objet+code intermediaire+virual machine). Pour autant, je ne les considere pas comme comparable dans leur utilisation. Je place dotNet coté client (ihm) et Java coté serveur (business). Suivant le type de programme que tu veux faire (jeu, widget, web-service, SOA, ...) tu auras des conclusions differentes, et c'est normal.

non, je ne pars d'aucun principe justement… et je ne cherche surtout pas de conclusions "universelles"…

puisqu'en comparant à partir d'exemples concrets on limiterait le scope de la comparaison à des choses bien précises, et surtout avec les exemples de code "prouvant" les affirmations à l'appui…

prenons un exemple concret, et comme ce qui est visuel est plus parlant, commencons par le contexte des applications avec GUI et 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…

rien que pour la liste, la comparaison de 2 couples langages/frameworks devraient donc montrer donc réaliser cette simple présentation en utilisant au mieux les fonctionnalités "de base" des 2 couples,
ensuite montrer ce que "coûte" l'ajout de fonctionnalités un peu plus "avancées" ou "agréables" pour l'utilisateur final :
- je veux que l'utilisateur puisse réordonner l'ordre des colonnes de la liste, changer la taille des colonnes
- je veux des couleurs de lignes alternées,
- je veux un style de texte par type de colonne
- je veux une interface simple pour qu'il puisse décider de trier la liste selon le contenu des colonnes affichées
- je veux une interface simple pour qu'il puisse décider quelles colonnes sont affichées
- je veux que ces options de présentation soient automatiquement sauvées lorsque l'utilisateur quitte l'application et restaurées quand il revient
- je veux qu'il puisse éditer la valeur de certains champs directement dans la liste
- je veux qu'il puisse ordonner les lignes par drag-and-drop
- et je veux bien sûr un undo/redo sur toutes les fonctionnalités…
- …

ainsi on mettra en évidence que
certains couples langages/frameworks feront tout cela en standard, d'autres avec quelques lignes de code, tandis qu'avec d'autres cela tournera au hacking ou au "sous-classage" lourd…

bref, si l'on multiplie ce genres de comparaison dans tous les aspects de chaque catégorie applicative, on pourrait aboutir à une comparaison réellement utile au-delà des discours "idéologiques" et du fuzz marketing…

[pseudocode]

- je veux que l'utilisateur puisse réordonner l'ordre des colonnes de la liste, changer la taille des colonnes
- je veux des couleurs de lignes alternées,
- je veux un style de texte par type de colonne
- je veux une interface simple pour qu'il puisse décider de trier la liste selon le contenu des colonnes affichées
- je veux une interface simple pour qu'il puisse décider quelles colonnes sont affichées
- je veux que ces options de présentation soient automatiquement sauvées lorsque l'utilisateur quitte l'application et restaurées quand il revient
- je veux qu'il puisse éditer la valeur de certains champs directement dans la liste
- je veux qu'il puisse ordonner les lignes par drag-and-drop
- et je veux bien sûr un undo/redo sur toutes les fonctionnalités…
- …

Bref tu veux faire une IHM. Alors prend .Net, Delphi ou Windev.

Les frameworks JSE et JEE ne sont pas fait pour faire des IHM performantes (dans le sens ergonomiques)

[JeitEmgie]

Bref tu veux faire une IHM. Alors prend .Net, Delphi ou Windev.

Les frameworks JSE et JEE ne sont pas fait pour faire des IHM performantes (dans le sens ergonomiques)

décidement, il m'arrive plus d'une fois de me demander si les participants à ce site lisent vraiment ce que l'on écrit dans les posts… non je ne veux pas faire une IMH : la liste des desiderata posées n'est que purement théorique et donnée à titre d'exemple comme base de réflexion ! (le "je" est ici une figure de style …)

Ce que j'aimerais un jour voir dans ce genre de site - plutôt que des perpétuelles discussions vaines avec des arguments vides répétées d'année en année par une nouvelle génération qui se croit dans l'obligation de réinventer le fil à mieux couper le beurre - c'est un comparatif de COMMENT ce genre de situations relativement courantes (et l'on pourrait faire beaucoup d'autres listes de desideratas théoriques… et qui n'auraient pas nécessairement à voir avec des spécifications de GUI…) sont résolus avec chacune des solutions de développement et ainsi arriver à un véritable comparatif des fonctionnalités que le lecteur pourrait filtrer à travers ses propres critères du moment (portabilité, clareté du code, efficacité du résultat, sécurité, etc.) sans devoir décrypter des avis … hem…
la qualification qui me vient à l'esprit serait sans doute censurée par le modo de passage…

et bien sûr ceci dépasse de loin la seule comparaison .Net/Java…

[pseudocode]

c'est un comparatif de COMMENT ce genre de situations relativement courantes (…) sont résolus avec chacune des solutions de développement

Bah c'est ca le probleme ! Ca n'a absolument aucun interet de savoir COMMENT faire un developpement en employant une SOLUTION inadaptée.

Pourquoi pas comparer le C et le PHP pour faire un site Web.
Ou l'ASSEMBLEUR et MATLAB pour du calcul matriciel ?

.Net et JSE n'ont pas la meme finalité.

.Net est une technologie destinée a simplifier le développement des applications (souvent graphiques) sur microsoft windows.

Java est une technologie destinée a garantir la portabilité d'une application (souvent non graphique) sur n'importe quel OS.

Comparer Java/.Net c'est comme C++/.Net, ou python/.Net ou ruby/.Net: ca n'a pas d'interet de les comparer sur une meme problematique, car chaque framework a sa specificité.

[le y@m's]

Les frameworks JSE et JEE ne sont pas fait pour faire des IHM performantes (dans le sens ergonomiques)

Java est une technologie destinée a garantir la portabilité d'une application (souvent non graphique) sur n'importe quel OS.

Java est parfaitement adapté pour faire des interfaces graphiques. Pour JEE certe (puisque surtout orienté web), mais en ce qui concerne JSE je te conseil de jeter un coup d'oeil à ces videos .

[JeitEmgie]

Bah c'est ca le probleme ! Ca n'a absolument aucun interet de savoir COMMENT faire un developpement en employant une SOLUTION inadaptée.

…
Java est une technologie destinée a garantir la portabilité d'une application (souvent non graphique) sur n'importe quel OS.

Comparer Java/.Net c'est comme C++/.Net, ou python/.Net ou ruby/.Net: ca n'a pas d'interet de les comparer sur une meme problematique, car chaque framework a sa specificité.

évidemment : comparer un langage à un framework cela n'a pas de sens !

ce sont des comparaisons :
.Net
Java & AWT
Java & Swing
Java & WebObjects
Java & Cocoa
Java & …
C++ & MFC
C++ & Carbon
C++ & Qt
C++ & …
Ruby & Cocoa
Obj-C & Cocoa
WindDev
etc.

dont il faut parler…

et le caractère éventuellement "inadapté" surgira plus ou moins rapidement du bilan comparatif mais certainement pas de jugements a priori …

[pseudocode]

Java est parfaitement adapté pour faire des interfaces graphiques

Flash ou XAML, eux, sont parfaitement adpatés pour faire des IHM.

Java n'est pas "adapté" pour faire des IHM. Il est POSSIBLE de faire des IHM en Java, c'est different.

Pour parler de SWING (la toolkit java de reference), c'est une implementation "100% Objet" d'une toolkit graphique. Quel est l'interet du "100% Objet" dans la definition d'une IHM ? Pour les widget, je peux comprendre (MyButton->JButton->Composant). Mais que interet pour dessiner des layouts, des animations, de la gestion evenementielle, ... ???

D'ailleur, l'apparition de langage scripté comme F3 montre bien un manque coté IHM Java. (sans parler de l'absence d'outils/gadgets/utilitaires de bureau ecrits en java)

Soyons clair, je ne denigre pas Java/JSE. C'est mon evironnement de dev préféré... mais pas pour TOUT faire. En particulier des IHM !

comparer un langage à un framework cela n'a pas de sens

Oui, ok, c'est un abus de langage. Il n'y a qu'a voir le titre de la discussion !

On dit Java pour parler du framework JSE (ex J2SE)
On dit C++ pour parler de C++ & stdlib (ou boost, ou ace, ...)
etc.

[Deadpool]

Java n'est pas "adapté" pour faire des IHM. Il est POSSIBLE de faire des IHM en Java, c'est different.

Qu'est ce que tu veux dire par adapté?

[pseudocode]

Qu'est ce que tu veux dire par adapté?

Je veux dire que le langage et les librairies ont pour objectif de simplifier/faciliter le developpement des IHM.

Par exemple:
- l'extensibilité des widgets (création, specialisation, import externe, ...)
- la dynamique visuelle (animations, transformations, ...)
- la dispositions des widgets (conteneurs, hierarchie, z-order, ...)
- la gestion des evenements (Form/Action ou autre)
- l'interfacage avec des systemes externes (appels web-service, ...)
- l'isolation/couplage entre la représentation graphique, les données et le comportement (MVC ou autre)
- la gestion des look'n feel (themes)
etc.

[JeitEmgie]

Flash ou XAML, eux, sont parfaitement adpatés pour faire des IHM.

Java n'est pas "adapté" pour faire des IHM. Il est POSSIBLE de faire des IHM en Java, c'est different.

vous tournez en rond…

…
Mais que interet pour dessiner des layouts, des animations, de la gestion evenementielle, ... ???
…

si vous vous posez encore la question de l'intérêt de l'OOP dans le domaine des UI…
(…profond soupir…)

Oui, ok, c'est un abus de langage. Il n'y a qu'a voir le titre de la discussion !

Donc si vous avez conscience que c'est un abus de langage pourquoi revenir avec des sentences comme "Java n'est pas adapté…"… ?

Il est évident que ce sont les frameworks développés au-dessus d'un langage qui permettent la réalisation plus ou moins facile de certaines applications… (et les applications à GUI ne sont qu'un exemple…)

Et ce sont les fonctionnalités et la "qualité" des frameworks qui sont éventuellement influencées par les capacités des langages sur lesquels ils sont basés…

RoR ne serait pas le même s'il n'était basé sur Ruby…
OpenSTEP/Cocoa par rapport à Objective-C…
MFC, Qt, wxWidgets, Carbon… par rapport à C++…
etc.

Mais quand il s'agit de choisir une solution de développement pour répondre à un cahier des charges, il est nécessaire d'en savoir beaucoup plus sur les "produits" que les simples avis que l'on voit habituellement dans les forums… (où l'on voit souvent l'un expliquer qu'il est très facile de faire telle chose avec tel outil mais qui "oublie" le petit détail qui "tue" - genre il faut telle bibliotèque… qui n'est pas compatible avec telle version de telle autre… ou qui n'a plus été mise à jour depuis X années… ou l'autre, a contrario, qui explique qu'il est très compliqué de réaliser telle fonctionnalité dans tel environnement soit disant qu'il faut sous-classer plein de choses, alors que tout simplement il n'a pas lu le mode d'emploi qui explique qu'il suffit de changer un paramètre de configuration… ou d'ajouter une méthode à une classe…)

une méthodologie de comparaison basée sur des exemples concrets de résolution de problèmes serait beaucoup plus parlante…
et au moins les inepties seraient très rapidement expurgées…

et ceci s'applique à toute comparaison d'outils … même à la comparaison de simples éditeurs de texte…

[Deadpool]

Bon, je suis pas un expert des GUI Java mais en lisant tes attentes, Java me semble "adapté" au contraire.

- l'extensibilité des widgets (création, specialisation, import externe, ...)

Ben le cas typique en Swing, quand par exemple tu veux dessiner un rectangle ou une forme géométrique, c'est d'étendre un JPanel en redéfinissant sa méthode paintComponent. Si c'est c'est pas de la spécialisation...

Par contre, qu'est ce que tu veux dire par import externe?

- la dynamique visuelle (animations, transformations, ...)

Ca, j'ai pas vraiment pratiqué en Java mais je sais que ça existe, je laisse des gens plus spécialisés répondre sur comment qu'on fait.

- la dispositions des widgets (conteneurs, hierarchie, z-order, ...)

Les Layouts servent à cela.

- la gestion des evenements (Form/Action ou autre)

Ben tu ajoute un écouteur sur le widget sur lequel tu veux capté les évenements (exemple pour un bouton tu appel la méthode addActionListener) et tu code le traitement (ce qui revient à créer une classe implémentant une interface particulière), je vois pas ce qu'il y a de compliqué en Java.

- l'interfacage avec des systemes externes (appels web-service, ...)

Heu là pareil, c'est possible en Java. On peut consommer des web services en Java, non? Je vois pas ce qui empêche de faire ça au sein d'une IHM.

- l'isolation/couplage entre la représentation graphique, les données et le comportement (MVC ou autre)

Swing à été codé en utilisant le pattern MVC mais je ne t'apprend rien, je présume.

- la gestion des look'n feel (themes)
etc.

Les look n' feel existent en java, me demande même si le terme n'a pas été introduit avec Java.
Java comporte plusieurs Look n' feel par défaut (Swing, Windows...) dont un customisable assez facilement avec des fichiers XML (Synth).


Je pense que tu sais déjà tout ça, donc je comprends vraiment pas ce qui t'embête avec les IHM Java,je dois être bête.

[pseudocode]

si vous vous posez encore la question de l'intérêt de l'OOP dans le domaine des UI…

C'est quand meme bizarre qu'il y ait autant d'IHM faites en VB ou en HTML, deux langages clairement non OO. Les gens doivent etre maso

Donc si vous avez conscience que c'est un abus de langage pourquoi revenir avec des sentences comme "Java n'est pas adapté…"…

Justement parceque c'est un abus de langage, donc on peut l'utiliser et se faire comprendre par les gens. Vous pouvez pinailler si vous voulez et faire un global-replace java par JSE. Mais bon, vous utilisez un autre framework pour java que JME/JSE/JEE ? moi non.

@Descent: Je n'ai pas dit que ce n'etait pas POSSIBLE. J'ai juste dit que ce n'etait pas adapté, dans le sens "explicitement fait pour simplifier ou faciliter la vie du developpeur".


Hello World - C++ (MFC)

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
// HelloMFC.H
class CSimpleApp : public CWinApp
{
  public:
    virtual BOOL InitInstance()
    {
      m_pMainWnd = new CSimpleFrame;  
      m_pMainWnd->ShowWindow( m_nCmdShow );
      m_pMainWnd->UpdateWindow();
 
      return TRUE; 
   }
};

class CSimpleFrame:public CFrameWnd
{
  public:
    CSimpleFrame()
    {
      Create( NULL, "Hello MFC" );
    }
  protected:
    DECLARE_MESSAGE_MAP();
    afx_msg void OnPaint();
};
--------------------------------------------
// HelloMFC.CPP

CSimpleApp helloApp;

BEGIN_MESSAGE_MAP( CSimpleFrame, CFrameWnd )
  ON_WM_PAINT()
END_MESSAGE_MAP() 

void CSimpleFrame::OnPaint()
{ 
  CPaintDC dc( this );
  dc.TextOut( 200, 200, "Hello World!" );
}

Hello World - C# (.NET 2.0)

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
using System.Windows.Forms;

public class SimpleForm : Form 
{
  private Label label1;

  public SimpleForm() 
  { 
    label1 = new Label();
    label1.Text = "Hello World!";
    Controls.Add( label1 );
  }
  [STAThread()]
  static void Main() {
    Application.Run(new SimpleForm());	
  }  
}

Hello World - Java (JSE/SWING)

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
import javax.swing.JFrame;
import javax.swing.JLabel;

public final class HelloWorld extends JFrame {
    private HelloWorld() {
        setDefaultCloseOperation(JFrame.DISPOSE_ON_CLOSE);
        getContentPane().add((new JLabel("Hello, World!")));
        pack();
        setLocationRelativeTo(null);
    }

    public static void main(String[] args) {
        new HelloWorld().setVisible(true);
    }
}

Hello World - Flash (MXML)

Code :

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

1
2
3
4
5
6
7
<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.macromedia.com/2003/mxml" >
  <mx:Panel title="Hello Flash">
    <mx:Label text="Hello World!"/>
  </mx:Panel>
</mx:Application>

Hello World - XAML

Code :

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

1
2
3
4
<FlowPanel xmlns="http://schemas.microsoft.com/2003/xaml">
    <Text>Hello World</Text>
</FlowPanel>

Hello World - PHP

Code :

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

1
2
<?="Hello World";?>

[Deadpool]

C'est quand meme bizarre qu'il y ait autant d'IHM faites en VB ou en HTML, deux langages clairement non OO. Les gens doivent etre maso

HTML c'est de l'interface Web, rien à voir avec Java SE à priori. Quant à VB, son utilisation s'explique facilement par le fait qu'il peut être facilement intégré avec la suite Office et par sa relative facilité d'appréhension par rapport à Java (du point de vue IHM c'est RAD obligatoire car aucun moyen de coder l'interface à la main si je ne m'abuse) mais pour l'extensibilité ou la gestion des thèmes par exemple tu repasseras.


Pour l'instant, donc, je ne vois toujours pas la différence entre ce que tu trouve adapté, et ce que tu trouves pas adapté.

Donc explique précisément en quoi tu trouve par exemple que .Net, Delphi ou autre est "explicitement fait pour simplifier ou faciliter la vie du developpeur" parce que pour l'instant là, c'est du dialogue de sourd.

[JeitEmgie]

C'est quand meme bizarre qu'il y ait autant d'IHM faites en VB ou en HTML, deux langages clairement non OO. Les gens doivent etre maso

vous oubliez les bons vieux écrans de saisie COBOL ou RPG…
le fait qu'il y ait beaucoup de codes basés sur tel ou telle technologie ne signifie absolument rien… ni sur la qualité de ces technologies, ni sur le QI de ceux qui les emploient…
tout le monde ici sait qu'il y des "break event" en dessous desquels la question du choix d'une solution technique est de l'ordre des préférences personnelles (càd la plupart du temps, la loi du moindre effort…)…*les questions intéressantes de choix commençant au-delà…

Justement parceque c'est un abus de langage, donc on peut l'utiliser et se faire comprendre par les gens. Vous pouvez pinailler si vous voulez et faire un global-replace java par JSE. Mais bon, vous utilisez un autre framework pour java que JME/JSE/JEE ? moi non.

utiliser des mots à contre-sens aide à la compréhension ?
JME/JSE/JEE des frameworks ?
non…, des plate-formes ? oui,
Swing, AWT, WebObjects, JMF, etc. sont des frameworks…


et je le répète encore une fois, l'exemple original de critères dans le contexte de GUI, n'était qu'un exemple …

le propos original est :
est-ce qu'il y un intérêt parmi les lecteurs à voir se développer des forums de discussion avec de véritable comparaisons "on the battle field" et non des discussions où s'accumulent les avis subjectifs et les exemples idiots ?

un exemple "idiot" : le "Hello world" justement…
quoiqu'il suffisse peut-être de rajouter le desiderata "multi-langues" pour qu'il devienne assez vite "amusant" … ou de montrer ce genre de code

Code :

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

1
2
3
4
5
6
7
#import <Cocoa/Cocoa.h>

int main(int argc, const char *argv[])
{
    return NSApplicationMain(argc, argv);
}

ou

Code :

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

1
2
3
class HelloController < ApplicationController
end

pour que surgissent des questions intéressantes, du genre mais où est donc le texte !?