Y'a un moment faut arrêter de vivre 15 ans en arrière ou rabacher la tagline de l'époque. C'est peut être plus intéressant d'essayer de comprendre ce que ca apporte concrètement aujourd'hui. Et voir si c'est adapté ou non à ton besoin.
On est d'accord. Et je maintiens que sorti des grosses applications métier (pour lesquelles effectivement, les profusion d'outils d'ingénierie logicielle autour de Java sont un atout), c'est assez peu adapté.
C'est quoi ce jugement à la con ?
Tu n'as jamais croisé de ces experts Java, qui t'expliquent que ton problème simple est beaucoup plus compliqué qu'il n'y parait, que d'ailleurs il va te falloir racheter du matos, constituer un comité de pilotage, et j'en passe. À tel point que tu n'oses plus leur dire que ce que tu voulais, c'était trois tables avec juste ce qu'il faut de formulaires pour faire des opérations CRUD de base.
Ce n'est pas plus compliqué ou opaque de n'importe quoi d'autre.
Le langage, non. L'écosystème (humain, essentiellement) qui va avec, oui.
C'est une blague ? C'est certainement l'un des langages les plus simples (voir simpliste). C'est bête et méchant, pauvre, ca évolue très lentement, ca fait exactement ce qui est écrit sans aucune surprise possible. C'est à la fois une force et une faiblesse.
C'est pour ça que je parle de marche haute. C'est très verbeux pour pas grand chose, et faire des choses simples en Java est plus compliqué qu'il n'est nécessaire (notamment comparé à Python ou Ruby). Après, comme souvent quand la première marche est haute, les autres s'enchaînent certainement mieux.
Mais j'ai tendance à me tenir au vieil adage "que les choses simples soient faciles, que les choses compliquées soient possibles". Java échoue, selon moi, sur le premier critère. Windev sur le second.
Si tu penses sérieusement que la marche est plus haute que du Python, Ruby, JS, Scala et leurs potes, je pense que tu te trompes lourdement. Ils te permettront peut être d'écrire plus rapidement du code en vrac.
Ce n'est pas "peut-être", c'est certain. Au moins pour les deux premiers (et dans une moindre mesure JS depuis qu'il y a Node), ils peuvent se comporter comme de simples langages de script. Là où Java demande une certaine compréhension (ou une acceptation sans comprendre, ce qui n'est pas forcément mieux) du modèle Objet, les petits copains en question permettent de faire une moulinette en juste ce qu'il faut de lignes pour faire le boulot. Boilerplate réduit au minimum.
Mais pour réellement les maitriser et faire des choses qui tiennent debout la marche est aussi haute.
C'est un peu là que se situe mon désaccord avec le monde Java (et une partie du monde de l'ingénierie logicielle, d'ailleurs), je pense. Un script de dix lignes tient debout, et n'est pas plus compliqué à maintenir que son équivalent en trois classes bien modélisées. KISS, comme dirait l'autre. Je n'aime pas du tout la "sur-ingénierie" (over-engineering?), et Java encourage (ou en tous cas attire les amateurs de) ce genre de travers.
Une partie de ce reproche s'applique d'ailleurs à C/C++ : faire une fonction main() juste pour avoir un point d'entrée, c'est élégant intellectuellement, mais l'imposer pour des bases de code de quelques lignes à quelques dizaines, ce me semble contre-productif. Et de ce côté-là, Java a poussé cette logique encore plus loin, hélas.
Bon après que tu "aimes" ou pas, je m'en fou un peu.
Apparemment pas suffisamment, mais ça m'arrange.
Mais quand je n'aime pas un truc je passe simplement mon chemin en essayant d'être honnête intellectuellement.
[^] # Re: vive Grails
Posté par Larry Cow . En réponse au journal Epsilon, un outil de gestion de dépense. Évalué à 1.
On est d'accord. Et je maintiens que sorti des grosses applications métier (pour lesquelles effectivement, les profusion d'outils d'ingénierie logicielle autour de Java sont un atout), c'est assez peu adapté.
Tu n'as jamais croisé de ces experts Java, qui t'expliquent que ton problème simple est beaucoup plus compliqué qu'il n'y parait, que d'ailleurs il va te falloir racheter du matos, constituer un comité de pilotage, et j'en passe. À tel point que tu n'oses plus leur dire que ce que tu voulais, c'était trois tables avec juste ce qu'il faut de formulaires pour faire des opérations CRUD de base.
Le langage, non. L'écosystème (humain, essentiellement) qui va avec, oui.
C'est pour ça que je parle de marche haute. C'est très verbeux pour pas grand chose, et faire des choses simples en Java est plus compliqué qu'il n'est nécessaire (notamment comparé à Python ou Ruby). Après, comme souvent quand la première marche est haute, les autres s'enchaînent certainement mieux.
Mais j'ai tendance à me tenir au vieil adage "que les choses simples soient faciles, que les choses compliquées soient possibles". Java échoue, selon moi, sur le premier critère. Windev sur le second.
Ce n'est pas "peut-être", c'est certain. Au moins pour les deux premiers (et dans une moindre mesure JS depuis qu'il y a Node), ils peuvent se comporter comme de simples langages de script. Là où Java demande une certaine compréhension (ou une acceptation sans comprendre, ce qui n'est pas forcément mieux) du modèle Objet, les petits copains en question permettent de faire une moulinette en juste ce qu'il faut de lignes pour faire le boulot. Boilerplate réduit au minimum.
C'est un peu là que se situe mon désaccord avec le monde Java (et une partie du monde de l'ingénierie logicielle, d'ailleurs), je pense. Un script de dix lignes tient debout, et n'est pas plus compliqué à maintenir que son équivalent en trois classes bien modélisées. KISS, comme dirait l'autre. Je n'aime pas du tout la "sur-ingénierie" (over-engineering?), et Java encourage (ou en tous cas attire les amateurs de) ce genre de travers.
Une partie de ce reproche s'applique d'ailleurs à C/C++ : faire une fonction main() juste pour avoir un point d'entrée, c'est élégant intellectuellement, mais l'imposer pour des bases de code de quelques lignes à quelques dizaines, ce me semble contre-productif. Et de ce côté-là, Java a poussé cette logique encore plus loin, hélas.
Apparemment pas suffisamment, mais ça m'arrange.
Tu veux une médaille? ;)