J'aimerais bien en savoir un peu plus sur ces prétendues tares que comporte Java.
En effet je travaille avec ce langage tous les jours depuis 2 ans, et je ne me rends pas compte que c'est un langage arriéré avec lequel on peut faire moins de choses ou apparemment de manière moins esthétique / performante / rigoureuse. Je rentre bien dans ton premier cas ("on a du mal à voir les problèmes").
Prenons donc la liste (non exhaustive apparement) des concepts qui manquent :
- absence de contrats : je ne connais pas trop cette manière de travailler, mais d'après Wikipedia, ca revient à tester des domaines de valeurs. les mots clé assert (Java 1.5) sont là pour ca, et au pire on pourra toujours utiliser le mécanisme des Exceptions si ca ne suffit pas.
- closures : effectivement pas de closures. on ne peut pas définir de fonctions dans une fonction. Mais est ce vraiment nécessaire ? Dans quel cas on ne ne peut faire quelque chose d'élégant et d'efficace uniquement avec les closures ?
- aspects dynamiques limités : pourrais tu développer, s'il te plait ? Parce que la reflexion, les generics et la modification de code a chaud dans la VM, je trouve ça déjà pas mal.
- compléxité de la grammaire : alors là forcément je ne m'en rends plus trop compte... Mais je ne suis pas sûr de trouver les points qui posent tant de problème. Et puis, en général, j'arrive souvent mieux à comprendre ce que fait un code Java qui utilise la plupart des mécanismes de la grammaire qu'un code Java qui appelle des méthodes de librairies que je ne connais pas. J'ai l'impression que de toutes facons il faudra passer par l'apprentissage de quelque chose.
Que ce soit une syntaxe complexe + plein de librairies ou une syntaxe simple mais encore plus de librairies à apprendre à manipuler ne change que peu de chose selon moi.
- lenteur de la compilation : en ce moment je travaille sur un produit qui contient environ une vingtaine d'archives jar. On estime travailler sur environ 800 000 lignes de code. Lorsqu'on compiile tout on en a pour environ 4 minutes (temps de récupération des données par SVN compris). Si on modifie seulement une partie du code, ca dépasse rarement la minute, on est plus de l'ordre de la dizaine de secondes.
- concernant les frameworks et les briques qui s'ajoutent : si ces briques peuvent s'ajouter, c'est comme dit plus bas car le langage est assez souple pour le permettre. Plutot que de voir ca comme une preuve de l'incapacité d'évoluer, je verrais plutôt ca comme une preuve de l'organisation du code : la syntaxe pour faire les choses de bases comme les boucles, les tests, la manipulation d'objets et les opérations mathématiques de base, le SDK pour le reste. Les libs tierces pour ajouter des concepts pas dispo dans le SDK (rarement utiles, nouveaux,...). Ensuite dire que les briques de base sont incapables d'évoluer, c'est aussi dire que les évolutions qui marquent les versions 1.4, 5 et 6 ne servent a rien. Un peu fort tout de même, non ?
Là où je trouve Java un peu embêtant, c'est pour la manipulation de fichiers (tous ces streams qui ne peuvent pas toujours communiquer entre eux, pfff...) [SDK] et pour la gestion de la concurrence [SDK + syntaxe].
L'avantage de Lisaac ne m'apparait pas encore clairement, et je pense ne pas être le seul. Bon je n'ai jamais été fan de lambda calcul, de théorie des types et de coq, mais j'ai bien apprécié le Caml, même si je trouve que j'allais plus lentement a développer quelque chose qu'en C ou Java.
Merci de votre patience.
P.S.: je ne sais pas si ce genre de "débat" a déjà eu lieu, merci de m'indiquer le lien le cas échéant.
[^] # Re: sonntag
Posté par Joël SCHAAL . En réponse à la dépêche Lisaac 0.12 en GPL v3. Évalué à 3.
En effet je travaille avec ce langage tous les jours depuis 2 ans, et je ne me rends pas compte que c'est un langage arriéré avec lequel on peut faire moins de choses ou apparemment de manière moins esthétique / performante / rigoureuse. Je rentre bien dans ton premier cas ("on a du mal à voir les problèmes").
Prenons donc la liste (non exhaustive apparement) des concepts qui manquent :
- absence de contrats : je ne connais pas trop cette manière de travailler, mais d'après Wikipedia, ca revient à tester des domaines de valeurs. les mots clé assert (Java 1.5) sont là pour ca, et au pire on pourra toujours utiliser le mécanisme des Exceptions si ca ne suffit pas.
- closures : effectivement pas de closures. on ne peut pas définir de fonctions dans une fonction. Mais est ce vraiment nécessaire ? Dans quel cas on ne ne peut faire quelque chose d'élégant et d'efficace uniquement avec les closures ?
- aspects dynamiques limités : pourrais tu développer, s'il te plait ? Parce que la reflexion, les generics et la modification de code a chaud dans la VM, je trouve ça déjà pas mal.
- compléxité de la grammaire : alors là forcément je ne m'en rends plus trop compte... Mais je ne suis pas sûr de trouver les points qui posent tant de problème. Et puis, en général, j'arrive souvent mieux à comprendre ce que fait un code Java qui utilise la plupart des mécanismes de la grammaire qu'un code Java qui appelle des méthodes de librairies que je ne connais pas. J'ai l'impression que de toutes facons il faudra passer par l'apprentissage de quelque chose.
Que ce soit une syntaxe complexe + plein de librairies ou une syntaxe simple mais encore plus de librairies à apprendre à manipuler ne change que peu de chose selon moi.
- lenteur de la compilation : en ce moment je travaille sur un produit qui contient environ une vingtaine d'archives jar. On estime travailler sur environ 800 000 lignes de code. Lorsqu'on compiile tout on en a pour environ 4 minutes (temps de récupération des données par SVN compris). Si on modifie seulement une partie du code, ca dépasse rarement la minute, on est plus de l'ordre de la dizaine de secondes.
- concernant les frameworks et les briques qui s'ajoutent : si ces briques peuvent s'ajouter, c'est comme dit plus bas car le langage est assez souple pour le permettre. Plutot que de voir ca comme une preuve de l'incapacité d'évoluer, je verrais plutôt ca comme une preuve de l'organisation du code : la syntaxe pour faire les choses de bases comme les boucles, les tests, la manipulation d'objets et les opérations mathématiques de base, le SDK pour le reste. Les libs tierces pour ajouter des concepts pas dispo dans le SDK (rarement utiles, nouveaux,...). Ensuite dire que les briques de base sont incapables d'évoluer, c'est aussi dire que les évolutions qui marquent les versions 1.4, 5 et 6 ne servent a rien. Un peu fort tout de même, non ?
Là où je trouve Java un peu embêtant, c'est pour la manipulation de fichiers (tous ces streams qui ne peuvent pas toujours communiquer entre eux, pfff...) [SDK] et pour la gestion de la concurrence [SDK + syntaxe].
L'avantage de Lisaac ne m'apparait pas encore clairement, et je pense ne pas être le seul. Bon je n'ai jamais été fan de lambda calcul, de théorie des types et de coq, mais j'ai bien apprécié le Caml, même si je trouve que j'allais plus lentement a développer quelque chose qu'en C ou Java.
Merci de votre patience.
P.S.: je ne sais pas si ce genre de "débat" a déjà eu lieu, merci de m'indiquer le lien le cas échéant.