Quel rôle joue «l'histoire culturelle des langues» avec une plateforme?


15

Je suis récemment tombé sur cettearticle d'il y a quelques années. Il fait valoir que les différences significatives dans la culture entourant VB et C #, et non les différences réelles dans la langue, contribuent à ce que les codeurs C # soient généralement plus talentueux que les codeurs VB. Évidemment, cela a causé beaucoup de guerres de flammes et la question de savoir si les C # ers ou les VBers sont les plus stupides ne sera jamais résolue. Cela étant dit, les auteurs affirment que la culture entourant une plate-forme particulière contribue à la qualité de l'équipe pourrait encore être plausible. Par exemple, même si Java est plus efficace pour développer des applications avec pour le moment, une équipe de développeurs Google Go semble susceptible d'être d'un calibre plus élevé en moyenne qu'une équipe de développeurs Java, car pour apprendre Go, un développeur a probablement être un adopteur super-précoce et un as du piratage des frontières. Donc, en un mot,Comment la culture entourant une plateforme ou une autre affecte-t-elle la qualité du développeur moyen sur cette plateforme, le cas échéant?


Est-ce un jour de C # contre VB.NET?

@ DeveloperArt - Ce n'est pas mon intention. En fait, la question que je me posais était intéressante en raison du fait que l'article semble très daté aujourd'hui, mais le concept pourrait être récupérable. L'article donne l'impression que les développeurs C # sont tous des génies. J'en suis un, donc je sais de première main que nous pouvons tous être aussi bâclés lorsque l'ambiance est bonne.
Morgan Herlocker

1
@Developer Art: J'ai lu cet article hier, et je suis sûr que c'est un lien publié dans une réponse ici qui m'a amené. C'est peut-être aussi ainsi que le professeur Plum l'a frappé - une question C # contre VB.NET en amène une autre. :-)
Carson63000

Réponses:


8

Question vraiment intéressante. Mon opinion personnelle est que c'est celle qui est demandée beaucoup trop souvent et qui ne contient vraiment aucune eau.

Les script kiddies (et les entreprises qui les embauchent) laissent la langue de leur choix dicter leur statut parmi les échelons des "programmeurs". Les bons ingénieurs ne se soucient pas de la langue de leur choix, mais se concentrent sur la résolution des problèmes donnés de la manière la plus optimale (évidemment optimal est une déclaration générale et peut être appliqué à de nombreux facteurs différents). Que ce soit C #, VB, C ++, Python ou un assemblage écrit à la main, peu importe car il y a un avantage évident à utiliser cette technologie pour résoudre le problème.

Donc, en bref, je pense qu'il est plus utile d'examiner la complexité des problèmes que l'on résout régulièrement plutôt que la langue qu'ils utilisent pour les résoudre.

Juste mes deux cents sur le sujet :)


2
+1: En outre, l'idée qu'il existe une culture VB qui transcende en quelque sorte les frontières de l'entreprise est ridicule. Comment cette culture se préserverait-elle? Des réunions secrètes entre programmeurs VB en dehors du travail? Une "union" ou "guilde" de programmeurs VB pour faire respecter cette "culture"? Après avoir passé 30 ans à rebondir parmi des centaines de boutiques informatiques, je peux dire que la seule culture que j'ai jamais vue est purement localisée. Le choix de la langue ne crée pas cette «autre» culture référencée dans la question.
S.Lott

1
Intéressant. Si vous l'avez attribué +1, demandez-vous qui a voté contre et pourquoi: P
Demian Brecht

1
@ S.Lott: Je suis corrigé alors (je dois aimer le sous-produit des hypothèses;)). Plus souvent qu'autrement, j'ai reçu des downvotes sur des sujets comme ceux-ci sans vraiment obtenir de commentaires, ce qui peut parfois être précieux et me fournir des informations dont j'étais auparavant inconscient :)
Demian Brecht

1
@prof: L'automatisation rend-elle vraiment inférieure, ou pensez-vous supérieure parce qu'ils comprennent quels raccourcis ils peuvent prendre pour atteindre la même sortie, mais plus efficacement? :) Bien sûr, c'est une généralisation excessive et presque impossible de répondre avec précision. Je suis un peu sur la barrière des codeurs Go étant plus passionnés. Vous pouvez toujours trouver des gens qui sont tout aussi passionnés par Fortran. Cela m'amènerait cependant à croire que le programmeur Go est plus passionné par les nouvelles technologies et pratiques, ce qui est une bonne chose à mon humble avis :)
Demian Brecht

1
@Prof Plum: "le choix de la plate-forme / langue n'a rien à voir avec la qualité moyenne du développeur". Correct. Comment peut-il en être autrement? Plus que tout, la culture de l' organisation compte. Les codeurs Google Go - eux-mêmes - ne sont que des personnes. L' organisation limite les gens à VB ou les encourage à utiliser Go. Les gens sont tous des gens.
S.Lott

4

La qualité du code développé dans chacun de ces langages est basée sur ces philosophies fondamentales et moins sur les développeurs individuels

Chaque langue a une culture autour d'elle, parce que chaque langue a été développée pour une raison par quelqu'un avec un agenda et une philosophie sous-jacente pour expliquer pourquoi sa langue allait être meilleure dans quelque chose que ce qui existait à l'époque a été créée.

Comme les religions, les langages de programmation ont tendance à attirer des gens qui ont déjà la même prédisposition aux principes de base et aux philosophies du créateur du langage.

Exemple sur la qualité perçue des solutions

Dans un camp Microsoft, vous avez:

La philosophie C # est qu'il est plus purement orienté objet, promeut des idiomes plus modernes et nécessite plus de connaissances pour le faire correctement et devrait donc fournir des solutions de meilleure qualité. C'est ce qui attire les gens vers VB.

Dans l'autre camp Microsoft:

La philosophie de VB est que je peux rapidement et avec peu de connaissances ou d'efforts créer quelque chose qui permettra à quelqu'un de cliquer sur un bouton et de faire quelque chose d'utile et de valeur commerciale, comment il le fait n'est pas si important. C'est ce qui attire les gens vers C #.

Voici quelques prises de langue et joue sur les langues et leurs philosophies:

Les gens de Perl ont tendance à se soucier de la chose exactement opposée aux gens de Python.

Les gens de Java se soucient de gagner de l'argent.

Les langages JVM (Groovy, Scala) se soucient du JMV et non du langage Java.

Tous les langages spécifiques à Microsoft (VB, C #, F #, C ++ managé) ont tendance à se soucier de gagner de l'argent sur Windows.

Les gens d'Erlang se soucient de choses dont tout le monde n'a pas besoin de se soucier et n'apprécient pas ce qu'ils ne savent pas.

Les gens de Lisp ne se soucient pas de ce que les autres pensent avoir à cœur.

Les préoccupations de ces groupes façonnent la langue, son développement et sa communauté.

Les philosophies changent avec l'expérience et les besoins

J'ai adopté ASM et BASIC parce qu'en 1983 c'était tout ce que vous aviez. Je voulais écrire des jeux et des démos, ce sont les outils pour le faire. Principalement ASM pour les démos.

J'ai adopté C puis C ++ quand c'était la seule façon d'écrire des choses comme le rendu 3D et à peu près tout ce qui était critique en termes d'espace et de temps. Ce n'était pas de l'ASM alors je l'ai appris.

J'ai adopté VB pour gagner de l'argent, c'était la chose la plus proche des environnements de développement Scala, Director et CanDo que j'avais l'habitude sur l'Amiga. Je suis d'accord avec la philosophie de développement rapide

J'ai adopté Java très tôt pour gagner de l'argent. J'ai gagné de l'argent avec VB jusqu'en 1999 et je l'ai laissé derrière quand Java 1.2 est devenu stable et mature et que le Web était pleinement opérationnel à ce moment-là, j'avais 4 ans d'expérience Java lorsque les gens ont vraiment commencé à le prendre au sérieux. Je suis d'accord avec l' écriture une fois, exécutez n'importe où, car plus mon code s'exécutait, plus il serait facile de le vendre. philosophie.

J'ai adopté Python à la fin de sa chronologie, 2005 parce qu'il grattait une démangeaison que Java n'avait pas. J'avais besoin d'écrire rapidement du code pour utiliser certaines bibliothèques qui n'étaient disponibles qu'en C et j'avais aussi besoin de faire un prototypage rapide de webservice Python était plus rapide et moins de code pour faire la même chose en Java. Quelque chose est allé à la production alors que Java certains restaient Python, beaucoup de choses ne sont jamais entrées dans la nature. Je suis d'accord avec ses batteries incluses, les philosophies idiomatiques simples ainsi que les autres.

J'ai adopté Lua quand j'avais besoin de mettre un moteur de script léger dans mes programmes C ++ et Java. C'était bien avant le support JSR233 en Java. J'ai accepté que l'intégration d'un langage de script complet et facile à utiliser soit une philosophie Lua simple.

J'ai adopté Erlang en 2006 lorsque j'ai commencé à avoir besoin d'une évolutivité massive et d'une exécution multicœur relativement indolore sur des problèmes hautement parallèles et d'une exécution multiplateforme. ** Je suis d'accord avec son absence de partage d'état, de transmission de messages et de philosophie d'état immuable. * 8

J'ai adopté Objective-C lorsque j'ai commencé à avoir besoin de créer des applications OSX et iOS. Je suis d'accord avec son ajout juste à propos de l'orientation d'objet à C pour en faire une meilleure philosophie. Aussi pour gagner plus d'argent.

J'ai adopté JavaScript officiellement en 2009 parce que j'étais d'accord avec la philosophie CouchDB et qu'il utilise JavaScript. Je n'aime toujours pas JavaScript quand je dois gérer le DOM.

Je n'ai toujours pas adopté officiellement Lisp, mais je vais finir par le faire! Je suis d'accord avec ses Ceux qui ne connaissent pas le lisp sont condamnés à réinventer sa philosophie.


0

Une question intéressante en effet. C'est l'un de ceux où vous comprenez la réponse au niveau subconscient mais vous vous efforcez de la mettre en mots.

Il est préférable de le voir comme une boucle de causalité.

La culture est responsable de la composition "ethnique" des développeurs attirés par la plateforme. Cette composition définit à son tour les qualités du programmeur «moyen». La qualité des développeurs qui utilisent désormais la plateforme influence la culture ou sa perception à l'extérieur, ce qui a par conséquent un effet sur les développeurs qui arrivent sur la plateforme ou la quittent. La valeur de la "qualité" change en conséquence.

J'ai essayé de trouver des règles spécifiques mais j'ai du mal à généraliser. Nous devons enquêter séparément sur chaque plate-forme. Quelques observations que j'ai faites:

  • La vitesse à laquelle une plate-forme particulière est développée, étendue, améliorée a une corrélation directe avec la qualité des développeurs. Le flux constant de nouvelles fonctionnalités et outils brillants attire des développeurs enthousiastes (qui sont en moyenne plus capables de travailler de qualité) et repousse les esprits conservateurs irrités par l'effort constant d'apprentissage.

  • Le moins de limites qu'une plateforme offre même au prix d'un risque plus élevé de se tirer une balle dans le pied attire également des esprits expérimentaux enthousiastes

  • Plus les choses sont complexes à comprendre et à maîtriser pour utiliser la plate-forme, elles attirent également les individus résolus et font fuir les développeurs paresseux


Comment cette culture transcende-t-elle les frontières de l'entreprise?
S.Lott

1
@Lott Technology transcende presque toujours les frontières culturelles. Il existe d'énormes fossés culturels entre les différents utilisateurs du système d'exploitation. Beaucoup de graphistes et d'ingénieurs audio que je connais penseraient que c'était une rupture pour aller dans une entreprise qui utilisait autre chose que Mac. Mac a favorisé une culture autour de ces deux groupes en particulier qui est entièrement tangible. Les langages de programmation sont des outils tout comme Photoshop et GIMP, il n'est donc pas surprenant qu'ils aient des cultures construites autour d'eux. S'ils ne le faisaient pas, nous n'aurions pas de guerres de flammes.
Morgan Herlocker

@Prof Plum: Vos exemples ne correspondent pas à la "culture" basée sur des outils. Vos exemples sont exactement le contraire. La culture actuelle (ingénieurs audio) choisit des outils communs. Non pas que tous les utilisateurs de Logic Pro soient obligés de devenir des ingénieurs du son, car Logic Pro crée une culture. Je pense que les exemples dans votre commentaire (même travail -> outils similaires) sont une excellente preuve qu'il n'y a pas "d'histoire culturelle de la langue". Il existe plutôt une culture de cas d'utilisation commune ou une culture de travail d'utilisateur final commune.
S.Lott
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.