dead

[Z80Fan]

• 

bah, io continuo a non vedere ragioni scientificamente valide, indentare mi complica il lexer e anche il parser e se il solo vantaggio e' rimuover due key-words allora non ci sono vantaggi rispetto agli effetti collaterali di cui sopra.

In realtà non è che il parsing sia così complesso: invece di pensare a caratteri devi pensare a righe, per ogni riga conti gli spazi iniziali e in base a quello determini il livello di indentazione. Il fatto di avere un nuovo blocco o no lo capisci dalla riga precedente: se ad esempio trovi un if, sai che la riga dopo deve avere un'indentazione maggiore, e se non la ha dai un errore, così come dai un errore se due righe che dovrebbero essere nello stesso blocco hanno indentazioni diverse.

Però anche io preferisco di gran lunga i delimitatori di blocchi.

[cdimauro]

• 

bah, io continuo a non vedere ragioni scientificamente valide, indentare mi complica il lexer e anche il parser e se il solo vantaggio e' rimuover due key-words allora non ci sono vantaggi rispetto agli effetti collaterali di cui sopra.

Non puoi valutarlo in questo modo semplicemente perché ti crea problemi nella tua implementazione.

tra l'altro ribadisco, ci sono modi per ripulire il codice appena e' stato creato il syntax-tree, sia in post-coding sia in real-time, ergo io abortisco assolutamente questa feature e mi tengo le keyword dei blocchi

mi intriga di piu' in assoluto la corretta costruzione del syntax-tree, e in cio' al lato sviluppo, ma anche al lato utilizzo, e' mille volte + comodo e sano usare i block delimter, e fatto cio' ... posso chiederne un reverse indentando come mi pare!

OK

al lato utilizzo, in un editor interattivo, digiti "begin", e lui indenta in automatico fino a che non scrivi "end", e se invece gli dai in pasto un sorgente, puoi pastrugnarlo come ti pare, mettere anche tutto sulla stessa riga, fare casini vari con CR/LF (casini tra mac e win ancora vivi), tanto lui se ne frega, costruisce il syntax-tree, e volendo ti risputa indietro un sorgente perfettamente non solo indentato ma con tutto al posto giusto
- area dichiarazione variabili, tutto in testa, e non mescolate tra il codice
- area funzion
- area costanti
-etc

le vere cose che fanno la differenza!

Io il codice lo scrivo ben indentato da anni: non aspetto che l'editor esegua un'operazione di post-processing su quello che ho scritto, per aggiustarmelo. Anche perché nel codice si lavora continuamente, e ho bisogno in QUEL preciso momento di vedere i blocchi strutturati, non a lavoro finito...

[cdimauro]

• 

prima ho provato sulla mia pelle
- pastebin
- un code/quote da forum che non tiene conto degli spazi, o meglio, fa come vuole lui (e i tab li filtra)
- email, con mime e' un delirio

risultato ? il codice senza blockkey e' imploso e c'e' voluto del tempo per risistemalo a manina!
ho fatto lo stesso esperimento con usando i blockkey ed il parser non ha fatto una piega, risputando fuori un codice passato in candeggina, smacchiato, pulito, perfetto e profumato!

come fanno i programmatori python a passarsi il codice ? sono tutti cosi' ligi da fare zip ?

E' chiaro che ci sono questi problemi, qui nessuno l'ha mai negato. Con pastbin non ho mai avuto problemi a selezionare il codice e poi incollarlo dove voglio, per cui non mi spiego il problema che hai avuto.

Per il resto è meglio passarsi i file sorgente così come sono, allegandoli nelle mail o in un archivio zip.

probabilmente sono meno bovini, ma alle statistiche il 90% di chi usa C non ci va tanto di finezze
(e si vede)

Appunto: noi NON siamo programmatori C.

[TheKaneB]

• 

Azz... il C andrebbe vietato per legge. Anch'io ci ho messo del tempo per disimparare certe brutte abitudini :\

[fulvio]

• 

Io pero' non sono d'accordo sul passarsi i file cosi' come sono, io sono per il machine duty, insegna alla macchina cosa vuoi che faccia per te, e poi ri-mettila ai suoi doveri, ed il primo dovere e' farti sgobbare il meno possibile!

e allora, una volta che hai fatto ingoiare un sorgente ed ottenuto il syntax-tree puoi fare l'operazione inversa a partire da indicazioni sul come farla!
qui puoi definire uno stile, uno tuo personale, come vuoi che venga indentato, dove vuoi che vengano messi i block-delimiter, e tanti altri dettagli estetici, etc, e la App di turno lo fa per te, sputando indietro un nuovo sorgente.

e' un po' che sto usando questo sistema, ed e' favoloso, piacevole sopratutto, puoi pastrocchiare quanto vuoi, sopratutto se hai poco tempo e vai giu' di copy & past selvaggio, di quelli che sballano non solo l'indentazione ma anche regole di safeC (tipo if () senza graffe al seguito), o pessime header-comments, o funzioni con troppi parametri sulla stessa linea, na roba che non si legge a meno di avere 200000 colonne, insomma pasticci fastidiosi da sistemare perche' di pura manovalanza, ecco in tutti questi casi e' piacevole infischiarsene perche' ci pensa la App a smacchiare tutto con risultati impeccabili!

Potresti dare un'occhiata a clang-format!

[fulvio]

• 

spe, forse l'avevo gia' visto, intendi questa feature ?
non ho ancora sbirciato come la faccia, mi ero annotato che la offre molto generosamente =P

Si, è un formatter con diverse opzioni che tiene conto di molte cose (del tipo se c'è una definizione di macro in mezzo ad una funzione e riformatti, la macro non viene toccata, oppure se hai particolari allineamenti nel codice se ne accorge e li preserva, etc.) In pratica usa il parser e l'AST di clang per raccogliere informazioni sul codice, c'è anche un video dove Chandler Carruth mostra la cosa al recente GoingNative2013 (http://channel9.msdn.com/Events/GoingNative/2013/The-Care-and-Feeding-of-C-s-Dragons, è tutto specifico per C++ ma magari ci tiri fuori qualche idea).

[cdimauro]

• 

Io pero' non sono d'accordo sul passarsi i file cosi' come sono, io sono per il machine duty, insegna alla macchina cosa vuoi che faccia per te, e poi ri-mettila ai suoi doveri, ed il primo dovere e' farti sgobbare il meno possibile!

e allora, una volta che hai fatto ingoiare un sorgente ed ottenuto il syntax-tree puoi fare l'operazione inversa a partire da indicazioni sul come farla!
qui puoi definire uno stile, uno tuo personale, come vuoi che venga indentato, dove vuoi che vengano messi i block-delimiter, e tanti altri dettagli estetici, etc, e la App di turno lo fa per te, sputando indietro un nuovo sorgente.

e' un po' che sto usando questo sistema, ed e' favoloso, piacevole sopratutto, puoi pastrocchiare quanto vuoi, sopratutto se hai poco tempo e vai giu' di copy & past selvaggio, di quelli che sballano non solo l'indentazione ma anche regole di safeC (tipo if () senza graffe al seguito), o pessime header-comments, o funzioni con troppi parametri sulla stessa linea, na roba che non si legge a meno di avere 200000 colonne, insomma pasticci fastidiosi da sistemare perche' di pura manovalanza, ecco in tutti questi casi e' piacevole infischiarsene perche' ci pensa la App a smacchiare tutto con risultati impeccabili!

Mai usato nulla in post-processing, per cui ciò che proponi mi sarebbe inutile. Un editor moderno oggi ti fa l'indentazione automatica quando premio invio per andare a capo, ti controlla la sintassi mentre scrivi e ti avvisa in tempo reale se hai commesso degli errori, in particolari per l'indentazione dei blocchi.
Al più ci sono alcuni editor che ti possono riformattare il sorgente quando lo salvi, ma non ho mai usato queste funzionalità perché il codice che scrivo è già ben formattato.

Quindi parlando di "real-life" non vedo il problema nell'usare l'indentazione per definire i blocchi. Già ai tempi del BASIC e del Pascal scrivevo codice ben strutturato, per cui l'unica differenza con Python è che adesso semplicemente non ho da scrivere in più parentesi graffe o begin/end. E il codice che viene fuori è pure più leggibile: sembra pseudocodice...

[Z80Fan]

• 

Beh ma se devi scrivere un parser per un tuo linguaggio fallo come vuoi, non devi per forza supportare tutti i metodi che si sono inventati per organizzare il codice...

[cdimauro]

• 

Quindi parlando di "real-life" non vedo il problema nell'usare l'indentazione per definire i blocchi

se usi nano, cosa che ti capita se fai il sistemista (o peggio vi/vim, tipico di debian e slackware), come la mettiamo ? a volte non hai nemmeno la banda rete (export DISPLAY X11 su tunnel SSH) ne ram, ne risorse  per invocare nedit o editor ancora migliore, figurarti eclipse, per cui dal mio punto di vista (e parliamo anche di micro robotica, o acquisitrici, o cnc, macchine che hanno interfacce testo misere), tu non hai che una console e un editor di testo grezzo e bovino (a volte VT100 su seriale) che col cavolo che ti indenta o fa qualsiasi cosa

e senza andare troppo lontano, prendi la stessa yun arduino, o router simili, se li usi PC-less (cosa che puoi fare perche' sono minicomputer) ti becchi python e codice C editato con nano!

non e' uno scenario ipotetico, e' uno scenario che a me capita spesso, infatti per una esigenza simile mi sono scritto un beautifier, scoprendo solo in seguito che, a fronte della stessa necessita', anche altri hanno fornito tool simil, per esempio dev-util/uncrustify (gentoo)

come vedi e' una esigenza che anche in Clang hanno sentito, altrimenti non l'avrebbero implementata!

Python for Unix and Linux System Administration
Python for system administrators
SysAdminPy

Allora come spieghi il fatto che Python si stia diffondendo così tanto proprio fra gli amministratori di sistema?

Già ai tempi del BASIC e del Pascal scrivevo codice ben strutturato, per cui l'unica differenza con Python è che adesso semplicemente non ho da scrivere in più parentesi graffe o begin/end. E il codice che viene fuori è pure più leggibile: sembra pseudocodice

col dovuto rispetto, per me non c'e' alcun valore aggiunto, quello che fai tu scrivendo bene il codice me lo fa in post coding il beautifier, e se il vantaggio e' solo questo, beh ... gli svantaggi tecnici per supportarlo, e pratici nell'usarlo, mostrano un rapporto PRO/CONTRO nettamente sfavorevole affinche' io lo prenda in cosiderazione.

Ma alla fine puoi implementarlo o meno, è un problema tuo e di come vuoi definire il tuo linguaggio.

Ciò non toglie che ci sono milioni di programmatori che usano proficuamente Python anche negli scenari di cui parlavi, o in generale che scrivono codice ben strutturato anche con altri linguaggi senza la maestrina che gli corregge il codice alla fine.

D'altra parte, come ti dicevo, il codice dev'essere ben strutturato già mentre lo si sta scrivendo, perché aiuta a comprendere meglio come funziona. Che me ne faccio di un codice ripulito e sistemato DOPO che ho sputato sangue per risolvere il mio problema?

[Z80Fan]

• 

eh, ma torna comodo se vuoi abusarne anche per altro
(tipo beautifier, ora ora e' utile per Verilog =P )

Tanto io programmo in VHDL.

Tra l'altro, l'altro ieri ho fatto un progettino veloce dove usavo un modulo FTDI per ricevere byte dalla USB e mandarli indietro aumentati di 1; una roba semplicissima ma molto simpatica una volta che cominciò a funzionare!

Magari quando faccio qualche altra cosuccia riapro un thread che si era perso nel grande crash.

[cdimauro]

• 

D'altra parte, come ti dicevo, il codice dev'essere ben strutturato già mentre lo si sta scrivendo, perché aiuta a comprendere meglio come funziona. Che me ne faccio di un codice ripulito e sistemato DOPO che ho sputato sangue per risolvere il mio problema?

non parliamo di gente che non sa mettere in fila due statement, per loro c'e' labview con i flow chart programming
esclusi loro, il codice o funziona o non funziona

se funziona e ritieni che sia impastrocchiato lo smacchi e torna utile sia a chi lo apre (sopratutto se sotto git-hub o similari)

se non funziona lo sistemi, ci pastrugni sopra e trovi la magagna. Per trovare la magagna puoi chiedere l'aiuto del pubblico, fare una telefonata a casa, e anche interpellare  la maestrina (che non bacchetta a caso ma per indicare possibili cose sbagliate fonti di problemi) o tool simili per avere indicazioni (tra cui la App Understand), e se ad un certo punto ti perdi nel troppo disordine che hai via via accumulato pastrugnando troppo ... fai una cosa molto semplice: chiudi l'editor, stacchi un attimo e chiedi al beautifier di ripulirlo, riapri, te lo trovi tutto bello smacchiato con i fiocchetti e l'alber magiche, e riparti alla ricerca della soluzione!

Con nedit puoi addirittura integrare tutto quanto a plug-in!



Tutto questo per dire, eccezion fatta per la App Understand (che si appoggia ad X11 ed e' pesante di suo, oltre che binaria x86 e ppc only) te la puoi ancora cavare con nano, vim, ed un paio di tools da console, ma con python su un router che fai ?

Usi joe come editor.

grazie alla bellissima feature di aver rimosso i blocks diventa bellissimo usare nano o Vim con uno script python lungo 1Km (tipo la roba gentoo, a cominciare da /usr/bin/emerge) dove se copy&past e scazzi un paio di indent poi a trovare la magagna ciao

stiamo parlando ancora di quello, ma pensa che solitamente la gente (anche quelli di EEVblog) preferisce uppare lo script python su PC, editarselo con l'editor potente, fixarlo, e rimandarlo indietro. Nulla da dire quando puoi farlo, e' quando non puoi farlo (non hai accesso alla rete, non hai un nei paragghi altro) che mi preoccupa.

In questi casi a lavoro usavamo il protocollo fish.

Comunque mi rendo conto delle difficoltà. Se sei abituato a incollare codice al volo sull'editor in remoto, è facile che incorri in questi problemi senza un editor in grado di gestire la situazione.

Ma in genere se hai un programmino abbastanza complesso da realizzare, lo scrivi in locale sulla tua macchina e poi lo invii a quella remota. Oppure, come succede spesso con Python, l'esigenza è quella di scrivere un po' di codice al volo senza nemmeno dover conservare il sorgente, perché magari hai qualcosa da sistemare e basta, e allora usi il terminale interattivo allo scopo (possibilmente con uno shell interattiva più avanzata, come bpython).

[cdimauro]

• 

Ad ogni modo per me è importante avere un delimitatore di fine blocco, soprattutto in cicli con if annidati è molto importante per non confondersi, infatti in Python piazzo sempre sotto forma di commenti un #END WHILE o #END IF

Può capitare con cicli o catene di if molto lunghe, ma in generale se non riesci a vedere per intero il corpo di un ciclo, vuol dire che il codice ha bisogno di una bella rifattorizzazione. Anzi, come regol(ett)a il concetto andrebbe applicato all'intera funzione.

[cdimauro]

• 

Per quanto l'idea di Python sia carina, il blocco ha carattere semantico e non sintattico, quindi deve essere trattato lato parser, il lexer non deve fornire alcuna informazione su ciò.

infatti, ho dovuto giocare sporco per "adattarmi" alla feature di python, e' stato giusto per vedere quanto e come si puo' supportare in modo da valutarne l'impatto e riconteggiare PRO e CONTRO.

Nel mio caso i CONTRO sono 4 byte in piu' per ogni lex,

Ma dai, 4 byte in più sono niente...

[cdimauro]

• 

Sì, ti capisco. Forse con Python sarebbero venute meno righe di codice.

Comunque non è solo Gentoo che usa Python. Ormai è diventato sostanzialmente un componente di sistema per qualunque distro Linux.