Quels problèmes peuvent découler de l'émulation de concepts dans d'autres langues?

12

J'ai lu à plusieurs reprises sur le Web que si votre langue ne prend pas en charge un concept, par exemple, l'orientation d'objet ou peut-être des appels de fonction, et que cela est considéré comme une bonne pratique dans cet autre contexte, vous devriez le faire.

Le seul problème que je peux voir maintenant est que d'autres programmeurs peuvent trouver votre code trop différent de l'habituel, ce qui rend leur programmation difficile. À votre avis, quels autres problèmes pourraient en découler?

programming-languages concepts idioms

— Julio Rodrigues
source

3

Les gens se moqueront de vous, pour une chose :-)

— Karl Bielefeldt

J'ai traduit une fois un analyseur de fonctions imbriqué de D en java une fois, mais je dois admettre que ce n'est pas le morceau de code le plus propre que j'ai jamais écrit (une grande fonction avec une interface et plusieurs classes l'implémentant définies à l'intérieur)

— ratchet freak

23

L'un des problèmes est que vous pouvez vous retrouver à écrire beaucoup de code pour exprimer quelque chose d'une manière que vous ferez dans une autre langue, alors qu'il existe une manière plus simple dans la langue que vous utilisez.

Par exemple, dans une réponse sur Stack Overflow , j'ai expliqué comment les contrats de code, concept utilisé dans .NET Framework, peuvent être partiellement émulés en PHP qui ne les prend pas en charge. J'ai fini par écrire beaucoup de code pour rien, car la même chose était faisable avec des tableaux simples.

Plus généralement, chaque langue a sa propre culture, ses propres bonnes pratiques, son propre style.

Si je commence à écrire du code C # comme si c'était C, ce serait moche.
Si j'appréhende Haskell en tant que développeur Java qui a été forcé d'utiliser Haskell, mais que je ne veux pas comprendre ses points forts et que je veux simplement cloner les concepts de Java, le code que j'écrirais en souffrira.
etc.

Il n'y a rien de mal à améliorer le langage (par exemple, améliorer C # en introduisant des unités de mesure comme en F #), mais si vous le faites trop, vous devriez peut-être choisir un langage différent qui correspond réellement à vos besoins.

— Arseni Mourzenko
source

+1 Bonne réponse, et merci pour les termes de recherche supplémentaires avec l'ajout d'unités de mesure à C # comme dans F #.

2

En tant que personne qui a quitté son emploi une fois parce qu'elle était forcée d'utiliser Java, mes 2 cents: on ne peut pas être forcé d'utiliser Haskell, on en tombe amoureux et ensuite ça vous aspire jusqu'au point de non-retour. Haskell est comme un joli trou noir dans lequel vous voulez juste tomber - et contrairement à un vrai, vous vivez toujours pour raconter l'histoire :)

— Cetin Sert

vous devriez peut-être choisir une autre langue ... sauf lorsque vous n'avez pas le choix, comme le JavaScript côté client. (Même ainsi, ne pas avoir le choix n'est pas une excuse pour implémenter l'émulation OOP basée sur les classes dans un langage prototype. Il est beaucoup plus efficace d'apprendre simplement comment le langage fonctionne.)

— kojiro

@kojiro: ou un autre travail. J'ai moi-même eu le même problème lorsque j'ai été forcé d'utiliser PHP, et j'essayais constamment de modifier le langage, y compris en écrivant mon propre compilateur. Une solution moins folle était de changer mon travail et de commencer à travailler uniquement sur des projets qui n'utilisent pas PHP.

— Arseni Mourzenko

1

@Cetin Sert: d'accord, Haskell est une excellente langue. Mais si quelqu'un ne veut pas l'apprendre et ne comprend pas la programmation fonctionnelle, il serait difficile d'apprécier Haskell.

— Arseni Mourzenko

10

La baisse de la lisibilité est déjà un problème en soi: elle réduit considérablement le bassin de personnes qui pourraient potentiellement maintenir votre projet sans une formation approfondie de votre part.

En plus,

La mise en œuvre du paradigme étranger peut coûter plus cher que les économies potentielles de son utilisation
Votre adaptation de la fonctionnalité étrangère peut être boguée, augmentant les coûts de maintenance
Votre adaptation de la fonctionnalité étrangère peut pousser votre pile technologique dans les limites au-delà de celles requises par votre implémentation native.

— dasblinkenlight
source

2

Une fois, j'ai dû émuler la répartition dynamique C ++ (tables virtuelles, etc.) dans C vanille, et j'ai rencontré exactement ce problème: les programmeurs C qui ne comprenaient pas la répartition dynamique n'étaient pas en mesure de contribuer ou de maintenir le projet.

— comingstorm

4

Ce n'est pas une aussi bonne idée qu'elle apparaît sur le papier.

Exemple 1: Si vous êtes assez vieux, vous vous souvenez peut-être des jours où C était le nouveau gosse de la ville. Les programmeurs Pascal et Ada n'aimaient pas les accolades laconiques d'ouverture et de fermeture de C. Ils #defined beginet endpour ouvrir l'accolade et fermer l'accolade, et le tour est joué! CAda! Le résultat malheureux était moche du point de vue d'Ada ou de C.

Exemple 2, personnel: L'une des choses que j'ai vraiment appréciées dans le système d'objets Common Lisp est que c'est avant, après et autour des méthodes. Ils peuvent être très utiles à plusieurs endroits. J'ai donc émulé ce concept en C ++ à quelques endroits choisis. La seule façon d'émuler ces constructions en C ++ est d'exiger que le développeur d'une classe dérivée appelle la méthode du même nom de la classe parente au bon endroit dans le code. Cela a mis une exigence sur les développeurs qui dérivaient de mes classes qui était un peu étrangère à la programmation C ++, et peut-être à l'encontre de la programmation C ++. Peu importe à quel point cette exigence était bien documentée, les gens ne suivaient tout simplement pas les lignes directrices car elles ne correspondaient pas tout à fait au paradigme C ++.

— David Hammen
source

2

Quels problèmes peuvent découler de l'émulation de concepts dans d'autres langues?

Abstractions qui fuient.

— Jim G.
source

Il serait peut-être bon d'inclure plus de détails dans votre réponse. L'article concerne un cas où une abstraction ne parvient pas à capturer une optimisation significative des performances, mais je dirais que des problèmes plus importants découlent d'un comportement incohérent dans le coin et de garanties incohérentes; un exemple de ce dernier serait la tentative de C # d'émuler des outparamètres dans un framework qui ne les supporte pas vraiment; C # suppose que chaque fonction écrit toujours dans tous ses outparamètres, mais les méthodes non C # appelées par les méthodes C # n'offrent aucune garantie.

— supercat

1

Cela peut être extrêmement difficile. Imaginez que vous essayez d'implémenter LINQ à partir de C # dans votre application Java. Ou que diriez-vous d'ajouter simplement des fermetures lexicales à une langue? Vous auriez à peu près à écrire un nouveau compilateur, ce qui vous donne à peu près un nouveau langage.

Ou, pour les cas où vous n'avez pas à implémenter votre propre langage, imaginez simplement essayer d'implémenter des méthodes de collecte en utilisant des fonctions d'ordre supérieur (comme la carte) dans un langage qui n'a pas de blocs de code ou de fonctions lambda ou de fermetures ou de fonctions en premier objets de classe. Chaque fonction d'ordre supérieur doit être déclarée en tant qu'interface et implémentée explicitement, et tous les états qui auraient été capturés dans une fermeture doivent être explicitement stockés dans la classe d'implémentation. C'est tellement de frappe supplémentaire, et tellement plus difficile à lire, que cela n'en vaut souvent pas la peine.

— psr
source