Les langages de haut niveau sont plein d'abstractions et les langages objets semblent donner les outils pour créer des systèmes d'une grande complexité, il est tentant de pousser l'utilisation de ces traits à leur limite! Expérimenter, après tout, fait partie du processus d'apprentissage.
Dans mon parcours de programmeur j'ai beaucoup pêché dans la direction de l'over-engineering, surtout dans ma période d'apprentissage. Puis, un beau jour, j'ai réalisé que je mettais beaucoup moins de temps à écrire des prototypes fonctionnels en utilisant le shell ou le C qu'en utilisant des langages plus sophistiqués. En principe, ce devrait être le contraire! Les langages sophistiqués devraient me permettre de développer plus rapidement, c'est donc que je faisais quelque chose de travers... Lorsqu'on se pose la question dans ces termes, on trouve facilement la réponse: là où mes programmes shell ou C se contentaient d'écrire leurs diagnostics sur stderr mes autres programmes implémentaient des systèmes complexe de propagation de messages d'erreur, là où en cas d'erreur mes programmes en C ou en shell se contentaient de quitter après avoir fait un ménage succinct, mes autres programmes implémentaient des stratégies complexes d'analyse d'erreur et de récupération...
Je vois donc mon expérience dans des langages frustes comme le C, le shell ou l'assembleur comme une expérience très salutaire qui m'a poussé à développer des techniques de programmation rapides, efficaces et robustes, que j'ai pu reprendre à bon compte dans des environnements plus sophistiqués pour me concentrer sur les tâches que doit accomplir le programme.
# L'expérience avec des langages "frustes" est très salutaire
Posté par Michaël (site web personnel) . En réponse au journal Lutter contre l'overengineering. Évalué à 7.
Les langages de haut niveau sont plein d'abstractions et les langages objets semblent donner les outils pour créer des systèmes d'une grande complexité, il est tentant de pousser l'utilisation de ces traits à leur limite! Expérimenter, après tout, fait partie du processus d'apprentissage.
Dans mon parcours de programmeur j'ai beaucoup pêché dans la direction de l'over-engineering, surtout dans ma période d'apprentissage. Puis, un beau jour, j'ai réalisé que je mettais beaucoup moins de temps à écrire des prototypes fonctionnels en utilisant le shell ou le C qu'en utilisant des langages plus sophistiqués. En principe, ce devrait être le contraire! Les langages sophistiqués devraient me permettre de développer plus rapidement, c'est donc que je faisais quelque chose de travers... Lorsqu'on se pose la question dans ces termes, on trouve facilement la réponse: là où mes programmes shell ou C se contentaient d'écrire leurs diagnostics sur stderr mes autres programmes implémentaient des systèmes complexe de propagation de messages d'erreur, là où en cas d'erreur mes programmes en C ou en shell se contentaient de quitter après avoir fait un ménage succinct, mes autres programmes implémentaient des stratégies complexes d'analyse d'erreur et de récupération...
Je vois donc mon expérience dans des langages frustes comme le C, le shell ou l'assembleur comme une expérience très salutaire qui m'a poussé à développer des techniques de programmation rapides, efficaces et robustes, que j'ai pu reprendre à bon compte dans des environnements plus sophistiqués pour me concentrer sur les tâches que doit accomplir le programme.