Discussione Ufficiale L'inesorabile morte di Atom Text Editor, l'ambiente in cui è stato sviluppato il Framework React.js

[nfvblog]

L'inesorabile morte di Atom Text Editor, l'ambiente in cui è stato sviluppato il Framework React.js​

Un mese fa circa Github dichiara che Atom verrà sospeso a Dicembre il giorno 15 visto che ormai il numero di sviluppatori che lo utilizzavano era sceso drasticamente, per di più nella soluzione in cloud e anche in VSCode all'apparenza è l'editor più diffuso, quindi visto che ormai Github appartiene ad Microsoft la scelta del nuovo editor era quanto meno obbligatoria.

Il tatto è che ormai Atom non è stato più in grado di preservare il suo spazio, visto che con lo sviluppo delle varie versioni è diventato via via più pesante diventando scomodo agli occhi dei Dev, per di più nonostante la sua integrazione con Github l'applicativo Github desktop riesce a soddisfare al meglio tutte le esigenze, anche con meno bug rispetto alla versione integrata nello stesso Atom. Comunque per la leggere tutte le motivazioni che hanno portato lo staff di GH a fare questa manovra, clicca qui.

0.1    I problemi

Atom era un editor multifunzione di quelli classici, aveva una buona integrazione a Github e onestamente il suo vero problema era l'ottimizzazione e anche il fatto che da un punto in poi gli sviluppatori si siano un po' adagiati sugli allori. Quindi per forza di cose sono nate soluzioni alternative come quella Microsoft che personalmente trovo poco funzionale ma che evidentemente piace alla stragrande maggioranza dei Dev che trovano in VScode, una buona base per poter fare la maggioranza dei progetti che non richiedano IDE più sofisticati.

Perché per quanto mi possa fare schifo VSCode perché su un sistema Unix esistono si sicuramente degli editor migliori tra cui Emacs e VIM che offrono tante impostazioni interessanti per la scrittura di codice e non solo.

0.1.1    L'interfaccia

Anche l'interfaccia di Atom non era la più pulita di questo mondo, effettivamente, come molti ide e text editor moderni incentrati sullo sviluppo di codice aveva troppi menù e sotto-menù rendendo l'esperienza di utilizzo non proprio delle migliori.

0.2    Contenuto del post di github.blog

Il post è diviso in 4 parti

• Introduzione;
• Why are we doing this now? "Perché lo stiamo facendo ora?";
• What happens next? "Cosa succederà dopo?";
• Thank you.

Nel primo punto spiega sommi capi quello che ho piegato nella prima parte, il fatto che le soluzioni il cloud e anche l'editor vscode abbiano preso il sopravvento nel mercato con una userspace molto vasta e ormai non c'è più spazio per Atom.

0.2.1    GitHub Codespaces

GitHub Codespaces è un servizio online, offerto da Github che consente di lavorare a propri progetti sfruttando direttamente una versione web di VScode e uno spazio cloud per il salvataggio dei progetti, ovviamente, anche questo è stato un altro dei fattori che ha contribuito alla morte di questo editor.

0.3    Cosa non mi piace di VScode

La prima cosa che mi lascia perplesso è il fatto che al contrario degli editor che si sono fatti la guerra fino ai primi del 2000, esso non possiede un suo linguaggio specifico per la configurazione, infatti, sia VIM che GNU Emacs sono due editor che posseggono il primo il VimScript e il secondo un linguaggio potentissimo chiamato è ELisp (Emacs Lisp), che fa parte della macrofamiglia dei linguaggi Lisp (List Processor), essi erano pensati per la scrittura di strutture complesse, creazione di altri linguaggi di programmazione, utilizzo generico e anche la realizzazione di intelligenze artificiali. Piccola citazione di un caso storico di intelligenze artificiali scritte con questo tipo di linguaggio è sotto gli occhi di tutto, infatti, Crash Bandicoot per ps1 ha le AI scritte in Lisp.

Ok, so benissimo che anche VScode è open source, ma non del tutto, infatti, la vera versione senza telemetria di Microsoft è VS codium che onestamente ho provato ed è esattamente identico alla versione standard dell'editor ma con l'unica differenza che uno ha componenti che studiano il comportamento del utente e l'altro no.

 

[0xbro]

Povero Atom, mi dispiace, per un po' di tempo l'ho usato e non mi dispiaceva, seppur preferissi Sublime Text. Di sicuro aveva e ha del potenziale inespresso

 

[nfvblog]

Povero Atom, mi dispiace, per un po' di tempo l'ho usato e non mi dispiaceva, seppur preferissi Sublime Text. Di sicuro aveva e ha del potenziale inespresso

infatti, questo risultato è legato ad una pessima politica di sviluppo

 

[giovy2707]

L'inesorabile morte di Atom Text Editor, l'ambiente in cui è stato sviluppato il Framework React.js​

Un mese fa circa Github dichiara che Atom verrà sospeso a Dicembre il giorno 15 visto che ormai il numero di sviluppatori che lo utilizzavano era sceso drasticamente, per di più nella soluzione in cloud e anche in VSCode all'apparenza è l'editor più diffuso, quindi visto che ormai Github appartiene ad Microsoft la scelta del nuovo editor era quanto meno obbligatoria.

Il tatto è che ormai Atom non è stato più in grado di preservare il suo spazio, visto che con lo sviluppo delle varie versioni è diventato via via più pesante diventando scomodo agli occhi dei Dev, per di più nonostante la sua integrazione con Github l'applicativo Github desktop riesce a soddisfare al meglio tutte le esigenze, anche con meno bug rispetto alla versione integrata nello stesso Atom. Comunque per la leggere tutte le motivazioni che hanno portato lo staff di GH a fare questa manovra, clicca qui.

0.1    I problemi

Atom era un editor multifunzione di quelli classici, aveva una buona integrazione a Github e onestamente il suo vero problema era l'ottimizzazione e anche il fatto che da un punto in poi gli sviluppatori si siano un po' adagiati sugli allori. Quindi per forza di cose sono nate soluzioni alternative come quella Microsoft che personalmente trovo poco funzionale ma che evidentemente piace alla stragrande maggioranza dei Dev che trovano in VScode, una buona base per poter fare la maggioranza dei progetti che non richiedano IDE più sofisticati.

0.1.1    L'interfaccia

Anche l'interfaccia di Atom non era la più pulita di questo mondo, effettivamente, come molti ide e text editor moderni incentrati sullo sviluppo di codice aveva troppi menù e sotto-menù rendendo l'esperienza di utilizzo non proprio delle migliori.

0.2    Contenuto del post di github.blog

Il post è diviso in 4 parti

• Introduzione;
• Why are we doing this now? "Perché lo stiamo facendo ora?";
• What happens next? "Cosa succederà dopo?";
• Thank you.

Nel primo punto spiega sommi capi quello che ho piegato nella prima parte, il fatto che le soluzioni il cloud e anche l'editor vscode abbiano preso il sopravvento nel mercato con una userspace molto vasta e ormai non c'è più spazio per Atom.

0.2.1    GitHub Codespaces

GitHub Codespaces è un servizio online, offerto da Github che consente di lavorare a propri progetti sfruttando direttamente una versione web di VScode e uno spazio cloud per il salvataggio dei progetti, ovviamente, anche questo è stato un altro dei fattori che ha contribuito alla morte di questo editor.

0.3    Cosa non mi piace di VScode

La prima cosa che mi lascia perplesso è il fatto che al contrario degli editor che si sono fatti la guerra fino ai primi del 2000, esso non possiede un suo linguaggio specifico per la configurazione, infatti, sia VIM che GNU Emacs sono due editor che posseggono il primo il VimScript e il secondo un linguaggio potentissimo chiamato è ELisp (Emacs Lisp), che fa parte della macrofamiglia dei linguaggi Lisp (List Processor), essi erano pensati per la scrittura di strutture complesse, creazione di altri linguaggi di programmazione, utilizzo generico e anche la realizzazione di intelligenze artificiali. Piccola citazione di un caso storico di intelligenze artificiali scritte con questo tipo di linguaggio è sotto gli occhi di tutto, infatti, Crash Bandicoot per ps1 ha le AI scritte in Lisp.

Non sono un programmatore esperto però con gli anni ho provato spesso atom e non mi ha mai convinto come Vscode, onestamente non ho mai capito perché tutti amano così tanto editor come Vim, sarà perché forse sono inesperto, ma a prima vista mi è sempre sembrato che Vim fosse un po' troppo "semplice" per la programmazione, vi ripeto non sono in esperto programmo principalmente per fare esercizi all'università (anche se conto di iniziare qualche progetto a breve) ma tornando a vim mi sembra troppo "semplice" o almeno non mi è sembrato di vedere funzionalità avanzate come ci sono ad esempio in vscode, ovviamente rispetto a vscode manca sicuramente l'odiata telemetria però apparte questo non ho notato grandi vantaggi nell'uso di Vim rispetto a editor come vscode.

 

[Psychonaut]

Non sono un programmatore esperto però con gli anni ho provato spesso atom e non mi ha mai convinto come Vscode, onestamente non ho mai capito perché tutti amano così tanto editor come Vim, sarà perché forse sono inesperto, ma a prima vista mi è sempre sembrato che Vim fosse un po' troppo "semplice" per la programmazione, vi ripeto non sono in esperto programmo principalmente per fare esercizi all'università (anche se conto di iniziare qualche progetto a breve) ma tornando a vim mi sembra troppo "semplice" o almeno non mi è sembrato di vedere funzionalità avanzate come ci sono ad esempio in vscode, ovviamente rispetto a vscode manca sicuramente l'odiata telemetria però apparte questo non ho notato grandi vantaggi nell'uso di Vim rispetto a editor come vscode.

Bè, quando ti troverai a dover modificare file di configurazione, script o programmi all'interno di un server linux/oracle/aix senza GUI ne riparliamo xD.

 

[giovy2707]

Bè, quando ti troverai a dover modificare file di configurazione, script o programmi all'interno di un server linux/oracle/aix senza GUI ne riparliamo xD.

Beh se non si può usare la gui allora tutto torna

 

[0xbro]

Allora, diciamo che se la necessità è solamente quella di programmare, e si ha a disposizione un GUI (come nel 99% dei casi), secondo me vim non è il massimo. E' vero che è comodo, ha mille shortcut e tutto quello che vuoi, ma ormai ogni editor / IDE moderno implementa funzionalità aggiuntive come la ricerca delle dichiarazioni dei metodi, dove sono utilizzati, la definizione di cosa faccia una specifica funzione, l'auto-completamento ecc. ecc. tutte feature che forse sono integrabili tramite plugin su vim ma che di defaul non mi pare siano presenti (potrei sbagliarmi però).

Diverso è il discorso senza GUI. Se sei su un server e devi fare modifiche a qualunque file, beh, non hai molte alternative, e tra tutti i vim e senza dubbio il più completo e potente

 

[nfvblog]

Bè, quando ti troverai a dover modificare file di configurazione, script o programmi all'interno di un server linux/oracle/aix senza GUI ne riparliamo xD.

niente di più vero

 

[nfvblog]

Allora, diciamo che se la necessità è solamente quella di programmare, e si ha a disposizione un GUI (come nel 99% dei casi), secondo me vim non è il massimo. E' vero che è comodo, ha mille shortcut e tutto quello che vuoi, ma ormai ogni editor / IDE moderno implementa funzionalità aggiuntive come la ricerca delle dichiarazioni dei metodi, dove sono utilizzati, la definizione di cosa faccia una specifica funzione, l'auto-completamento ecc. ecc. tutte feature che forse sono integrabili tramite plugin su vim ma che di defaul non mi pare siano presenti (potrei sbagliarmi però).

Diverso è il discorso senza GUI. Se sei su un server e devi fare modifiche a qualunque file, beh, non hai molte alternative, e tra tutti i vim e senza dubbio il più completo e potente

io ultimamente sto utilizzando molto emacs perché ha un bellissimo file di configurazione in lisp e avendo tanti precedenti a riguardo gli posso far fare quello che voglio, esattamente come accade con Vim e il vimscript, onestamente non capisco come facciano ad apprezzare un editor limitato come VScode che non può implementare certe cose con la semplicità del ELisp o del VimScript. Per di più piglia parecchia ram senza un reale motivo e soffre di un leggero memory leak e a me rompe abbastanza questo aspetto

 

[nfvblog]

Beh se non si può usare la gui allora tutto torna

io ho sempre usato editor testuali anche su desktop e non ho mai avuto problemi perché supportano anche la clipboard di sistema, per di più io sono un utente Unix nativo, il mio concetto di editor è molto più raffinato di quello di un utente microsoft e risulto estremamente esigente a riguardo

 

[hackynonpointer]

A questo punto credo di essere l'unico che usa nano/vim giornalmente per programmare, onestamente non mi interessa l'auto-completamento, l'identazione automatica, le parole colorate, i temi ecc ecc, basta programmare, comunque sia bell'articolo.

 

[nfvblog]

A questo punto credo di essere l'unico che usa nano giornalmente per programmare, onestamente non mi interessa l'auto-completamento, l'identazione automatica, le parole colorate, i temi ecc ecc, basta programmare, comunque sia bell'articolo.

che poi anche Emacs e vim autocompletano, quindi voglio capire perché tutti mi dicono che preferiscono vscode perché autocompleta, semplicemente la funzione di default è giustamente disattivata

 

[hackynonpointer]

che poi anche Emacs e vim autocompletano, quindi voglio capire perché tutti mi dicono che preferiscono vscode perché autocompleta, semplicemente la funzione di default è giustamente disattivata

ehh ahahha, valli a capire, io personalmente utilizzo editor da terminale anche per comodità, vedi un po te,

vi file #crei un file
vim file #crei un file
nano file #crei un file

su VScode / ide in generale devi andare dal menu a tendina fare nuovo file (o schiacciare ctrl+n) ecc ecc, poi fai tutto in un ambiente, il terminale, scrivi il tuo codice salvi e runni subito:

nano ciao.py
python3 ciao.py
#####
nano main.c
gcc -o main main.c

 

[--- Ra ---]

Io, personalmente, considero "nano" una buona alternativa a Vim perché è più semplice ed intuitivo (nonostante Vim sia più completo e personalizzabile e su questo non ci piove). Il punto forte di "nano" è che puoi utilizzarlo subito senza nemmeno leggere il manuale perché le varie shortcut sono sempre riepilogate in basso, in fondo alla finestra dell'editor. In alto trovi il nome del file, al centro il contenuto testuale: pura semplicità e comodità di utilizzo. Se devi lavorare con file di configurazione di dimensioni ridotte e non devi programmarci tante linee di codice, nano è la soluzione ideale. Per scrivere programmi "sostanziosi" utilizzo Sublime Text come editor, che non delude mai ahaha.

 

[nfvblog]

anche nel caso di emacs fai un qualcosa di simile perché usando il vecchio e classico

emacs -nw nomefile.estensione

in cui il -nw sta per no window e serve per eseguire la variante da terminale, io ricordo che emacs è un applicativo che utilizza il meccanismo Client/server, infatti, emacs può avere più sessioni di se all'interno della stessa macchina con il buffer condiviso.

 

[giovy2707]

Io onestamente ho sempre evitato vim perchè a prima vista mi era sembrato piuttosto rudimentale, utile comunque solo per fare delle modifiche al volo come spesso faccio con nano, però da quanto dite mi sembra che sia molto meglio di quanto pensassi, mi voglio informare un pò al riguardo, chissà magari mi piacerà e lo utilizzerò come editor principale.