Quel langage bas niveau de nouvelle génération est le meilleur choix lors de la migration d'une base de code? [fermé]

Question

Supposons qu'une entreprise utilise beaucoup le C / C ++ et que vous souhaitez commencer à planifier la migration vers les nouvelles technologies afin de ne pas devenir une entreprise COBOL d'il y a 15 ans.

Pour le moment, C / C ++ fonctionne plus que bien et il y a de nombreux outils de développement sur le marché.

Mais vous voulez commencer à y penser maintenant, car compte tenu de l’énorme base de code en cours d’exécution et de la sensibilité des données, vous estimez qu’il peut prendre 5 à 10 ans pour passer à l’étape suivante sans surcharger le budget et les équipes de développement.

Vous avez entendu parler de D , qui commence à être assez mature, et Go , promettant d'être très populaire.

Quel serait votre choix et pourquoi?

Answer 1

D et Go deviendront probablement aussi populaires que Python et Ruby aujourd'hui. Ils occupent chacun un créneau et, même si D était supposé être un remplaçant à part entière du C ++, il n'acquerra probablement jamais assez de masse pour le repousser. Sans parler du fait qu'ils ne sont pas suffisamment stables / matures et que l'on ignore si ces langages seront pris en charge dans 10 à 20 ans pour le matériel et les systèmes d'exploitation actuels. Étant donné que le C / C ++ est à peu près le langage compilé et qu'il est utilisé dans la grande majorité des systèmes d'exploitation et des applications en code natif, il est très peu probable que ce langage disparaisse dans un avenir proche.

Answer 2

C et C ++ sont un combo à peu près imbattable en ce qui concerne natif / non géré / "lowlevel". langues.

Non pas parce que ce sont les meilleures langues, loin de là, mais parce qu’elles existent, elles font le travail et elles sont assez bonnes . Il ne fait guère de doute que D, par exemple, est meilleur que le C ++ à bien des égards. Mais cela échoue dans le plus important: Compatibilité avec tout le code C ++ existant. Sans cette exigence, la plupart de ce code serait écrit dans un langage géré de toute façon. La seule raison pour laquelle tant de bases de code utilisent le C ++ aujourd'hui, c'est parce qu'ils l'ont utilisé l'année dernière et qu'il serait trop pénible de passer à autre chose. Mais si et quand ils basculent, ils ne basculent généralement pas en D. Ils basculent en C #, Java ou Python.

Le problème de D et des autres "à venir" Les langues en concurrence pour les mêmes créneaux sont qu’elles sont meilleures, mais qu’elles ne sont pas assez novatrices pour motiver les gens à les remplacer.

Donc C et C ++ sont là pour rester. Il est peu probable que C évolue beaucoup plus loin. C’est ce qu’il est, et l’un des créneaux qu’il doit combler est la "simplicité, même pour les rédacteurs de compilateur". Aucune autre langue n’est susceptible de le battre dans ce créneau, même s’ils ne révisent plus jamais la norme.

Le C ++ évolue de manière beaucoup plus spectaculaire, le C ++ 0x se rapprochant et il dispose déjà d'une liste énorme de fonctionnalités qu'il souhaite intégrer par la suite . C ++ n’est en aucun cas une impasse.

Les deux langues sont là pour rester. Peut-être que dans 50 ans, d'autres langues les auront remplacées, mais cela n'arrivera pas cette décennie.

Answer 3

J'utilise actuellement D régulièrement. Je ne le recommanderais pas encore pour les personnes qui écrivent du code de production car il est trop avancé. Je m'en tire parce que l'essentiel de mon code est constitué de prototypes de recherche en bioinformatique. Cependant, le langage commence à se stabiliser. Andrei Alexandrescu publie un livre intitulé "The D Programming Language". En mars prochain, des efforts sont actuellement déployés pour stabiliser les spécifications de la version 2 de la langue à temps pour le livre.

Bien que D ne soit pas un sur-ensemble formel de C, c’est ce que j’appellerais un sur-ensemble idiomatique, à l’exception de l’absence de pré-processeur. En d’autres termes, tout code écrit en C proprement dit (en ignorant le préprocesseur) peut être traduit trivialement en D sans refonte, car les concepts C tels que les pointeurs et l’ASM en ligne sont présents et fonctionnent de la même manière en D et en C. D prend également en charge direct les liens vers le code C et la bibliothèque standard D incluent l’ensemble de la bibliothèque standard C.

En outre, malgré le manque de bibliothèques de D, car il s’agit toujours d’un langage à la fine pointe, c’est le rêve d’un auteur de bibliothèques en raison de ses capacités de métaprogrammation. Si ça décolle, il aura probablement des libs assez impressionnants. Pour un aperçu de cela, voir std.range ou std.algorithm dans la bibliothèque standard D2 (Phobos). Comme autre exemple, j’ai implémenté un modèle de parallélisme de type OpenMP (parallèle, foreach, carte parallèle, parallèle, futurs) en tant que bibliothèque pure en D, sans aucun support spécial du compilateur. (Voir http://cis.jhu.edu/~dsimcha/parallelFuture.html . )

Étant donné que vous êtes principalement intéressé par le long terme, je dirais qu'il faut 6 mois à D pour se stabiliser (compte tenu du livre d'Andrei et de la tendance actuelle à stabiliser le langage, la version 2 devrait être stable d'ici là), puis regarder dur.

Modifier: maintenant que les spécifications de base du langage sont relativement stables et que l'accent a été mis sur le développement de chaînes d'outils et de bibliothèques, je recommanderais de D pour les petits projets de production, sauf si vous vous trouvez dans un environnement très hostile au risque. . Les grands projets qui doivent absolument avoir une bonne chaîne d’outils et le support des bibliothèques doivent néanmoins attendre.

Answer 4

Si vous croyez aux principes de la fabrication sans gaspillage, vous devez vous efforcer de "décider le plus tard possible". Le moment devrait être le dernier moment responsable, c'est-à-dire le moment où le fait de ne pas prendre de décision élimine une alternative importante.

Je pense que ce principe peut être appliqué à votre situation. Au lieu de vous engager maintenant dans une langue (que vous ne savez même pas dans 10 ans), gardez vos options ouvertes. Peut-être que vous refactorisez une partie de votre code pour qu'il soit un peu plus générique ou qu'il repose sur plus d'abstractions, de sorte que le processus sera plus facile lorsqu'il sera nécessaire de migrer.

Answer 5

Tenez-vous en C et C ++. Je ne vois pas que cela ressemblerait à COBOL, ça marche aussi bien que n'importe quoi, et vous n'aurez aucun problème à trouver des personnes pour coder en C et C ++.

Answer 6

C ++ - il est relativement jeune et mis à jour ... Il compte un grand nombre de fournisseurs de compilateurs et possède amélioré tout le temps.

C - il vivrait longtemps en comblant le fossé entre les langages assembleur et les langages de niveau supérieur. Il est également très simple et facile d’implémenter un langage, il resterait donc le première langue pour divers " étrange " des architectures comme celles qui sont intégrées ou extrêmement nouvelles.

D est prometteur, mais ses spécifications et bibliothèques encore très nouvelles et instables.

Go est né il y a quelques semaines ... N'utilisez jamais la version 0 pour les grands projets importants. En outre, le C ++ ou le D est nettement plus limité.

Answer 7

Mise à jour 2019: Le C ++ restera en place pendant les 10 prochaines années ... (sinon, je corrigerai cette réponse si elle ne sera plus pertinente ....)

La raison pour laquelle les entreprises travaillent avec COBOL aujourd'hui est qu’elles ont déjà écrit des millions de codes COBOL. si les utilisateurs pouvaient le lancer - ils le feront immédiatement, par contre - les entreprises travaillent avec le C / C ++ dans le cadre de leurs besoins et de nouveaux projets utilisant ce langage, car elles ne peuvent pas / ne veulent pas utiliser Java / c # n’importe quel autre langage basé sur le framework - donc COBOL n’est pas l’analogie ici.

Answer 8

Comme Dsimcha a déclaré que la voie D est actuellement risquée. Pourtant, le langage a un potentiel énorme, il est de bas niveau et j'ai connu une productivité considérablement meilleure avec D (au lieu de C ++). Peut-être ce que les gens ressentent avec les langages dynamiques.

Go est tellement mis sur le marché sur les blogs que cela ressemble à une blague. La distribution d'une méthode d'interface n'est pas anodine et est en fait plus lente que la distribution d'une méthode classique à héritage unique.

Si vous avez une base de code énorme, la décision est bien sûr plus difficile, je vous conseillerais seulement de passer à de nouveaux projets, pas à ceux existants.

Answer 9

Je ne me concentrerais pas sur une langue mais plutôt sur les bibliothèques qui l’entourent. C ++ en combinaison avec les bibliothèques boost sont un excellent choix. Les personnes qui développent en C ++ ont tendance à mieux comprendre l’informatique. J’ai moi-même commencé par Java, ce qui m’a facilité la vie en cachant beaucoup de choses fondamentales, ce qui est bien. Cependant, j’ai vraiment commencé à comprendre la programmation une fois que j’ai appris le C / C ++ (pointeurs, etc.).

Je reconnais que le C ++ peut être difficile (par exemple, la gestion de la mémoire). Je pense donc qu’il est bon d’avoir un langage "complémentaire" où les performances ne sont pas essentielles et où la lisibilité (== maintenabilité) est élevée: je recommande Python pour cela.

Answer 10

Il existe d'innombrables machines exécutant le logiciel C ++, je ne les vois pas arrêter tout à la fois. Si C ++ va faire obstacle à COBOL, il y aura un énorme marché pour la migration d'applications. Des outils spécialisés seront développés pour traduire les applications C ++ dans le langage populaire du moment (Z ++ ???).

Je pense donc que le meilleur conseil est de traverser ce pont quand vous y arriverez.

Answer 11

Découvrez le kit de développement logiciel Intel® Cilk ++ si vous Je souhaite susciter votre intérêt pour le développement C ++ / multicœurs. Je ne vois pas C ou C ++ partir de si tôt non plus.

Answer 12

La comparaison de C * avec Cobol est discutable

La comparaison de C * à Cobol peut conduire à une conclusion erronée. C était parfait pour sa journée, un énorme pas en avant lors de son introduction et il fait toujours le travail aujourd'hui.

Je résumerais Cobol lors de ma journée la plus charitable avec " nice try ".

C et C ++ survivront longtemps car ils conviennent parfaitement aux langages d’implémentation. Cela ne changera jamais vraiment.

En outre, considérez que le principal problème négatif avec C / C ++ est le manque de sécurité de la mémoire. Cela tend à être de moins en moins problématique à mesure que les codes mûrissent. Cela signifie qu'il n'y aura aucune raison sérieuse de remplacer les anciens codes.

Je m'attends à ce que les systèmes logiciels se développent à partir de C. Regardez la hiérarchie actuelle:

• application écrite dans un cadre tel que Rails
• back-end d'application écrit en Ruby, PHP, Python, C #, peu importe
• Implémentation d'exécution Ruby, PHP, Python ou C # (écrite en C *)
• Noyau OS (écrit en C89)

Je ne pense pas que les anciennes couches disparaîtront, et je pense que les couches supérieures héritées écrites en C et C ++ seront simplement prises en charge de cette façon pendant une période indéterminée, puis seront progressivement supprimées pour leur remplacement écrites en Ruby, Python. , C #, ou un développement futur.

Answer 13

Nous n'avons aucune idée si Go trouvera l'acceptation. Être sur Google ne suffira probablement pas.

D? Eh bien, on dit de bonnes choses à ce sujet, mais cela ne décollera pas non plus. Aucune base d'utilisateurs à proprement parler. D est n ° 20 en popularité sur index TIOBE et tomber rapidement.

Vous pouvez dire que la popularité d’une langue n’a pas grand-chose à voir avec la pertinence de son adaptation au travail de votre entreprise. Mais cela a beaucoup à voir avec la facilité avec laquelle il sera possible de trouver des personnes qualifiées pour le programmer.

Java est au top et je serais surpris que cela disparaisse au cours des 20 prochaines années. Ce n'est pas considéré comme un langage de programmation système, mais il fonctionne suffisamment bien pour que vous puissiez effectuer quelques tâches en C ++ que vous ne pourriez pas en Java. Certes, de nos jours, personne n'est disposé à confier aux programmeurs humains le travail (sans faille et souvent plus efficacement) effectué par le ramasse-miettes. J’ai pour ma part considéré que Java constituait une avancée significative par rapport au C ++ en termes d’efficacité de la programmation.

Je suis assez impressionné par Ruby . C'est un langage élégant et expressif: vous pouvez accomplir beaucoup de choses avec pas trop de code, mais ce code est toujours lisible. L'un des principes fondamentaux de Ruby est d'être cohérent et de ne pas laisser de surprises au développeur. C'est une très bonne idée, IMO, et augmente la productivité. Au moment du grand battage médiatique de Rails (qui est peut-être toujours en cours), j’ai pris un large risque pour Ruby car son implémentation de référence est extrêmement lente. Toutefois, les employés de JRuby de Sun ont accéléré les choses rapidement sur une machine virtuelle, de sorte qu’il vaut vraiment la peine d’y réfléchir. Ruby fournit des fermetures et une bonne poignée de capacités de programmation fonctionnelle (voir ci-dessous pourquoi cet important point important), bien que ce ne soit pas vraiment considéré comme un langage de PF. Indice TIOBE: 10 et en hausse.

Un aspect à prendre en compte pour l’avenir est le fait que les fabricants de processeurs se sont heurtés à une limite de performances imposée par la physique. Il n'y a plus de CPU disponible 30% plus rapide chaque Noël, comme c'était le cas auparavant. Alors maintenant, pour obtenir plus de performances, vous avez besoin de plus de cœurs. Le développement logiciel nécessitera toute l'aide possible pour la programmation simultanée multicœur. C ++ vous laisse presque seul avec cela, et les solutions de Java sont horribles par rapport aux normes modernes.

De ce fait, il existe une certaine tendance à la programmation fonctionnelle (qui élimine en grande partie les tracas associés à la concurrence) ainsi que les langages offrant un meilleur support de la concurrence. Erlang a été écrit spécifiquement pour cela et pour pouvoir échanger du code dans un programme en cours d'exécution (Ericsson voulait des temps de disponibilité incroyables). Scala est similaire à Java mais offre un support beaucoup plus puissant pour la programmation fonctionnelle et la concurrence. Clojure , idem, mais c'est un Lisp et il ne figure même pas dans le top 50 (pour le moment !!).

Scala a été développé par des universitaires et le montre: Il est sophistiqué et totalement pédant sur les types de données; il essaie d'être le couteau suisse des langages de programmation. Je pense que beaucoup de programmeurs moyennement intelligents auront du mal à maîtriser Scala. Ruby est moins FP et ne fait pas tellement de choses en matière de concurrence, mais c'est pragmatique, amusant et facile à gérer. De plus, sur la JVM, une quantité énorme de code est facilement disponible dans les bibliothèques Java. peut interfacer avec. Donc:

Mon pari serait sur Ruby, avec une chance extérieure sur Scala. Mais il y a beaucoup d'alternatives!

Answer 14

Java. Pour la plupart des choses de bas niveau, Java va bien de nos jours. Pourquoi opter pour une solution partielle à C / C ++ telle que D ou Go, alors que vous pouvez avoir quelque chose d'aussi sûr et facile à développer que Java? Si vous recherchez une solution en temps réel, D et Go ne le sont certainement pas , sans compter qu'ils sont probablement encore moins pris en charge que Java.

Java est maintenant un langage de programmation système . Je ne vois pas comment vous pouvez envisager quoi que ce soit avec des constructions non sécurisées telles que les pointeurs "next gen". La seule raison pour laquelle ces constructions instables ont jamais existé est qu’il s’agissait d’une approche pragmatique de la construction d’un langage complet. Il n’y avait aucun souci de représenter la mémoire dans des objets discrets, car ils voulaient juste construire quelque chose qui fonctionnait . Il existe déjà des applications temps réel matérielles et logicielles en Java, une variété de processeurs de bytecode matériels et plus de 2 milliards d'appareils mobiles exécutant Java. Au mieux, il vous suffira d'ajouter des constructions pour l'interopérabilité avec des périphériques, ce qui ne représenterait pas beaucoup de code. même en C / C ++, il vous faudrait quand même ajouter ces constructions ...

Qu'est-ce que vous programmez? Microcontrôleurs 8 bits avec 1 Ko de RAM? Dans ce cas, il serait inutile d’utiliser autre chose que l’assembleur pour cette plate-forme ...