• [^] # Re: Et si ....

    Posté par . En réponse à la dépêche 170 virus et chevaux de Troie pour Linux. Évalué à 5.

    Je citerais plusieurs problèmes :

    - le fait que beaucoup de LL ne soient pas écrits par des développeurs professionnels, ou bien par des gens qui n'ont pas tant de temps que ça pour le faire, fait que ces gens ne vont pas forcément "investir" dans l'apprentissage de techniques/langages de programmation modernes

    - un des intérêts des la communauté, c'est de pouvoir partager et réutiliser ; c'est l'argument de RMS quand il demande aux programmeurs de LL d'utiliser uniquement le C (ou à la rigueur Guile), afin que tout le monde puisse en profiter (connaissances des programmeurs) sur toutes les architectures (compilo C dispo sur quasi toutes les archs, ce qui n'est pas le cas de tous les compilo/interpréteurs)

    - l'immobilisme global de l'industrie informatique (qui utilise encore de nos jours majoritairement du C++ ou du Java)

    - à part OCaml, il n'existe pas de compilateur/outil libre "utilisable"* permettant de générer du code rapide dans un langage évolué ; et comme peu de développeurs connaissent OCaml et que la croyance populaire veut qu'on ait besoin de performance dans tous les logiciels, ca coince au C ou au C++ dans les LL

    Par contre, niveau techniques de programmations, les plus "grosses briques" sont codées de manière moderne, puissante et efficace, le kernel, gtk ou KDE en sont des exemples. Mais même dans ces briques, les raisons que j'ai avancées au-dessus sont toujours valides, ce qui fait coincer au niveau du langage.


    (*) utilisable dans le sens : le compilo est stable et maintenu, il existe une bonne lib de base (ou bien des extensions suffisamment standard), il existe des binding pour les lib/gui les plus répandus