Hm l'IDE utilisé en tant qu'outil ultime à tout faire, et qui fait tout.
Extrêmement performant pour tout ce qui est prévu.
Extrêmement lourd et contre productif pour tout ce qui de rentre pas dans le moule de l'IDE et du langage, et... c'est justement ce qu'explique ce journal!
Forcement quand on est expert dans un domaine, ça fait mal de voir qu'il y a un manière de le faire 25x plus vite en utilisant d'autres outils. Alors on se console comme on peut en se disant que sur ce point particulier on perd, mais que dans la majorité des autres cas on gagne.
A voir l'histoire des projets informatiques remplis de succès rapides dus aux gens qui utilisent un outil en rupture et bien adapté à un problème précis donné, j'ai énormément de mal à croire en l'outil ultime qui fait tout d'une manière en moyenne optimale. Et j'ai encore plus de mal à croire que cet outil est à tout instant le truc à la mode du moment (ou l'avant dernier truc à la mode).
Un outil n'est jamais adapté simultanément à tout. Les outils qui tentent de le devenir sont plus typiquement médiocre en tout que bon en tout... Il en va de même pour les compétences: si on se limite à des "experts langage XYZ" comment réagir quand les besoins fonctionnels vont changer vers un domaine encore inconnu pour eux? Le langage ne devrait être qu'un détail. Hors il est des secteurs où il est devenu un critère principal de détermination de compétence. C'est aussi ça que je critique.
Vu sous cet angle enfermer tout un projet dans une IDE et dans un langage, et ce surtout quand il est de grande envergure, me laisse sans voix.
Un projet de grande envergure ne peut pas se permettre de fixer des choix technologiques arbitraires restreints à ce point pour cause d'IDE manquant d'ouverture sur le monde surtout quand on considère la volatilité du marché informatique. On est dans un contexte ou quelque chose qui ne s'integre bien qu'avec les trucs du même type va forcement poser des problème à un point donné.
Java est peut être très adapté pour certains problèmes mais croire qu'il peut tout faire tout seul ou à grand coup d'outils magiques est une erreur monumentale. C'est tout aussi grave que de dire qu'on veut déployer une archi énorme entière sous Linux juste pcq'on aime Linux, sans même prendre la peine d'étudier les besoins multiples et divers de l'application considérée.
Bref tout ça pour dire d'un langage n'est qu'un outil et qu'une IDE aussi, et que s'enfermer dans un seul outil pour un gros projet n'a pas vraiment de sens en terme de productivité. Un projet bien géré saura être souple et garder une archi cohérente tout en s'autorisant d'utiliser les outils potentiellement différents les mieux adaptés aux fonctions à intégrer sous réserve de couplage suffisamment souple pour permettre ça.
Et sur un gros projet, un couplage technique tellement rigide qu'il ne permettrait ce genre de souplesse nul part est typiquement le signe d'une mauvaise archi et/ou de mauvaise directions techniques prises sans que le besoin ait été correctement qualifié.
[^] # Re: Heu...
Posté par Guillaume Knispel . En réponse au journal Création du projet "OQLToLang". Évalué à 3.
Extrêmement performant pour tout ce qui est prévu.
Extrêmement lourd et contre productif pour tout ce qui de rentre pas dans le moule de l'IDE et du langage, et... c'est justement ce qu'explique ce journal!
Forcement quand on est expert dans un domaine, ça fait mal de voir qu'il y a un manière de le faire 25x plus vite en utilisant d'autres outils. Alors on se console comme on peut en se disant que sur ce point particulier on perd, mais que dans la majorité des autres cas on gagne.
A voir l'histoire des projets informatiques remplis de succès rapides dus aux gens qui utilisent un outil en rupture et bien adapté à un problème précis donné, j'ai énormément de mal à croire en l'outil ultime qui fait tout d'une manière en moyenne optimale. Et j'ai encore plus de mal à croire que cet outil est à tout instant le truc à la mode du moment (ou l'avant dernier truc à la mode).
Un outil n'est jamais adapté simultanément à tout. Les outils qui tentent de le devenir sont plus typiquement médiocre en tout que bon en tout... Il en va de même pour les compétences: si on se limite à des "experts langage XYZ" comment réagir quand les besoins fonctionnels vont changer vers un domaine encore inconnu pour eux? Le langage ne devrait être qu'un détail. Hors il est des secteurs où il est devenu un critère principal de détermination de compétence. C'est aussi ça que je critique.
Vu sous cet angle enfermer tout un projet dans une IDE et dans un langage, et ce surtout quand il est de grande envergure, me laisse sans voix.
Un projet de grande envergure ne peut pas se permettre de fixer des choix technologiques arbitraires restreints à ce point pour cause d'IDE manquant d'ouverture sur le monde surtout quand on considère la volatilité du marché informatique. On est dans un contexte ou quelque chose qui ne s'integre bien qu'avec les trucs du même type va forcement poser des problème à un point donné.
Java est peut être très adapté pour certains problèmes mais croire qu'il peut tout faire tout seul ou à grand coup d'outils magiques est une erreur monumentale. C'est tout aussi grave que de dire qu'on veut déployer une archi énorme entière sous Linux juste pcq'on aime Linux, sans même prendre la peine d'étudier les besoins multiples et divers de l'application considérée.
Bref tout ça pour dire d'un langage n'est qu'un outil et qu'une IDE aussi, et que s'enfermer dans un seul outil pour un gros projet n'a pas vraiment de sens en terme de productivité. Un projet bien géré saura être souple et garder une archi cohérente tout en s'autorisant d'utiliser les outils potentiellement différents les mieux adaptés aux fonctions à intégrer sous réserve de couplage suffisamment souple pour permettre ça.
Et sur un gros projet, un couplage technique tellement rigide qu'il ne permettrait ce genre de souplesse nul part est typiquement le signe d'une mauvaise archi et/ou de mauvaise directions techniques prises sans que le besoin ait été correctement qualifié.