Topic: Pep8 discussione filosofica  (Letto 388 volte)

0 Utenti e 1 Visitatore stanno visualizzando questo topic.

Offline tommyb1992

  • python neanderthalensis
  • ****
  • Post: 295
  • Punti reputazione: 0
    • Mostra profilo
Pep8 discussione filosofica
« il: Aprile 06, 2018, 12:54 »
Ultimamente ho letto molti source code (anche recenti) di organizzazioni che possono essere considerate serie (es. OpenAI) e ho notato che la maggior parte se ne sbatte...

Di conseguenza, perchè uno dovrebbe rispettarlo?
Partendo dal fatto che esistono soluzioni che rendono il codice "più leggibile" che però non sono accettate dal pep8.

Per esempio, per me, questo:


è moooooooooooolto più leggibile di questo:


(si il codice è java ma in pyton io faccio la stessa cosa)
Cioè, è palese come sia incredibilmente più prestazionale a livello di riconoscimento la prima immagine rispetto alla seconda.

Di conseguenza, se per assodato, io so che una pratica è più comoda di un'altra perchè dovrei rispettare quella sbagliata, anche se utilizzata dalla community?

Offline jamba

  • python unicellularis
  • *
  • Post: 18
  • Punti reputazione: 0
    • Mostra profilo
Re:Pep8 discussione filosofica
« Risposta #1 il: Aprile 06, 2018, 14:26 »
Ultimamente ho letto molti source code (anche recenti) di organizzazioni che possono essere considerate serie (es. OpenAI) e ho notato che la maggior parte se ne sbatte...

Di conseguenza, perchè uno dovrebbe rispettarlo?
Partendo dal fatto che esistono soluzioni che rendono il codice "più leggibile" che però non sono accettate dal pep8.

Per esempio, per me, questo:


è moooooooooooolto più leggibile di questo:


(si il codice è java ma in pyton io faccio la stessa cosa)
Cioè, è palese come sia incredibilmente più prestazionale a livello di riconoscimento la prima immagine rispetto alla seconda.

Di conseguenza, se per assodato, io so che una pratica è più comoda di un'altra perchè dovrei rispettare quella sbagliata, anche se utilizzata dalla community?


da profano posso anche dire che forse il codice sia più leggibile ma non credo che così sia più velcoe da scrivere.
guardiamo il primo blocco: riesci a mantenere quell'alliniamento solo se sai a priori che STALE_SPECIES è formato da 13 caratteri. altrimenti di riformattare tutto il codice. non credo che sia comodo...

Offline tommyb1992

  • python neanderthalensis
  • ****
  • Post: 295
  • Punti reputazione: 0
    • Mostra profilo
Re:Pep8 discussione filosofica
« Risposta #2 il: Aprile 06, 2018, 14:37 »
La velocità di scrittura del codice può essere un parametro interessante, grazie per avermelo fatto considerare.

Però per quanto riguarda il pep8, credo che nasca dall'esigenza di rendere "leggibile" il codice comune creando uno standard comune.

Ho trovato anche questo googlando "pep8 is stupid" (ricerche fatte senza pregiudizio XD):
Citazione
PEP8 is stupid and people using spaces in code are dumb. Wastes file size and make it impossible for me to customize my tabstops. #python

E trovo interessante anche questo, nonostante io utilizzi gli spazi in generale con qualsiasi linguaggio, trovo la sua obiezione fatta in maniera non garbata avere un senso.
Vero che lo spazio dei caratteri è una sottigliezza... però è anche vero che pure il pep8 si attacca a tante sottigliezze.
« Ultima modifica: Aprile 06, 2018, 14:50 da tommyb1992 »

Offline jamba

  • python unicellularis
  • *
  • Post: 18
  • Punti reputazione: 0
    • Mostra profilo
Re:Pep8 discussione filosofica
« Risposta #3 il: Aprile 06, 2018, 15:07 »
Vero che lo spazio dei caratteri è una sottigliezza... però è anche vero che pure il pep8 si attacca a tante sottigliezze.
pep8 sono una serie di regole create da una persona, e come tali opinabili. l'obbiettivo è quello di rendere il codice "standard".

Offline tommyb1992

  • python neanderthalensis
  • ****
  • Post: 295
  • Punti reputazione: 0
    • Mostra profilo
Re:Pep8 discussione filosofica
« Risposta #4 il: Aprile 06, 2018, 15:19 »
E infatti qui entra il titolo del topic riguardante il filosofico.

Ha senso rispettare una regola solo in quanto regola anche se possibilmente sbagliata?

Offline riko

  • python deus
  • *
  • moderatore
  • Post: 7.447
  • Punti reputazione: 12
    • Mostra profilo
    • RiK0 Tech Temple
Re:Pep8 discussione filosofica
« Risposta #5 il: Aprile 07, 2018, 12:22 »
Ha senso rispettare una regola solo in quanto regola anche se possibilmente sbagliata?

Si. Non importa quale sia lo standard (a patto che sia vagamente ragionevole), importa che ci sia uno standard e che sia standard.
Per esempio quelli di go hanno fatto un passo oltre: la "loro pep8" e' codificata da un tool e nessuno ti prendera' una cr se non hai fatto passare il tuo codice per gofmt.
L'effetto? Leggere codice go di un progetto completamente random e' *semplicissimo*, perche' tutti usano le stesse convenzioni. Tutti.  Il che vuole dire che dopo poco ti abitui, al tuo cervello viene naturale e si semplifica la vita a tutta la community. E nota che non e' che "piacciono a tutti". E' che la gente ha abbastanza esperienza da riconoscere l'immenso valore di uno standard comune.

L'estremo opposto sono community dove *ogni progetto* ha, se va bene, le sue convenzioni. Che porta un monte di problemi:
1. non hai il colpo d'occhio (se non dopo un bel po' di tempo che stai lavorando su quel progetto)
2. avere dipendenze multiple (che e' inevitabile) vuole dire molto probabilmente avere tracce di standard diversi nella stessa code base, con l'inevitabile effetto arlecchino (e il costante dubbio se in quello specifico punto sia meglio seguire una o l'altra convenzione)
3. ogni volta che contribuisci devi imparare lo standard, o configurarti i tool per rispettarlo (e ricordarti di usare quelli giusti) oppure ricordarsi di farlo a mano, poi avere la pull request rifiutata perche' si e' cazzato qualche dettaglio.

Il tempo che si perde a fare questa cosa non vale i benefici di uno standard piuttosto che un altro.

Ah, poi ci sono anche i progetti "senza convenzioni" di tipo (A) e di tipo (B). Quelli di tipo (A) sono quelli che in realta' hanno convenzioni, ma non sono scritte. Bisogna percepirle leggendo il codice del ras del progetto. E poi quelli di tipo (B) dove ognuno fa quello che gli pare. Di solito questo e' un buon segno per stare lontano dal progetto: amateurs at work.

> Ultimamente ho letto molti source code (anche recenti) di organizzazioni che possono essere considerate serie (es. OpenAI) e ho notato che la maggior parte se ne sbatte...

Non so cosa intendi come organizzazione seria o non seria. Posso dirti che ci sono progetti molto usati (in ogni linguaggio) in cui e' meglio *non* aprire la codebase per quanto fa schifo. Capita. Ci vuole un po' di spirito critico.

In particolare molto di quello che e' accademico tende ad avere poor code quality per vari motivi (culturali, ego, detachment dal mondo reale, non abbiamo mai messo in produzione niente).

> Partendo dal fatto che esistono soluzioni che rendono il codice "più leggibile" che però non sono accettate dal pep8.

Opinabile. Per qualcuno con poca esperienza di Python forse sono piu' leggibili. Per qualcuno che deve saltare di progetto in progetto (e lo fa da 15 anni) la pep8 e' una manna e non si ha un ottima opinione dei progetti che "non sono manco capaci di rispettare la pep8". E nota, questo prescinde completamente dal fatto che la pep8 sia o non sia lo standard migliore possibile.

Sono decenni che si litiga su quale sia lo standard migliore: ormai e' chiaro che non frega nulla a nessuno (se hai visto un po' di acqua passare sotto i ponti, i ragazzetti si infiammano da sempre per tutto e su tutto). Ci sono poche cose oggettive, un altro numero di cose oggettive ma che dipendono da come lavori e poi il resto e' la completa irrilevanza. Il valore di fare tutti la stessa cosa si mangia completamente tutto il resto.

Quando possibile, questa cosa poi viene automatizzata perche' non ci voglio nemmeno pensare. Il modo in cui il codice e' indentato (salvo che per motivi di controllo di flusso) e' qualcosa che i tool possono gestire per me. Non mi cambia davvero.

Offline riko

  • python deus
  • *
  • moderatore
  • Post: 7.447
  • Punti reputazione: 12
    • Mostra profilo
    • RiK0 Tech Temple
Re:Pep8 discussione filosofica
« Risposta #6 il: Aprile 07, 2018, 12:31 »
E trovo interessante anche questo, nonostante io utilizzi gli spazi in generale con qualsiasi linguaggio, trovo la sua obiezione fatta in maniera non garbata avere un senso.

Questa e' la classica diatriba che va avanti da sempre. E prova a pensare... ma *davvero* ha senso?
Lo *spazio*? Cioe' ho un laptop con l'hard disk di default che saranno 500 GB e mi parla dello spazio risparmiato per via di 3 bytes? Mi sta facendo perdere tempo.
Non puo' customizzare cosa? Forse non e' capace. Ma di sta roba se ne e' parlato alla nausea. Generalmente la gente piu' senior tende ad essere dalla parte degli spazi... io personalmente sono pro-spazio (troppe cose brutte con i tab). Ma alla fine non e' che cambia tantissimo.

Offline tommyb1992

  • python neanderthalensis
  • ****
  • Post: 295
  • Punti reputazione: 0
    • Mostra profilo
Re:Pep8 discussione filosofica
« Risposta #7 il: Aprile 07, 2018, 17:51 »
Mi piacciono molto alcune tue opinioni e devo ammettere di aver parzialmente cambiato opinione, le argomentazioni riguardo alla mia domanda sono molto valide.

Citazione
Non so cosa intendi come organizzazione seria o non seria. Posso dirti che ci sono progetti molto usati (in ogni linguaggio) in cui e' meglio *non* aprire la codebase per quanto fa schifo. Capita. Ci vuole un po' di spirito critico.

Beh OpenAI ("di" elon musk) mi sembra un progetto serio a livello mondiale per quanto riguarda lo sviluppo delle intelligenze artificiali.

Citazione
Quelli di tipo (A) sono quelli che in realta' hanno convenzioni, ma non sono scritte
No ma non metto in dubbio che ne abbiano, solo che non è PEP8.

Il mio discorso non è Standard si, standard no, il mio discorso è: pep8 si pep8 no.
Della serie che se "importanti organizzazioni a livello mondiale" scelgono di non adottarlo evidentemente non sono l'unico che si pone il problema.

Posso concordare su molti aspetti che hai esplicato ma secondo me pecca di un paio di cose.
Continuo ad avere dubbi perchè anche se una cosa può essere ottima, non vuol dire che non si possa migliorare e ritengo che uno standard se vogliamo utilizzarlo per migliorare la vita veramente a tutti debba basarsi su dei dati che non siano empirici.
Si fanno i test, dati alla mano (quali stilemi sono più immediati, meno stancanti per l'occhio umano e permettono una lettura a livello di stratificazione senza uscire fuori di testa) e non solo creiamo uno standard, ma creiamo uno standard che sta a un livello superiore, oltre a poter applicare le basi a (quasi) qualsiasi linguaggio.

Ovvio per questa cosa servono soldi e tempo, però ipotizzando di avere i fondi secondo me ha senso.

Offline RicPol

  • python sapiens sapiens
  • ******
  • Post: 2.844
  • Punti reputazione: 9
    • Mostra profilo
Re:Pep8 discussione filosofica
« Risposta #8 il: Aprile 07, 2018, 19:52 »
Non hai proprio chiaro il senso del discorso di Riko, mi sa.

> Della serie che se "importanti organizzazioni a livello mondiale" scelgono di non adottarlo evidentemente non sono l'unico che si pone il problema.

Sì. Bene. E quindi? Se Elon Musk vuole farsi la sua "pep8musk", buon per lui. Se non ha problemi ad attrarre sviluppatori, interessi, etc. con una codebase non-pep8, ed evidentemente non pare avere problemi, ri-buon per lui.
Se in futuro la "pep8musk" facesse proseliti fino a imporsi come nuovo standard per il codice Python, ri-ri-buon per lui.
Il problema non è "che cosa fa Elon Musk". Il problema è "che cosa vuoi fare tu". Se pensi che tu (tu! tu! non Elon Musk. Tu) otterresti più attenzione per il tuo codice, supereresti meglio colloqui di lavoro, code review, e quant'altro seguendo la "pep8musk" (o un'altra qualsiasi che vuoi seguire o anche inventarti da zero), buon per te. Se pensi che la "pep8musk" (o un'altra qualunque, o una che ti inventi tu di sana pianta) sia così tanto meglio, al punto che vuoi rischiare quello che c'è da rischiare ma assolutamente vuoi scrivere codice in quel modo, ri-buon per te. Prima o poi ti passerà, suppongo.

> Continuo ad avere dubbi perchè anche se una cosa può essere ottima, non vuol dire che non si possa migliorare

Continui a non capire che cos'è uno standard, soprattutto lo standard di una code guide. Il drive di uno standard non è un costante miglioramento, è restare *stabile*. Certo che periodicamente anche gli standard vengono ritoccati, ci mancherebbe: anche la pep8 è stata cambiata nel tempo (magari non lo sapevi: buone notizie, vedi). Ma ci devono essere ragioni molto valide per modificare uno standard. Non modificheresti una API ogni due settimane così a muzzo, vero? Ecco, una code guide deve restare ancora più stabile di una API, se vuole servire a qualcosa.

> Si fanno i test, dati alla mano (quali stilemi sono più immediati, meno stancanti per l'occhio umano e permettono una lettura a livello di stratificazione senza uscire fuori di testa) e non solo creiamo uno standard, ma creiamo uno standard che sta a un livello superiore, oltre a poter applicare le basi a (quasi) qualsiasi linguaggio.

Ma per carità. A parte che sembrano discorsi del tipo "non sarebbe bello se tutti si facessero più furbi e parlassimo solo Esperanto?", ma poi, concretamente: chi te lo fa fare? "Dati alla mano"... ok, e sotto con la mega-commissione internazionale di cervelloni per capire quali dati, e raccolti con che criterio, etc. Boh?

> Ovvio per questa cosa servono soldi e tempo

Proprio così. Ovvio. Vedi che ti sei risposto da solo, alla fine. E aggiungo: chi ha soldi e tempo in genere preferisce investirli a scrivere codice (seguendo la pep8, perché no).
Però, intendiamoci: puoi sempre cominciare a investire il *tuo* di tempo e i *tuoi* di soldi. Comincia a studiarci sopra, fatti avanti, proponi cambiamenti e miglioramenti. La Pep8 è solo una pep, come tutte le altre: sono previsti passaggi di discussione per modificarla. Puoi cominciare a postare delle proposte su python-dev, e se sono effettivamente migliorative della condizione attuale non credo che troverai difficoltà a fartele accettare.

Offline riko

  • python deus
  • *
  • moderatore
  • Post: 7.447
  • Punti reputazione: 12
    • Mostra profilo
    • RiK0 Tech Temple
Re:Pep8 discussione filosofica
« Risposta #9 il: Aprile 07, 2018, 20:57 »
Beh OpenAI ("di" elon musk) mi sembra un progetto serio a livello mondiale per quanto riguarda lo sviluppo delle intelligenze artificiali.

Secondo me non ti e' chiaro cosa vuole dire lavorare in scala. Fermo tutto e prendo software engineer per rimettere a posto la code base oppure assumo qualche software engineer e qualche AI engineer per migliorare gli algoritmi?
Nessuna organizzazione e nessun progetto ha fondi illimitati e ogni progetto e' un isola. A volte un tipo ha scritto il core in poco tempo perche' gli serviva, senza preoccuparsi degli standard. A volte lo fa. A volte ha piu' tempo. A volte si consolida il core, altre volte ci si butta su nuove features. A volte hai un progetto iniziato da esperti di dominio che non sanno molto di software engineering.  A volte magari sono programmatori esperti ma che vengono da altri linguaggi, conoscono poco l'ecosistema di destinazione e semplicemente non lo approfondiscono e invece usano le convenzioni che sono tipiche di altro.
A volte si fanno scelte sbagliate che sono troppo costose da correggere.

Citazione
Citazione
Quelli di tipo (A) sono quelli che in realta' hanno convenzioni, ma non sono scritte
No ma non metto in dubbio che ne abbiano, solo che non è PEP8.

Secondo me ti stai confondendo: non sto parlando di OpenAI. Sto parlando di progetti nelle condizioni descritte.

> Il mio discorso non è Standard si, standard no, il mio discorso è: pep8 si pep8 no.

> Della serie che se "importanti organizzazioni a livello mondiale" scelgono di non adottarlo evidentemente non sono l'unico che si pone il problema.

Sbagli a pensare che sia sempre una scelta. E sbagli a pensare che se alcuni l'hanno fatta sia una buona idea.  Anzi, in generale se anche e' una scelta, molto probabilmente la scelta non e' stata fra seguire lo standard che seguono tutti e non seguirlo. Perche' e' una scelta *sbagliata*. E' molto piu' probabile che qualcuno sul progetto da subito non avesse buona conoscenza delle best practice del linguaggio (mica e' una cosa che succede solo in Python). A volte ha un'opinione molto forte su quello che piace *a lui*. Ma spesso semplicemente uno si mette a scrivere il codice e fine. Qualcuno tira insieme una cosa per fare vedere che si puo' fare o perche' gli serve e poi si va avanti.
Posso concordare su molti aspetti che hai esplicato ma secondo me pecca di un paio di cose.

Citazione
Continuo ad avere dubbi perchè anche se una cosa può essere ottima, non vuol dire che non si possa migliorare e ritengo che uno standard se vogliamo utilizzarlo per migliorare la vita veramente a tutti debba basarsi su dei dati che non siano empirici.
Si fanno i test, dati alla mano (quali stilemi sono più immediati, meno stancanti per l'occhio umano e permettono una lettura a livello di stratificazione senza uscire fuori di testa) e non solo creiamo uno standard, ma creiamo uno standard che sta a un livello superiore, oltre a poter applicare le basi a (quasi) qualsiasi linguaggio.

Sono pu**anate. Il costo di una roba del genere non vale i benefici. Non ci sono problemi pratici *fintanto che tutti si fa la stessa cosa*. Il problema e' non fare la stessa cosa. Fare una cosa o un altra, nel limite del ragionevole, non cambia *nulla*. Ci sono cose che sappiamo sono cattive idee e fine. Fra il resto, fine. Sono 50 anni che si programma "in roba che assomiglia al C". E sono 50 anni che non emerge uno stile dominante. Spesso gli stili che si diffondono in un linguaggio simile ma separato (che so... Java) vengono dalle preferenze specifiche di chi comincia a fare la libreria standard. Che e' un tizio probabilmente esperto cui piace il codice fatto cosi'. O magari e' che ci sono dei tool che usa con cui funziona bene cosi'. Perche' le convenzioni piu' diffuse in C++ e in Java sono diverse? Quante di quelle C++ ci sono? La STL usa uno stile molto diverso da, per intenderci, Qt. Su tante cose, non solo di formattazione. E pensa a tutto il C++ di gente che viene dal mondo Borland. Quelle sono convenzioni che arrivano in parte da essere su Windows e in parte da Pascal (su Windows). Fai te.

Citazione
Ovvio per questa cosa servono soldi e tempo, però ipotizzando di avere i fondi secondo me ha senso.

I fondi non sono mai illimitati: bisogna sempre capire quale e' il miglior modo di spenderli. E non puoi tirare persone ad un problema di sviluppo: la comunicazione e il management diventano un costo proibitivo e la qualita' finisce per scendere.

Offline tommyb1992

  • python neanderthalensis
  • ****
  • Post: 295
  • Punti reputazione: 0
    • Mostra profilo
Re:Pep8 discussione filosofica
« Risposta #10 il: Aprile 10, 2018, 14:51 »
Citazione
Sono pu**anate. Il costo di una roba del genere non vale i benefici. Non ci sono problemi pratici *fintanto che tutti si fa la stessa cosa*. Il problema e' non fare la stessa cosa. Fare una cosa o un altra, nel limite del ragionevole, non cambia *nulla*. Ci sono cose che sappiamo sono cattive idee e fine. Fra il resto, fine. Sono 50 anni che si programma "in roba che assomiglia al C". E sono 50 anni che non emerge uno stile dominante. Spesso gli stili che si diffondono in un linguaggio simile ma separato (che so... Java) vengono dalle preferenze specifiche di chi comincia a fare la libreria standard. Che e' un tizio probabilmente esperto cui piace il codice fatto cosi'. O magari e' che ci sono dei tool che usa con cui funziona bene cosi'. Perche' le convenzioni piu' diffuse in C++ e in Java sono diverse? Quante di quelle C++ ci sono? La STL usa uno stile molto diverso da, per intenderci, Qt. Su tante cose, non solo di formattazione. E pensa a tutto il C++ di gente che viene dal mondo Borland. Quelle sono convenzioni che arrivano in parte da essere su Windows e in parte da Pascal (su Windows). Fai te.
Forse mi sono spiegato male, intendo dire che servirebbe proprio un "ente a se stante" che crea lo standard in maniera analitica (testa alla mano, si monitorano X soggetti e si trova matematicamente quello che funziona meglio e poi si riadatta per tutti i linguaggi).

Mi sembra più saggio che creare uno standard senza una base scientifica e non mi risulta che il pep8 lo sia.

Citazione
Nessuna organizzazione e nessun progetto ha fondi illimitati e ogni progetto e' un isola. A volte un tipo ha scritto il core in poco tempo perche' gli serviva, senza preoccuparsi degli standard. A volte lo fa. A volte ha piu' tempo. A volte si consolida il core, altre volte ci si butta su nuove features. A volte hai un progetto iniziato da esperti di dominio che non sanno molto di software engineering.  A volte magari sono programmatori esperti ma che vengono da altri linguaggi, conoscono poco l'ecosistema di destinazione e semplicemente non lo approfondiscono e invece usano le convenzioni che sono tipiche di altro.
A volte si fanno scelte sbagliate che sono troppo costose da correggere.

Secondo me non ti e' chiaro cosa vuole dire lavorare in scala. Fermo tutto e prendo software engineer per rimettere a posto la code base oppure assumo qualche software engineer e qualche AI engineer per migliorare gli algoritmi?
Nessuna organizzazione e nessun progetto ha fondi illimitati e ogni progetto e' un isola. A volte un tipo ha scritto il core in poco tempo perche' gli serviva, senza preoccuparsi degli standard. A volte lo fa. A volte ha piu' tempo. A volte si consolida il core, altre volte ci si butta su nuove features. A volte hai un progetto iniziato da esperti di dominio che non sanno molto di software engineering.  A volte magari sono programmatori esperti ma che vengono da altri linguaggi, conoscono poco l'ecosistema di destinazione e semplicemente non lo approfondiscono e invece usano le convenzioni che sono tipiche di altro.
A volte si fanno scelte sbagliate che sono troppo costose da correggere.


E sono d'accordo. CI possono essere X motivi per cui non si utilizza lo standard di pep8. Però fra tutti questi motivi, ammetti che alcune società decido volontariamente di non adottarlo e io non credo che TUTTE siano nel torto.

Offline RicPol

  • python sapiens sapiens
  • ******
  • Post: 2.844
  • Punti reputazione: 9
    • Mostra profilo
Re:Pep8 discussione filosofica
« Risposta #11 il: Aprile 10, 2018, 22:01 »
> Mi sembra più saggio

Ecco, direi che puoi fermarti qui a riflettere un po'.
Visto che questa sarebbe una "discussione filosofica" (yawn... e poi ti dico perché), ti propongo un esercizio filosofico che in genere funziona sempre per le discussioni filosofiche.
Prova a farti una domanda: perché nessuno lo ha ancora fatto, quello che a te sembra così ovvio, saggio, giusto, naturale? Sono tutti stupidi, là fuori?
Invece di continuare a ripetere (e ripetere... e ripetere) le *tue* motivazioni, adesso fai l'esercizio filosofico di esprimere le motivazioni degli altri. Senza cadere in una variante di "sono tutti stupidi / sono tutti pigri / sono miopi / sono cattivi nel cuore".
Provaci. Vedrai che è un'esperienza illuminante.


Altra considerazione a margine delle "discussioni filosofiche". La natura delle discussioni filosofiche è tale per cui si può andare avanti all'infinito. E come ci si diverte, ad andare avanti all'infinito. A spaccare il capello in quattrocento. Ad argomentare e controargomentare ed esemplificare e dedurre e raccontare aneddoti e casi di studio e bla, e bla, e bla, e bla, e bla, e bla, e bla, e bla bla bla bla bla bla


finché


finché un guastafeste qualsiasi (sorry) non dice:

scusa, ma me lo faresti un esempio concreto? Un solo esempio? Chiaro, definito, preciso?
Dimmi una cosa precisa che si trova attualmente nella pep8 e che non ti piace, e dimmi come la cambieresti. Una cosa, una sola cosa, una cosa soltanto. Ma concreta. Dimmi i vantaggi concreti che avrebbe la tua variante concreta al posto della regola attuale.
Vedrai che se ci provi, è un'altra esperienza illuminante.

Offline riko

  • python deus
  • *
  • moderatore
  • Post: 7.447
  • Punti reputazione: 12
    • Mostra profilo
    • RiK0 Tech Temple
Re:Pep8 discussione filosofica
« Risposta #12 il: Aprile 10, 2018, 22:26 »
Citazione
Sono pu**anate. Il costo di una roba del genere non vale i benefici. Non ci sono problemi pratici *fintanto che tutti si fa la stessa cosa*. Il problema e' non fare la stessa cosa. Fare una cosa o un altra, nel limite del ragionevole, non cambia *nulla*. Ci sono cose che sappiamo sono cattive idee e fine. Fra il resto, fine. Sono 50 anni che si programma "in roba che assomiglia al C". E sono 50 anni che non emerge uno stile dominante. Spesso gli stili che si diffondono in un linguaggio simile ma separato (che so... Java) vengono dalle preferenze specifiche di chi comincia a fare la libreria standard. Che e' un tizio probabilmente esperto cui piace il codice fatto cosi'. O magari e' che ci sono dei tool che usa con cui funziona bene cosi'. Perche' le convenzioni piu' diffuse in C++ e in Java sono diverse? Quante di quelle C++ ci sono? La STL usa uno stile molto diverso da, per intenderci, Qt. Su tante cose, non solo di formattazione. E pensa a tutto il C++ di gente che viene dal mondo Borland. Quelle sono convenzioni che arrivano in parte da essere su Windows e in parte da Pascal (su Windows). Fai te.
Forse mi sono spiegato male, intendo dire che servirebbe proprio un "ente a se stante" che crea lo standard in maniera analitica (testa alla mano, si monitorano X soggetti e si trova matematicamente quello che funziona meglio e poi si riadatta per tutti i linguaggi).

Mi sembra più saggio che creare uno standard senza una base scientifica e non mi risulta che il pep8 lo sia.

No, non e' che ti sei spiegato male: ti sei spiegato benissimo. Il problema e' che non hai fatto la fatica di leggermi. Te lo rispiego: e' essenzialmente irrilevante. Sappiamo che con un briciolo di buon senso uno standard vale l'altro. Non vale la pena di spendere danaro per scoprire quale sia "leggermente migliore di quell'altro". I corpi che fanno standard *costano*. Fare standard e' *costoso*. Se non hai nessun beneficio pratico rilevante e' inutile spendere soldi.

Tra l'altro cosa vuoi fare International Standardization Committee for Formatting C And Languages That Look Like C? Ma perche' non fare il anche il comitato per la lunghezza della punta delle matite (ora, tristemente, e' capace anche che qualcuno abbia convinto qualcun altro a pagare per questa cosa, ma non la rende una buona idea)?

Citazione
E sono d'accordo. CI possono essere X motivi per cui non si utilizza lo standard di pep8. Però fra tutti questi motivi, ammetti che alcune società decido volontariamente di non adottarlo e io non credo che TUTTE siano nel torto.

Guarda, ti ripeto tutto ancora una volta: questa questione che ti sei preso a cuore non frega davvero un ca**o a nessuno. La sua principale utilita' e' giustificare raid punitivi nei covi dei programmatori avversari quando non si trova nessuno che ha torto sull'internet (per questioni piu' rilevanti). La varieta' di ragioni per chi non segue la PEP8 e' davvero ampia. E in generale una volta che qualcuno fa sta cosa (o semplicemente dopo un po' che nessuno fa nulla per i coding standard e si ha imparato a vivere nel bailamme) diventa poi troppo costoso

Per il resto commetti fallacie logiche.

https://yourlogicalfallacyis.com/appeal-to-authority
https://yourlogicalfallacyis.com/black-or-white
https://yourlogicalfallacyis.com/false-cause
https://yourlogicalfallacyis.com/personal-incredulity

Offline tommyb1992

  • python neanderthalensis
  • ****
  • Post: 295
  • Punti reputazione: 0
    • Mostra profilo
Re:Pep8 discussione filosofica
« Risposta #13 il: Aprile 15, 2018, 07:30 »
Citazione
No, non e' che ti sei spiegato male: ti sei spiegato benissimo. Il problema e' che non hai fatto la fatica di leggermi. Te lo rispiego: e' essenzialmente irrilevante. Sappiamo che con un briciolo di buon senso uno standard vale l'altro. Non vale la pena di spendere danaro per scoprire quale sia "leggermente migliore di quell'altro". I corpi che fanno standard *costano*. Fare standard e' *costoso*. Se non hai nessun beneficio pratico rilevante e' inutile spendere soldi.

Non mi permetterei mai di non leggere per intero una risposta a una mia domanda.
Posso non aver capito nel precedente messaggio, ma perchè sono un fallibilissimo umano.

Comunque ok, questa è la tua opinione,  io non posso darti una risposta perchè onestamente sono giorni che mi capita di riprensarci ogni tanto e ancora non ho formato una idea critica in merito.

Citazione
Tra l'altro cosa vuoi fare International Standardization Committee for Formatting C And Languages That Look Like C? Ma perche' non fare il anche il comitato per la lunghezza della punta delle matite (ora, tristemente, e' capace anche che qualcuno abbia convinto qualcun altro a pagare per questa cosa, ma non la rende una buona idea)?

E come lo chiami poi il sito web? www.standardizationcommitteeforformattingcandlanguagesthatlooklikec.com mi sembra un pò lungo ma nel dubbio che qualcuno lo rubi potremmo comprare il dominio preventivamente.

Citazione
Guarda, ti ripeto tutto ancora una volta: questa questione che ti sei preso a cuore non frega davvero un ca**o a nessuno. La sua principale utilita' e' giustificare raid punitivi nei covi dei programmatori avversari quando non si trova nessuno che ha torto sull'internet (per questioni piu' rilevanti). La varieta' di ragioni per chi non segue la PEP8 e' davvero ampia. E in generale una volta che qualcuno fa sta cosa (o semplicemente dopo un po' che nessuno fa nulla per i coding standard e si ha imparato a vivere nel bailamme) diventa poi troppo costoso

Per il resto commetti fallacie logiche.

Onestamente non è che non ci dormo la notte se la gente utilizza o non utilizza uno standard. La mia era la curiosità di uno che utilizza la programmazione per semplificarsi la vita lavorativa.
Oltretutto dirmi che ho un pensiero dicotomico lo trovo piuttosto lol visto che ho dimostrato più volte che sono pronto anche a modificare idee riguardo a qualcosa se mi vengono portate le giuste argomentazioni.

Offline riko

  • python deus
  • *
  • moderatore
  • Post: 7.447
  • Punti reputazione: 12
    • Mostra profilo
    • RiK0 Tech Temple
Re:Pep8 discussione filosofica
« Risposta #14 il: Aprile 15, 2018, 12:34 »
> Non mi permetterei mai di non leggere per intero una risposta a una mia domanda.
> Posso non aver capito nel precedente messaggio, ma perchè sono un fallibilissimo umano.

Ok, fair enough.

> Comunque ok, questa è la tua opinione,  io non posso darti una risposta perchè onestamente sono giorni che mi capita di riprensarci ogni tanto e ancora non ho formato una idea critica in merito.

No, non e' una mia "opinione". Quello che ti sto dicendo e' che quello che ho visto e' che essenzialmente i vantaggi "intrinseci" di uno standard (e' meglio mettere le parentesi graffe aperte sulla linea della dichiarazione oppure a capo?) sono trascurabili: i problemi ci sono quando non c'e' uno standard. Evidenza ulteriore di questo fatto e' che in 50 anni su tanti dettagli non si e' raggiunta una conclusione univoca. In 50 anni in cui ognuno difende il suo punto di vista, non si e' raggiunta una conclusione univoca. Uno dei motivi e' che davvero nessuno e' riuscito a misurare un impatto negativo dovuto dall'avere standardizzato in un modo piuttosto che in un altro.

I vantaggi di avere un unico standard all'interno di una piattaforma (gofmt in go, PEP8 in Python) sono pure evidenti. Non sono "opinioni". E' oggettivo che se tutte le librerie che usi hanno lo stesso standard le seguenti sono vere (e sono vere, se vuoi "by definition", perche' si basano sul fatto che essere familiare con qualcosa semplifica lavorarci e che se c'e' una sola opzione non e' necessario prendere una decisione perche' la questione non si pone):
1. e' ovvio quale standard seguire nel codice che chiama le librerie (ovvero il "tuo" codice)
2. si e' gia' abituati a leggere il codice in quel modo e quindi e' piu' facile approcciare un pezzo di codice random (che seguira' le stesse convenzioni)
3. e' meno costoso abituarsi alle convenzioni quando si sottomettono patch a codebase esistenti

Citazione
Onestamente non è che non ci dormo la notte se la gente utilizza o non utilizza uno standard. La mia era la curiosità di uno che utilizza la programmazione per semplificarsi la vita lavorativa.

E quello che ti dico e' come stanno le cose. Credo che se escludi i fanatici hardcore di uno stile piuttosto che un altro (i quali ovviamente difenderanno a spada tratta il loro stile verso gli altri), grosso modo tutti quanti saranno d'accordo che avere un qualche standard e' una buona cosa e che quanto piu' questo standard e' usato e' pure una buona cosa. Nota che anche gli altri sono d'accordo su questo punto: semplicemente in aggiunta "il loro standard e' meglio di tutti gli altri". Poi cerca di monetizzare i benefici.

Questa cosa e' piuttosto facile per i casi che menziono, mentre se entri dentro le specifiche rule diventa fumoso. Per esempio: se devo fare una patch per un baco e' chiaro che se non devo spendere tempo per imparare lo standard seguito in quel progetto (perche' lo conosco gia') spendo meno tempo. Specificamente non spendo il tempo necessario per studiare lo standard (che sono alcune pagine) o per configurare il mio ambiente per usare quello standard. Meno misurabile e' il costo necessario per *leggere* il codice altrui. Ma credo che se ripensi alla tua esperienza, ti verranno in mente casi in cui hai capito una cosa male perche' ti aspettassi forsse qualcosa invece che qualcos'altro. Piu' leggi codice altrui e piu' e' facile. Ma insomma, e' comodo sapere che a = SomeObject() molto probabilmente sta creando un'istanza di SomeObject mentre a = do_something() probabilmente sta invocando del codice che "fa qualcosa" e che ti ritorna un risultato (che non e' di tipo "fa qualcosa"). Ovviamente se inverti le convenzioni, funziona tutto. Le costanti magari teniamole distinte, perche' sappiamo che "ALL_CAPITALS" e' piu' faticoso da leggere e quindi vogliamo relativamente poche cose che seguono quella convenzione (e specialmente non vogliamo catene di metodi ALL_CAPITALS.DO_ANOTHER_ALL_CAPITALS...).

Citazione
Oltretutto dirmi che ho un pensiero dicotomico lo trovo piuttosto lol visto che ho dimostrato più volte che sono pronto anche a modificare idee riguardo a qualcosa se mi vengono portate le giuste argomentazioni.

Non ho detto che hai un pensiero dicotomico (altra fallacia logica: stai mal rappresentando il mio pensiero per "attaccarlo"). Io sto solo dicendo che il tuo ragionamento conteneva fallacie logiche, e ti ho detto quali. E non ti ho detto quale parte del pensiero riguardano poiche' mi pareva ovvio da quello che ho scritto. Se non lo e' posso essere piu' preciso.