Discussion :

[OButterlin]

Excusez la question mais un autre langage, soit, mais pourquoi faire ?
Dans quel contexte auriez-vous besoin d'autre chose que java ?

[professeur shadoko]

Excusez la question mais un autre langage, soit, mais pourquoi faire ?
Dans quel contexte auriez-vous besoin d'autre chose que java ?

Java c'est bien mais c'est en train de s'alourdir en essayant de capter de nouveaux paradigmes.
Sans parler de petits détails déjà traités de manière cochonne (auto-boxing, boucle foreach par exemple) la généricité, les annotations,lla modularité, les fonctions comme type à part entière (fermetures/closures), et d'autres paradigmes comme les "traits" ne peuvent que rendre Java un peu bancal... on aimerait un "java bis" dans lequel tout ça soit d'équerre (quoique j'aie des réserves sur les détails des traits "à la Scala")
En plus une syntaxe bien régulière serait bienvenue (c'est l'enfer d'analyser du source Java! + avis personnel: réserver les "facilités syntaxiques" et autres irrégularités pour les langages de script!)

[Grimly_old]

Java c'est bien mais c'est en train de s'alourdir en essayant de capter de nouveaux paradigmes.
Sans parler de petits détails déjà traités de manière cochonne (auto-boxing, boucle foreach par exemple) la généricité, les annotations,lla modularité, les fonctions comme type à part entière (fermetures/closures), et d'autres paradigmes comme les "traits" ne peuvent que rendre Java un peu bancal... on aimerait un "java bis" dans lequel tout ça soit d'équerre (quoique j'aie des réserves sur les détails des traits "à la Scala")
En plus une syntaxe bien régulière serait bienvenue (c'est l'enfer d'analyser du source Java! + avis personnel: réserver les "facilités syntaxiques" et autres irrégularités pour les langages de script!)

Auto-Boxing : J'avoue que c'est affreux. Autant passer en C++ et aller jusqu'à la surcharge d'opérateurs.

For-Each : Sucre syntaxique que même moi j'apprécie. De plus ça a un sens correct, "Pour tout les <Objects> nommés <obj> dans <collection> ..."

Généricité : Ça a un sens bien logique pourtant. Certain l'utilisent de manière 100% cochonne mais c'est comme tout, le langage Java n'a pas été créé pour que des singes l'utilisent.

Annotation : Ça ou écrire du XML en JEE6 ... Chacun ses goûts.

Modularité, Fonctions : Il faudrait m'expliquer car je vois mal (hormis certains patterns qui justement ont leur buts, mais là c'est toute la POO que tu dénoncerais).

C'est l'enfer d'analyser du source Java! : C'est normal, comme je l'ai dit plus haut : le langage Java n'a pas été créé pour que des singes l'utilisent. Si c'est le cas alors je suis le roi des chimpanzés .

Il n'en reste pas moins que Scala est assez élégant pour une application mathématique et de modèles simples.
/me a voté Scala

[Invité]

AspectJ c'est pas un langage non ? c'est un framework de gestion d'AOP non ?

Non, c'est un langage. Un surensemble de Java qui permet la création d'aspects.

[kerflyn]

J'ai voté pour Groovy et Scala car ce sont les langages liés à la JVM les plus populaires, en dehors de Java lui-même. Ces deux languages se retrouvent dans des outils ou des framework qui eux-même sont déjà populaires. J'ai pu voir avec quelle élégance ils pouvaient mettre en pratique la BDD.

Personnellement, je ne cache pas ma préférence pour Scala. Ce n'est pas seulement parce que Scala me rappelle Caml, avec lequel j'ai travailler. C'est aussi parce que Scala intègre des concepts qu'on devrait voir plus souvent dans les langages. En particulier, le fait d'orienter le développeur vers une démarche déclarative, pour peu qu'il comprenne les avantages de cette démarche. Néanmoins, je ne suis pas sûr que le premier développeur venu puisse assimiler correctement les concepts de Scala.

[professeur shadoko]

For-Each : Sucre syntaxique que même moi j'apprécie. De plus ça a un sens correct, "Pour tout les <Objects> nommés <obj> dans <collection> ..."

mois aussi j'adore (surtout pour des iterables). mais le drame c'est que c'est une macro et que quelqu'un peut aussi faire des bétises comme affecter une valeur à la variable de boucle (en C# le compilateur refuse, en Java il ne dit rien et du coup quelques innocents se font piéger)

Généricité : Ça a un sens bien logique pourtant. Certain l'utilisent de manière 100% cochonne mais c'est comme tout, le langage Java n'a pas été créé pour que des singes l'utilisent.

j'adore aussi mais.... il y a des "trous" dans les principes mêmes et la syntaxe est à chier!

Annotation : Ça ou écrire du XML en JEE6 ... Chacun ses goûts.

toujours pareil c'est super! mais on peut améliorer pas mal de choses

Modularité, Fonctions : Il faudrait m'expliquer car je vois mal (hormis certains patterns qui justement ont leur buts, mais là c'est toute la POO que tu dénoncerais).

voir évolutions en cours sur la modularité et les fermetures

C'est l'enfer d'analyser du source Java! : C'est normal, comme je l'ai dit plus haut : le langage Java n'a pas été créé pour que des singes l'utilisent. Si c'est le cas alors je suis le roi des chimpanzés .

j'ai pas tout à fait compris ton message sous-jacent mais peut-être n'ai je pas été moi-même clair. Je voulais dire ceci: il est extrèmement difficile d'écrire un analyseur de code java pour faire certaines analyses statiques simples. Sans être être un sectataire du "code comme donnée" (langage homoiconiques) l'héritage du C fait à la fois du bien et du mal à Java
(le prgrammeur moyen n'est pas trop dérangé dans sa lecture mais la structure syntaxique est assez byzantine).

[dingoth]

mois aussi j'adore (surtout pour des iterables). mais le drame c'est que c'est une macro et que quelqu'un peut aussi faire des bétises comme affecter une valeur à la variable de boucle (en C# le compilateur refuse, en Java il ne dit rien et du coup quelques innocents se font piéger)

Quel piège ? Java travaille par référence. Ce comportement ne diffère en rien du fonctionnement habituel de Java. Pour être certain de ne pas changer la variable de boucle, un final fait très bien l'affaire !

[jowo]

Pour le cas du "For-Each", j'utilise toujours ce type de code:

Code :

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

1
2
3
4
5
List<String> list = new ArrayList<String>(Arrays.asList(new String[]{"Un", "Deux", "Trois"}));
for (final String s : list) {
   System.out.println(s);
   s = ""; // Le compilateur me dit Non-Non
}

ou final me protège de certaines bêtises. Mais qui utilise final?

Dans mon code, il y a trop de final. Il faudrait pouvoir déclarer final comme étant implicite.

[Invité]

Pour le cas du "For-Each", j'utilise toujours ce type de code:

Code :

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

1
2
3
4
5
List<String> list = new ArrayList<String>(Arrays.asList(new String[]{"Un", "Deux", "Trois"}));
for (final String s : list) {
   System.out.println(s);
   s = ""; // Le compilateur me dit Non-Non
}

ou final me protège de certaines bêtises. Mais qui utilise final?

Dans mon code, il y a trop de final. Il faudrait pouvoir déclarer final comme étant implicite.

C'est là que j'aime aussi Scala et sa notion de val et var à la définition des variables. De plus pour une méthode, les arguments sont toujours des valeurs (donc immuables).
Ce qui me dérange un peu en java c'est les mots clef à double sens genre final et (dans une moindre mesure) extends.

J'ai découvert Scala il y a un an et je dois dire que j'aime ce langage et que je le trouve très élégant et pas ridicule en terme de perf. Il faut dire que j'aime le fonctionnel, je trouve ça beau même si moins efficace... Pour ce qui est de l'implémentation des traits ou des first class functions, le langage est aussi limité par la plateforme Java (de même pour les génériques) et doit user de trucs pour contourner les limitations.
Ceci dit pour travailler avec scala tous les jours, je peux vous dire que le systéme de types du langage est très avancé et permet des choses puissantes (covariance et contravariance des types génériques entre autres).
Bien sûr la premiére fois que j'ai vu le langage j'ai trouvé la syntaxe "compliquée", mais en fait je m'y suis vite habitué et je la trouve cohérente et limite plus que celle de Java. C'est comme tout, un langage de programmation reste une langue qu'il faut apprendre et s'approprier pour la parler !

[professeur shadoko]

Quel piège ? Java travaille par référence. Ce comportement ne diffère en rien du fonctionnement habituel de Java. Pour être certain de ne pas changer la variable de boucle, un final fait très bien l'affaire !

on est bien d'accord mais quand tu tombes sur cette erreur dans des codes de débutants pour la 36° fois tu commences à fumer (je lis beaucoup de codes que je n'écris pas).
Juste pour donner un exemple voici un code que j'ai vu XXXL fois:

Code :

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

1
2
3
4
5
6
 
for( Truc chose: tableauDeTrucs) {
      if(choseAChercher.equals(chose)){
           chose = null ;
      }
}

ça semble étrange d'écrire ça quand on connait ... mais apparemment ça a l'air "naturel" pour beacoup! (d'accord les langages ne sont pas censé être protégé contre les raisonnements bizarres ...mais encore une fois en C# le compilo te jettes!)

[Uther]

J'ai du mal à voir pourquoi ce code devrait lever une erreur.

[professeur shadoko]

pareceque dans l'esprit du programmeur il veut en fait mettre à null une référence dans le tableau... ça marche pas et il va mettre un temps fou à comprendre.
(précision: ici un objet est égal à "choseAchercher" à l'index 10 par exemple; le code sous-jacent fait chose = tableauDeTrucs[10] ; ensuite le test fonctionne et, bien entendu tableauDeTrucs[10] n'est pas mis à null) Encore un fois comme c'est une macro le programmeur naïf ne voit pas.
Bien sur on pourrait arguer la liberté du programmeur de faire ce qu'il veut de sa référence "chose" mais je suis pas chaud-chaud (pour une fois je préfère l'attitude dictatoriale de C# -une fois n'est pas coutume-)

[OButterlin]

Enfin, c'est comme tout : sur 10 programmeurs, tu risques d'avoir 10 avis différents
On va dire que tes propos n'engagent que toi...

Pour le fond, j'ai cru entrevoir que certains des langages permettaient de faire certaines choses plus facilement que java, alors pourquoi pas...
Pour faire des calculs poussés, s'il y a plus simple que java (ça ne devrait pas être trop difficile), tant mieux...
J'ai l'impression que les éléments cités ne sont pas là pour remplacer java mais plutôt pour une utilisation connexe...

Pour ce qui est de la complexité de java, je ne suis pas d'accord. Tout langage a tendance à ce complexifier dans le temps pour apporter un plus haut niveau d'abstraction. Ce n'est pas une tare... c'est plus compliqué à appréhender, mais bon, un langage à 20 instructions n'est pas forcément le must pour développer des applications de gestion (au sens large)...