Nota. trad.: Questo articolo, diventato un successo su Medium, è una panoramica dei cambiamenti chiave (2010-2019) nel mondo dei linguaggi di programmazione e nell'ecosistema tecnologico associato (con un focus speciale su Docker e Kubernetes). L'autrice originale è Cindy Sridharan, specializzata in strumenti di sviluppo e sistemi distribuiti - in particolare, ha scritto il libro "Distributed Systems Observability" - ed è molto popolare nello spazio Internet tra gli specialisti IT, particolarmente interessati al tema del cloud nativo.
Con l’avvicinarsi della fine del 2019, volevo condividere i miei pensieri su alcuni dei più importanti progressi e innovazioni tecnologiche degli ultimi dieci anni. Inoltre, cercherò di guardare un po’ al futuro e di delineare i principali problemi e opportunità del prossimo decennio.
Voglio chiarire che in questo articolo non tratterò i cambiamenti in aree come la scienza dei dati (scienza dei dati), intelligenza artificiale, ingegneria frontend, ecc., poiché personalmente non ho sufficiente esperienza in essi.
La tipizzazione colpisce ancora
Una delle tendenze più positive degli anni 2010 è stata la rinascita delle lingue tipizzate staticamente. Tuttavia, tali linguaggi non sono mai scomparsi (C++ e Java sono richiesti oggi; dieci anni fa dominavano), ma i linguaggi tipizzati dinamicamente (dinamici) hanno registrato un aumento significativo di popolarità dopo l'emergere del movimento Ruby on Rails nel 2005 . Questa crescita ha raggiunto il picco nel 2009 con l’open source di Node.js, che ha reso Javascript-on-the-server una realtà.
Nel corso del tempo, i linguaggi dinamici hanno perso parte del loro fascino nel campo della creazione di software server. Il linguaggio Go, reso popolare durante la rivoluzione dei container, sembrava più adatto alla creazione di server ad alte prestazioni ed efficienti in termini di risorse con elaborazione parallela (con cui lo stesso creatore di Node.js).
Rust, introdotto nel 2010, includeva dei progressi in nel tentativo di diventare un linguaggio sicuro e dattiloscritto. Nella prima metà del decennio, l'accoglienza di Rust da parte dell'industria fu piuttosto tiepida, ma la sua popolarità aumentò significativamente nella seconda metà. Casi d'uso degni di nota per Rust includono il suo utilizzo per , (ne abbiamo parlato in - ca. trad.), uno dei primi compilatori WebAssembly da Fastly (ora parte di bytecodealliance), ecc. Con Microsoft che considera la possibilità di riscrivere alcune parti del sistema operativo Windows in Rust, si può dire con certezza che questo linguaggio ha un futuro brillante negli anni '2020.
Anche i linguaggi dinamici hanno nuove funzionalità come (tipi opzionali). Sono stati implementati per la prima volta in TypeScript, un linguaggio che consente di creare codice digitato e compilarlo in JavaScript. PHP, Ruby e Python hanno i propri sistemi di digitazione opzionali (, ), che vengono utilizzati con successo in .
Restituzione di SQL a NoSQL
NoSQL è un’altra tecnologia che all’inizio del decennio era molto più popolare che alla fine. Penso che ci siano due ragioni per questo.
Innanzitutto, il modello NoSQL, con la sua mancanza di schemi, transazioni e garanzie di coerenza più deboli, si è rivelato più difficile da implementare rispetto al modello SQL. IN con il titolo "Perché dovresti preferire una consistenza forte quando possibile" (Perché dovresti scegliere una consistenza forte, quando possibile) Google scrive:
Una delle cose che abbiamo imparato in Google è che il codice dell'applicazione è più semplice e i tempi di sviluppo sono più brevi quando gli ingegneri possono fare affidamento sullo spazio di archiviazione esistente per gestire transazioni complesse e mantenere i dati in ordine. Per citare la documentazione originale di Spanner, "Crediamo che sia meglio per i programmatori affrontare i problemi di prestazioni delle applicazioni dovuti all'abuso delle transazioni quando si verificano colli di bottiglia, piuttosto che tenere costantemente a mente l'assenza di transazioni".
Il secondo motivo è dovuto all'aumento dei database SQL distribuiti "scale-out" (come и ) nello spazio del cloud pubblico, nonché alternative Open Source come CockroachDB (stiamo parlando anche di lei - ca. trad.), che risolvono molti dei problemi tecnici che causavano la "non scalabilità" dei database SQL tradizionali. Anche MongoDB, un tempo sinonimo del movimento NoSQL, lo è adesso transazioni distribuite.
Per le situazioni che richiedono letture e scritture atomiche su più documenti (su una o più raccolte), MongoDB supporta transazioni multi-documento. Nel caso di transazioni distribuite, le transazioni possono essere utilizzate in più operazioni, raccolte, database, documenti e partizioni.
Streaming totale
Apache Kafka è senza dubbio una delle invenzioni più importanti degli ultimi dieci anni. Il suo codice sorgente è stato reso disponibile nel gennaio 2011 e, nel corso degli anni, Kafka ha rivoluzionato il modo in cui le aziende lavorano con i dati. Kafka è stato utilizzato in tutte le aziende per cui ho lavorato, dalle start-up alle grandi aziende. Le garanzie e i casi d'uso che fornisce (pub-sub, stream, architetture event-driven) sono utilizzati in una varietà di compiti, dall'archiviazione dei dati al monitoraggio e all'analisi dello streaming, richiesti in molti settori come finanza, sanità, settore pubblico, vendita al dettaglio ed ecc.
Integrazione continua (e, in misura minore, distribuzione continua)
L'integrazione continua non è apparsa negli ultimi 10 anni, ma negli ultimi dieci anni si è diffuso a tal punto, che è diventato parte del flusso di lavoro standard (esegui test su tutte le richieste pull). Stabilire GitHub come piattaforma per lo sviluppo e l'archiviazione di codice e, cosa ancora più importante, sviluppare un flusso di lavoro basato su significa che eseguire test prima di accettare una richiesta pull al master lo è единственный flusso di lavoro in fase di sviluppo, familiare agli ingegneri che hanno iniziato la loro carriera negli ultimi dieci anni.
La distribuzione continua (distribuzione di ciascun commit come e quando raggiunge il master) non è così diffusa come l'integrazione continua. Tuttavia, con la pletora di diverse API cloud per la distribuzione, la crescente popolarità di piattaforme come Kubernetes (che forniscono un'API standardizzata per le distribuzioni) e l'emergere di strumenti multipiattaforma e multicloud come Spinnaker (costruiti sopra quelli standardizzati). API), i processi di distribuzione sono diventati più automatizzati, semplificati e, in generale, più sicuri.
contenitori
I container sono forse la tecnologia più pubblicizzata, discussa, pubblicizzata e fraintesa degli anni 2010. D’altronde si tratta di una delle innovazioni più importanti del decennio precedente. Parte della ragione di tutta questa cacofonia risiede nei segnali contrastanti che ricevevamo da quasi ovunque. Ora che l’hype si è un po’ calmato, alcune cose sono diventate più nitide.
I contenitori sono diventati popolari non perché siano il modo migliore per eseguire un'applicazione che soddisfi le esigenze della comunità globale di sviluppatori. I contenitori sono diventati popolari perché si adattano con successo a una richiesta di marketing per un determinato strumento che risolve un problema completamente diverso. Docker si è rivelato esserlo fantastico uno strumento di sviluppo che risolve il pressante problema di compatibilità (“funziona sulla mia macchina”).
Più precisamente, la rivoluzione è stata fatta Immagine Docker, perché risolveva il problema della parità tra ambienti e forniva una vera portabilità non solo del file dell'applicazione, ma anche di tutti i suoi software e dipendenze operative. Il fatto che questo strumento abbia in qualche modo stimolato la popolarità dei “contenitori”, che sono essenzialmente un dettaglio di implementazione di livello molto basso, rimane per me forse il mistero principale dell’ultimo decennio.
serverless
Scommetto che l'avvento del computing "serverless" è ancora più importante dei container perché trasforma davvero il sogno del computing on-demand in realtà (Su richiesta). Negli ultimi cinque anni, ho visto l'approccio serverless espandere gradualmente la portata aggiungendo il supporto per nuovi linguaggi e runtime. L'emergere di prodotti come Azure Sustainable Functions sembra essere il passo giusto verso l'implementazione delle funzioni stateful (allo stesso tempo un passo decisivo relativi alle limitazioni FaaS). Osserverò con interesse come si svilupperà questo nuovo paradigma nei prossimi anni.
Automazione
Forse il più grande beneficiario di questa tendenza è la comunità dell’ingegneria operativa, poiché ha consentito a concetti come l’infrastruttura come codice (IaC) di diventare realtà. Inoltre, la passione per l’automazione ha coinciso con l’ascesa della “cultura SRE”, che mira ad adottare un approccio alle operazioni più incentrato sul software.
APIzione universale
Un'altra caratteristica interessante dell'ultimo decennio è stata l'APIzzazione di varie attività di sviluppo. API valide e flessibili consentono allo sviluppatore di creare flussi di lavoro e strumenti innovativi, che a loro volta aiutano con la manutenzione e migliorano l'esperienza dell'utente.
Inoltre, l'API-ficazione è il primo passo verso la SaaS-ficazione di alcune funzionalità o strumenti. Questa tendenza ha coinciso anche con la crescente popolarità dei microservizi: SaaS è diventato solo un altro servizio a cui è possibile accedere tramite API. Ora sono disponibili molti strumenti SaaS e FOSS in aree quali monitoraggio, pagamenti, bilanciamento del carico, integrazione continua, avvisi, cambio di funzionalità (segnalazione delle funzionalità), CDN, ingegneria del traffico (ad esempio DNS), ecc., che sono fioriti negli ultimi dieci anni.
Osservabilità
Vale la pena notare che oggi abbiamo accesso a molto più avanzato strumenti per monitorare e diagnosticare il comportamento delle applicazioni come mai prima d'ora. Forse si può chiamare il sistema di monitoraggio Prometheus, che nel 2015 ha ottenuto lo status di Open Source il migliore sistema di monitoraggio da quelli con cui ho lavorato. Non è perfetto, ma un numero significativo di cose sono implementate esattamente nel modo giusto (ad esempio, il supporto per le misurazioni [dimensionalità] nel caso delle metriche).
Il tracciamento distribuito è stata un’altra tecnologia entrata nel mainstream negli anni 2010, grazie a iniziative come OpenTracing (e il suo successore OpenTelemetry). Sebbene il tracciamento sia ancora piuttosto difficile da applicare, alcuni degli ultimi sviluppi fanno sperare che ne sbloccheremo il vero potenziale negli anni 2020. (Nota: leggere anche nel nostro blog la traduzione dell’articolo “"dello stesso autore.)
Guardando al futuro
Sfortunatamente, ci sono molti punti critici che attendono una soluzione nel prossimo decennio. Ecco i miei pensieri su di loro e alcune potenziali idee su come sbarazzarsene.
Risoluzione del problema della legge di Moore
La fine della legge di scala di Dennard e il ritardo rispetto alla legge di Moore richiedono nuove innovazioni. John Hennessy dentro spiega perché i tossicodipendenti problematici (specifico del dominio) architetture come il TPU possono essere una delle soluzioni al problema del ritardo rispetto alla legge di Moore. Kit di strumenti come da Google sembrano già essere un buon passo avanti in questa direzione:
I compilatori devono supportare nuove applicazioni, essere facilmente portabili su nuovo hardware, collegare più livelli di astrazione che vanno da linguaggi dinamici e gestiti ad acceleratori vettoriali e dispositivi di archiviazione controllati da software, fornendo allo stesso tempo switch di alto livello per l'auto-tuning, fornendo solo- in termini di funzionalità, diagnostica e distribuzione di informazioni di debug sul funzionamento e sulle prestazioni dei sistemi in tutto lo stack, fornendo nella maggior parte dei casi prestazioni ragionevolmente vicine all'assemblatore scritto a mano. Intendiamo condividere la nostra visione, i progressi e i piani per lo sviluppo e la disponibilità pubblica di tale infrastruttura di compilazione.
CI / CD
Sebbene l’ascesa dell’IC sia diventata una delle tendenze più importanti degli anni 2010, Jenkins è ancora il gold standard per l’IC.
Questo spazio ha un disperato bisogno di innovazione nelle seguenti aree:
- interfaccia utente (DSL per la codifica delle specifiche di test);
- dettagli implementativi che lo renderanno veramente scalabile e veloce;
- integrazione con diversi ambienti (staging, prod, ecc.) per implementare forme di testing più avanzate;
- test e implementazione continui.
Strumenti di sviluppo
Come settore, abbiamo iniziato a creare software sempre più complessi e impressionanti. Tuttavia, per quanto riguarda i nostri strumenti, la situazione potrebbe essere molto migliore.
L'editing collaborativo e remoto (tramite ssh) ha guadagnato una certa popolarità, ma non è mai diventato il nuovo modo standard di sviluppo. Se tu, come me, rifiuti l'idea stessa di bisogno una connessione permanente a Internet solo per poter programmare, quindi difficilmente è adatto a lavorare tramite ssh su una macchina remota.
Gli ambienti di sviluppo locale, soprattutto per gli ingegneri che lavorano su grandi architetture orientate ai servizi, rappresentano ancora una sfida. Alcuni progetti stanno cercando di risolvere questo problema e sarei interessato a sapere quale sarebbe la UX più ergonomica per un determinato caso d'uso.
Sarebbe interessante anche estendere il concetto di “ambienti portabili” ad altri ambiti di sviluppo come la riproduzione dei bug (o ) che si verificano in determinate condizioni o impostazioni.
Mi piacerebbe anche vedere più innovazione in aree come la ricerca di codice semantica e sensibile al contesto, strumenti per correlare gli incidenti di produzione con parti specifiche della base di codice, ecc.
Informatica (il futuro del PaaS)
Dopo il clamore attorno ai container e al serverless negli anni 2010, negli ultimi anni la gamma di soluzioni nel settore del cloud pubblico si è notevolmente ampliata.
Ciò solleva diverse domande interessanti. Innanzitutto l’elenco delle opzioni disponibili nel cloud pubblico è in continua crescita. I fornitori di servizi cloud hanno il personale e le risorse per tenere facilmente il passo con gli ultimi sviluppi nel mondo Open Source e rilasciare prodotti come "pod serverless" (sospetto semplicemente rendendo i propri runtime FaaS conformi a OCI) o altre cose fantasiose simili.
Si può solo invidiare chi utilizza queste soluzioni cloud. In teoria, le offerte cloud Kubernetes (GKE, EKS, EKS su Fargate, ecc.) forniscono API indipendenti dal provider cloud per l'esecuzione dei carichi di lavoro. Se utilizzi prodotti simili (ECS, Fargate, Google Cloud Run, ecc.), probabilmente stai già sfruttando le funzionalità più interessanti offerte dal fornitore di servizi. Inoltre, con l’emergere di nuovi prodotti o paradigmi informatici, è probabile che la migrazione sia semplice e priva di stress.
Considerando la rapidità con cui si sta evolvendo la gamma di tali soluzioni (sarei molto sorpreso se un paio di nuove opzioni non apparissero nel prossimo futuro), piccoli team "piattaforma" (team associati all'infrastruttura e responsabili della creazione di piattaforme on-premise per aziende che eseguono carichi di lavoro) sarà incredibilmente difficile competere in termini di funzionalità, facilità d'uso e affidabilità complessiva. Gli anni 2010 hanno visto Kubernetes come uno strumento per costruire PaaS (platform-as-a-service), quindi mi sembra del tutto inutile costruire una piattaforma interna sopra Kubernetes che offra la stessa scelta, semplicità e libertà disponibili al pubblico spazio nuvola. Inquadrare il PaaS basato su container come una “strategia Kubernetes” equivale a evitare deliberatamente le funzionalità più innovative del cloud.
Se guardi il disponibile oggi capacità di calcolo, diventa ovvio che creare il proprio PaaS basato esclusivamente su Kubernetes equivale a mettersi in un angolo (non è un approccio molto lungimirante, eh?). Anche se oggi qualcuno decidesse di costruire un PaaS containerizzato su Kubernetes, tra un paio d'anni sembrerà obsoleto rispetto alle funzionalità cloud. Sebbene Kubernetes sia iniziato come progetto open source, il suo antenato e ispirazione è uno strumento interno di Google. Tuttavia, è stato originariamente sviluppato all’inizio/metà degli anni 2000, quando il panorama informatico era completamente diverso.
Inoltre, in un senso molto ampio, le aziende non devono diventare esperte nella gestione di un cluster Kubernetes, né costruire e mantenere i propri data center. Fornire una base informatica affidabile è una sfida fondamentale fornitori di servizi cloud.
Infine, sento che siamo regrediti un po' come settore in termini di esperienza di interazione (). Heroku è stato lanciato nel 2007 ed è ancora uno dei più popolari facile da usare piattaforme. Non si può negare che Kubernetes sia molto più potente, estensibile e programmabile, ma mi manca quanto sia facile iniziare e distribuirlo su Heroku. Per utilizzare questa piattaforma, devi solo conoscere Git.
Tutto ciò mi porta alla seguente conclusione: abbiamo bisogno di astrazioni migliori e di livello superiore per funzionare (questo è particolarmente vero per astrazioni di massimo livello).
L'API giusta al massimo livello
Docker è allo stesso tempo un ottimo esempio della necessità di una migliore separazione delle preoccupazioni corretta implementazione dell'API di livello più alto.
Il problema con Docker è che (almeno) inizialmente gli obiettivi del progetto erano troppo ampi: tutto per risolvere il problema di compatibilità ("funziona sulla mia macchina") utilizzando la tecnologia dei contenitori. Docker era un formato immagine, un runtime con una propria rete virtuale, uno strumento CLI, un demone eseguito come root e molto altro. In ogni caso lo scambio di messaggi c'era di più confusione, per non parlare delle "VM leggere", cgroup, spazi dei nomi, numerosi problemi di sicurezza e funzionalità mescolati con l'appello di marketing a "creare, fornire, eseguire qualsiasi applicazione ovunque".
Come per tutte le buone astrazioni, ci vuole tempo (ed esperienza e dolore) per scomporre i vari problemi in livelli logici che possano essere combinati tra loro. Sfortunatamente, prima che Docker potesse raggiungere una maturità simile, Kubernetes entrò nella mischia. Ha monopolizzato così tanto il ciclo dell'hype che ora tutti cercavano di tenere il passo con i cambiamenti nell'ecosistema Kubernetes e l'ecosistema dei contenitori ha assunto uno status secondario.
Kubernetes condivide molti degli stessi problemi di Docker. Nonostante tutti i discorsi sull'astrazione interessante e componibile, separando le diverse attività in livelli non molto ben incapsulato. Fondamentalmente, è un orchestratore di contenitori che esegue contenitori su un cluster di macchine diverse. Si tratta di un'attività di livello piuttosto basso, applicabile solo agli ingegneri che gestiscono il cluster. D'altra parte, anche Kubernetes lo è astrazione di altissimo livello, uno strumento CLI con cui gli utenti interagiscono tramite YAML.
Docker era (ed è tuttora) Freddo strumento di sviluppo, nonostante tutte le sue carenze. Nel tentativo di tenere il passo con tutte le "lepri" contemporaneamente, i suoi sviluppatori sono riusciti a implementarlo correttamente astrazione al massimo livello. Per astrazione al massimo livello intendo sottoinsieme funzionalità a cui il pubblico target (in questo caso, gli sviluppatori che hanno trascorso la maggior parte del tempo nei loro ambienti di sviluppo locali) era veramente interessato e che ha funzionato benissimo fin da subito.
Dockerfile e utilità CLI docker dovrebbe essere un esempio di come costruire una buona “esperienza utente di altissimo livello”. Uno sviluppatore ordinario può iniziare a lavorare con Docker senza sapere nulla delle complessità implementazioni che contribuiscono all’esperienza operativacome spazi dei nomi, cgroup, limiti di memoria e CPU, ecc. In definitiva, scrivere un Dockerfile non è molto diverso dallo scrivere uno script di shell.
Kubernetes è destinato a diversi gruppi target:
- amministratori di cluster;
- ingegneri del software che lavorano su problemi infrastrutturali, espandendo le capacità di Kubernetes e creando piattaforme basate su di esso;
- utenti finali che interagiscono con Kubernetes tramite
kubectl.
L'approccio "un'API adatta a tutti" di Kubernetes presenta una "montagna di complessità" non sufficientemente incapsulata senza alcuna guida su come scalarla. Tutto ciò porta ad un percorso di apprendimento ingiustificatamente prolungato. Come Adam Jacob, “Docker ha portato un'esperienza utente trasformativa che non è mai stata superata. Chiedi a chiunque utilizzi un K8 se desidera che funzioni come il primo docker run. La risposta sarà sì":
Direi che la maggior parte della tecnologia infrastrutturale oggi è di livello troppo basso (e quindi considerata "troppo complessa"). Kubernetes è implementato a un livello piuttosto basso. Tracciamento distribuito nel suo (molti tratti uniti insieme per formare una traceview) è implementato anche a un livello troppo basso. Gli strumenti per sviluppatori che implementano le “astrazioni di livello più alto” tendono ad avere più successo. Questa conclusione è vera in un numero sorprendente di casi (se la tecnologia è troppo complessa o difficile da usare, allora “l’API/interfaccia utente di livello più alto” per quella tecnologia deve ancora essere scoperta).
In questo momento, l’ecosistema nativo del cloud crea confusione a causa della sua attenzione di basso livello. Come industria, dobbiamo innovare, sperimentare ed educare su come si presenta il giusto livello di “massima, più alta astrazione”.
Commercio al dettaglio
Negli anni 2010, l’esperienza di vendita al dettaglio digitale è rimasta sostanzialmente invariata. Da un lato la comodità dello shopping online avrebbe dovuto colpire i negozi al dettaglio tradizionali, dall’altro lo shopping online è rimasto sostanzialmente invariato in un decennio.
Anche se non ho pensieri specifici su come si evolverà questo settore nel prossimo decennio, sarei molto deluso se facessimo acquisti nel 2030 nello stesso modo in cui lo facciamo nel 2020.
giornalismo
Sono sempre più disilluso dallo stato del giornalismo globale. Sta diventando sempre più difficile trovare fonti di notizie imparziali che riferiscano in modo obiettivo e meticoloso. Molto spesso il confine tra la notizia stessa e le opinioni al riguardo è labile. Di norma, le informazioni vengono presentate in modo parziale. Ciò è particolarmente vero in alcuni paesi dove storicamente non c’è stata separazione tra notizie e opinione. In un recente articolo pubblicato dopo le ultime elezioni generali del Regno Unito, Alan Rusbridger, ex direttore del The Guardian, :
Il punto principale è che per molti anni ho guardato i giornali americani e mi sono dispiaciuto per i miei colleghi lì, che erano gli unici responsabili delle notizie, lasciando il commento a persone completamente diverse. Tuttavia, col tempo, la pietà si trasformò in invidia. Ora penso che tutti i giornali nazionali britannici dovrebbero separare la loro responsabilità per le notizie da quella per i commenti. Sfortunatamente, è troppo difficile per il lettore medio, soprattutto per i lettori online, discernere la differenza.
Considerata la dubbia reputazione della Silicon Valley in termini di etica, non mi fiderei mai che la tecnologia possa “rivoluzionare” il giornalismo. Detto questo, io (e molti dei miei amici) sarei felice se ci fosse una fonte di notizie imparziale, disinteressata e affidabile. Anche se non ho idea di come potrebbe essere una piattaforma del genere, sono fiducioso che in un’epoca in cui la verità sta diventando sempre più difficile da discernere, la necessità di un giornalismo onesto è più grande che mai.
Social Networks
I social media e le piattaforme di notizie comunitarie sono la principale fonte di informazioni per molte persone in tutto il mondo e la mancanza di accuratezza e riluttanza di alcune piattaforme a effettuare anche un controllo dei fatti di base ha portato a conseguenze disastrose come genocidi, interferenze elettorali e altro ancora. .
I social media sono anche lo strumento mediatico più potente che sia mai esistito. Hanno cambiato radicalmente la pratica politica. Hanno cambiato la pubblicità. Hanno cambiato la cultura pop (ad esempio, il principale contributo allo sviluppo della cosiddetta cultura dell’annullamento [culture dell'ostracismo - ca. trad.] i social network contribuiscono). I critici sostengono che i social media si sono rivelati un terreno fertile per cambiamenti rapidi e capricciosi dei valori morali, ma hanno anche fornito ai membri di gruppi emarginati l’opportunità di organizzarsi in modi mai avuti prima. In sostanza, i social media hanno cambiato il modo in cui le persone comunicano e si esprimono nel XNUMX° secolo.
Tuttavia, credo anche che i social media facciano emergere i peggiori impulsi umani. La considerazione e l'attenzione vengono spesso trascurate a favore della popolarità, e diventa quasi impossibile esprimere un disaccordo ragionato con determinate opinioni e posizioni. La polarizzazione spesso va fuori controllo, con il risultato che il pubblico semplicemente non ascolta le opinioni individuali mentre gli assolutisti controllano le questioni di etichetta e accettabilità online.
Mi chiedo se sia possibile creare una piattaforma “migliore” che promuova discussioni di migliore qualità? Dopotutto, è ciò che guida il “coinvolgimento” che spesso porta il profitto principale a queste piattaforme. Come Kara Swisher sul New York Times:
È possibile sviluppare interazioni digitali senza provocare odio e intolleranza. Il motivo per cui la maggior parte dei siti di social media sembrano così tossici è perché sono stati costruiti per la velocità, la viralità e l’attenzione, piuttosto che per il contenuto e l’accuratezza.
Sarebbe davvero un peccato se, nel giro di un paio di decenni, l’unica eredità dei social media fosse l’erosione delle sfumature e dell’appropriatezza nel discorso pubblico.
PS da traduttore
Leggi anche sul nostro blog:
- «";
- «";
- «";
- «'.
Fonte: habr.com