Mouais, je ne me suis pas vraiment convaincu. Lorsque tu as 30K lignes de template Machin et 50K lignes de code utilisant l'ORM Bidule, quand bien même tu peux changer ton moteur de template ou ton ORM, tu ne vas pas le faire car tu devras quand même réécrire énormément de choses. Alors oui tu vas peut être pouvoir changer des composants secondaires, mais je pense que le choix des composants principaux se fera au début du projet et ne changera plus lorsqu'une masse critique de code sera atteinte.
On retrouve cette philosophie en Go, de ne pas s'encombrer de ce qui pourrait devenir un boulet par la suite.
Lorsque ton code grossi, il devient son propre boulet. Regarde FireFox ou OpenOffice (programmes que je respectent énormément mais qui illustreront très bien mon propos): ils n'utilisent pas de framework, pourtant les faire évoluer est très complexe, même si leurs développeurs sont eux mêmes écrits la plupart du code, parce que les décisions de design d'il y a plus de 15 ans ne sont plus forcément pertinentes aujourd'hui etc... Et OpenOffice passerait volontiers à Qt (un framework donc) si ça ne représentait pas tant de travail que ça de changer son propre code tout-écrit-à-la-main-sans-dépendance-à-un-framework.
Lorsqu'il y a aura pléthore de programmes en Go de plusieurs millions de ligne, que les gens auront essayé de s'en servir pour plein de choses pour lesquelles il n'était pas prévu à la base (ce qui est naturel et moteur de progrès), tu en trouveras plein des programmes en Go qui se traînent des boulets.
[^] # Re: Go
Posté par GuieA_7 (site web personnel) . En réponse au journal Et si JavaScript allait droit dans le mur ?. Évalué à 5.
Mouais, je ne me suis pas vraiment convaincu. Lorsque tu as 30K lignes de template Machin et 50K lignes de code utilisant l'ORM Bidule, quand bien même tu peux changer ton moteur de template ou ton ORM, tu ne vas pas le faire car tu devras quand même réécrire énormément de choses. Alors oui tu vas peut être pouvoir changer des composants secondaires, mais je pense que le choix des composants principaux se fera au début du projet et ne changera plus lorsqu'une masse critique de code sera atteinte.
Lorsque ton code grossi, il devient son propre boulet. Regarde FireFox ou OpenOffice (programmes que je respectent énormément mais qui illustreront très bien mon propos): ils n'utilisent pas de framework, pourtant les faire évoluer est très complexe, même si leurs développeurs sont eux mêmes écrits la plupart du code, parce que les décisions de design d'il y a plus de 15 ans ne sont plus forcément pertinentes aujourd'hui etc... Et OpenOffice passerait volontiers à Qt (un framework donc) si ça ne représentait pas tant de travail que ça de changer son propre code tout-écrit-à-la-main-sans-dépendance-à-un-framework.
Lorsqu'il y a aura pléthore de programmes en Go de plusieurs millions de ligne, que les gens auront essayé de s'en servir pour plein de choses pour lesquelles il n'était pas prévu à la base (ce qui est naturel et moteur de progrès), tu en trouveras plein des programmes en Go qui se traînent des boulets.