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

Davvero domanda interessante. La mia opinione personale è che è uno che viene chiesto troppo spesso e che non tiene assolutamente l'acqua.

Gli script kiddies (e le aziende che li assumono) lasciano che il linguaggio scelto stabilisca il loro status tra i "programmatori". I bravi ingegneri non potrebbero importare di meno del linguaggio di scelta, ma concentrarsi sulla soluzione dei problemi dati nel modo più ottimale (ovviamente ottimale è una dichiarazione generale e può essere applicata a molti fattori diversi). Che si tratti di assemblaggio C #, VB, C ++, Python o scritto a mano, non importa in quanto c'è un chiaro vantaggio nell'usare questa tecnologia per risolvere il problema.

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

Solo i miei due centesimi sul tema:)

La qualità del codice sviluppata in ciascuna di queste lingue si basa su queste filosofie fondamentali e meno sui singoli sviluppatori

Ogni lingua ha una cultura intorno ad essa, perché ogni lingua è stata sviluppata per una ragione da qualcuno con un programma e una filosofia sottostante sul perché il loro linguaggio sarebbe stato migliore a qualcosa di quello che esisteva al momento è stato creato.

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

Esempio sulla qualità percepita delle soluzioni

In un campo Microsoft hai:

The C# philosophy is that it is more purely Object Oriented, promotes more modern idioms and requires more knowledge to do it correctly and thus should provide more higher quality solutions. This is what draws people to it over VB.

Nell'altro campo Microsoft:

The VB philosophy is I can quickly and with little knowledge or effort build something that will let someone click a button and do something useful and of business value, how it does it isn't so important. This is what draws people to it over C#.

Ecco un po 'di lingua e guancia assumono le lingue e le loro filosofie:

Perl people tend to care about the exact opposite thing Python people care about.

Java people care about making money.

JVM languages ( Groovy, Scala ) care about the JMV and not about Java the language.

All the Microsoft specific languages (VB,C#,F#, managed C++) tend to care about making money on Windows.

Erlang people care about stuff everyone other people haven't needed to care about, and don't appreciate what they don't know.

Lisp people don't care about what anyone else thinks they care about.

Ciò su cui questi gruppi si prendono cura di forme la lingua, il suo sviluppo e la sua comunità.

Le filosofie cambiano con l'esperienza e richiedono

Ho adottato ASM e BASIC perché in 1983 era tutto ciò che avevi. Volevo scrivere giochi e demo, quelli erano gli strumenti per farlo. Per lo più ASM per demo.

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 spazio-temporale. 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 di sviluppo rapido

Ho adottato Java nelle prime fasi per fare soldi migliori. Ho fatto soldi con VB fino al 1999 e mi sono lasciato alle spalle quando Java 1.2 diventava stabile e maturo e il web si era pienamente impegnato da allora, ho avuto 4 anni di esperienza in Java quando le persone hanno iniziato a prenderlo sul serio. Sono d'accordo con scrivi una volta, eseguo ovunque in quanto più posti il mio codice è stato eseguito più facilmente sarebbe stato in grado di venderlo. filosofia.

Ho adottato Python in ritardo nella sua timeline, 2005 perché ha graffiato un prurito che Java non ha. Avevo bisogno di scrivere velocemente del codice per usare alcune librerie che erano disponibili solo in C e anche io avevo bisogno di fare rapid prototipazione del webservice Python era più veloce e meno codice per fare la stessa cosa in Java. Qualcosa andò in produzione mentre Java rimaneva in Python, molte cose non lo facevano mai. Sono d'accordo con le sue batterie incluse, le singole filosofie idiomatiche e le altre.

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

Ho adottato Erlang nel 2006, quando ho iniziato a richiedere una massiccia scalabilità e un'esecuzione multi-core relativamente indolore su problemi altamente paralleli e l'esecuzione su più piattaforme. ** Sono d'accordo con il suo stato non condiviso, il messaggio che passa, la filosofia dello stato immutabile. * 8

Ho adottato Objective-C quando ho iniziato a dover creare applicazioni OSX e iOS. Sono d'accordo con il suo aggiungere solo il diritto di Orientamento agli oggetti in 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 gestire il DOM.

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

Una domanda interessante davvero. È uno di quelli in cui si capisce la risposta a livello inconscio, ma si sforzano di metterlo in parole.

È meglio visto come un ciclo di causalità.

La cultura è responsabile della composizione "etnica" degli sviluppatori attratti dalla piattaforma. Quella composizione a sua volta definisce le qualità del programmatore "medio". La qualità degli sviluppatori che ora utilizzano la piattaforma influenza la cultura o la sua percezione al di fuori della quale, di conseguenza, ha un effetto sugli sviluppatori che arrivano alla piattaforma o lo lasciano. Il valore della "qualità" cambia di conseguenza.

Ho cercato di elaborare regole specifiche, ma trovo difficile generalizzare. Dobbiamo investigare separatamente 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 caratteristiche e strumenti brillanti attira sviluppatori entusiasti (che in media sono più capaci di un lavoro di qualità) e respinge le menti conservatrici che sono irritate dal costante sforzo di apprendimento.

• I meno limiti che una piattaforma offre anche a costo di un rischio più elevato di spararsi nel piede attirano ugualmente le menti sperimentali entusiaste

• Quanto più complesse sono le cose che è necessario comprendere e padroneggiare per utilizzare la piattaforma, attirano ugualmente gli individui risolti e fanno paura agli sviluppatori pigri