Les langages de programmation (enfin les "vieux") ont été conçus à une époque où on n'avait pas de recul sur les gestions de versions, sur les éditeurs de texte, sur la diversité des conventions, etc. Ils trainent donc des erreurs du passé, et le mélange fond/forme dans un fichier source, c'est AMHA une erreur de conception profonde du langage. Les sauts de ligne faisant partie de la forme (et malheureusement parfois du fond), ils sont traînés comme des boulets depuis 20 ans.
Error: helloworld.c:1 : c'est évidemment un bug du compilateur. Ça serait beaucoup plus logique qu'il indique le caractère dans le fichier qui pose problème, et pas la ligne.
Ce que je veux dire, c'est que le système a une inertie terrible : 1) les langages de programmation existants prennent parfois en compte des informations de mise en page du code, 2) les éditeurs savent très mal travailler l'indentation d'un fichier, 3) les programmeurs sont probablement encore plus intertes que le reste de l'humanité, et faire changer ses habitudes à un programmeur, ca doit être au moins aussi stimulant intellectuellement que de faire rentrer des notions de politique internationale dans la tête de G. W. Bush. La conclusion de ça, c'est que dans 30 ans, les fichiers seront encore indentés à la main ou très mal indentés par un éditeur, les languages (comme C++++) prendront toujours en compte des informations de fond pour fabriquer du sens, il faudra toujours un bac +30 pour faire fonctionner les autotools (dont la version 37.8 sera bien entendu incompatible avec la 37.7, elle même incompatible avec la 37.6).
Mais ça me rend juste triste de voir qu'il faut implémenter des workarounds sales dans les svn en 2006 parce qu'il est rigoureusement impossible de comprendre qu'un gusse a remplacé une tab par 8 espaces. Ça me rend aussi triste de voir que des projets comme Gnome ou KDE (et probablement des centaines d'autres) continuent à se prendre la tronche et donc à perdre un temps fou sur la définition de normes pour l'indentation, alors qu'encore une fois ça serait tellement simple si ça pouvait être géré par l'éditeur de chacun, en fonction des préférences de chacun, mais seulement à l'affichage, puisque c'est bien de ça qu'il s'agit, et pas dans le fichier source lui-même. Tout ça parce qu'on traine les erreurs du passé, comme un boulet au pied auquel on est tellement habitué que ça nous ferait presque mal de nous en débarrasser.
[^] # Re: Enfin !!
Posté par arnaudus . En réponse à la dépêche Subversion 1.4.0 est disponible. Évalué à 5.
Error: helloworld.c:1 : c'est évidemment un bug du compilateur. Ça serait beaucoup plus logique qu'il indique le caractère dans le fichier qui pose problème, et pas la ligne.
Ce que je veux dire, c'est que le système a une inertie terrible : 1) les langages de programmation existants prennent parfois en compte des informations de mise en page du code, 2) les éditeurs savent très mal travailler l'indentation d'un fichier, 3) les programmeurs sont probablement encore plus intertes que le reste de l'humanité, et faire changer ses habitudes à un programmeur, ca doit être au moins aussi stimulant intellectuellement que de faire rentrer des notions de politique internationale dans la tête de G. W. Bush. La conclusion de ça, c'est que dans 30 ans, les fichiers seront encore indentés à la main ou très mal indentés par un éditeur, les languages (comme C++++) prendront toujours en compte des informations de fond pour fabriquer du sens, il faudra toujours un bac +30 pour faire fonctionner les autotools (dont la version 37.8 sera bien entendu incompatible avec la 37.7, elle même incompatible avec la 37.6).
Mais ça me rend juste triste de voir qu'il faut implémenter des workarounds sales dans les svn en 2006 parce qu'il est rigoureusement impossible de comprendre qu'un gusse a remplacé une tab par 8 espaces. Ça me rend aussi triste de voir que des projets comme Gnome ou KDE (et probablement des centaines d'autres) continuent à se prendre la tronche et donc à perdre un temps fou sur la définition de normes pour l'indentation, alors qu'encore une fois ça serait tellement simple si ça pouvait être géré par l'éditeur de chacun, en fonction des préférences de chacun, mais seulement à l'affichage, puisque c'est bien de ça qu'il s'agit, et pas dans le fichier source lui-même. Tout ça parce qu'on traine les erreurs du passé, comme un boulet au pied auquel on est tellement habitué que ça nous ferait presque mal de nous en débarrasser.