Che tipo di ruolo gioca la "storia culturale della lingua" con una piattaforma?

Di recente mi sono imbattuto in questoarticolo di qualche anno fa. Sostiene che differenze significative nella cultura che circonda VB e C #, non le differenze effettive nella lingua, contribuiscono a rendere i programmatori C # generalmente più talentuosi dei programmatori VB. Ovviamente, ciò ha causato molte guerre di fiamma e alla domanda se C # o VBer sia il più stupido non riceverà mai risposta. Detto questo, gli autori sostengono che la cultura che circonda una determinata piattaforma contribuisce alla qualità della squadra potrebbe essere ancora plausibile. Ad esempio, anche se al momento Java è più efficiente per lo sviluppo di app, un team di sviluppatori Google Go sembrerebbe probabilmente avere un calibro più alto in media rispetto a un team di sviluppatori Java, poiché per imparare Go, uno sviluppatore probabilmente ha essere un super-early adopter e un mago di hacker alla frontiera. Quindi, in poche parole,in che modo la cultura che circonda una piattaforma o un'altra influenza la qualità dello sviluppatore medio su quella piattaforma, se non del tutto?

Domanda davvero interessante. La mia opinione personale è che è una domanda che viene chiesta troppo spesso e che davvero non contiene acqua.

Gli script kiddies (e le compagnie che li assumono) lasciano che la lingua scelta stabilisca il loro status tra i settori dei "programmatori". I bravi ingegneri non potrebbero fregare di meno del linguaggio prescelto, ma concentrarsi sulla risoluzione dei problemi indicati nel modo più ottimale (ovviamente ottimale è una dichiarazione generale e può essere applicato a molti fattori diversi). Che si tratti di C #, VB, C ++, Python o assembly scritti a mano, non importa in quanto vi è un chiaro vantaggio nell'utilizzare quella tecnologia per risolvere il problema.

Quindi in breve, penso che sia più prezioso guardare alla complessità dei problemi che si risolvono su base regolare rispetto al linguaggio che usano per risolverli.

Solo i miei due centesimi sull'argomento :)

La qualità del codice sviluppato in ciascuno di questi linguaggi si basa su queste filosofie fondamentali e meno sui singoli sviluppatori

Ogni lingua ha una cultura attorno ad essa, perché ogni lingua è stata sviluppata per un motivo da qualcuno con un'agenda e una filosofia di base sul perché la loro lingua sarebbe stata migliore in qualcosa di quella che esisteva al momento.

Come le religioni, i linguaggi di programmazione tendono ad attrarre persone che hanno già la stessa predisposizione ai principi e alle filosofie fondamentali del creatore del linguaggio.

Esempio sulla qualità percepita delle soluzioni

In un campo Microsoft hai:

La filosofia C # è che è più puramente orientato agli oggetti, promuove modi di dire più moderni e richiede più conoscenze per farlo correttamente e quindi dovrebbe fornire soluzioni di qualità più elevata. Questo è ciò che attira le persone su VB.

Nell'altro campo Microsoft:

La filosofia di VB è che posso rapidamente e con poca conoscenza o sforzo costruire qualcosa che permetta a qualcuno di fare clic su un pulsante e fare qualcosa di utile e di valore aziendale, come lo fa non è così importante. Questo è ciò che attira le persone su C #.

Ecco un po 'di lingua e guance sulle lingue e le loro filosofie:

La gente del Perl tende a preoccuparsi dell'esatta cosa opposta alla gente della Python.

La gente di Java si preoccupa di fare soldi.

Le lingue JVM (Groovy, Scala) si preoccupano della lingua JMV e non di Java.

Tutti i linguaggi specifici di Microsoft (VB, C #, F #, C ++ gestito) tendono a preoccuparsi di fare soldi su Windows.

Le persone di Erlang si preoccupano delle cose di cui tutti gli altri non hanno avuto bisogno e non apprezzano ciò che non sanno.

Le persone di Lisp non si preoccupano di ciò che qualcun altro pensa di preoccuparsi.

Ciò che interessa a questi gruppi modella il linguaggio, il suo sviluppo e la sua comunità.

Le filosofie cambiano con esperienza e necessità

Ho adottato ASM e BASIC perché nel 1983 era tutto ciò che avevi. Volevo scrivere giochi e demo, quelli erano gli strumenti per farlo. Principalmente ASM per dimostrazioni.

Ho adottato C e poi C ++ quando era l'unico modo per scrivere cose come il rendering 3D e praticamente qualsiasi altra cosa che fosse critica in termini di spazio e tempo. Non era ASM, quindi l'ho imparato.

Ho adottato VB per fare soldi, era la cosa più vicina agli ambienti di sviluppo Scala, Director e CanDo a cui ero abituato su Amiga. Sono d'accordo con la filosofia del rapido sviluppo

Ho adottato Java all'inizio per fare soldi migliori. Ho guadagnato soldi con VB fino al 1999 e l'ho lasciato alle spalle quando Java 1.2 è diventato stabile e maturo e il web è entrato completamente in gioco da allora, ho avuto 4 anni di esperienza Java quando le persone hanno iniziato a prenderlo sul serio. Sono stato d'accordo con la scrittura una volta, eseguito ovunque in quanto più posti il ​​mio codice correva più facile sarebbe stato in grado di venderlo. filosofia.

Ho adottato Python in ritardo nella sua cronologia, 2005 perché ha graffiato un prurito che Java non ha fatto. Avevo bisogno di scrivere rapidamente codice per usare alcune librerie che erano disponibili solo in C e avevo anche bisogno di fare prototipazione rapida di servizi Web Python era più veloce e meno codice per fare la stessa cosa in Java. Qualcosa è andato in produzione come Java alcuni sono rimasti in Python, un sacco di cose non sono mai diventate selvagge. Ho concordato con le sue batterie incluse, le filosofie del singolo idioma e le altre.

Ho adottato Lua quando avevo bisogno di inserire un motore di script leggero nei miei programmi C ++ e Java. Questo era molto prima del supporto JSR233 in Java. Sono d'accordo con l'incorporazione di un linguaggio di scripting completo che è facile da usare dovrebbe essere semplice filosofia Lua.

Ho adottato Erlang nel 2006 quando ho iniziato a necessitare di un'enorme scalabilità e un'esecuzione multi-core relativamente indolore su problemi altamente paralleli e con esecuzione multipiattaforma. ** Sono d'accordo con il suo stato non condiviso, il passaggio di messaggi, la filosofia di stato immutabile. * 8

Ho adottato Objective-C quando ho iniziato a creare applicazioni OSX e iOS. Sono d'accordo con la sua aggiunta della giusta orientazione degli oggetti a C per renderlo migliore filosofia. Anche per fare soldi migliori.

Ho adottato JavaScript ufficialmente nel 2009 perché ero d'accordo con la filosofia CouchDB e utilizza JavaScript. Ancora non mi piace JavaScript quando devo occuparmi del DOM.

Non ho ancora adottato ufficialmente Lisp, ma alla fine lo farò! Sono d'accordo con coloro che non conoscono lisp sono condannati a reinventarlo .

Una domanda davvero interessante. È una di quelle in cui capisci la risposta a livello subconscio ma ti sforzi di esprimerla a parole.

È meglio visto come un ciclo di causalità.

La cultura è responsabile della composizione "etnica" degli sviluppatori attratti dalla piattaforma. Tale composizione a sua volta definisce le qualità del programmatore "medio". La qualità degli sviluppatori che ora usano la piattaforma influenza la cultura o la sua percezione al di fuori di ciò che di conseguenza ha un effetto sul fatto che gli sviluppatori vengano sulla piattaforma o lascino. Il valore della "qualità" cambia di conseguenza.

Ho cercato di elaborare regole specifiche ma trovo difficile generalizzare. Dobbiamo indagare separatamente su ciascuna piattaforma. Alcune osservazioni che ho fatto:

• La velocità con cui una particolare piattaforma viene sviluppata, estesa, migliorata ha una correlazione diretta con la qualità degli sviluppatori. Il flusso costante di nuove funzionalità e strumenti brillanti attira sviluppatori entusiasti (che in media sono più capaci di lavorare di qualità) e respinge le menti conservatrici che sono irritate dal costante sforzo di apprendimento.

• Meno limiti offre una piattaforma anche a costo di un rischio maggiore di spararsi al piede attira ugualmente entusiasti menti sperimentali

• Più sono complesse le cose che è necessario comprendere e padroneggiare per utilizzare la piattaforma attirando ugualmente gli individui risolti e spaventando gli sviluppatori pigri