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.
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 blocchimi 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!
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-etcle vere cose che fanno la differenza!
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 deliriorisultato ? 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 ?
probabilmente sono meno bovini, ma alle statistiche il 90% di chi usa C non ci va tanto di finezze(e si vede)
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!
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
Citazione da: cdimauro - 25 ſettembre 2013, 19:24:40Quindi parlando di "real-life" non vedo il problema nell'usare l'indentazione per definire i blocchise 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 cosae 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!
Quindi parlando di "real-life" non vedo il problema nell'usare l'indentazione per definire i blocchi
Citazione da: cdimauro - 25 ſettembre 2013, 19:24:40Già 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 pseudocodicecol 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.
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
eh, ma torna comodo se vuoi abusarne anche per altro (tipo beautifier, ora ora e' utile per Verilog =P )
Citazione da: cdimauro - 25 ſettembre 2013, 20:37:58D'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 programmingesclusi loro, il codice o funziona o non funzionase 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 ?
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?
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 ciaostiamo 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.
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
Citazione da: dsar - 26 ſettembre 2013, 09:49:02Per 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,
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ò.