Nota del traduttore.: Questo articolo, diventato un successo su Medium, è una panoramica dei principali cambiamenti (dal 2010 al 2019) nel mondo dei linguaggi di programmazione e dell'ecosistema tecnologico correlato (con un focus particolare su Docker e Kubernetes). L'autrice originale è Cindy Sridharan, che si specializza in strumenti per sviluppatori e sistemi distribuiti — in particolare, ha scritto il libro "Distributed Systems Observability" — ed è abbastanza popolare nel cyberspazio tra i professionisti IT, specialmente quelli interessati al tema cloud native.
Il 2019 è giunto al termine, quindi vorrei condividere alcune delle mie riflessioni sui traguardi e le innovazioni tecnologiche più significative del decennio passato. Inoltre, cercherò di dare uno sguardo al futuro e di delineare le principali sfide e opportunità del prossimo decennio.
Voglio precisare fin da subito che in questo articolo non affronto i cambiamenti in settori come la scienza dei dati (data science), intelligenza artificiale, ingegneria frontend e simili, poiché personalmente non ho un'esperienza sufficiente in questi campi.
La tipizzazione colpisce di nuovo
Una delle tendenze più positive degli anni 2010 è stata la resurrezione dei linguaggi a tipizzazione statica. Tuttavia, questi linguaggi non sono mai scomparsi (C++ e Java sono ancora richiesti oggi; erano dominanti anche dieci anni fa), ma i linguaggi a tipizzazione dinamica hanno conosciuto una crescita significativa in popolarità dopo l'emergere del movimento Ruby on Rails nel 2005. Questa crescita ha raggiunto il suo apice nel 2009 con il rilascio del codice sorgente di Node.js, che ha reso Javascript sul server una realtà.
Col passare del tempo, i linguaggi dinamici hanno perso parte del loro fascino nella creazione di software server. Il linguaggio Go, popolarizzato dalla rivoluzione dei container, sembrava essere meglio attrezzato per la creazione di server ad alte prestazioni e risorse efficienti con elaborazione parallela (cosa con cui lo stesso creatore di Node.js).
Rust, presentato nel 2010, ha integrato progressi nella nella sua ricerca per diventare un linguaggio sicuro e tipizzato. Nella prima metà del decennio, l'atteggiamento nei confronti di Rust nell'industria era piuttosto freddo, ma nella seconda metà la sua popolarità è aumentata significativamente. Alcuni degli usi notevoli di Rust includono il suo impiego in , (di cui abbiamo parlato in — nota di traduzione), un compilatore WebAssembly anticipato da Fastly (ora parte di bytecodealliance) e altri. In un contesto in cui Microsoft sta considerando di riscrivere alcune parti del sistema operativo Windows in Rust, si può affermare con sicurezza che questo linguaggio ha un futuro luminoso nei 2020.
Anche i linguaggi dinamici hanno ricevuto nuove opportunità come . Sono stati implementati per la prima volta in TypeScript, un linguaggio che consente di creare codice tipizzato e compilarlo in JavaScript. PHP, Ruby e Python hanno sviluppato i propri sistemi di tipizzazione opzionale (mypy, ), che vengono utilizzati con successo in .
Il ritorno di SQL nel NoSQL
NoSQL è un'altra tecnologia che era molto più popolare all'inizio del decennio che alla fine. Credo ci siano due motivi per questo.
In primo luogo, il modello NoSQL con assenza di schema, transazioni e garanzie di coerenza più deboli, si è rivelato più difficile da implementare rispetto al modello SQL. In intitolato 'Perché dovresti preferire la coerenza forte ogni volta che è possibile' (Why you should pick strong consistency, whenever possible) Google scrive:
Una delle cose che abbiamo appreso in Google è che il codice dell'applicazione è più semplice, e i tempi di sviluppo sono più brevi, se gli ingegneri possono contare sui database esistenti per elaborare transazioni complesse e mantenere l'ordine dei dati. Citando la documentazione originale di Spanner, "crediamo che sia meglio se i programmatori si occupino dei problemi di prestazioni dell'applicazione dovuti all'abuso delle transazioni man mano che si presentano colli di bottiglia, piuttosto che tenere sempre a mente l'assenza di transazioni".
La seconda ragione è legata alla crescita di database distribuiti SQL "scalabili" (come e ) nel cloud pubblico, così come alle alternative open source come CockroachDB (di cui abbiamo anche — nota del traduttore), che risolvono molti dei problemi tecnici che rendevano i database SQL tradizionali "non scalabili". Anche MongoDB, un tempo simbolo del movimento NoSQL, ora sostiene transazioni distribuite.
Per situazioni che richiedono l'atomicità delle operazioni di lettura e scrittura in più documenti (in una o più collezioni), MongoDB supporta le transazioni multi-documento. Nel caso di transazioni distribuite, le transazioni possono essere utilizzate per numerose operazioni, collezioni, database, documenti e shard.
Strimificazione totale
Apache Kafka è senza dubbio una delle invenzioni più importanti dell'ultimo decennio. Il suo codice sorgente è stato reso disponibile nel gennaio 2011, e nel corso degli anni Kafka ha rivoluzionato il modo in cui le aziende gestiscono i dati. È stato utilizzato in tutte le aziende in cui ho lavorato, dai startup alle grandi corporazioni. Le garanzie e le possibilità d'uso che offre (pub-sub, flussi, architetture orientate agli eventi) sono applicabili a vari compiti: dall'organizzazione della conservazione dei dati al monitoraggio e all'analisi dei flussi, - utilizzate in molti settori, come finanza, sanità, settore pubblico, commercio al dettaglio, ecc.
Integrazione continua (e, in misura minore, distribuzione continua)
L'integrazione continua (Continuous Integration) non è emersa negli ultimi 10 anni, ma è stata negli ultimi dieci anni così diffusa da diventare parte del flusso di lavoro standard (eseguire test su tutte le pull request). L'affermazione di GitHub come piattaforma per lo sviluppo e l'archiviazione del codice e, soprattutto, lo sviluppo di flussi di lavoro basati susignifica che eseguire test prima di accettare una pull request nel master è un workflow di sviluppo familiare agli ingegneri che hanno iniziato le loro carriere negli ultimi dieci anni. l'unica La distribuzione continua (Continuous Deployment; distribuire ogni commit appena entra nel master) non è così diffusa come l'integrazione continua. Tuttavia, con la molteplicità di API cloud per la distribuzione, la crescente popolarità di piattaforme come Kubernetes (che forniscono API standardizzate per le distribuzioni) e l'emergere di strumenti multi-piattaforma e multi-cloud come Spinnaker (costruiti sopra le API standardizzate menzionate), i processi di distribuzione sono diventati più automatizzati, ordinati e, in generale, più sicuri.
I container possono essere considerati la tecnologia più sopravvalutata, discussa, pubblicizzata e fraintesa degli anni 2010. D'altra parte, rappresentano una delle innovazioni più importanti dell'ultimo decennio. Parte del motivo di questa confusione risiede nei segnali contrastanti che abbiamo ricevuto praticamente da ogni parte. Ora che il clamore si è un po' placato, alcuni aspetti sono diventati più chiari.
Container
I container non sono diventati popolari perché sono il miglior modo per avviare un'applicazione che soddisfi le esigenze della comunità globale degli sviluppatori. Sono diventati popolari perché si sono adattati perfettamente alla richiesta di mercato di uno strumento che risolvesse un problema completamente diverso. Docker si è rivelato
uno strumento fantastico per lo sviluppo, risolvendo un problema cruciale di compatibilità ("funziona sul mio computer"). In effetti, la vera rivoluzione è stata poiché ha risolto il problema della parità tra ambienti e ha garantito una vera portabilità non solo del file dell'applicazione, ma anche di tutte le sue dipendenze software e operative. Il fatto che questo strumento abbia in qualche modo alimentato la popolarità dei "container", che fondamentalmente rappresentano un aspetto a basso livello dell'implementazione, rimane per me forse il grande mistero dell'ultimo decennio.
Scommetto che l'emergere del calcolo "serverless" è addirittura più importante dei container, poiché rappresenta una vera realizzazione del sogno del calcolo su richiesta immagine Docker(on-demand). Negli ultimi cinque anni ho visto un'espansione graduale del campo di applicazione dell'approccio serverless (aggiunta di supporto per nuovi linguaggi e ambienti di esecuzione). L'emergere di prodotti come Azure Durable Functions appare come un passo corretto verso la realizzazione di funzioni stateful (affrontando nel contempo
Serverless
alcuni problemi legati alle limitazioni di FaaS). Sarò interessata a vedere come questa nuova paradigma si evolverà nei prossimi anni.Forse, il trend che ha beneficiato di più è stato quello della comunità degli ingegneri DevOps, poiché ha permesso di realizzare concetti come "infrastruttura come codice" (IaC). Inoltre, la passione per l'automazione si è allineata con la crescita della "cultura SRE", il cui obiettivo è un approccio più orientato al software per l'operatività. , legati alle limitazioni del FaaS). Sono curioso di vedere come questa nuova paradigmasi si svilupperà nei prossimi anni.
Automazione
Forse il settore che ha maggiormente beneficiato di questa tendenza è stato quello degli ingegneri operativi, poiché ha reso possibile realizzare concetti come "infrastruttura come codice" (IaC). Inoltre, la passione per l'automazione si è allineata con la crescita della "cultura SRE", il cui obiettivo è adottare un approccio più orientato al software nella gestione.
Universal API-ization
Un'altra caratteristica interessante dell'ultimo decennio è stata l'API-ificazione di vari task di sviluppo. Buone API flessibili permettono agli sviluppatori di creare flussi di lavoro e strumenti innovativi che, a loro volta, aiutano nella manutenzione e migliorano l'usabilità.
Inoltre, l'API-ificazione è il primo passo verso la SaaS-ificazione di alcune funzionalità o strumenti. Questa tendenza è coincisa con la crescente popolarità dei microservizi: la SaaS è diventata semplicemente un altro servizio con cui lavorare tramite API. Attualmente, esiste un'ampia varietà di strumenti SaaS e FOSS in settori come monitoraggio, pagamenti, bilanciamento del carico, integrazione continua, notifica e commutazione delle funzionalità (feature flagging), CDN, ingegneria del traffico (ad esempio, DNS) e altro, che hanno prosperato nell'ultimo decennio.
Osservabilità
È importante notare che oggi abbiamo a disposizione strumenti molto più avanzati per il monitoraggio e la diagnosi del comportamento delle applicazioni rispetto a qualsiasi altro momento precedente. Il sistema di monitoraggio Prometheus, diventato open source nel 2015, può essere considerato, probabilmente, il miglior sistema di monitoraggio tra quelli con cui ho avuto a che fare. Non è perfetto, tuttavia molte cose sono state implementate in modo molto corretto (ad esempio, il supporto per le misure [dimensionality] nel caso delle metriche).
La tracciatura distribuita è diventata un'altra tecnologia emersa nel mainstream negli anni 2010 grazie a iniziative come OpenTracing (e il suo successore OpenTelemetry). Sebbene la tracciatura sia ancora abbastanza complessa da applicare, alcune delle ultime innovazioni fanno sperare che negli anni 2020 possiamo sbloccare il suo vero potenziale. (Nota dell'autore: Leggi anche nel nostro blog la traduzione dell'articolo «» dello stesso autore.)
Guardando al futuro
Purtroppo, ci sono molte criticità che aspettano di essere risolte nel prossimo decennio. Ecco i miei pensieri a riguardo e alcune potenziali idee su come eliminarle.
Affrontare la questione della legge di Moore
La fine della legge di scalabilità di Dennard e il ritardo rispetto alla legge di Moore richiedono nuove innovazioni. John Hennessy nella spiega perché le architetture specifiche per i problemi (domain specific) come TPU possono diventare una delle soluzioni al problema del ritardo rispetto alla legge di Moore. Toolkit come di Google sembrano già un buon passo avanti in questa direzione:
I compilatori devono supportare nuove applicazioni, essere facilmente portabili su nuovo hardware, collegare molti livelli di astrazione, partendo da linguaggi dinamici e gestiti fino a acceleratori vettoriali e memorie programmabili, fornendo al contempo interruttori di alto livello per l'autotuning, garantendo funzionalità just-in-time, diagnosticando e distribuendo informazioni di debug sul funzionamento e le prestazioni dei sistemi attraverso l'intero stack e, nella maggior parte dei casi, mantenendo prestazioni sufficientemente vicine a quelle dell'assembly scritto a mano. Ci proponiamo di condividere la nostra visione, i progressi e i piani riguardanti lo sviluppo e la disponibilità pubblica di tale infrastruttura di compilazione.
CI/CD
Sebbene la crescente popolarità del CI sia stata una delle principali tendenze degli anni 2010, Jenkins rimane ancora il gold standard del CI.
Questo ambito ha un urgente bisogno di innovazioni nelle seguenti aree:
- interfaccia utente (DSL per la codifica delle specifiche dei test);
- dettagli di implementazione che lo rendano veramente scalabile e veloce;
- integrazione con diversi ambienti (staging, prod, ecc.) per realizzare forme di test più avanzate;
- verifica e distribuzione continue.
Strumenti per sviluppatori
Come settore, abbiamo iniziato a creare software sempre più complessi e impressionanti. Tuttavia, quando si tratta dei nostri strumenti, si potrebbe dire che la situazione potrebbe essere molto migliore.
La modifica collaborativa e remota (via ssh) ha guadagnato una certa popolarità, ma non è mai riuscita a diventare il nuovo standard per lo sviluppo. Se, come me, rifiuti l'idea stessa di dover essere costantemente connesso a Internet solo per poter programmare, allora lavorare tramite ssh su una macchina remota potrebbe non soddisfarti.
Le ambienti di sviluppo locali, specialmente per gli ingegneri che lavorano su architetture orientate ai servizi di grandi dimensioni, rimangono ancora un problema. Alcuni progetti stanno cercando di risolverlo, e sarei curioso di sapere come sarebbe l'UX più ergonomico per questo scenario d'uso.
Sarebbe interessante anche sviluppare il concetto di "ambienti portabili" in altri ambiti dello sviluppo, come la riproduzione degli errori (o ), che si verificano in determinate condizioni o configurazioni.
Mi piacerebbe vedere più innovazioni in aree come la ricerca semantica e contestuale del codice, strumenti che consentono di correlare incidenti in produzione con parti specifiche della base di codice, ecc.
Computing (il futuro del PaaS)
Contesto il grande entusiasmo per i container e il serverless negli anni 2010, la gamma di soluzioni nel cloud pubblico si è notevolmente ampliata negli ultimi anni.
A questo proposito, emergono alcune domande interessanti. Innanzitutto, l'elenco delle opzioni disponibili nel cloud pubblico è in continua crescita. I fornitori di servizi cloud hanno personale e risorse che permettono loro di tenere facilmente il passo con le ultime innovazioni del mondo Open Source e di lanciare prodotti come "serverless pods" (sospetto che stiano semplicemente adattando i propri runtime FaaS per essere compatibili con l'OCI) o altre stranezze simili.
Chi utilizza queste soluzioni cloud deve solo invidiare. In teoria, le offerte cloud di Kubernetes (GKE, EKS, EKS su Fargate, ecc.) forniscono API indipendenti dal fornitore cloud per eseguire carichi di lavoro. Se utilizzi prodotti simili (ECS, Fargate, Google Cloud Run, ecc.), probabilmente stai già sfruttando al massimo le funzioni più interessanti offerte dal fornitore di servizi. Inoltre, con l'arrivo di nuovi prodotti o paradigmi di calcolo, la migrazione sarà probabilmente semplice e senza problemi.
Considerando quanto velocemente si sta sviluppando la gamma di tali soluzioni (sarò molto sorpreso se non appariranno un paio di nuove opzioni a breve), sarà incredibilmente difficile per le piccole "team piattaforme" (team legati all'infrastruttura responsabili della creazione di piattaforme on-premise per eseguire carichi di lavoro all'interno delle aziende) competere in termini di funzionalità, facilità d'uso e affidabilità complessiva. Gli anni 2010 sono stati caratterizzati da Kubernetes come strumento per costruire PaaS (platform-as-a-service), quindi trovo completamente insensato costruire una piattaforma interna basata su Kubernetes che offra le stesse possibilità di scelta, semplicità e libertà disponibili nel cloud pubblico. Conceppire una PaaS basata su "container" come una "strategia Kubernetes" equivale a rinunciare deliberatamente alle capacità più innovative del cloud.
Se consideri le capacità di calcolo disponibili oggi , diventa ovvio che costruire un proprio PaaS esclusivamente basato su Kubernetes equivale a incastrarsi in un angolo (non è un approccio molto lungimirante, vero?). Anche se oggi qualcuno decidesse di creare una PaaS containerizzati basata su Kubernetes, tra un paio d'anni apparirà obsoleta rispetto alle capacità cloud. Sebbene Kubernetes sia iniziato come un progetto open source, la sua origine e ispirazione risiedono in un corrispondente strumento interno di Google. Tuttavia, è stato originariamente sviluppato all'inizio/metà degli anni 2000, quando il paesaggio computazionale era completamente diverso.
Inoltre, in un senso molto ampio, le aziende non dovrebbero nemmeno diventare esperte nella gestione di cluster Kubernetes, così come non si occupano della creazione e gestione dei propri data center. Fornire una base di calcolo affidabile è la principale responsabilità dei fornitori di servizi cloud.
Infine, ho l'impressione che come settore siamo un po' regrediti riguardo all' esperienza dell'interazione (). Heroku è stata lanciata nel 2007 ed è ancora una delle più facili da usare piattaforme. Non c'è dubbio, Kubernetes offre molta più potenza, scalabilità e programmabilità, ma mi manca quanto fosse semplice iniziare e distribuire in Heroku. Per usare questa piattaforma, è sufficiente conoscere Git.
Tutto ciò mi porta a concludere che abbiamo bisogno delle migliori astrazioni, più elevate (questo è particolarmente vero per le astrazioni di livello più alto).
Il giusto API di livello più alto
Docker è un ottimo esempio della necessità di una migliore suddivisione delle attività insieme a una corretta implementazione di API di altissimo livello.
Il problema di Docker è che (almeno inizialmente) sono stati posti obiettivi troppo ambiziosi: tutto per risolvere il problema della compatibilità ("funziona sulla mia macchina") attraverso la tecnologia dei container. Docker è stato sia un formato di immagini, sia un runtime con una propria rete virtuale, sia uno strumento CLI, sia un demone che lavora sotto root e molto altro ancora. Ad ogni modo, lo scambio di messaggi era più di complicato, per non parlare delle "VM leggere", dei gruppi di controllo, degli spazi dei nomi, dei numerosi problemi di sicurezza e delle funzioni miscelate con il richiamo di marketing "crea, fornisci, esegui qualsiasi applicazione ovunque".
Come per tutte le buone astrazioni, ci vuole tempo (e anche esperienza e dolore) per suddividere i vari problemi in strati logici che possono essere combinati tra loro. Purtroppo, prima che Docker potesse raggiungere una tale maturità, è entrato in scena Kubernetes. Ha monopolizzato così tanto il ciclo di hype che ora tutti cercavano di non rimanere indietro rispetto ai cambiamenti nell'ecosistema di Kubernetes, mentre l'ecosistema dei container ha acquisito uno status secondario.
Kubernetes condivide, in molti modi, gli stessi problemi di Docker. Nonostante tutte le chiacchiere su un'astrazione composabile la divisione delle varie attività in strati non è troppo ben incapsulata. Fondamentalmente, è un orchestratore di container che esegue container in un cluster composto da varie macchine. Questo è un compito piuttosto a basso livello, applicabile solo agli ingegneri che gestiscono il cluster. D'altra parte, Kubernetes è anche un'astrazione di alto livello, uno strumento CLI con cui gli utenti interagiscono attraverso YAML.
Docker è stato (e rimane) uno strumento fantastico per lo sviluppo, nonostante tutti i suoi difetti. Nell'intento di tenere il passo con tutti i "cani scottati", i suoi sviluppatori sono riusciti a implementare correttamente un'astrazione di alto livello.. Con astrazione di alto livello intendo un sottoinsieme una funzionalità in cui il pubblico di riferimento (in questo caso, gli sviluppatori che trascorrevano gran parte del tempo nei loro ambienti di sviluppo locali) era realmente interessato e che funzionava egregiamente "out of the box"..
Dockerfile e strumenti CLI docker dovrebbero essere esempio di una buona "interfaccia utente di alto livello". Un comune sviluppatore può iniziare a lavorare con Docker senza sapere nulla delle complessità dell'implementazione che influenzano l'esperienza operativa, come gli spazi dei nomi, i gruppi di controllo, i limiti di memoria e CPU, ecc. In fin dei conti, scrivere un Dockerfile non è molto diverso dallo scrivere uno script shell.
Kubernetes è destinato a diversi gruppi target:
- amministratori di cluster;
- ingegneri del software che si occupano di infrastruttura, per potenziare Kubernetes e costruire piattaforme su di esso;
- utenti finali che interagiscono con Kubernetes tramite
kubectl.
L'approccio "un API per tutti" applicato in Kubernetes rappresenta una "montagna di complessità" poco incapsulata senza indicazioni su come scalarla. Tutto ciò conduce a una traiettoria di apprendimento ingiustificatamente lunga. Come Adam Jacob ha affermato, "Docker ha portato agli utenti un'esperienza trasformativa che non è ancora stata superata. Chiedi a chiunque utilizzi K8s se desidererebbe che funzionasse come il loro primo docker run. La risposta sarà affermativa":
Direi che la maggior parte della tecnologia infrastrutturale oggi è troppo a basso livello (e, di conseguenza, considerata "troppo complessa"). Kubernetes è implementato a un livello piuttosto basso. La tracciatura distribuita nella sua (molti span cuciti insieme per formare un traceview) è anch'essa implementata a un livello troppo basso. Gli strumenti per gli sviluppatori che realizzano "astrazioni ad alto livello" tendono ad avere il maggior successo. Questa conclusione si dimostra valida in un sorprendente numero di casi (se la tecnologia è troppo complessa o difficile da usare, allora "API/UI di alto livello" per quella tecnologia sono ancora da scoprire).
Attualmente, l'ecosistema cloud native è confuso dalla sua insistenza sulla bassezza. Come settore, dobbiamo innovare, sperimentare e insegnare come dovrebbe apparire il giusto livello di "astrazione massima".
Vendita al dettaglio
Negli anni 2010, l'esperienza digitale nel commercio al dettaglio è cambiata poco. Da un lato, la facilità degli acquisti online avrebbe dovuto colpire i negozi tradizionali, ma dall'altro, lo shopping online è fondamentalmente rimasto invariato per un decennio.
Sebbene non abbia idee specifiche sullo sviluppo di questo settore nel prossimo decennio, sarei profondamente delusa se nel 2030 facessimo acquisti allo stesso modo in cui li facciamo nel 2020.
Giornalismo
Sono sempre più delusa dallo stato del giornalismo mondiale. È diventato sempre più difficile trovare risorse di notizie imparziali che trasmettono in modo obiettivo e meticoloso. Spesso, il confine tra la notizia stessa e l'opinione al riguardo si fa sottile. Di norma, le informazioni vengono presentate in modo parziale. Questo è particolarmente vero per alcuni paesi in cui storicamente non esisteva distinzione tra notizia e opinione su di essa. In un recente articolo pubblicato dopo le ultime elezioni generali nel Regno Unito, Alan Rusbridger, ex redattore di The Guardian, :
Il punto principale è che per molti anni ho guardato i giornali americani e ho compatito i colleghi lì, che erano responsabili solo delle notizie, mentre il commento era affidato ad altre persone. Tuttavia, col tempo, la compassione si è trasformata in invidia. Ora penso che tutti i giornali nazionali britannici dovrebbero separare la responsabilità per le notizie dalla responsabilità per i commenti. Purtroppo, per un lettore medio — soprattutto un lettore online — è troppo difficile cogliere la differenza.
Data la piuttosto discutibile reputazione della Silicon Valley in materia di etica, non affiderei mai alla tecnologia una "rivoluzione" nel giornalismo. Detto ciò, io (e molti dei miei conoscenti) saremmo felici se emergesse una risorsa di notizie imparziale, disinteressata e affidabile. Al momento, non riesco a immaginare quale aspetto potrebbe avere una piattaforma del genere, ma sono sicura che in un'epoca in cui è sempre più difficile individuare la verità, la necessità di un giornalismo onesto è più alta che mai.
Social Network
I social media e le piattaforme di notizie collettive sono la principale fonte di informazioni per molte persone in tutto il mondo, e la mancanza di accuratezza e il rifiuto di alcune piattaforme di condurre anche il più basilare controllo dei fatti portano a conseguenze tragiche come genocidi, interferenze nelle elezioni, ecc.
I social media sono anche il mezzo di comunicazione più potente mai esistito. Hanno radicalmente cambiato la pratica politica. Hanno cambiato la pubblicità. Hanno cambiato la cultura pop (ad esempio, il principale contributo allo sviluppo della cosiddetta cancel culture [cultura dell'ostracismo — nota del traduttore]). I critici affermano che i social media sono diventati un terreno fertile per cambiamenti rapidi e "capricciosi" nei valori morali, ma hanno anche dato la possibilità ai rappresentanti di gruppi marginali di unirsi (cosa che precedentemente non avevano mai avuto). In sostanza, i social media hanno cambiato il modo in cui le persone comunicano e si esprimono nel XXI secolo. Tuttavia, sono anche convinta che i social media favoriscano il manifestarsi dei peggiori impulsi umani. Attenzione e riflessione vengono spesso trascurate in nome della popolarità, e diventa praticamente impossibile esprimere un dissenso argomentato su determinate opinioni e posizioni. La polarizzazione spesso sfugge al controllo, e così il pubblico non sente semplicemente singole opinioni, mentre gli assolutisti dettano le regole dell'etichetta online e dell'accettabilità.
Mi chiedo se possa esistere una "migliore" piattaforma che favorisca un miglioramento della qualità delle discussioni? Infatti, ciò che alimenta il "coinvolgimento" è spesso ciò che porta la maggiore redditività a queste piattaforme. Come
Kara Swisher nel New York Times: Si può sviluppare un'interazione digitale senza incitare all'odio e all'intolleranza. Il motivo per cui la maggior parte dei social media appare così tossica è che sono stati creati per la velocità, la viralità e l'attrazione dell'attenzione, piuttosto che per il contenuto e l'accuratezza.
Sarebbe veramente triste se tra qualche decennio l'unico lascito dei social media fosse quello di annacquare le sfumature e l'adeguatezza del discorso pubblico.
La trasformazione di Docker: vendita di Docker Enterprise a Mirantis e nuovo percorso
P.S. dal traduttore
Leggete anche nel nostro blog:
- «»;
- «»;
- «»;
- «».
Fonte: habr.com
