21 tendenze di programmazione calde e 21 fredde

I programmatori adorano deridere il mondo della moda, dove le tendenze passano come brezze. Le lunghezze delle gonne si alzano e si abbassano, i pigmenti vanno e vengono, le cravatte si ingrossano, poi si assottigliano. Ma nel mondo della tecnologia, il rigore, la scienza, la matematica e la precisione dominano la moda.

Questo non vuol dire che la programmazione sia una professione priva di tendenze. La differenza è che le tendenze di programmazione sono guidate da una maggiore efficienza, maggiore personalizzazione e facilità d'uso. Le nuove tecnologie che forniscono uno o più di questi eclissi la generazione precedente. È una meritocrazia, non una stravaganza-ocrazia.

Quello che segue è un elenco di ciò che è caldo e ciò che non lo è tra i programmatori di oggi. Non tutti saranno d'accordo con ciò che è elencato in A, ciò che è in elenco D e ciò che è stato tralasciato. Questo è ciò che rende la programmazione una professione infinitamente affascinante: rapidi cambiamenti, dibattiti appassionati, rimonte improvvise.

Caldo: preprocessori

Non: stack completo della lingua

Non è passato molto tempo da quando le persone che hanno creato un nuovo linguaggio di programmazione hanno dovuto costruire tutto ciò che trasformava il codice in bit alimentati al silicio. Poi qualcuno ha capito che potevano cavarsela con il lavoro precedente. Ora le persone con un'idea intelligente scrivono semplicemente un preprocessore che traduce il nuovo codice in qualcosa di vecchio con un ricco set di librerie e API.

I linguaggi di scripting come Python o JavaScript erano una volta limitati a piccoli progetti, ma ora sono la base per un lavoro serio. E quelli a cui non piaceva JavaScript ha creato CoffeeScript, un preprocessore che consente loro di codificare, ancora una volta, senza l'onerosa punteggiatura. Esistono dozzine di variazioni che preslicano e predicano la sintassi in modo diverso.

Le persone che amavano la digitazione dinamica hanno creato Groovy, una versione più semplice di Java senza punteggiatura eccessivamente insistente. Sembra che ci siano dozzine di linguaggi - Groovy, Scala, Clojure, Kotlin, ecc. - che girano sulla JVM, ma c'è solo una JVM. Puoi eseguire molte lingue anche sulla VM di .Net. Perché reinventare la ruota?

Caldo: serverless

Non: Docker

Questo non è esattamente vero. I container Docker sono ovunque. I server girano e chiudono i contenitori tutto il tempo. Tuttavia, i container Docker sono davvero molto più grandi di quanto devono essere.

Se ci pensi, puoi scrivere solo poche dozzine di righe di codice decisionale reale per quel microservizio che stai distribuendo, ma dovrai aggiungere un miliardo di righe di configurazione per far partire Node.js e qualsiasi altra cosa correttamente con Docker. Sì, è tutto standard, ma manca il punto.

Le nuove architetture serverless ci consentono di implementare solo quelle poche istruzioni if-then-else che prendono le decisioni reali. Tutto il resto è lasciato alle persone che ci affittano la piattaforma serverless.

Sì, ci lamenteremo del lock-in e della mancanza di personalizzazione tra qualche anno, ma per ora le opzioni serverless sembrano un dolce sollievo da tutti i devops e la configurazione.

Caldo: framework JavaScript MV *

Non: file JavaScript

Molto tempo fa, tutti hanno imparato a scrivere JavaScript per far apparire una finestra di avviso o controllare che l'indirizzo e-mail nel modulo contenga un segno @. Ora le app HTML AJAX sono così sofisticate che poche persone iniziano da zero. È più semplice adottare un framework elaborato e scrivere un po 'di codice collante per implementare la logica aziendale.

Ora ci sono dozzine di framework come Kendo, Sencha, jQuery Mobile, AngularJS, Ember, Backbone, Meteor JS e molti altri, tutti pronti a gestire eventi e contenuti per le tue app e pagine web.

Quelle sono semplicemente le app web. Ci sono anche un numero sintonizzato per offrire sviluppo multipiattaforma per il mondo degli smartphone / tablet. Tecnologie come NativeScript, PhoneGap, Apache Cordova e React Native sono alcune delle opzioni per creare app con la tecnologia HTML5.

Caldo: framework CSS

Non: CSS generico

C'era una volta, aggiungere un po 'di pizzazz a una pagina web significava aprire il file CSS e includere un nuovo comando come font-style:italic. Quindi hai salvato il file e sei andato a pranzo dopo una dura mattinata di lavoro. Ora le pagine web sono così sofisticate che è impossibile riempire un file con comandi così semplici. Una modifica a un colore e tutto va fuori di testa. È come quello che si dice su cospirazioni ed ecologie: tutto è interconnesso.

È qui che i framework CSS come SASS ei suoi cugini come Compass hanno trovato solide basi. Incoraggiano la codifica colta e stabile offrendo costrutti di programmazione come variabili reali, blocchi di annidamento e mix-in. Potrebbe non sembrare una novità nel livello di programmazione, ma è un grande balzo in avanti per il livello di progettazione.

Caldo: SVG su tela

Non: Flash

Flash ha fatto impazzire le persone per anni, ma gli artisti hanno sempre amato i risultati. Il rendering con anti-alias sembra ottimo e molti artisti di talento hanno creato una grande quantità di codice Flash per offrire transizioni e animazioni sofisticate. I giochi casuali continuano ad essere molto popolari. Quindi Flash si aggrappa alla vita sul web.

Ora che il livello JavaScript ha la capacità di fare la stessa cosa, i creatori di browser e gli sviluppatori stanno tifando per la fine di Flash. Vedono una migliore integrazione con il livello DOM proveniente da nuovi formati come SVG (Scalable Vector Graphics). SVG e HTML comprendono una grande pila di tag che spesso è più facile da usare per gli sviluppatori web. Poi ci sono API di grandi dimensioni che offrono disegni elaborati sull'oggetto Canvas, spesso con l'aiuto di schede video. Mettili insieme e ti rimangono pochi motivi per utilizzare Flash.

Hot: quasi big data (analisi senza Hadoop)

Non: Big data (con Hadoop)

A tutti piace sentirsi come il grande uomo del campus e, se non lo sono, stanno cercando un campus delle dimensioni appropriate dove possano distinguersi. Non sorprende quindi che quando le parole "big data" hanno iniziato a scorrere nella suite executive, le tute hanno iniziato a chiedere i sistemi di big data più grandi e potenti come se stessero acquistando uno yacht o un grattacielo.

La cosa divertente è che molti problemi non sono abbastanza grandi per utilizzare le più fantasiose soluzioni per big data. Certo, aziende come Google o Yahoo tengono traccia di tutta la nostra navigazione web; hanno file di dati misurati in petabyte o yottabyte. Ma la maggior parte delle aziende dispone di set di dati che possono essere facilmente inseriti nella RAM di un PC di base. Sto scrivendo questo su un PC con 16 GB di RAM, sufficiente per un miliardo di eventi con una manciata di byte. Nella maggior parte degli algoritmi, i dati non devono essere letti in memoria perché lo streaming da un SSD va bene.

Ci saranno casi che richiedono i tempi di risposta rapidi di dozzine di macchine in un cloud Hadoop in esecuzione in parallelo, ma molte andranno bene collegandosi su una singola macchina senza i problemi di coordinamento o comunicazione.

Caldo: Spark

Non: Hadoop

Non è tanto che Hadoop si stia raffreddando. È più che Apache Spark è rovente, rendendo il modello Hadoop un po 'vecchio. Spark prende in prestito alcune delle migliori idee dell'approccio di Hadoop all'estrazione di significato da grandi volumi di dati e li aggiorna con alcuni solidi miglioramenti che rendono il codice molto, molto più veloce. Il più grande potrebbe essere il modo in cui Spark conserva i dati in una memoria veloce invece di richiedere che tutto venga scritto e letto dal file system distribuito.

Ovviamente molte persone stanno unendo i due utilizzando la velocità di elaborazione di Spark sui dati archiviati nel file system distribuito di Hadoop. Hadoop e Spark sono più spesso partner dei concorrenti.

Hot: configurazione del database

Non: programmazione software

Molto tempo fa, i programmatori scherzavano dicendo che non sapevano come sarebbe stata la programmazione nel prossimo secolo, ma sapevano che si sarebbe chiamata Fortran. Questa battuta era così divertente che cadevano dai loro dinosauri e rompevano le loro mutande di legno. Quindi tornerebbero a configurare un database.

E stiamo ancora costruendo database oggi, ma quello che pensiamo come un "database" è ora molte volte più sofisticato e potente. I database standard si sincronizzeranno tra i continenti offrendo al contempo un compromesso flessibile tra coerenza e velocità. Alcuni servizi cloud come Firebase invieranno tutti i nuovi dati alle app Web in esecuzione su client mobili.

Gran parte della rivoluzione senza server si basa sulla consapevolezza che molti degli archivi di dati nel cloud sono ora così potenti che abbiamo solo bisogno di scrivere alcune clausole if-then-else per creare un'app web piuttosto interessante.

Caldo: framework di gioco

Non: sviluppo di giochi nativi

C'era una volta, lo sviluppo di giochi significava assumere molti sviluppatori che scrivevano tutto in C da zero. Certo, costava un miliardo di dollari, ma sembrava fantastico e correva come il vento. Nessuno può permettersi il lusso del codice personalizzato. La maggior parte degli sviluppatori di giochi ha rinunciato al proprio orgoglio anni fa e utilizza librerie come Unity, Corona o LibGDX per creare i propri sistemi. Non scrivono tanto codice C quanto istruzioni per le librerie.

È un peccato che i nostri giochi non siano realizzati a mano con orgoglio ma stampati con lo stesso motore? No. La maggior parte degli sviluppatori è sollevata. Poiché non hanno a che fare con i dettagli, possono concentrarsi sul gioco, sull'arco narrativo, sui personaggi e sull'arte. 

Hot: generatori di siti Web statici

Non: app Web a pagina singola

Ricordi quando gli URL puntavano a pagine web piene di testo e immagini statiche? Quindi sono arrivate le app Web dinamiche a pagina singola e le hanno sostituite tutte con un'app Web intelligente che avrebbe recuperato i dati in questione. Indovina un po? Il pendolo sta tornando indietro e tutti i ragazzi stanno costruendo generatori di siti statici. Ce ne sono a dozzine. È come un ibrido. Metti tutti i dati in una pila e poi scrivi del codice che inserisce i dati in alcuni modelli in modo che ci sia un file HTML per ogni URL statico e questo proviene da ogni riga nella tabella dei dati.

I ragazzi pensano che questi siti statici siano superveloci e lo sono. Basta non dire loro che i vecchi sistemi dinamici come WordPress e Drupal funzionavano più o meno allo stesso modo, mantenendo cache che erano praticamente piene di pagine statiche generate con i dati più recenti.

Caldo: GraphQL

Non: RIPOSO

Non è come se REST fosse morto. È solo che vogliamo fare di più con l'API e GraphQL è un modo per farlo. GraphQL restituisce i dati in JSON, proprio come REST. GraphQL inizia con un HTTP POST, proprio come molte chiamate REST. È solo che la sintassi GraphQL consente di specificare query molto complesse con solo poche sequenze di tasti. Ciò rende più semplice per i programmatori chiedere solo quello che vogliono e riduce la quantità di lavoro lato server che deve essere fatto quando qualcuno desidera un'API leggermente diversa.

Caldo: IDE cloud

Non: IDE locali

Molto tempo fa, le persone usavano un compilatore da riga di comando. Poi qualcuno l'ha integrato con un editor e altri strumenti per creare l'IDE. Ora è il momento che l'IDE venga eclissato (ha) dagli strumenti basati su browser che ti consentono di modificare il codice, anche il codice di un sistema funzionante. Se non ti piace come funziona WordPress, viene fornito con un editor integrato che ti consente di modificare il codice subito e lì. Azure di Microsoft ti consente di scrivere codice colla JavaScript direttamente nel suo portale. Questi sistemi non offrono i migliori ambienti di debug e c'è qualcosa di pericoloso nella modifica del codice di produzione, ma l'idea ha le gambe.

Puoi iniziare con AWS Cloud9, Codenvy e WebIDE di Mozilla, ma continua a esplorare. Gli strumenti basati sul web stanno diventando sempre più potenti. È possibile, ad esempio, creare un intero progetto di analisi dei big data nel sito Web di Azure di Microsoft. E se stai iniziando a esplorare le opzioni serverless, scoprirai rapidamente che puoi scrivere tutto il tuo codice in un elemento del modulo su una pagina web. Uno che non è molto più grande del modulo che usi per aggiornare i tuoi amici su Facebook.

Caldo: GPU

Non: CPU

Quando il software era semplice e le istruzioni erano disposte in una bella linea, la CPU era la regina del computer perché faceva tutto il lavoro pesante. Ora che i videogiochi sono pieni di routine grafiche estese che possono essere eseguite in parallelo, la scheda video gestisce lo spettacolo. È facile spendere $ 500, $ 600 o più su una scheda video fantasia e alcuni giocatori seri ne usano più di una. È più del doppio del prezzo di molti desktop di base.

Inoltre, i giocatori non sono gli unici a vantarsi delle proprie schede GPU. Gli informatici stanno ora convertendo molte applicazioni parallele per eseguire centinaia di volte più velocemente sulla GPU. E i data scientist utilizzano server pieni di GPU per accelerare lo sviluppo dei loro modelli di machine learning. 

Caldo: GitHub

Non: curriculum

Certo, potresti conoscere un candidato leggendo un elenco gonfio di risultati che include il vicepresidente del club di scacchi della scuola media. Ma leggere il codice effettivo di qualcuno è molto più ricco e istruttivo. Scrivono buoni commenti? Perdono troppo tempo a suddividere gli oggetti in piccole classi che fanno poco? Esiste una vera architettura con margini di espansione? A tutte queste domande si può rispondere dando un'occhiata al loro codice.

Questo è il motivo per cui partecipare a progetti open source sta diventando sempre più importante per trovare un lavoro. Condividere il codice da un progetto proprietario è difficile, ma il codice open source può andare ovunque.