Pour Python, je dirais que la fixette de la lisibilité (via l’indentation) en particulier du fait de s'être passé de délimiteurs de blocs "inutiles" a quand même longtemps (avant que les mix tab/espaces ne soient signalés à la première tentative d’exécution, mais en 2.7 qui a vécu si longtemps c'était encore le cas) été une source d'emmerde qui, sur du code passé par différentes personnes et/ou configs d'éditeurs, pouvait exécuter un truc différent de ce qui était affiché. Il suffisait d'un combo tab/espace qui aligne visuellement mais sortait à l’exécution la fin d'un bloc.
Le nb de fois ou j'ai passé un source au comportement prévu dans une moulinette remplacant les tab par 8 ou 16 espaces pour voir ce qui se retrouvait décalé...
In fine, je n'ai jamais aimé non plus le C++ (je n'en ait fait un peu qu'en école d'ingé en fait), qui sera peut-être remplacé par Rust en effet. Par contre je ne crois pas que Rust remplacera le C car la liberté qu'il offre et sa capacité à vraiment limiter l'usage de l'assembleur (toujours bénéfique à la portabilité d'un max de code) à très peu de choses combiné à la masse de code bas niveau intrinsèquement difficile à déverminer écrite dans ce langage est plus susceptible de poser des problèmes qu'en résoudre. Puis c'est toujours pareil avec les langages objets: Quand on en instancie un, c'est dans le code généré la foire aux allocations non précisément maîtrisées. Et il y a certaines phases (dans le démarrage, tout ce qui est avant d'avoir initialisé la DDR est concerné) ou sans le C, on serait probablement contraint de refaire plus de choses en assembleur ce qui serait un comble (et moins efficace sur tout processeur RISC, cad tout ce qui existe désormais même si on le cache pour raison de compatibilité binaire).
Ne pas oublier qu'il y a dans la génèse d'un langage de programmation toujours un usage qui va avec: C, c'est clairement pour tout faire et surtout un système d'exploitation complet. C++ a poussé avec les interfaces graphiques car dans ce cadre l'objet se justifie. Rust est venu de Mozilla... qui fait un applicatif graphique (donc besoins type C++) en frontal réseau (la sécurité n'y est pas une option) bien connu.
Python aurait dû en rester à un bash plus puissant et lisible ;o)
Sinon, dans les langages qui couchent bien avec C/C++ pour amener à un applicatif des capacités de script internes, n'oublions pas Lua qui est fait pour et ferait un meilleur compromis que des micropython & co, à mon sens. En prime, il ne casse rien entre 2 versions majeures car on a mal réfléchi au départ (coucou Python, pourquoi tout le monde est resté si longtemps en 2.7??? Ça faisait gueuler les gardiens du temple et le gourou Guido, ce qui ne s'invente pas, mais personne n'aime revenir sur ce qui marche car on a changé la division, entre autres).
[^] # Re: La suite , la suite ...
Posté par lym . En réponse au journal De la rigueur dans la programmation. Évalué à 2.
Pour Python, je dirais que la fixette de la lisibilité (via l’indentation) en particulier du fait de s'être passé de délimiteurs de blocs "inutiles" a quand même longtemps (avant que les mix tab/espaces ne soient signalés à la première tentative d’exécution, mais en 2.7 qui a vécu si longtemps c'était encore le cas) été une source d'emmerde qui, sur du code passé par différentes personnes et/ou configs d'éditeurs, pouvait exécuter un truc différent de ce qui était affiché. Il suffisait d'un combo tab/espace qui aligne visuellement mais sortait à l’exécution la fin d'un bloc.
Le nb de fois ou j'ai passé un source au comportement prévu dans une moulinette remplacant les tab par 8 ou 16 espaces pour voir ce qui se retrouvait décalé...
In fine, je n'ai jamais aimé non plus le C++ (je n'en ait fait un peu qu'en école d'ingé en fait), qui sera peut-être remplacé par Rust en effet. Par contre je ne crois pas que Rust remplacera le C car la liberté qu'il offre et sa capacité à vraiment limiter l'usage de l'assembleur (toujours bénéfique à la portabilité d'un max de code) à très peu de choses combiné à la masse de code bas niveau intrinsèquement difficile à déverminer écrite dans ce langage est plus susceptible de poser des problèmes qu'en résoudre. Puis c'est toujours pareil avec les langages objets: Quand on en instancie un, c'est dans le code généré la foire aux allocations non précisément maîtrisées. Et il y a certaines phases (dans le démarrage, tout ce qui est avant d'avoir initialisé la DDR est concerné) ou sans le C, on serait probablement contraint de refaire plus de choses en assembleur ce qui serait un comble (et moins efficace sur tout processeur RISC, cad tout ce qui existe désormais même si on le cache pour raison de compatibilité binaire).
Ne pas oublier qu'il y a dans la génèse d'un langage de programmation toujours un usage qui va avec: C, c'est clairement pour tout faire et surtout un système d'exploitation complet. C++ a poussé avec les interfaces graphiques car dans ce cadre l'objet se justifie. Rust est venu de Mozilla... qui fait un applicatif graphique (donc besoins type C++) en frontal réseau (la sécurité n'y est pas une option) bien connu.
Python aurait dû en rester à un bash plus puissant et lisible ;o)
Sinon, dans les langages qui couchent bien avec C/C++ pour amener à un applicatif des capacités de script internes, n'oublions pas Lua qui est fait pour et ferait un meilleur compromis que des micropython & co, à mon sens. En prime, il ne casse rien entre 2 versions majeures car on a mal réfléchi au départ (coucou Python, pourquoi tout le monde est resté si longtemps en 2.7??? Ça faisait gueuler les gardiens du temple et le gourou Guido, ce qui ne s'invente pas, mais personne n'aime revenir sur ce qui marche car on a changé la division, entre autres).